Route aggregation happens where multiple routes are rolled up into a series of shorter prefixes (ie 4 /24’s become a /22). The idea is to reduce the number of routes that need to be processed. Often, the specifics don’t matter. If I’m advertising the 4 /24’s as above and they all go the the same place, why does the whole Internet need to know about all four of them when a single /22 will describe the whole lot?
This also leads to some global routing stability. If one of the /24’s went down, I don’t have to tell the rest of the Internet since the /22 covers three other networks that are working. Yes, any packets destined to the downed network will return an error, but it’s a small price to pay to reduce the amount of flapping on the Internet.
While getting the size of the global route tables down is a great idea, sites that are multihomed face challenges with route aggregation, which means that BGP has to handle the exceptions.
To illustrate the last point, consider this example network. It’s similar to what we’ve been following along with except that I split AS1 into two separate ASNs for later examples.
Imagine that AS1 advertised a /24 prefix (1.1.42.0/24) to AS2 and AS3, and that AS2 aggregated this to a /16 (1.1.0.0/16) before sending it to AS3. Now, further imagine that both AS2 and AS3 were transit providers to the rest of the Internet, and advertised their prefixes out.
The rest of the Internet would see a /24 via AS3, and a /16 via AS2. Following the longest match rule, all packets to anything in 1.1.42.0/24 would go via AS3 even though R3 in AS1 indicated that both links were available.
The solution is that AS2 must also advertise the /24 in addition to the /16. It is not necessary to advertise all the component routes, just the ones that need to stand alone on the Internet. This is called “punching a hole”, and is often necessary for sites to be properly multihomed. This comes up in many cases where an AS got its address space from a provider rather than obtaining provider independant space from ARIN. In this example, it is possible that AS1 started off with address space from AS2 before becoming multihomed.
In the example above, R3 has several networks in the 10/8 space it can aggregate to R0 in AS4:
r0#show ip bgp 10.0.0.0/8 longer-prefixes
BGP table version is 7, local router ID is 10.0.0.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.1.1.0/24 10.50.0.2 0 1 2 i
*> 10.2.2.0/24 10.50.0.2 0 1 3 i
*> 10.3.3.0/24 10.50.0.2 0 0 1 i
Using “aggregate-address” under the BGP configuration on R3, we can force it to only advertise a summary route:
r3(config-router)#aggregate-address 10.0.0.0 255.0.0.0 summary-only
r0#show ip bgp 10.0.0.0/8 longer-prefixes
BGP table version is 11, local router ID is 10.0.0.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 10.50.0.2 0 1 i
R3 doesn’t discriminate when it sends out the summary, so R2 and R1 also see it:
r2#show ip bgp 10.0.0.0/8 longer-prefixes BGP table version is 14, local router ID is 10.2.2.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.0.0.0 192.168.3.5 0 1 i *> 10.1.1.0/24 192.168.3.9 0 200 0 2 i *> 10.2.2.0/24 0.0.0.0 0 32768 i
Interestingly enough, r3 shows that it is suppressing the more specific routes, and has created a route to Null0 representing the aggregate (remember anything more specific that exists will be in R3’s routing table, and won’t hit the Null0 bit bucket)
r3#show ip bgp
BGP table version is 16, local router ID is 10.3.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0 0.0.0.0 32768 i
s> 10.1.1.0/24 192.168.3.2 0 0 2 i
s> 10.2.2.0/24 192.168.3.6 0 0 3 i
s 192.168.3.2 0 2 3 i
s> 10.3.3.0/24 0.0.0.0 0 32768 i
r3#show ip route
...
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 10.0.0.0/8 [200/0] via 0.0.0.0, 00:44:14, Null0
B 10.2.2.0/24 [20/0] via 192.168.3.6, 02:37:15
B 10.1.1.0/24 [20/0] via 192.168.3.2, 02:42:55
C 10.3.3.0/24 is directly connected, Loopback5
C 10.50.0.0/24 is directly connected, Ethernet0
In this case it’s fine because the intended goal is met, but if anything in the 10/8 space existed elsewhere we might find some bad routing.
On R0 it knows this is an aggregate:
r0#show ip bgp 10.0.0.0
BGP routing table entry for 10.0.0.0/8, version 11
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
1, (aggregated by 1 10.3.3.1)
10.50.0.2 from 10.50.0.2 (10.3.3.1)
Origin IGP, localpref 100, valid, external, atomic-aggregate, best
The problem, though, is that the AS-PATH to the aggregate doesn’t include any of the component ASNs. Since this is used for loop avoidance, routing loops can be introduced in larger systems.
The as-set option to the aggregate-address command brings forward some of these things:
r3(config)#router bgp 1
r3(config-router)#no aggregate-address 10.0.0.0 255.0.0.0 summary-only
r3(config-router)# aggregate-address 10.0.0.0 255.0.0.0 summary-only as-set
r0#show ip bgp 10.0.0.0 255.0.0.0 longer-prefixes
...
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0 10.50.0.2 0 1 {2,3} i
r0#show ip bgp 10.0.0.0
BGP routing table entry for 10.0.0.0/8, version 19
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Not advertised to any peer
1 {2,3}, (aggregated by 1 10.3.3.1)
10.50.0.2 from 10.50.0.2 (10.3.3.1)
Origin IGP, localpref 100, valid, external, best
The {2,3} shows that these AS contributed to the aggregate. atomic-aggregate has also disappeared, since the information has been included.
The last thing I’ll try today is leaving out summary-only and putting in as-set:
r3#show ip bgp 10.0.0.0 255.0.0.0 longer-prefixes
BGP table version is 5, local router ID is 10.3.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0 0.0.0.0 32768 {2,3} i
*> 10.1.1.0/24 192.168.3.2 0 0 2 i
*> 10.2.2.0/24 192.168.3.6 0 0 3 i
* 192.168.3.2 0 2 3 i
*> 10.3.3.0/24 0.0.0.0 0 32768 i
r0#show ip bgp 10.0.0.0 255.0.0.0 longer-prefixes
BGP table version is 30, local router ID is 10.0.0.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 10.50.0.2 0 1 {2,3} i
*> 10.1.1.0/24 10.50.0.2 0 1 2 i
*> 10.2.2.0/24 10.50.0.2 0 1 3 i
*> 10.3.3.0/24 10.50.0.2 0 0 1 i
As expected, we see an aggregate and the specific routes.
Next up, controlling the behaviour of the specific routes to filter what goes out, and controlling the makeup of that aggregate.
No user commented in " BGP Route Aggregation "
Follow-up comment rss or Leave a TrackbackLeave A Reply