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.
Consider our lab above. Let’s take a look at the ISP B router’s BGP configuration…
Notice that Im specifying a advertise-map of ispb_summary. Let’s look at that route-map and associated prefix list…
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…
Everything looks like I expect. Now, let’s remove the two static routes I have that match the ispb_summary prefix list …
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…
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…
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…
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…
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…
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…
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.
i am student for Networks course CCNA
Hi there
I’m a network engineer and I recently had an encounter with this topic. specially, INE scenarios mixed me up. I can not comprehend its use-case? I really appreciate if you guys help me.
this is my Gmail:
[email protected]