We know that ExaBGP can be used to inject BGP routes into an AS that you control. It’s a very helpful feature that allows you to automate reachability and traffic flows within your network. But what if you want to you ExaBGP to influence what is advertised, or in this case, not advertised to external peers that are not willing to peer with your ExaBGP service?

BGP PeeringsOur scenario is this: We have a 100.10.10.0/24 prefix attached to our SW. The CE router learns about this prefix from SW via OSPF, and then advertises the prefix out to the Internet via the PE router. This 100.10.10.0/24 prefix is anycasted so it is also advertised out of a different location. In order to withdraw the prefix from the PE and therefore the Internet we would need to manually filter the prefix outbound via route-map, or stop the advertisement from the SW which would also remove the resource from local resources.

There has to be a better way, right? You’re in luck because I’m going to show you how we can use ExaBGP and BGP communities along with some basic functionality on your existing routers to indirectly influence the advertisement of the 100.10.10.0/24 prefix.

Here’s how our BGP peer configuration looks on the CE router:

Here’s the important details:

  • Peering with PE (172.16.2.1) goes through route-map OUTBOUND
    • This route-mapmatchesthecommunity-listEXABGP to match community 6553700 (or [100:100])
      • Any prefix with this community is dropped, all other prefixes are allowed
  • PeeringwithExaBGP (10.0.0.3)
    • Setting the weight of learned routes from ExaBGP to 32768 ties with the default local sourced weight
    • By matching the Cisco-proprietary weight value, the higher local-preference will win out even on non-Cisco BGP routers
    • This must be an iBGP peering (same AS) so that local-preference passed with the UPDATE from ExaBGP

Here’s what the network looks like before the ExaBGP announcement :

And here is what it looks like after:

CE knows about the 100.10.10.0/24 prefix and uses SW as its next-hop. PE is learning the prefix from CE with next-hop of CE due to the eBGP peering.  Notice that the default weight for locally sourced (network or redistribute commands) prefixes on R1 is 32768. This weight value can range from 0-65535, and on a Cisco device, it is the first value taken into account during the BGP Path Selection algorithm.

When we startup ExaBGP and advertise the prefix 100.10.10.0/24, CE changes the prefix’s weight to 65000 and it takes preference over the locally sourced route (network 100.10.10.0 mask 255.255.255.0) and is marked as best. Now when CE calculates which prefixes to advertise out to PE, it selects the 100.10.10.0/24 prefix from ExaBGP, which happens to be marked with the [100:100] community. This prefix is then filtered in the outbound advertisements with the OUTBOUND route-map and Viola! The prefix is no longer advertised to PE and the rest of the Internet from this site. The r code (RIB failure) on the routes in lines 4 and 5 is happening because the R1 can’t prefer the BGP route and install it in the RIB since the OSPF learned prefix has a lower AD. 100.10.10.0/24 is still reachable from R1 and AR so it’s not a big deal, read more about it from ipspace.net.

Here’s the ExaBGP conf.ini and python script that allows for this magic to happen:

Note that this python script clearly isn’t the only way to get ExaBGP to advertise this route to R1. The focus of this post is more of how to use the ExaBGP announcements to manipulate your traffic flows by managing prefix advertisements. To see more examples of how to control ExaBGP, check out the earlier posts in this series.

Series Navigation<< Advanced Router Peering and Route AnnouncementProcessing and Storing BGP Messages in MongoDB >>

This article has 3 comments

Leave a Reply

Your email address will not be published. Required fields are marked *