Aggregation and Deaggregation
Last updated
Last updated
Topology: russo-bgp-iol
Load unix:agg.init.cfg
R1 is announcing 192.0.2.128/27 and 192.0.2.160/27.
Aggregate these into a /26 on R4 and suppress the more-specifics.
Include R1’s ASN so that it will reject this aggregate from being advertised back to itself.
On R6, deaggregate this into 192.0.2.129/32 and 192.0.2.130/32.
Include a no-export community on the deaggregated prefixes so that these are not advertised back to ASN 65000.
Likewise for IPv6, R1 is announcing 2001:db8:100::/64 and 2001:db8:101::/64.
Aggregate these into a /40 on R4, supressing more-specifics and including R1’s ASN.
Deaggregate this into 2001:db8:100::1/128 and 2001:DB8:100::2/128 on R6, including a no-export community.
When creating an aggregate, the default behavior is:
Specifics are not suppressed
Suppress all specifics using summary-only
Suppress select specifics using suppress-map
Unsuppress specifics on a per-neighbor basis using neighbor unsuppress-map
The AS path information is lost, and all attributes are lost. Attributes are reset.
Include the attributes of the component routes using as-set. This creates an AS_PATH_SET attribute which is an unordered list of ASNs the aggregate has been generated from. This restores loop prevention. Additionally, attributes such as the community are included on the aggregate.
To set particular attributes, for example reset the community, use an attribute-map on the aggregate
To control which specifics contribute to the aggregate, and therefore have their attributes contributed when using as-set, use advertise-map
The ATOMIC_AGGREGATE attribute is created, which is just a tag that this is an aggregated route
The AGGREGATOR attribute is created, using the router’s RID and ASN
A router can deaggregate an aggregate into more specifics. This is configuration intensive, because you need a few route-maps and prefix-lists to do this. You match the aggregate using a prefix-list and a nexthop. You then create the more specifics using set ip address prefix-list. An example for IPv4 is below:
On R4 we can see that the aggregates have been correctly created. They include ASN 65001. Because there are no other ASNs contributing to the aggregate, this does not have to be an AS_PATH_SET.
We can also see that R4 is suppressing the more-specifics to R6:
The more-specific prefixes are marked with an s in the local BGP RIB on R4:
On R6, we see that the router has created the deaggregated prefixes, and they contain the correct no-export community.
A neat show command for displaying the deaggregated prefixes is show bgp ipv4 uni injected-paths.
If we remove the aggregates on R4, the injected-paths are no longer present on R6 (verified in the lab, but not shown).
