Course contents

Module 4: BGP PolicyLesson 4.6 (6 of 8 in this module)28 of 43 in the BGP course

Route aggregation

The internet routing table is large because networks advertise every small prefix they own. Aggregation is how you tell the world about one block instead of four, and the AS path is why it needs care.

Advanced · 14 min read

You'll learn to configure aggregate-address with and without summary-only, explain as-set and atomic-aggregate, and predict what a neighbour receives.

Why aggregate

Each prefix in the BGP table costs memory on every router that holds it, and every change is an UPDATE that reaches all of them. An organisation with four neighbouring /24s that advertises each separately adds four entries to the global table. Advertised as a single /22 it adds one, and a flap inside it is invisible outside.

Four routes become one aggregate
Four routes become one aggregateFour /24 prefixes in the BGP table are covered by the aggregate 198.51.100.0/22 configured with aggregate-address. Without summary-only the neighbour receives the aggregate and the four specifics. With summary-only it receives only the aggregate.In the BGP table of R1198.51.100.0/24198.51.101.0/24198.51.102.0/24198.51.103.0/24aggregate-address198.51.100.0255.255.252.0Without summary-onlyNeighbour receives 5 routes:the /22 and the four /24sWith summary-onlyNeighbour receives 1 route:198.51.100.0/22

On small screens, swipe sideways or focus the diagram and use the arrow keys.

The /22 covers 198.51.100.0 to 198.51.103.255 exactly. The aggregate exists only while at least one more-specific route is in the BGP table.

Configuring aggregate-address

The aggregate is created inside the BGP address family. Without options, it is advertised together with the more-specific routes: the neighbour gets the /22 and the four /24s, so nothing is saved and only the covering route is added.

router bgp 64500 address-family ipv4 unicast aggregate-address 198.51.100.0 255.255.252.0 summary-only

R1. Creates 198.51.100.0/22 while any contributor is in the BGP table, and with summary-only suppresses the four /24 contributors towards every neighbour.

What happens when you add the command
What happens when you add the commandFour events, in order.ContributorA /24 insidethe /22 is in BGPAggregate/22 created,weight 32768DiscardNull0 route,AD 200AdvertiseNeighbours getthe /22

On small screens, swipe sideways or focus the diagram and use the arrow keys.

When the last contributor disappears, the aggregate and its discard route are removed too.
Illustrative Cisco IOS XE output written for this lesson, not a router capture
R1#show ip bgp 198.51.100.0/22
BGP routing table entry for 198.51.100.0/22, version 6
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Local, (aggregated by 64500 192.0.2.254)
    0.0.0.0 from 0.0.0.0 (192.0.2.254)
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best
aggregated by 64500 192.0.2.254 is the AGGREGATOR attribute: which AS and which router built the summary. atomic-aggregate warns that path information was lost in summarising.
Illustrative Cisco IOS XE output written for this lesson, not a router capture
R1#show ip route 198.51.100.0 255.255.252.0
Routing entry for 198.51.100.0/22
  Known via "bgp 64500", distance 200, metric 0, type locally generated
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1
The router installs the aggregate in the RIB pointing to Null0 with an administrative distance of 200. It is the same idea as the static discard route for a network statement: addresses inside the block with no real route are dropped instead of following a default somewhere else, which prevents a loop.

summary-only or not

What the neighbour receives
What the neighbour receivesWith and without summary-only.No summary-only/22 plus four /24sFive routesNeighbour can stillprefer a /24summary-only/22 onlyOne routeSpecifics stay localvs

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Without summary-only the only gain is that the covering route exists. With it, the table the neighbour holds really shrinks.

Without summary-only the more-specific routes are still sent. That is sometimes what you want. Traffic engineering across two providers often means advertising the /22 to both and the /24s only to one so inbound traffic prefers it, since the longest match wins.

Control which routes are suppressed

summary-only is all or nothing. When you need to suppress some specifics and send others, use a suppress-map to name the routes to hide, and an unsuppress-map to let a hidden route through to one neighbour only.

