Redistributing Customer Routes into BGP

I'm often promoting the idea of separating customer routing from core routing in the design articles I write. The only viable solution (unless you want to implement MPLS VPN and migrate customer routing into VPNv4) is to carry customer routes in BGP, redistributing them into BGP from other routing sources. On the other hand, I’m telling you that you should advertise only static IP prefixes into the public Internet. Obviously there’s a seeming disconnect between the two advices.

However, the dilemma is easily solved with the no-export BGP community that prevents an IP prefix from being advertised over EBGP sessions. Whenever you redistribute customer routes into BGP, you should attach the no-export community to them, ensuring that only the statically advertised IP prefixes will be propagated outside of your AS boundaries.

Important: for this design to work, you have to configure BGP community propagation with the neighbor send-community router configuration command on all IBGP sessions in your network, preferably with a peer template. Otherwise, the BGP communities will be lost on IBGP updates and the IP prefixes will leak to your EBGP neighbors.

For example, if you use static routing with your customers and want to redistribute the static routes into BGP, use the following configuration (I’ve used tag 123 to tag static routes that should get inserted into BGP).

router bgp 65001
 redistribute static route-map StaticToBGP
!
route-map StaticToBGP permit 10
 match tag 123
 set community no-export additive

When you configure a static route toward the IP subnet 10.1.2.0/24 …

ip route 10.1.2.0 255.255.255.0 Null0 tag 123

… it’s automatically inserted in the BGP table and marked with the no-export community.

6 comments:

  1. dont forget to also use the "local-as" community if you are using confederations as no-export refers to the confederation and not the subconfederation.
  2. I really came to this site looking for a Failover Solution for iBGP. Your article with tags moved me in the correct direction and I appreciate the posted comments on aggregation. My problem was simple, can one failover a remote iBGP spoke location and have BGP act in a similar “Link State” protocol as its Core Router? Moreover, can this solution not export iBGP routes in and out of EIGRP or OSPF WAN routing protocols?
    Without telling you the entire whole story, the answer is “Yes it can be completed.” However, it quite complicated and one needs to be careful. The solution utilizes route maps, tags on static routes and BGP Backdoor commands. I am able to fail a remote MPLS location (running iBGP) and have its IP Traffic traverse an IPSEC Tunnel across the Internet and into an ASA. At the core router, I point that backup traffic to that ASA. While the failover time is not instantaneous, it does resume in less than 30 seconds.

    Network Details;
    Remote Site1: 10.1.60.1/24 and Remote Site2: 10.1.70.1/24
    Core Router: 10.1.2.1/24 with Failover ASA: 10.1.2.5/25

    Here is what the Core Route configuration looks like;
    !
    router bgp 111
    network 10.1.60.0 mask 255.255.255.0 route-map NoStatic backdoor
    network 10.1.70.0 mask 255.255.255.0 route-map NoStatic2 backdoor
    !
    ip route 10.1.60.0 255.255.255.0 10.1.2.5 220 tag 220
    ip route 10.1.70.0 255.255.255.0 10.1.2.5 225 tag 225
    !
    route-map NoStatic permit 10
    match tag 220
    set metric 220
    !
    route-map NoStatic2 permit 20
    match tag 225
    set metric 225
    !
    If one would wish to speak directly, shoot me an email @ [email protected] and I can explain in detail how it was completed with the complete details on my Failover Solution.
  3. sweet! this fixed my problem :)

    thanks!
    jd.
  4. Hi - When i advertise any network under bgp it shoulbe be learned by peer bgp router which is in same VRF . But i am not seeing the advertised route reachbility from my peer router. pls advise.

    Regards/Venkat
  5. Need more info. Follow the "Contact" link at the top of the page for instructions on how to send me an e-mail.
  6. Simple and very good explanation.
Add comment
Sidebar