Now that you’re familiar with the basics of setting up a peer with ExaBGP and advertising routes, let’s look at expanding those concepts towards something that might actually be used in production.

Peering with Multiple BGP Routers

ExaBGP Multi-peer

Networks running BGP tend to have more than one edge router that you would want to advertise routes to with ExaBGP, so first let’s look at how to setup our conf.ini file to add peers. What I didn’t mention in the previous articles is that the group { } object in the config file is similar to a peer-group in Cisco IOS. The difference is that you can only have one group per ExaBGP instance, but this makes sense since the use case seems to be advertising and receiving updates to/from one ASN. We can setup shared values such as router-id, our local AS and update source, and the peer AS. Then we ‘activate’ each neighbor within the group:

And here’s the basic BGP config on our routers:

Advertising Routes to Multiple Peers

With each router being peered with ExaBGP, you can use the same announce|withdraw route x.x.x.x/x next-hop y[.y.y.y] command and the UPDATE message will be sent to all peers. But what if you want to send the same prefix with different next-hops to your routers? Well, this type of advertisement granularity is definitely possible. Let’s imagine this scenario where we want to send the prefix to both CSR routers, but each router should use a different outbound next-hop.

ExaBGP multi-update

The commands to do this (possibly using curl with the Flask based HTTP API from the previous article) are:

And the results on our routers are below. Note that because of the iBGP peering between the routers, both have each other’s next hop advertisements in the BGP table. Only the advertised prefix from the ExaBGP is installed in the RIB because of the preference for eBGP learned routes however.

Advertising Prefixes with Attributes

In all of these examples so far, I’ve been setting the next-hop attribute to either an IP address or the self keyword. Using the next-hop self will act as expected and advertise the next-hop as the IP address of the ExaBGP machine. The good news is, we can change other attributes as well! I’m not sure if this is an exhaustive list as it’s not well documented (that I can find, maybe this will be my mission) but I dug through the code and test examples to extract the following list and examples of values that we can use:

  • MED (Multi Exit Discriminator): med 50
  • Origin: origin incomplete (also egb or igp)
  • Local Preference: local-preference 200
  • AS Path: as-path [ 65000 65010 65020 ]
  • Community: community [65000:2]

Please note local-preference will only work if ExaBGP and the peer you’re advertising to are in the same AS (iBGP), since local-preference is non-transitive and will not be advertised outside the ExaBGP AS.

From what I see, you can combine these as you wish. Here’s a few example commands I ran into ExaBGP and the output on one of my routers (I used the Flask HTTP API created in the previous article as a simple way to inject these into the ExaBGP process):

Advertising Multiple Prefixes with the same Attributes

There is a shortcut when advertising multiple prefixes that have the same attributes (next-hop, med, origin, etc.). It works very similar to BGP UPDATE messages where you set all the desired attributes, and then list the prefixes that share these attributes. Based on notes from the ExaBGP docs, this is an unsupported feature but I like it and hope that more focus can be brought to make this production ready.

Here’s two example commands, note that we can specify a neighbor or send to all neighbors, just like the other examples listed so far:

That turned out to be a pretty jam-packed with excitement post! There’s some helpful flexibility built into ExaBGP and we haven’t even gotten to the exciting part. The next couple posts will start to use ExaBGPs JSON interface to receive and work with advertised routes from the peered routers, instead of focusing on pushing advertisements out to your routers.

Series Navigation<< Give ExaBGP an HTTP API with SimpleHTTPServer or FlaskControl BGP Advertisements to eBGP peers with ExaBGP >>

This post was originally published on

This article has 2 comments

  1. Adam

    The local-preference attribute is not passed along the AS boundaries due to it’s transitive or non-transitive nature like it was mentioned above (correct meaning of “transitiveness” is defined in rfc4271) but disallowed simply due to definition of it’s purpose in section 5.1.5 of the mentioned rfc. Glad to visit your blog and enjoyed reading of ExaBGP article series, thanks.

Leave a Reply

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