Unsuppress maps fit a very specific need in BGP. When writing this post, I was really only able to think of one or two examples of where you might need to use them. However, in many cases where BGP is aggregating addresses, they are required.
Let’s take into consideration this lab configuration…
Let’s assume that the lower tier ISPs (B and C) have IP space allocations from the mid tier ISP (A) which in turn has a space allocation from the upstream major ISP. Let’s also assume, that ISP B and C have some much smaller networks (/24s) that are allocated in their AS. Let’s add some prefixes to give you a more real life example…
Assuming the upstream ISP starts with a /16. It then allocated a /18 to to the nest hop provider (ISP A), who then in turn allocated a /18 to each of it’s downstream providers (ISP B and C). Let’s also assume that ISP A, B, and C are doing proper route aggregation to their upstream neighbors. We haven’t talked about BGP route aggregation in this post, so we’ll cover that briefly. The configuration for route aggregation in BGP is quite simple. Let’s look at a router in each lower tier to get an idea of the configuration.
Here we can see that the router for ISP B has a pretty standard configuration. It’s redistributing static routes but it also lists the command ‘aggregate-address 175.15.0.0 255.255.240.0 summary-only’ This command tells BGP to aggregate any routes which fall within this prefix into a single /20 summary route. We can see this by examining the BGP table…
Note that there are 4 locally originated routes. The /20 is the aggregate but we also have the three /24s. Note that the /24s show a ‘s’ to the far left. This indicates that they are being suppressed in BGP advertisements.
Looking at one of the ISP A routers, we can see a similar configuration…
ISP A is aggregating all of it’s routes in the /18 network. The BGP table will show the /20s from the lower tier, but none of the /24s…
And looking at the BGP table of the upstream ISP, we see only the /18 network…
Considering we have aggregation configured on all four lower tier routers, there appears to be a problem. Did you notice what it was in the output that I showed above?
If you look at the output from router ISPa-1, you’ll notice that it only lists a route to one of the /20 networks, the one directly connected to it. On the other hand, it lists two paths to get to 175.15.0.0/18. So if ISP B wanted to get to ISP C (175.15.16.0 /20 space) he should be able to get there via that summary route right? Wrong…
The two ISP A routers are sending each other the /18 summary. Route aggregation in BGP works off of injecting a null0 route for the aggregate address. The router will always pick it’s own local route pointing to null0 for the aggregate. Even if it didn’t the return traffic would hit the null0 route on the other router and never get back.
So how do you fix this? Unsuppress Maps! I’m going to guess you can sort out what they do. Basically, they tell BGP not suppress matching prefixes from it’s route advertisements. The configuration needs to be done on both of the ISP a routers in order for them to tell each other about the /20 networks they are learning from ISP B and C. It looks like this…
Here we create a prefix list that matches any prefix with a mask longer than /20. We assume that as an ISP, you don’t want to maintain a list of every single exact prefix. Second, you configure a route-map that matches the prefix list. Thirdly, you configure the BGP neighbor to use the unsuppress-map referencing the route-map you just created. When this configuration is applied on both of the ISP A routers, their BGP table will now show the summaries for ISP B and C…
And there you have it!
match ip address prefix-list unsuppress