Control BGP Advertisements

to eBGP peers with ExaBGP

Jun - 2015 (~5 minutes read time)

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?

Our scenario is this: We have a 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 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 prefix.

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

CE# show run
router bgp 65000
 network mask
 network mask
 neighbor remote-as 100
 neighbor route-map OUTBOUND out
 neighbor remote-as 65000
 neighbor weight 32768
ip community-list standard EXABGP permit 6553700
route-map OUTBOUND deny 10
 match community EXABGP
route-map OUTBOUND permit 20

Here's the important details:

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

C##sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*>                  0         32768 i
*>                11         32768 i

PE#sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*>               0             0 65000 i
*>              11             0 65000 i

And here is what it looks like after:

CE#sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*>                  0         32768 i
r>i100.10.10.0/24                  65000  32768 i
r                         11         32768 i
CE#sh ip bgp nei adv | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*>                  0         32768 i

Total number of prefixes 1

PE#sh ip bgp | b Network
   Network          Next Hop            Metric LocPrf Weight Path
*>               0             0 65000 i

CE knows about the 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, CE changes the prefix's weight to 65000 and it takes preference over the locally sourced route (network mask and is marked as best. Now when CE calculates which prefixes to advertise out to PE, it selects the 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. is still reachable from R1 and AR so it's not a big deal, read more about it from

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

from sys import stdout, stdin
from time import sleep

# Print the command to STDIN so ExaBGP can execute
stdout.write('announce route next-hop local-preference 65000 community [100:100]\n')

#Keep the script running so ExaBGP doesn't stop running and tear down the BGP peering
while True:

<pre class="lang:ini decode:true" title="conf.ini">group test {
    local-as 65000;

    process add_route {
        run /usr/bin/python /etc/exabgp/;

    neighbor {
        peer-as 65000;

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.