BGP - Can an aggregate-address suppress another aggregate-address on the same router?

Or can an aggregate-address aggregate another aggregate-address on the same router?

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. And 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 configuration 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 bgp 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"

Anyhow, you may want to keep that in mind.