BGP Atomic Aggregate

When a router performs aggregation in BGP, there are some options that can allow the aggregate and the aggregated routes to be passed on to the next neighbor or autonomous system.

The Atomic Aggregate is simply a Well-Known Optional attribute that specifies that this is an aggregated route that might or might-not be originated from the advertising AS, that is because the aggregated route is a generated route, it technically doesn't exist, but it represents a contiguous group of addresses in just one.

In the topology shown above, R6 in AS 500 is originating the prefixes 192.168.1.0/24 through 192.168.6.0/24. these prefixes are then propagated to AS 600 then to AS 100. Let's see how they look on R1 in AS 100.

R1#show ip bgp | i 192

*> 192.168.1.0      8.8.8.8                                0 600 500 ?

*> 192.168.2.0      8.8.8.8                                0 600 500 ?

*> 192.168.3.0      8.8.8.8                                0 600 500 ?

*> 192.168.4.0      8.8.8.8                                0 600 500 ?

*> 192.168.5.0      8.8.8.8                                0 600 500 ?

*> 192.168.6.0      8.8.8.8                                0 600 500 ?

As the output shows above, the Originating AS is AS 500, then it traversed AS 600 to reach R1. Now let's perform Aggregation on R8 without suppressing the original /24 routes.

R8(config-router)#aggregate-address 192.168.0.0 255.255.0.0

R1#show ip bgp | i 192

*> 192.168.0.0/16   8.8.8.8                  0             0 600 i

*> 192.168.1.0      8.8.8.8                                0 600 500 ?

*> 192.168.2.0      8.8.8.8                                0 600 500 ?

*> 192.168.3.0      8.8.8.8                                0 600 500 ?

*> 192.168.4.0      8.8.8.8                                0 600 500 ?

*> 192.168.5.0      8.8.8.8                                0 600 500 ?

*> 192.168.6.0      8.8.8.8                                0 600 500 ?

  

BGP routing table entry for 192.168.0.0/16, version 21

Paths: (1 available, best #1, table default)

  Not advertised to any peer

  600, (aggregated by 600 8.8.8.8)

    8.8.8.8 from 8.8.8.8 (8.8.8.8)

      Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best

As shown in the above output, the aggregated route from R1 prospective is originated from AS 600 , and it is indicated that update that this is an aggregated route. R1 can't confirm if this route was originated in AS 600 or not. Now let's suppress the other routes to show how this can be confusing if you're trying to know the source of these prefixes by adding the summary-only  to the aggregation command on R8

R8(config-router)#aggregate-address 192.168.0.0 255.255.0.0 summary-only

R1#show ip bgp | i 192

*> 192.168.0.0/16   8.8.8.8                  0             0 600 i

as you can see, R1 can only see the aggregated route and it's origin is AS 600 which can be very misleading. Let's see a capture of the BGP update packet to go in deep into it

Well, the capture here explains it in depth to make it really easy to understand what's going on. There are 2 BGP updates, the first one is for the aggregated route which described the prefix and the originating AS which is 600. while the other BGP updates tells router R1 to withdraw the more specific prefixes which show's how the summary-only works

Of course BGP is a policy protocol which is capable of almost anything when it comes to prefix manipulation, and also to preserve the integrity of the routes between different ASs since service providers might only accept certain prefixes which is originating from their real originating AS as a part of prefix origin validation. There's another option that keeps the originating AS in the atomic aggregate update which is as-set. Now let's add the as-set option to the aggregate command and see how would that affect the aggregated prefix origin.

R8(config-router)#aggregate-address 192.168.0.0 255.255.0.0 summary-only as-set

R1#show ip bgp | i 192

*> 192.168.0.0/16   8.8.8.8                  0             0 600 500 ?

R1#show ip bgp 192.168.0.0

BGP routing table entry for 192.168.0.0/16, version 28

Paths: (1 available, best #1, table default)

  Not advertised to any peer

  600 500, (aggregated by 600 8.8.8.8)

    8.8.8.8 from 8.8.8.8 (8.8.8.8)

      Origin incomplete, metric 0, localpref 100, valid, external, best

Now it looks like R1 is getting the origin of 192.168.0.0/16 as AS 500. Unfortunately, R1 can never be sure if the smaller prefixes was originated by AS 500 because AS 500 might have aggregated the /24 subnets from another AS into /18 for example and then R8 aggregated those /18 into a /16. All R1 knows that smaller prefixes from AS 500 was aggregated at R8 in AS 600.