Routing Protocols

Tutorial: BGP Conditional Route Injection with inject-map

One of the great new features that was introduced in IOS 12.0 is BGP conditional route injection. With conditional route injection we can insert more specific routes into a BGP table based on the existance of another route. Most of the routes in the current internet BGP table consists of aggregate routes. This is used to minimize the size and number of routes in global BGP routing table. The aggregation of routes can sometimes obscure more specific and accurate routing information. Wouldn’t it be cool if we could control and “un-aggregate” those routes on demand? Well that’s kinda what BGP conditional route injection does. It allows us to originate a more specific prefix into the BGP routing table based on an existing aggregated route.

We will be using the following topology for this tutorial:

The Dynagen .net file that respresents the above topology for this tutorial is shown below:

ghostios = True
sparsemem = True
model = 3640

[localhost]

    [[3640]]
        image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        ram = 96

    [[ROUTER R1]]
        f0/0 = LAN 12
        console = 2000
        model = 3640

    [[ROUTER R2]]
        f0/0 = LAN 12
        f1/0 = LAN 23
        console = 2001
        model = 3640

    [[ROUTER R3]]
        f0/0 = LAN 23
        console = 2002
        model = 3640

You can download the dynagen .net file here.

Initial Setup

Let’s set up the basic topology above. We will advertise the 1.1.1.0/25 and 1.1.1.128/25 loopbacks on R1 as an aggregate address 1.1.1.0/24 into the bgp routing table. R2, and R3 will not be able to see the specific routes but only the aggregate route.

R1:

hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.128
!
interface Loopback1
 ip address 1.1.1.129 255.255.255.128
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.0 mask 255.255.255.128
 network 1.1.1.128 mask 255.255.255.128
 aggregate-address 1.1.1.0 255.255.255.0 summary-only
 neighbor 192.168.12.2 remote-as 2
 no auto-summary

R2:

hostname R2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.0
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet1/0
 ip address 192.168.23.2 255.255.255.0
 duplex auto
 speed auto
!
router bgp 2
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.12.1 remote-as 1
 neighbor 192.168.23.3 remote-as 3
 no auto-summary

R3:

hostname R3
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.0
!
interface FastEthernet0/0
 ip address 192.168.23.3 255.255.255.0
 duplex auto
 speed auto
!
router bgp 3
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.23.2 remote-as 2
 no auto-summary

Pretty simple. R1, R2, and R3 are in BGP AS 1, 2, and 3 respectively. Let’s verify the BGP tables on R1 and R2.

R1#sh ip bgp
BGP table version is 6, local router ID is 1.1.1.129
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
s> 1.1.1.0/25       0.0.0.0                  0         32768 i
*> 1.1.1.0/24       0.0.0.0                            32768 i
s> 1.1.1.128/25     0.0.0.0                  0         32768 i

You can see above that R1 has the more specific routes and the aggregate in its BGP table. The more specific routes are being suppressed, so the only route that R2 and R3 should see is that aggregate route (1.1.1.0/24).

R2#sh ip bgp
BGP table version is 2, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.12.1             0             0 1 i

R3#sh ip bgp
BGP table version is 4, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/24       192.168.23.2                           0 2 1 i

Looks good. R2 and R3 have received the aggregate route.

BGP inject-map

We will be using the bgp inject-map command to originate some routes. We will set up R2, so that if the 1.1.1.0/24 aggregate routes exist in its BGP table it will “un-aggregate” those routes. R2 will test if it is receiving the aggregate address from R1, before it originates the more specific routes.

Let’s take a look at the configuration for this:

R2:

ip prefix-list ROUTE seq 5 permit 1.1.1.0/24
!
ip prefix-list ROUTE_SOURCE seq 5 permit 192.168.12.1/32
!
route-map LEARNED_ROUTE permit 10
 match ip address prefix-list ROUTE
 match ip route-source prefix-list ROUTE_SOURCE

Firstly we have defined the route that we want to match using a prefix list (ROUTE), and source of that prefix using another prefix list (ROUTE_SOURCE). The route prefix list must match prefix we are looking for in the BGP table exactly, and the route source prefix list MUST be a /32 source. We have tied the two together in a route-map. The route map is matching both the route and where we learned it from.

So that’s the first part. We will be using that route-map later on in the BGP inject-map to specify the condition that must exist.

Next we need to define what to originate if that condition exists:

R2:

ip prefix-list UNAGGREGATED_ROUTES seq 5 permit 1.1.1.0/25
ip prefix-list UNAGGREGATED_ROUTES seq 10 permit 1.1.1.128/25
!
route-map ORIGINATE permit 10
 set ip address prefix-list UNAGGREGATED_ROUTES

We have created a single prefix list called UNAGGREGATED_ROUTES that defines the more specific routes we want to originate. We can originate any route that is a subnet of the aggregate address (so I could have just as easily originated three routes 1.1.1.0/26, 1.1.1.64/26, 1.1.1.128/25), however they must be a subnet of the aggregate address.

We have tied this together with another route-map called ORIGINATE. This will set the ip prefixes we want to originate based on the UNAGGREGATED_ROUTES prefix list. ie ORIGINATE those UNAGGREGATED_ROUTES. :)

So we have two route-maps. ORIGINATE is the route-map containing prefixes we want to originate. LEARNED_ROUTE is the condition we want to match.

R2:

router bgp 2
 bgp inject-map ORIGINATE exist-map LEARNED_ROUTE

Finally we have our BGP inject-map statement. The inject-map command takes two arguments. The first is a route-map containing prefixes we want to originate. The second is a route-map that contains the conditions that must be met before we originate the prefixes defined in the first route-map. Cool huh?

Verification

The first thing we should do is check whether the unaggregated routes are in R2’s BGP table:

R2#sh ip bgp
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/25       192.168.12.1                           0 ?
*> 1.1.1.0/24       192.168.12.1             0             0 1 i
*> 1.1.1.128/25     192.168.12.1                           0 ?

Looks good. If they unaggregated routes don’t show up check whether you have defined a /32 route source and that you are matching a prefix correctly.

We can verifying what bgp paths are injected using the show ip bgp injected-paths command.

R2#sh ip bgp injected-paths
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/25       192.168.12.1                           0 ?
*> 1.1.1.128/25     192.168.12.1                           0 ?

Looks great. Finally, lets check if they show up on R3.

R3#sh ip bgp
BGP table version is 4, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.0/25       192.168.23.2                           0 2 ?
*> 1.1.1.0/24       192.168.23.2                           0 2 1 i
*> 1.1.1.128/25     192.168.23.2                           0 2 ?

Awesome! This could really come in handy. Especially if you are doing route policies where you want more fine grain control on how they apply to individual subnets of an aggregate address. HTH. Now back to labs!

Summary:

• BGP conditional route injection allows us to originate more specific prefixes based on an existing aggregate prefix.
• We use the bgp inject-map command to perform conditional route injection
• We can only originate more specific subnets of an existing aggregate prefix

Resources:

• Dynamips/Dynagen .net configuration file

© 2008 Arden Packeer. All rights reserved. The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway. This material is not sponsored or endorsed by Cisco Systems, Inc. Cisco, Cisco Systems, CCIE and the CCIE Logo are trademarks of Cisco Systems, Inc. and its affiliates