Aggregate only, suppressing more specific routes

Setup: This example network is based on the topology outlined on page 343 of Internet Routing Architectures.

First we look at the BGP Table without aggregates or any summary.

RTC>sh ip bgp
BGP table version is 27, local router ID is 192.68.11.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
*> 172.16.1.0/24 192.68.6.1 0 2 3 i
*> 172.16.65.0/26 192.68.6.1 0 2 3 i
*> 172.16.220.0/24 192.68.6.1 0 2 3 i
*> 192.68.10.0 192.68.6.1 0 0 2 i
*> 192.68.11.0 0.0.0.0 0 32768 i

In our example we have three "172.16.0.0" networks that we will aggregate with the command:

aggregate-address 172.16.0.0 255.255.0.0 summary-only

The "summary only" option makes sure no more-specific routes than the aggregate will be advertised.

You do not need to "clear ip bgp address soft out" for this to take effect as you would with a route-map.

Let’s have a look at the new BGP table on our BGP neighbour.

RTC>sh ip bgp
BGP table version is 30, local router ID is 192.68.11.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
* 172.16.0.0 192.68.6.1 0 2 3 i
*> 172.16.20.2 0 0 3 i
*> 192.68.10.0 192.68.6.1 0 0 2 i
*> 192.68.11.0 0.0.0.0 0 32768 i

As we expected, a reduced BGP table. We can discover further information about our aggregate network with the "show ip bgp address" command.

RTC>sh ip bgp 172.16.0.0
BGP routing table entry for 172.16.0.0/16, version 15
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.68.6.1
2 3, (aggregated by 3 192.68.5.1)
192.68.6.1 from 192.68.6.1 (192.68.10.1)
Origin IGP, localpref 100, valid, external, atomic-aggregate
3, (aggregated by 3 172.16.2.254)
172.16.20.2 from 172.16.20.2 (172.16.2.254)
Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best
RTC>

This gives us details of the "atomic-aggregate" attribute and which AS and Router it was set by.

Static Routes into BGP

Rather than the above example which relied on dynamic routing with each network defined in the routers BGP configuration a static route can be set.

With the following commands we will remove the aggregate configuration & networks.

RTF#conf t
Enter configuration commands, one per line. End with CNTL/Z.
RTF(config)#router bgp 3
RTF(config-router)#no aggregate-address 172.16.0.0 255.255.0.0 summary-only
RTF(config-router)#no network 172.16.1.0 255.255.255.0
RTF(config-router)#no network 172.16.65.0 255.255.255.192
RTF(config-router)#no network 172.16.220.0 255.255.255.0

Then install a network that advertises the aggregate address.

RTF(config-router)#network 172.16.0.0
RTF(config-router)#exit

Along with a static address.

RTF(config)#ip route 172.16.0.0 255.255.0.0 null0
RTF(config)#end

Remember with BGP, the process will only advertise a network that is in the ip routing table so we need to add the static ip route so it appears in the said routing table. The null0 interface ensures that if the 172.16.0.0 network router has no knowledge of more-specific routes than the traffic is sent to the "bit bucket" rather than possibly creating a routing loop.

We can run the show ip bgp commands from our neighbour router to verify our configurations. The basic "show ip bgp" will give us the same table as our aggregated table, however if we "show ip bgp 172.16.0.0" you will notice the lack of atomic-aggregate attributes.

You can auto-magically aggregate address with the "auto-summary" command under Cisco BGP configuration but not in Zebra/Quagga so it’s probably better not to. Plus I find it more re-assuring to have the aggregate looking back at me when I’m scanning through the runn/start conf.