Boiled down inject maps look for a particular prefix, from a particular source, and if detected, advertise other prefixes. This is mostly used along with BGP aggregation to ‘un-aggregate’ certain prefixes. Inject maps sort of let you break the traditional rules of BGP by allowing you to originate routes into BGP without the use of a network or redistribute statement. However, there are a couple of rules to consider when using inject maps. Namely, you have to ensure that the prefix you are injecting is one that is within an existing aggregate. So you can’t just make up prefixes that you wish to inject.
Let’s pick the lab up from where we left it in the last post about unsuppress maps…
Now, if you recall, at this point we have a nice summarization going on. All of the routers have full reachability to each other and each tier is aggregating it’s prefixes up to the next tier. Let’s prove that we have good connectivity by doing a ping between 18.104.22.168 (ISP B) and 22.214.171.124 (ISP C)…
Looks good. Now, lets assume that ISP A starts having some link issues and the connection between the two ISP A routers breaks…
No worries right? We still have the path through the upstream ISP to get between ISP B and ISP C. Let’s verify we still have connectivity…
No dice. What’s going on? Let’s check the path starting from the ISP B router…
Here you can see that ISP B has a summary route from ISP A for the entire /18 network with a next hop of 10.0.0.13. Sounds good, lets take a look at that ISP A router…
Here’s our problem. While ISP A does have the /18 route, it’s only because its generating the route itself. A look at the routing table points that destination to null0. So at this point, things look like this…
The ISP A routers are more than happy to tell all of their BGP peers about the /18 aggregate the have. This includes the routers who are sending the aggregated prefixes (ISP B and C). ISP B and C are telling their upstream peers in ISP A about their aggregate for their respective /20s. The ISP A routers are only advertising the aggregate to the upstream ISP. Even if the upstream ISP advertised the route back down to the other ISP A router, it wouldn’t look as appealing as the aggregate that the router itself was generating to null0. That besides the point though since the receiving ISP A router will ditch the advertisement once it sees it’s own AS in the AS-path.
So how do we fix this? One way, is to use inject maps. As mentioned above, the inject map allows a BGP router to advertise a smaller prefix of a larger aggregate so long as the aggregate is being learned from a specific BGP peer. It’s sort of hard to get your mind around without an example so let’s just jump into the configuration. All of the configuration will be done on the upstream ISP router…
The first thing we have to do is build a route-map that specifies which prefixes we wish to inject…
The first step is to configure two prefix lists that match the ISP B and C aggregate (the /20) that we wish to inject. Next, we match them up with a route-map. NOTE!!!! Do not use the ‘match’ command in the route-map to specify the prefix-list. You MUST use the ‘set’ command.
Next we configure the match piece of the inject map. These prefix lists are used to match the BGP peer from which the aggregate is received as well as the aggregate we are looking for. These are then matched up in two route-maps. Route-map ‘learnedb’ matches on the aggregate address (126.96.36.199/18) being advertised as well as the route-source of that advertisement which should be the ISP A router a1 (10.0.0.22). I do the same for the other side calling that route-map ‘learnedc’.
The final step is to tell the BGP process to use the inject maps. This is done under the BGP process by specifying the inject-map command matching the inject route-map you created and matching it to an exist-map of the second route-map you created.
If it all worked out as expected, you should be able to verify that the upstreamISP router is injecting the routes with the ‘show ip bgp injected-paths’ command…
The ISP A routers should now also have a valid /20 path to each of their respective downstream ISPs…
And with any luck, connectivity is restored!
At the concept level, inject-maps are rather easy to grasp, but their configuration can be hard to recall and get right on the first go around. Here’s the entire configuration that I used on the upstreamISP router to make it work. Sometimes it’s easier to see it all in one big block…
ip address 10.0.0.21 255.255.255.252
ip address 10.0.0.25 255.255.255.252
router bgp 400
neighbor 10.0.0.22 remote-as 200
neighbor 10.0.0.26 remote-as 200
ip prefix-list ispb_aggregate permit 188.8.131.52/20
ip prefix-list ispc_aggregate permit 184.108.40.206/20
ip prefix-list from_ispa1 permit 10.0.0.22/32
ip prefix-list from_ispa2 permit 10.0.0.26/32
ip prefix-list learned permit 220.127.116.11/18
route-map inject_ispb permit 10
set ip address prefix-list ispb_aggregate
route-map inject_ispc permit 10
set ip address prefix-list ispc_aggregate
route-map learnedb permit 10
match ip address prefix-list learned
match ip route-source prefix-list from_ispa1
route-map learnedc permit 10
match ip address prefix-list learned
match ip route-source prefix-list from_ispa2
router bgp 400
bgp inject-map inject_ispc exist-map learnedc
bgp inject-map inject_ispb exist-map learnedb