Punching Holes with BGP Aggregation
Last week I started in on BGP Route Aggregation, used to reduce the number of routes advertised in the global tables and to increase stability. This article will look at fine tuning the advertisements sent out when using the aggregate-address command.
First, I left off one method of advertising an aggregate, which is creating a local route to Null0 representing the aggregate, and advertise the route with the network statement. The Null0 route is required because the identical route must appear in the routing tables to advertise a network. For example, if you were advertising 10.0.0.0/16 with network 10.0.0.0 mask 255.255.0.0, you would need a statement like ip route 10.0.0.0 255.255.0.0 Null0.
The aggregate-address command behaves differently. If any component of the route (such as 10.0.1.0/24 in the above example) is available, the aggreate is advertised.
Back to our example network. Pretend for a moment that R0 and R2 had an eBGP peering, and R1 was advertising a /24 out of AS1's allocation to both AS1 and AS3. AS1 aggregates all its address space into one /16. R0 gets a /16 from AS1 and a /24 from AS3, and will always choose the /24 since it's a longer match.
What we need is a way to selectively punch holes in our advertisements, such as to advertise the /16 and the /24. While we could use a distribute-list at the peer level, it is easier to use a suppress-map at the same spot where we generate the aggregate.
Looking back on the config of R3 from last week:
router bgp 1 aggregate-address 10.0.0.0 255.0.0.0 as-set
And looking at one of its neighbours:
r0#show ip bgp
BGP table version is 7, local router ID is 9.9.9.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
For now, we only want the 10.2.2.0/24 prefix to come through.
router bgp 1 aggregate-address 10.0.0.0 255.0.0.0 as-set suppress-map filter-specifics ! access-list 5 deny 10.2.2.0 access-list 5 permit any ! route-map filter-specifics permit 10 match ip address 5
I'll explain that in a bit, but first let's check to see if it was successful:
r0#show ip bgp
...
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0 10.50.0.2 0 1 {2,3} i
*> 10.2.2.0/24 10.50.0.2 0 1 3 i
r2#show ip bgp
...
Network Next Hop Metric LocPrf Weight Path
*> 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, r2 and r1 don't see the aggregate, since the as-set option puts their AS in the AS_SET path attribute. When they see their own AS there, they reject the route since it would form a loop. Hold onto that thought.
Back to the config above. access-list 5 matches the exact prefix of 10.2.2.0 and denys it, permitting anything else. The route-map permits anything that is matched by the ACL. The suppress-map references the route map.
Here's the thing to know about suppress-maps:
Anything permitted by the suppress-map is suppressed (denied). Anything denied by the suppress-map is advertised (permitted).
It's completely counter-intuitive. Regardless, once you get by that, it's a simple matter of figuring out what you want to allow and how you want to match it, making sure it gets denied, and then creating the suppress map. In this case I chose to use a standard access-list because it's an easy way to match a particular route (and I was reading through Doyle Volume II last night, and he switches around all the time too).
Rather than matching on a particular route, how about matching on the originating AS? For instance, all the routes coming from AS2 will be allowed through, anything else will be suppressed:
router bgp 1 aggregate-address 10.0.0.0 255.0.0.0 as-set suppress-map filter-specifics ! ip as-path access-list 1 deny _2$ ip as-path access-list 1 permit .* ! route-map filter-specifics permit 10 match as-path 1
r3#show ip bgp
BGP table version is 7, 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, ? - incompleteNetwork 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
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
So, only the 10.1.1.0/24 component is allowed through because it originated in AS2 by way of the BGP regular expression:
_2$ means
_ : Match break between two AS, or no AS
2 : Match the literal 2
$ : Anchor to the end of the string.
This regular expression matches anything with 2 as the final AS hop. Since each peer prepends their ASN, the originating AS is at the end. Note that without the _, it would have matched the AS_PATH of 42. For more information on BGP regular expressions, see Using Regular Expressions in BGP and as regular expression. I hope to do an article on it later.
One final thought before I go. If a community is set on a component route, how is it treated? On R2 I sent 3:42 on the 10.2.2.0/24 route. After removing the suppression from R3, I can see the community:
r3#show ip bgp 10.2.2.0
BGP routing table entry for 10.2.2.0/24, version 20
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.50.0.1 192.168.3.2
3
192.168.3.6 from 192.168.3.6 (10.2.2.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 3:42
However, this community is then propagated to the aggregate:
r3#show ip bgp 10.0.0.0
BGP routing table entry for 10.0.0.0/8, version 21
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.50.0.1 192.168.3.2 192.168.3.6
{2,3}, (aggregated by 1 10.3.3.1)
0.0.0.0 from 0.0.0.0 (10.3.3.1)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best
Community: 3:42
Ick. What if the community was no-export?
The advertise-map option to aggregate-address selects the routes whose attributes are propagated to the aggregate. The attribute-map option allows you to set attributes.
So that's it for BGP aggregation.
References
[1]http://ccnprecertification.com/archives/bgp_route_aggregation-260705.html[2]http://ccnprecertification.com/archives/bgp21.html
[3]http://www.cisco.com/warp/public/459/26.html