Today i was playing with BGP a little (i found some time to prepare for my CCIP) and here is what i found out:
Suppose you have the following config on a router:
interface Loopback1 ip address 1.1.1.1 255.255.255.128 ! router bgp 1 no synchronization bgp log-neighbor-changes network 1.1.1.0 mask 255.255.255.128 aggregate-address 1.1.0.0 255.255.0.0 summary-only aggregate-address 1.1.1.0 255.255.255.0 summary-only neighbor 10.10.10.2 remote-as 2 no auto-summary
What do you think “sh ip bgp” will show? (please take some time and think about it…)
To be honest, as a first thought i was hoping it would display only the 1.1.0.0/16 summary, which actually “overlaps” the 1.1.1.0/24 summary.
Guess what?
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
*> 1.1.0.0/16 0.0.0.0 32768 i
s> 1.1.1.0/25 0.0.0.0 0 32768 i
*> 1.1.1.0/24 0.0.0.0 32768 i
According to Cisco, in order to aggregate an address, you must have a more-specific route of that address in the BGP table. An if you want the more-specific route to be suppressed, you must use the “summary-only” keyword.
So, if we want to be as strict as possible, in our case we do have a more-specific route in the BGP table (and in the routing table).
R1#sh ip bgp 1.1.1.0/24
BGP routing table entry for 1.1.1.0/24, version 5
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.10.10.2
Local, (aggregated by 1 1.1.1.1)
0.0.0.0 from 0.0.0.0 (1.1.1.1)
Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best
R1#
R1#sh ip route 1.1.1.0 255.255.255.0
Routing entry for 1.1.1.0/24
Known via "bgp 1", distance 200, metric 0, type locally generated
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 0, traffic share count is 1
AS Hops 0
Although the aggregation part seems to be working fine (it actually isn’t), the suppression one isn’t. As it seems, an aggregate-address cannot suppress another more-specific aggregate-address, when both are created locally in the same router.
Now, let’s change the config and make it more interesting by removing the “summary-only” keyword from the more-specific aggregate-address :
router bgp 1
no synchronization
bgp log-neighbor-changes
network 1.1.1.0 mask 255.255.255.128
aggregate-address 1.1.0.0 255.255.0.0 summary-only
aggregate-address 1.1.1.0 255.255.255.0
neighbor 10.10.10.2 remote-as 2
no auto-summary
R1#clear ip bgp *
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
*> 1.1.0.0/16 0.0.0.0 32768 i
s> 1.1.1.0/25 0.0.0.0 0 32768 i
*> 1.1.1.0/24 0.0.0.0 32768 i
What do you think of that? We still have the same output. The more-specific (lower level) aggregate-address is not suppressed, but the more-specific network is (by the 1.1.0.0/16 aggregate-address).
Why is that? Although i’m not sure, looking at the following debugs (after adding another level of aggregation using the “aggregate-address 1.0.0.0 255.0.0.0 summary-only” command and reseting the gp session), i have come to this explanation:
*Mar 1 02:28:52.107: BGP(0): nettable_walker 1.1.1.0/25 route sourced locally *Mar 1 02:28:52.111: BGP(0): Aggregate processing for IPv4 Unicast *Mar 1 02:28:52.111: BGP(0): For aggregate 1.0.0.0/8 *Mar 1 02:28:52.111: BGP(0): 1.0.0.0/8 subtree has an entry 1.1.1.0/25 *Mar 1 02:28:52.115: BGP(0): sub-prefix : 1.1.1.0/25 *Mar 1 02:28:52.115: BGP(0): Needs to be re-aggregated *Mar 1 02:28:52.115: BGP(0): 1.0.0.0/8 subtree has an entry 1.1.1.0/25 *Mar 1 02:28:52.115: BGP(0): 1.0.0.0/8 aggregate has 1.1.1.0/25 more-specific *Mar 1 02:28:52.115: BGP(0): 1.0.0.0/8 aggregate created, attributes updated *Mar 1 02:28:52.115: BGP(0): created aggregate route for 1.0.0.0/8 *Mar 1 02:28:52.115: BGP(0): 1.0.0.0/8 subtree has an entry 1.0.0.0/8 *Mar 1 02:28:52.115: BGP(0): 1.0.0.0/8 subtree has another entry 1.1.1.0/25 *Mar 1 02:28:52.115: BGP(0): Found sub-prefix 1.1.1.0/25: suppressed *Mar 1 02:28:52.115: BGP(0): For aggregate 1.1.0.0/16 *Mar 1 02:28:52.115: BGP(0): 1.1.0.0/16 subtree has an entry 1.1.1.0/25 *Mar 1 02:28:52.115: BGP(0): sub-prefix : 1.1.1.0/25 *Mar 1 02:28:52.115: BGP(0): Needs to be re-aggregated *Mar 1 02:28:52.115: BGP(0): 1.1.0.0/16 subtree has an entry 1.1.1.0/25 *Mar 1 02:28:52.115: BGP(0): 1.1.0.0/16 aggregate has 1.1.1.0/25 more-specific *Mar 1 02:28:52.115: BGP(0): 1.1.0.0/16 aggregate created, attributes updated *Mar 1 02:28:52.115: BGP(0): created aggregate route for 1.1.0.0/16 *Mar 1 02:28:52.115: BGP(0): 1.1.0.0/16 subtree has an entry 1.1.0.0/16 *Mar 1 02:28:52.115: BGP(0): 1.1.0.0/16 subtree has another entry 1.1.1.0/25 *Mar 1 02:28:52.115: BGP(0): Found sub-prefix 1.1.1.0/25: suppressed *Mar 1 02:28:52.115: BGP(0): For aggregate 1.1.1.0/24 *Mar 1 02:28:52.115: BGP(0): 1.1.1.0/24 subtree has an entry 1.1.1.0/25 *Mar 1 02:28:52.115: BGP(0): sub-prefix : 1.1.1.0/25 *Mar 1 02:28:52.115: BGP(0): Needs to be re-aggregated *Mar 1 02:28:52.115: BGP(0): 1.1.1.0/24 subtree has an entry 1.1.1.0/25 *Mar 1 02:28:52.115: BGP(0): 1.1.1.0/24 aggregate has 1.1.1.0/25 more-specific *Mar 1 02:28:52.115: BGP(0): 1.1.1.0/24 aggregate created, attributes updated *Mar 1 02:28:52.115: BGP(0): created aggregate route for 1.1.1.0/24 *Mar 1 02:28:52.115: BGP(0): 1.1.1.0/24 subtree has an entry 1.1.1.0/25 *Mar 1 02:28:52.115: BGP(0): Found sub-prefix 1.1.1.0/25: suppressed *Mar 1 02:28:52.115: BGP(0): Found sub-prefix 1.1.1.0/24: *Mar 1 02:28:52.115: BGP(0): Revise route installing 1 of 1 route for 1.0.0.0/8 -> 0.0.0.0 to main IP table *Mar 1 02:28:52.119: RT: network 1.0.0.0 is now variably masked *Mar 1 02:28:52.119: RT: add 1.0.0.0/8 via 0.0.0.0, bgp metric [200/0] *Mar 1 02:28:52.119: RT: NET-RED 1.0.0.0/8 *Mar 1 02:28:52.119: BGP(0): Revise route installing 1 of 1 route for 1.1.0.0/16 -> 0.0.0.0 to main IP table *Mar 1 02:28:52.119: RT: add 1.1.0.0/16 via 0.0.0.0, bgp metric [200/0] *Mar 1 02:28:52.119: RT: NET-RED 1.1.0.0/16 *Mar 1 02:28:52.119: BGP(0): nettable_walker 1.1.1.0/25 route sourced locally *Mar 1 02:28:52.119: BGP(0): Revise route installing 1 of 1 route for 1.1.1.0/24 -> 0.0.0.0 to main IP table *Mar 1 02:28:52.119: RT: add 1.1.1.0/24 via 0.0.0.0, bgp metric [200/0] *Mar 1 02:28:52.119: RT: NET-RED 1.1.1.0/24
During the initial scanning, the aggregate processing algorithm of BGP doesn’t even check the locally aggregated addresses (is recursive scanning too difficult/dangerous to implement?), because they aren’t in the BGP routing table at the time of scanning (i guess if the scanning was happening from more-specific to less-specific, it would find them). So it checks only the networks that are injected into BGP through the 3 known ways (network command, redistribution, other ASs). In our case, every configured aggregate-address is aggregating and suppressing only the locally configured more-specific network. Specifically, the more-specific local network is aggregated & suppressed 3 times, one for each aggregate-address definition.
The result?
R1#sh ip bgp
BGP table version is 6, 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
*> 1.0.0.0 0.0.0.0 32768 i
*> 1.1.0.0/16 0.0.0.0 32768 i
s> 1.1.1.0/25 0.0.0.0 0 32768 i
*> 1.1.1.0/24 0.0.0.0 32768 i
If we add the less-specific aggregate after the BGP has already started, we get different debug logs:
*Mar 1 00:05:26.995: BGP(0): Aggregate processing for IPv4 Unicast *Mar 1 00:05:26.995: BGP(0): For aggregate 1.0.0.0/8 *Mar 1 00:05:26.995: BGP(0): 1.0.0.0/8 subtree has an entry 1.1.0.0/16 *Mar 1 00:05:26.999: BGP(0): sub-prefix : 1.1.0.0/16 *Mar 1 00:05:26.999: BGP(0): Needs to be re-aggregated *Mar 1 00:05:26.999: BGP(0): 1.0.0.0/8 subtree has an entry 1.1.0.0/16 *Mar 1 00:05:27.003: BGP(0): 1.0.0.0/8 aggregate has 1.1.1.0/25 more-specific *Mar 1 00:05:27.007: BGP(0): 1.0.0.0/8 aggregate created, attributes updated *Mar 1 00:05:27.007: BGP(0): created aggregate route for 1.0.0.0/8 *Mar 1 00:05:27.011: BGP(0): 1.0.0.0/8 subtree has an entry 1.0.0.0/8 *Mar 1 00:05:27.011: BGP(0): 1.0.0.0/8 subtree has another entry 1.1.0.0/16 *Mar 1 00:05:27.011: BGP(0): Found sub-prefix 1.1.0.0/16: not suppressed *Mar 1 00:05:27.011: BGP(0): Found sub-prefix 1.1.1.0/25: suppressed *Mar 1 00:05:27.011: BGP(0): Found sub-prefix 1.1.1.0/24: not suppressed *Mar 1 00:05:27.011: BGP(0): For aggregate 1.1.0.0/16 *Mar 1 00:05:27.011: BGP(0): 1.1.0.0/16 subtree has an entry 1.1.0.0/16 *Mar 1 00:05:27.011: BGP(0): 1.1.0.0/16 subtree has another entry 1.1.1.0/25 *Mar 1 00:05:27.011: BGP(0): sub-prefix : 1.1.1.0/25 *Mar 1 00:05:27.011: BGP(0): Needs to be re-aggregated *Mar 1 00:05:27.011: BGP(0): 1.1.0.0/16 subtree has an entry 1.1.0.0/16 *Mar 1 00:05:27.011: BGP(0): 1.1.0.0/16 subtree has another entry 1.1.1.0/25 *Mar 1 00:05:27.011: BGP(0): 1.1.0.0/16 aggregate has 1.1.1.0/25 more-specific *Mar 1 00:05:27.011: BGP(0): 1.1.0.0/16 aggregate updated *Mar 1 00:05:27.011: BGP(0): 1.1.0.0/16 subtree has an entry 1.1.0.0/16 *Mar 1 00:05:27.011: BGP(0): 1.1.0.0/16 subtree has another entry 1.1.1.0/25 *Mar 1 00:05:27.011: BGP(0): Found sub-prefix 1.1.1.0/25: suppressed *Mar 1 00:05:27.011: BGP(0): Found sub-prefix 1.1.1.0/24: not suppressed *Mar 1 00:05:27.011: BGP(0): For aggregate 1.1.1.0/24 *Mar 1 00:05:27.011: BGP(0): 1.1.1.0/24 subtree has an entry 1.1.1.0/25 *Mar 1 00:05:27.011: BGP(0): sub-prefix : 1.1.1.0/25 *Mar 1 00:05:27.011: BGP(0): Needs to be re-aggregated *Mar 1 00:05:27.011: BGP(0): 1.1.1.0/24 subtree has an entry 1.1.1.0/25 *Mar 1 00:05:27.011: BGP(0): 1.1.1.0/24 aggregate has 1.1.1.0/25 more-specific *Mar 1 00:05:27.011: BGP(0): 1.1.1.0/24 aggregate updated *Mar 1 00:05:27.011: BGP(0): 1.1.1.0/24 subtree has an entry 1.1.1.0/25 *Mar 1 00:05:27.011: BGP(0): Found sub-prefix 1.1.1.0/25: suppressed *Mar 1 00:05:27.011: BGP(0): Found sub-prefix 1.1.1.0/24: *Mar 1 00:05:27.011: BGP(0): Revise route installing 1 of 1 route for 1.0.0.0/8 -> 0.0.0.0 to main IP table *Mar 1 00:05:27.011: RT: add 1.0.0.0/8 via 0.0.0.0, bgp metric [200/0] *Mar 1 00:05:27.011: RT: NET-RED 1.0.0.0/8
This time, all the existing more-specific aggregates are scanned, but they are clearly not suppressed.
According to RFC 4271:
3.2. Routing Information Base
The Routing Information Base (RIB) within a BGP speaker consists of
three distinct parts:
a) Adj-RIBs-In: The Adj-RIBs-In stores routing information learned
from inbound UPDATE messages that were received from other BGP
speakers. Their contents represent routes that are available
as input to the Decision Process.
b) Loc-RIB: The Loc-RIB contains the local routing information the
BGP speaker selected by applying its local policies to the
routing information contained in its Adj-RIBs-In. These are
the routes that will be used by the local BGP speaker. The
next hop for each of these routes MUST be resolvable via the
local BGP speaker's Routing Table.
c) Adj-RIBs-Out: The Adj-RIBs-Out stores information the local BGP
speaker selected for advertisement to its peers. The routing
information stored in the Adj-RIBs-Out will be carried in the
local BGP speaker's UPDATE messages and advertised to its
peers.
...
The Decision Process takes place in three distinct phases, each
triggered by a different event:
a) Phase 1 is responsible for calculating the degree of preference
for each route received from a peer.
b) Phase 2 is invoked on completion of phase 1. It is responsible
for choosing the best route out of all those available for each
distinct destination, and for installing each chosen route into
the Loc-RIB.
c) Phase 3 is invoked after the Loc-RIB has been modified. It is
responsible for disseminating routes in the Loc-RIB to each
peer, according to the policies contained in the PIB. Route
aggregation and information reduction can optionally be
performed within this phase.
...
9.2.2.2. Aggregating Routing Information
Aggregation is the process of combining the characteristics of
several different routes in such a way that a single route can be
advertised. Aggregation can occur as part of the Decision Process to
reduce the amount of routing information that will be placed in the
Adj-RIBs-Out.
If someone else can provide a better (preferred technical) explanation for both cases, i would be very happy to hear it.
Btw, someone must tell Cisco to write more detailed docs :
“Aggregation applies only to routes that exist in the BGP routing table. An aggregated route is forwarded if at least one more specific route of the aggregation exists in the BGP routing table”