Aggregate options
Aggregate optionsThe keywords after the prefix and what each one does.summary-onlySuppress every more-specific routesuppress-map NAMESuppress only routes theroute map permitsunsuppress-map NAMELet selected suppressed routesthrough to one neighbourattribute-map NAMESet attributes on the aggregate(community, MED and so on)as-setKeep AS numbers of contributorsin the AS path

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Combine options on one aggregate-address line. summary-only and suppress-map do the same job in different ways.
ip prefix-list HIDE-THESE seq 5 permit 198.51.101.0/24 ip prefix-list HIDE-THESE seq 10 permit 198.51.103.0/24 ! route-map SUPPRESS-SOME permit 10 match ip address prefix-list HIDE-THESE ! router bgp 64500 address-family ipv4 unicast aggregate-address 198.51.100.0 255.255.252.0 suppress-map SUPPRESS-SOME

R1. Hides two of the four contributors and still advertises the other two alongside the aggregate.

The AS path of an aggregate: atomic-aggregate and as-set

The AS path is how BGP prevents loops. If four routes with different AS paths become one aggregate with an empty path, that information is gone. BGP gives you two attributes to deal with it.

The AS path grows by one AS at every eBGP hop
The AS path grows by one AS at every eBGP hopAS 64503 originates 203.0.113.0/24 with an empty AS path inside its own AS. It sends the route to AS 64501, which sees AS path 64503 and adds its own number when passing it to AS 64500, which sees AS path 64501 64503.Prefix 203.0.113.0/24AS 64503Originates the prefixAS_PATH: (empty)AS 64501ISP AAS_PATH: 64503AS 64500Your companyAS_PATH: 64501 64503UPDATEUPDATEIf AS 64500 saw 64500 inside the path, it would drop the route

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Each AS prepends its own number when it advertises a route to an eBGP neighbour. A router that finds its own AS number in a path drops the route, which is how BGP prevents loops.
  • ATOMIC_AGGREGATE is a flag. It says: this route is a summary, and AS path information was dropped. Receivers must not de-aggregate it into more specifics. IOS sets it automatically when contributors had AS paths and they were not kept.
  • AS_SET keeps the AS numbers. With as-set, the aggregate carries an unordered set of every AS from the contributors, such as {64501 64502}, so loop prevention still works. An AS_SET counts as a single hop for path length. The ATOMIC_AGGREGATE flag is then not set.
Illustrative Cisco IOS XE output written for this lesson, not a router capture
R1#show ip bgp 198.51.100.0/22
BGP routing table entry for 198.51.100.0/22, version 9
Paths: (1 available, best #1, table default)
  {64501,64502}, (aggregated by 64500 192.0.2.254)
    0.0.0.0 from 0.0.0.0 (192.0.2.254)
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best
With as-set the AS numbers of the contributors appear in braces where the AS path goes. Note the missing atomic-aggregate flag. The cost: if a contributor flaps or changes AS path, the aggregate changes too, which sends an UPDATE and can be unstable.

Troubleshooting an aggregate that is missing

Why is there no aggregate
Why is there no aggregateThree checks in order.Contributorshow ip bgpa /24 inside?ValidIs it validand not filtered?Advertisedneighbor ...advertised-routes

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Aggregation reads the BGP table, not the routing table.

The most common mistake is expecting the aggregate when the contributors are only in the RIB. A static or OSPF route inside the block is not enough. It must be in the BGP table, which means a network statement or redistribution for it.

Technical reference: RFC 4271, section 9.2.2.2 on aggregation, and RFC 4632, CIDR. Output above is illustrative.

Check your understanding

Predict · scenario 1

You configure aggregate-address 198.51.100.0 255.255.252.0 with no keywords. How many routes does a neighbour receive for that block?

Predict · scenario 2

The routing table has a static route for 198.51.101.0/24 but no BGP route for it. No other contributor exists. What happens to the aggregate?

Predict · scenario 3

Why would you add as-set to an aggregate built from routes learned from two different ASes?

FAQ

Why is my aggregate not in the BGP table?
An aggregate is created only while at least one more-specific route that falls inside it is in the BGP table. Check that a contributor exists with show ip bgp, not only in the routing table.
Does summary-only stop traffic reaching the more-specific networks?
No. It only stops the specifics being advertised to neighbours. Your own router still holds them and forwards by longest match.
When do I need as-set?
When the contributing routes come from different autonomous systems and you want the aggregate to keep their AS numbers, so loop prevention still works and downstream filters can see the origins.