BGP Route Aggregation is not only an important topic to learn for the CCIE exam, its what keeps the internet routing tables manageable. The basic idea is simple, instead of BGP advertising lots of different prefixes, we can summarize individual prefixes as an aggregate. In this series of articles we will be looking at BGP Route Aggregation using various methods that you should be familiar with before attempting the CCIE lab in case one of those evil proctors decides to limit the use of one or the other.
In this article we will be introducing the aggregate-address command to create route aggregates. We will be using the following topology for this tutorial:
Dynagen .net Configuration File:
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 = 128
[[router R1]]
model = 3640
console = 2000
e1/0 = LAN 12
[[router R2]]
model = 3640
console = 2001
e1/0 = LAN 12
e1/1 = LAN 23
e1/2 = LAN 24
[[router R3]]
model = 3640
console = 2002
e1/0 = LAN 23
[[router R4]]
model = 3640
console = 2003
e1/0 = LAN 24You can download the pre-configured .net dynagen configuration file for this tutorial here.
Basic Configuration
Let’s take a look at the basic configuration for this topology:
R1
hostname R1
!
interface Loopback0
ip address 10.0.0.1 255.255.255.0
!
interface Loopback1
ip address 10.0.1.1 255.255.255.0
!
interface Ethernet1/0
ip address 192.168.12.1 255.255.255.0
full-duplex
no shut
!
router bgp 1
no synchronization
bgp router-id 1.1.1.1
network 10.0.0.0 mask 255.255.255.0
network 10.0.1.0 mask 255.255.255.0
neighbor 192.168.12.2 remote-as 2
no auto-summaryR2
hostname R2
!
interface Ethernet1/0
ip address 192.168.12.2 255.255.255.0
full-duplex
no shut
!
interface Ethernet1/1
ip address 192.168.23.2 255.255.255.0
full-duplex
no shut
!
interface Ethernet1/2
ip address 192.168.24.2 255.255.255.0
full-duplex
no shut
!
router bgp 2
no synchronization
bgp router-id 2.2.2.2
neighbor 192.168.12.1 remote-as 1
neighbor 192.168.23.3 remote-as 3
neighbor 192.168.24.4 remote-as 4
no auto-summaryR3
hostname R3
!
interface Loopback0
ip address 10.0.2.1 255.255.255.0
!
interface Loopback1
ip address 10.0.3.1 255.255.255.0
!
interface Ethernet1/0
ip address 192.168.23.3 255.255.255.0
full-duplex
no shut
!
router bgp 3
no synchronization
bgp router-id 3.3.3.3
network 10.0.2.0 mask 255.255.255.0
network 10.0.3.0 mask 255.255.255.0
neighbor 192.168.23.2 remote-as 2
no auto-summaryR4
hostname R4
!
interface Ethernet1/0
ip address 192.168.24.4 255.255.255.0
full-duplex
no shut
!
router bgp 4
no synchronization
bgp router-id 4.4.4.4
bgp log-neighbor-changes
neighbor 192.168.24.2 remote-as 2
no auto-summaryYou can see in the configuration above we have three routers: R1, R2, R3 and R4 each in their own AS. R1 has two loopbacks defined which it is advertising into BGP. R3 also has two loopbacks defined which it is also advertising into BGP. Lets verify these advertised BGP prefixes:
R1#sh ip bgp
BGP table version is 5, local router ID is 1.1.1.1
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
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 10.0.2.0/24 192.168.12.2 0 2 3 i
*> 10.0.3.0/24 192.168.12.2 0 2 3 iR2#sh ip bgp
BGP table version is 5, 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
*> 10.0.0.0/24 192.168.12.1 0 0 1 i
*> 10.0.1.0/24 192.168.12.1 0 0 1 i
*> 10.0.2.0/24 192.168.23.3 0 0 3 i
*> 10.0.3.0/24 192.168.23.3 0 0 3 iR3#sh ip bgp
BGP table version is 5, 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
*> 10.0.0.0/24 192.168.23.2 0 2 1 i
*> 10.0.1.0/24 192.168.23.2 0 2 1 i
*> 10.0.2.0/24 0.0.0.0 0 32768 i
*> 10.0.3.0/24 0.0.0.0 0 32768 iR4#sh ip bgp
BGP table version is 5, local router ID is 4.4.4.4
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
*> 10.0.0.0/24 192.168.24.2 0 2 1 i
*> 10.0.1.0/24 192.168.24.2 0 2 1 i
*> 10.0.2.0/24 192.168.24.2 0 2 3 i
*> 10.0.3.0/24 192.168.24.2 0 2 3 iYou can see clearly above that the networks have been advertised into BGP. Let’s verify connectivity.
R1#ping 10.0.2.1 source 10.0.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 116/213/296 msLooks like we have connectivity from the networks that R1 is advertising (10.0.0.0/24 and 10.0.1.0/24) and the networks that R3 is advertising (10.0.2.0/24 and 10.0.3.0/24). We haven’t run an IGP here as we don’t usually have an IGP running between AS’s (thats the whole purpose of BGP!). When we did the ping, we have to source the address from R1’s loopback for connectivity. If we didn’t do that the source address of the ping packet would be 192.168.12.1, which R3 does not have a route for. We can run an IGP protocol here, but it is not needed for these examples.
Basic BGP Aggregation using the aggregate-address command
Lets do some aggregation! We will be using the aggregate-address command to create a summary.
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router bgp 2
R2(config-router)#aggregate-address 10.0.0.0 255.255.252.0We have created an aggregrate address on R2 here that summarizes the 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24 and 10.0.3.0/24 networks. If you look at the four networks in binary we get:
10.0.0.0/24 = 00001010.00000000.00000000.00000000
10.0.1.0/24 = 00001010.00000000.00000001.00000000
10.0.2.0/24 = 00001010.00000000.00000010.00000000
10.0.3.0/24 = 00001010.00000000.00000011.00000000The first 22 bits of these are common, hence an aggregate of 10.0.0.0/22.
One of the first things we need to remember is that we cannot aggregate an address unless at least one of the more specific routes we are trying to aggregate exists in the routing table already. If all the prefixes that we are summarizing in our aggregate go down, the router will remove the aggregate from the BGP table.
Let’s verify the aggregate:
R2#sh ip bgp
BGP table version is 6, 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
*> 10.0.0.0/24 192.168.12.1 0 0 1 i
*> 10.0.0.0/22 0.0.0.0 32768 i
*> 10.0.1.0/24 192.168.12.1 0 0 1 i
*> 10.0.2.0/24 192.168.23.3 0 0 3 i
*> 10.0.3.0/24 192.168.23.3 0 0 3 iR2#sh ip route | b Gateway
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, Ethernet1/0
C 192.168.24.0/24 is directly connected, Ethernet1/2
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 10.0.2.0/24 [20/0] via 192.168.23.3, 00:10:57
B 10.0.3.0/24 [20/0] via 192.168.23.3, 00:10:57
B 10.0.0.0/24 [20/0] via 192.168.12.1, 00:10:57
B 10.0.0.0/22 [200/0] via 0.0.0.0, 00:10:57, Null0
B 10.0.1.0/24 [20/0] via 192.168.12.1, 00:10:57
C 192.168.23.0/24 is directly connected, Ethernet1/1Looking at the routing table above we can see that we have an entry in the routing table to Null0 on R2.
Null0 - The road to nowhere
Why does an aggregate create an entry to Null0? Good question lets think about this. Say we had this scenario:
On R3 lets say we created 4 more loopbacks that we advertise into BGP: 150.0.0.0/24, 150.0.1.0/24, 150.0.2.0/24, 150.0.3.0/24.
R3
R3(config)#int lo10
R3(config-if)#ip add 150.0.0.1 255.255.255.0
R3(config-if)#int lo11
R3(config-if)#ip add 150.0.1.1 255.255.255.0
R3(config-if)#int lo12
R3(config-if)#ip add 150.0.2.1 255.255.255.0
R3(config-if)#int lo13
R3(config-if)#ip add 150.0.3.1 255.255.255.0
R3(config-if)#router bgp 3
R3(config-router)#network 150.0.0.0 mask 255.255.255.0
R3(config-router)#network 150.0.1.0 mask 255.255.255.0
R3(config-router)#network 150.0.2.0 mask 255.255.255.0
R3(config-router)#network 150.0.3.0 mask 255.255.255.0R2
R2#sh ip bgp
BGP table version is 10, 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
*> 10.0.0.0/24 192.168.12.1 0 0 1 i
*> 10.0.0.0/22 0.0.0.0 32768 i
*> 10.0.1.0/24 192.168.12.1 0 0 1 i
*> 10.0.2.0/24 192.168.23.3 0 0 3 i
*> 10.0.3.0/24 192.168.23.3 0 0 3 i
*> 150.0.0.0/24 192.168.23.3 0 0 3 i
*> 150.0.1.0/24 192.168.23.3 0 0 3 i
*> 150.0.2.0/24 192.168.23.3 0 0 3 i
*> 150.0.3.0/24 192.168.23.3 0 0 3 iR2 then aggregates this as 150.0.0.0/22 and creates a Null0 route in its routing table.
R2
R2(config)#router bgp 2
R2(config-router)#aggregate-address 150.0.0.0 255.255.252.0 R2#sh ip route | b Gateway
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, Ethernet1/0
C 192.168.24.0/24 is directly connected, Ethernet1/2
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 10.0.2.0/24 [20/0] via 192.168.23.3, 00:48:15
B 10.0.3.0/24 [20/0] via 192.168.23.3, 00:48:15
B 10.0.0.0/24 [20/0] via 192.168.12.1, 00:48:15
B 10.0.0.0/22 [200/0] via 0.0.0.0, 00:30:07, Null0
B 10.0.1.0/24 [20/0] via 192.168.12.1, 00:48:15
C 192.168.23.0/24 is directly connected, Ethernet1/1
150.0.0.0/16 is variably subnetted, 5 subnets, 2 masks
B 150.0.2.0/24 [20/0] via 192.168.23.3, 00:12:54
B 150.0.3.0/24 [20/0] via 192.168.23.3, 00:12:54
B 150.0.0.0/24 [20/0] via 192.168.23.3, 00:13:24
B 150.0.0.0/22 [200/0] via 0.0.0.0, 00:12:01, Null0
B 150.0.1.0/24 [20/0] via 192.168.23.3, 00:01:31This aggregate is then passed it on to R1. Lets also say that R2 has a default gateway set to R1.
R2
R2(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.1R2#sh ip route | b Gateway
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
C 192.168.12.0/24 is directly connected, Ethernet1/0
C 192.168.24.0/24 is directly connected, Ethernet1/2
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 10.0.2.0/24 [20/0] via 192.168.23.3, 00:50:08
B 10.0.3.0/24 [20/0] via 192.168.23.3, 00:50:08
B 10.0.0.0/24 [20/0] via 192.168.12.1, 00:50:08
B 10.0.0.0/22 [200/0] via 0.0.0.0, 00:32:00, Null0
B 10.0.1.0/24 [20/0] via 192.168.12.1, 00:50:08
C 192.168.23.0/24 is directly connected, Ethernet1/1
150.0.0.0/16 is variably subnetted, 5 subnets, 2 masks
B 150.0.2.0/24 [20/0] via 192.168.23.3, 00:14:46
B 150.0.3.0/24 [20/0] via 192.168.23.3, 00:14:46
B 150.0.0.0/24 [20/0] via 192.168.23.3, 00:15:17
B 150.0.0.0/22 [200/0] via 0.0.0.0, 00:13:53, Null0
B 150.0.1.0/24 [20/0] via 192.168.23.3, 00:03:24
S* 0.0.0.0/0 [1/0] via 192.168.12.1What would happen if the network 150.0.1.0/24 went down on R3 and we didn’t have that Null0 route on R2?
R3
R3(config)#int lo11
R3(config-if)#shutR2
R2#sh ip bgp
BGP table version is 14, 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
*> 10.0.0.0/24 192.168.12.1 0 0 1 i
*> 10.0.0.0/22 0.0.0.0 32768 i
*> 10.0.1.0/24 192.168.12.1 0 0 1 i
*> 10.0.2.0/24 192.168.23.3 0 0 3 i
*> 10.0.3.0/24 192.168.23.3 0 0 3 i
*> 150.0.0.0/24 192.168.23.3 0 0 3 i
*> 150.0.0.0/22 0.0.0.0 32768 i
*> 150.0.2.0/24 192.168.23.3 0 0 3 i
*> 150.0.3.0/24 192.168.23.3 0 0 3 iR2#sh ip route | b Gateway
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
C 192.168.12.0/24 is directly connected, Ethernet1/0
C 192.168.24.0/24 is directly connected, Ethernet1/2
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 10.0.2.0/24 [20/0] via 192.168.23.3, 00:51:18
B 10.0.3.0/24 [20/0] via 192.168.23.3, 00:51:18
B 10.0.0.0/24 [20/0] via 192.168.12.1, 00:51:18
B 10.0.0.0/22 [200/0] via 0.0.0.0, 00:33:10, Null0
B 10.0.1.0/24 [20/0] via 192.168.12.1, 00:51:18
C 192.168.23.0/24 is directly connected, Ethernet1/1
150.0.0.0/16 is variably subnetted, 4 subnets, 2 masks
B 150.0.2.0/24 [20/0] via 192.168.23.3, 00:15:57
B 150.0.3.0/24 [20/0] via 192.168.23.3, 00:15:57
B 150.0.0.0/24 [20/0] via 192.168.23.3, 00:16:27
S* 0.0.0.0/0 [1/0] via 192.168.12.1Well R1 pings 150.0.1.1, the Aggregate will be matched on R1’s routing table. It will be received on R2. The route for 150.0.1.0/24 is missing. Remember there is no Null0 route here, so what will R2 match? The default gateway! So it will send it back to R1. R1 will then send to R2. Ladies and Gentleman we have a routing loop! This is one of the reasons we create a Null0 route on R2 when an aggregate is generated.
Let’s clean up and get back to our aggregate for 10.0.0.0/22 on R2 and take a look at the atomic-aggregate attribute.
R3
R3(config)#no int lo10
R3(config)#no int lo11
R3(config)#no int lo12
R3(config)#no int lo13
R3(config)#router bgp 3
R3(config-router)#no network 150.0.0.0 mask 255.255.255.0
R3(config-router)#no network 150.0.1.0 mask 255.255.255.0
R3(config-router)#no network 150.0.2.0 mask 255.255.255.0
R3(config-router)#no network 150.0.3.0 mask 255.255.255.0R2
R2(config)#router bgp 2
R2(config-router)#no aggregate-address 150.0.0.0 255.255.252.0Atomic-Aggregate
I gotta admit, Atomic-Aggregate sounds kinda cool. Like an Aggregate with superpowers or something :). But what the hell is it and what does it have to do with BGP aggregation? Take a look at the output below:
R2#sh ip bgp 10.0.0.0/22
BGP routing table entry for 10.0.0.0/22, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
Local, (aggregated by 2 2.2.2.2)
0.0.0.0 from 0.0.0.0 (2.2.2.2)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, bestYou can see above that R2 has now originated an entry in BGP for the 10.0.0.0/22 aggregate. You can see also that the aggregate has the atomic-aggregate attribute set. What this means is that the AS path information about the aggregate has been lost. What do I mean by that?
Lets take a look at the BGP tables on R1.
R1#sh ip bgp
BGP table version is 18, local router ID is 1.1.1.1
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
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.0.0.0/22 192.168.12.2 0 0 2 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 10.0.2.0/24 192.168.12.2 0 2 3 i
*> 10.0.3.0/24 192.168.12.2 0 2 3 iLook at the output above we can see that the path information for the 10.0.0.0/22 prefix only contains AS 2!
R1#sh ip bgp 10.0.0.0/22
BGP routing table entry for 10.0.0.0/22, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
2, (aggregated by 2 2.2.2.2)
192.168.12.2 from 192.168.12.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, bestYou can see that R1 thinks the 10.0.0.0/22 network originated in AS 2. The networks in that aggregate however originated in AS 1, and AS 3. By aggregating on R2 we have lost that information. So all an atomic-aggregate attribute on an aggregate route says is “I’ve lost all the as-path information for the routes that I am aggregating”.
Lets look a bit closer at the BGP table on R2:
R2#sh ip bgp
BGP table version is 6, 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
*> 10.0.0.0/24 192.168.12.1 0 0 1 i
*> 10.0.0.0/22 0.0.0.0 32768 i
*> 10.0.1.0/24 192.168.12.1 0 0 1 i
*> 10.0.2.0/24 192.168.23.3 0 0 3 i
*> 10.0.3.0/24 192.168.23.3 0 0 3 iYou can see there that the 10.0.0.0/22 route has lost the as-path information. The atomic-aggregate attribute has been set so we don’t see the complete as-path for the prefixes contained within that aggregate.
This situation can also be seen on R3 and R4:
R3#sh ip bgp
BGP table version is 6, 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
*> 10.0.0.0/24 192.168.23.2 0 2 1 i
*> 10.0.0.0/22 192.168.23.2 0 0 2 i
*> 10.0.1.0/24 192.168.23.2 0 2 1 i
*> 10.0.2.0/24 0.0.0.0 0 32768 i
*> 10.0.3.0/24 0.0.0.0 0 32768 iR4#sh ip bgp
BGP table version is 6, local router ID is 4.4.4.4
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
*> 10.0.0.0/24 192.168.24.2 0 2 1 i
*> 10.0.0.0/22 192.168.24.2 0 0 2 i
*> 10.0.1.0/24 192.168.24.2 0 2 1 i
*> 10.0.2.0/24 192.168.24.2 0 2 3 i
*> 10.0.3.0/24 192.168.24.2 0 2 3 iHow can we retain the as-path information?
Using the as-set keyword
The as-path paramter for the aggregate-address command allows us to create an BGP aggregate without setting the atomic-aggregate attribute. This allows us to see the as-path of the routes we are aggregating.
Let’s take a look at the configuration:
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router bgp 2
R2(config-router)#aggregate-address 10.0.0.0 255.255.252.0 as-setSimple configuration huh? Just add the as-set keyword to the aggregate-address command. Let’s verify this and take a look at the effects this has on our BGP tables.
R2#sh ip bgp 10.0.0.0 255.255.252.0
BGP routing table entry for 10.0.0.0/22, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1
{1,3}, (aggregated by 2 2.2.2.2)
0.0.0.0 from 0.0.0.0 (2.2.2.2)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, bestYou can see above we have that the route is originated on R2 but it has a {1,3} in the as-path information. This means that 10.0.0.0/22 is an aggregate of prefixes that went through AS 1 and AS 3. Also notice, that the atomic-aggregate attribute is no longer set as no AS information for the aggregate has been lost.
What will this do to our BGP routing tables? Lets take a look at the routing table on R1:
R1#sh ip bgp
BGP table version is 7, local router ID is 1.1.1.1
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
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 10.0.2.0/24 192.168.12.2 0 2 3 i
*> 10.0.3.0/24 192.168.12.2 0 2 3 iTake a look carefully at the output above. Hey wait a minute, we don’t have the aggregate anymore. Did we stuff up our configuration? Is R2 even advertising the prefixes?
R2#sh ip bgp neighbors 192.168.12.1 advertised-routes
BGP table version is 7, 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
*> 10.0.0.0/24 192.168.12.1 0 0 1 i
*> 10.0.0.0/22 0.0.0.0 100 32768 {1,3} i
*> 10.0.1.0/24 192.168.12.1 0 0 1 i
*> 10.0.2.0/24 192.168.23.3 0 0 3 i
*> 10.0.3.0/24 192.168.23.3 0 0 3 i
Total number of prefixes 5 R2#sh ip bgp neighbors 192.168.23.3 advertised-routes
BGP table version is 7, 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
*> 10.0.0.0/24 192.168.12.1 0 0 1 i
*> 10.0.0.0/22 0.0.0.0 100 32768 {1,3} i
*> 10.0.1.0/24 192.168.12.1 0 0 1 i
*> 10.0.2.0/24 192.168.23.3 0 0 3 i
*> 10.0.3.0/24 192.168.23.3 0 0 3 i
Total number of prefixes 5 R2 is advertising the prefixes but R1 and R3 are not accepting them! What gives? Actually, this is expected behaviour. What the rule with BGP when a router sees its own AS number in the AS-PATH? It doesn’t accept the route!
R2#sh ip bgp
BGP table version is 7, 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
*> 10.0.0.0/24 192.168.12.1 0 0 1 i
*> 10.0.0.0/22 0.0.0.0 100 32768 {1,3} i
*> 10.0.1.0/24 192.168.12.1 0 0 1 i
*> 10.0.2.0/24 192.168.23.3 0 0 3 i
*> 10.0.3.0/24 192.168.23.3 0 0 3 iOn R2, we can clearly see that the AS path of the aggregate now contains all the AS’s of the routes that it is summarizing.
R3#sh ip bgp
BGP table version is 7, 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
*> 10.0.0.0/24 192.168.23.2 0 2 1 i
*> 10.0.1.0/24 192.168.23.2 0 2 1 i
*> 10.0.2.0/24 0.0.0.0 0 32768 i
*> 10.0.3.0/24 0.0.0.0 0 32768 iR3 doesn’t accept the route because it sees its own AS 3 in the path for 10.0.0.0/22.
R4#sh ip bgp
BGP table version is 7, local router ID is 4.4.4.4
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
*> 10.0.0.0/24 192.168.24.2 0 2 1 i
*> 10.0.0.0/22 192.168.24.2 0 0 2 {1,3} i
*> 10.0.1.0/24 192.168.24.2 0 2 1 i
*> 10.0.2.0/24 192.168.24.2 0 2 3 i
*> 10.0.3.0/24 192.168.24.2 0 2 3 iR4 however accepts the route as it does not see its own AS in the aggregate. Cool huh?
Controlling the BGP aggregrate using advertise-map
Using the advertise-map option on the aggregate-address command allows us to control which routes make up the summary address. We can use this to say which prefixes make up the aggregate address.
Lets take a look at an example:
R2
router bgp 2
no synchronization
bgp router-id 2.2.2.2
aggregate-address 10.0.0.0 255.255.252.0 as-set advertise-map AS_3_PREFIXES
neighbor 192.168.12.1 remote-as 1
neighbor 192.168.23.3 remote-as 3
neighbor 192.168.24.4 remote-as 4
no auto-summary
!
access-list 1 permit 10.0.2.0 0.0.0.255
access-list 1 permit 10.0.3.0 0.0.0.255
!
route-map AS_3_PREFIXES permit 10
match ip address 1We have created an access list that matches the 10.0.2.0/24, and 10.0.3.0/24 prefixes. Both of these prefixes are originated in AS 3. This access list is then associated with the route-map AS_3_PREFIXES. We call this route-map in the aggregate-address advertise-map command.
Notice we also have the as-set command so the atomic-aggregate will be set.
Lets take a look at the summary address that this creates.
R2#sh ip bgp 10.0.0.0/22
BGP routing table entry for 10.0.0.0/22, version 8
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to update-groups:
1
3, (aggregated by 2 2.2.2.2)
0.0.0.0 from 0.0.0.0 (2.2.2.2)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, bestNotice that the AS-PATH information only has AS 3 in the path list. This is because when we created the aggregate address we told the router that “this aggregate is a summary of 10.0.2.0/24 and 10.0.3.0/24″. These prefixes only originate in AS 3 so thats all that goes in the path list! Also notice that the atomic-aggregate attribute is set. This is because information for the aggregate has been lost (ie. we don’t include AS 1’s prefixes).
R1#sh ip bgp
BGP table version is 8, local router ID is 1.1.1.1
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
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.0.0.0/22 192.168.12.2 0 0 2 3 i
*> 10.0.1.0/24 0.0.0.0 0 32768 i
*> 10.0.2.0/24 192.168.12.2 0 2 3 i
*> 10.0.3.0/24 192.168.12.2 0 2 3 iYou can see above that R1 now accepts this aggregate as it no longer sees its own AS in the path.
R2#sh ip bgp
BGP table version is 8, 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
*> 10.0.0.0/24 192.168.12.1 0 0 1 i
*> 10.0.0.0/22 0.0.0.0 100 32768 3 i
*> 10.0.1.0/24 192.168.12.1 0 0 1 i
*> 10.0.2.0/24 192.168.23.3 0 0 3 i
*> 10.0.3.0/24 192.168.23.3 0 0 3 iR3#sh ip bgp
BGP table version is 7, 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
*> 10.0.0.0/24 192.168.23.2 0 2 1 i
*> 10.0.1.0/24 192.168.23.2 0 2 1 i
*> 10.0.2.0/24 0.0.0.0 0 32768 i
*> 10.0.3.0/24 0.0.0.0 0 32768 iR3 does not accept the path. Why? Because it saw its own AS in the update.
R4#sh ip bgp
BGP table version is 17, local router ID is 4.4.4.4
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
*> 10.0.0.0/24 192.168.24.2 0 2 1 i
*> 10.0.0.0/22 192.168.24.2 0 0 2 3 i
*> 10.0.1.0/24 192.168.24.2 0 2 1 i
*> 10.0.2.0/24 192.168.24.2 0 2 3 i
*> 10.0.3.0/24 192.168.24.2 0 2 3 iR4 happily accepts the update. Notice the AS path looks like it originated from AS 3.
Why might this stuff come in handy? Well imagine those evil CCIE proctors as you to filter BGP updates but you are not allowed to use the traditional means (filter-lists etc). This just gives you another tool that you can add to your belt!
In our next article we will be looking at suppress-maps and attribute-maps as well as few other cool little things with BGP aggregation. Stay tuned!
HTH. Now back to labs!
Summary:
- BGP can summaries prefixes with the aggregate-address command
- When an aggregate is created, a Null0 route is entered into the routing table to stop routing loops.
- By default, the aggregate will be originated from the AS creating the aggregate. All AS-PATH information about prefixes contained within the aggregate is lost.
- When AS-PATH information is lost, the atomic-aggregate attribute is set on the aggregate.
- We can control what prefixes make up the aggregate using the advertise-map parameter on the aggregate-address command.
1 comment:
Sorry for my bad english. Thank you so much for your good post. Your post helped me in my college assignment, If you can provide me more details please email me.
Post a Comment