BGP aggregate advertise-map

I hope you are starting to get the point, but there are a ton of different maps that can be configured with BGP.  The next one I want to cover is the advertise-map.  These maps tell the router which prefixes should part of the aggregate.  This becomes particularly handy when dealing with the as-set variable on a BGP aggregate.  However, lets test this out without as-set first so you get an idea of how it works.   image

Consider our lab above.  Let’s take a look at the ISP B router’s BGP configuration…

image

Notice that Im specifying a advertise-map of ispb_summary.  Let’s look at that route-map and associated prefix list…

image

So as you can see, the route-map is matching on the first two /24 routes in ISP B.  Let’s take a look at the BGP table as well…

image

Everything looks like I expect.  Now, let’s remove the two static routes I have that match the ispb_summary prefix list …

image

Immediately after removing the routes we look at the BGP table and see that we are no longer advertising the /20 aggregate.  This is because we told the router that the aggregate was comprised of the first two /24 prefixes.  As with any aggregate, if there are no matching (generally smaller) prefixes within the aggregate in the routing table, the aggregate is not advertised. 

Pretty straight forward right?  An interesting use case involves the as-set variable on the aggregate command.  Let’s restore the lab and take another look at how this works in conjunction with the as-set command.

Let’s take another look at ISP B’s BGP table…

image

Note that we don’t show a prefix for the /18 aggregate being generated at the ISP A level.  This is because the aggregate on ISP A is being generated with the as-set  command.  Let’s look at the BGP table on one of the ISP A routers to verify…

image

As you can see, both /18 routes include AS 100 and AS 300 in their AS set.  Since the /18 advertisement has each respective ISPs AS number in it, the advertisement will be blocked by the ISP B and C routers.  Suppose we want to advertise the /18 down to ISP B and ISP C.  This could be achieved by removing the ISP B and C AS from the /18 advertisement.  However, we still need one of the advertisements for the aggregate to exist.  We could, in this case, rely on the advertisement from one of the lower tier ISPs to provide the aggregate for the second ISP.  That would look like this…

image

Here, the solid green line shows that ISP A will build its aggregate for /18 based on receiving the single /20 from ISP B.  In turn, it can then advertise the /18 down to ISP C since the aggregate will not have AS 300 in it’s AS path attribute.  The same can be done in the reverse direction.  Let’s try this out on one of the ISP A routers…

image

Above, we configure a route-map with a prefix list matching the 175.15.0.0/20 aggregate coming from ISP B.  We then update our /18 aggregate with a advertise-map that tells the router which prefixes to build the local aggregate (the /18) with.  Once the change has been made, let’s examine the BGP table of the ISP A router to see if it worked…

image

Sure enough.  Note that we still have two /18 prefixes.  Note that the locally originated /18 lists a AS path only including AS 100.  Looking at the BGP table on ISP C, we can see that this worked as expected…

image

There are some flaws with this design.  Namely, if the ISP A iBGP peering fails ISP C will lose the /18 aggregate since it’s being built on the prefix coming across that iBGP peering.  However, it is another tool to keep in your BGP belt.

Tags:

  1. Amar’s avatar

    i am student for Networks course CCNA

    Reply

Reply

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