BGP aggregation — aggregate-address, summary-only, as-set, attribute inheritance

BGP aggregation is the operator’s tool for advertising a summary prefix while the RIB carries more-specific components. On VyOS 1.5 LTS / FRR 10.x the configuration lives under the address family — set protocols bgp address-family ipv4-unicast aggregate-address <prefix> — with options for summary-only, as-set, and a route-map for attribute control. The AS number is declared once, separately, as set protocols bgp system-as <asn>; a config that still carries the AS inside the path (set protocols bgp 64512 aggregate-address ...) is pre-1.4 and will not commit.

This lesson is the BGP-specific operator’s reference for the aggregate: when to use it, what the options do, what attributes the aggregate inherits from the more-specifics (and what it does not), how the atomic-aggregate flag is set, and how it fails in production.

What the aggregate-address does

The BGP aggregate-address statement installs a static entry in the BGP Loc-RIB for the configured prefix, but only if at least one more-specific component exists in the BGP table.

flowchart LR
  BGP["BGP table<br/>(more-specifics)"]
  AGG{"Aggregate has<br/>components?"}
  ASTATIC["Static aggregate entry"]
  SOMORE["More-specific entries<br/>(both kept by default)"]
  POLICY["Outbound policy"]
  PEER["BGP peer"]

  BGP --> AGG
  AGG -- "yes" --> ASTATIC
  AGG -- "no" --> X["Drop<br/>(no aggregate advertised)"]
  ASTATIC --> POLICY
  SOMORE --> POLICY
  POLICY --> PEER

The aggregate is generated when:

1. Components exist. At least one more-specific prefix that is a subnet of the aggregate prefix exists in the BGP table (locally originated, learned from a peer, or redistributed).
2. The component is selected. If the component is filtered out by inbound or outbound policy on the peer that sent it, the component may not be visible to the local router. The aggregate’s existence depends on what the local BGP table contains, not on what the peer’s BGP table contains.

The default behaviour:

• The aggregate is advertised alongside the more-specifics.
• The aggregate’s origin is derived from the components rather than fixed: the least-preferred origin among the contributing paths wins, so one incomplete component makes the whole aggregate incomplete. Read it off the router; do not assume.
• The aggregate has an empty AS-path and a weight of 32768 (locally originated).
• The aggregate has the next-hop of 0.0.0.0 (overwritten by outbound policy at advertise time).
• The aggregate has the atomic-aggregate flag set, unless as-set is configured — the flag is what tells a receiver that AS-path information was discarded in the aggregation.

The VyOS configuration

configure
set protocols bgp system-as 64512
set protocols bgp address-family ipv4-unicast aggregate-address 192.0.2.0/22
set protocols bgp neighbor 10.0.0.2 remote-as '64513'
commit
save

The aggregate is a property of the address family, not of the router as a whole: the IPv6 equivalent is the same leaf under address-family ipv6-unicast, and aggregating v4 does nothing for v6.

The prefix 192.0.2.0/22 summarises 192.0.2.0/24, 192.0.3.0/24, 192.0.4.0/24, and 192.0.5.0/24. If any of those more-specifics exists in the BGP table, the aggregate is generated.

vyos@r1:~$ show ip bgp

BGP table version is 7, 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, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.0.2.0/22     0.0.0.0                  0         32768 i
*> 192.0.2.0/24     0.0.0.0                  0         32768 i
*> 192.0.3.0/24     0.0.0.0                  0         32768 i
*> 192.0.4.0/24     0.0.0.0                  0         32768 i
*> 192.0.5.0/24     0.0.0.0                  0         32768 i

Note that the aggregate is alongside the more-specifics. The operator who wants only the aggregate advertised adds summary-only:

set protocols bgp address-family ipv4-unicast aggregate-address 192.0.2.0/22 summary-only

With summary-only, the more-specifics are marked suppressed (the s status code) and are not advertised. Only the aggregate leaves the router.

as-set — preserving the AS-path set

The default aggregate has an empty AS-path: the local router is the originator, and the path the traffic takes to the aggregate depends on the IGP routing to the local router. This is fine for intra-AS aggregation.

For inter-AS aggregation — the operator aggregates prefixes from multiple ASes into one summary — the empty AS-path is information loss. The peer receiving the aggregate cannot tell where the more-specifics originated, so the peer cannot make a routing decision based on origin AS.

flowchart TB
  subgraph "AS 64512"
    A["192.0.2.0/24"]
  end
  subgraph "AS 64513"
    B["192.0.3.0/24"]
  end
  subgraph "AS 64514"
    C["192.0.4.0/24"]
  end
  subgraph "AS 64515 (aggregator)"
    AGG["aggregate 192.0.2.0/22<br/>AS-path: empty (default)<br/>AS-path: {64512,64513,64514} (as-set)"]
  end

  A --> AGG
  B --> AGG
  C --> AGG

The fix is as-set:

set protocols bgp address-family ipv4-unicast aggregate-address 192.0.2.0/22 as-set
set protocols bgp address-family ipv4-unicast aggregate-address 192.0.2.0/22 summary-only

as-set and summary-only are two independent leaves on the same aggregate, not a compound keyword — set each one on its own line.

With as-set, the aggregate’s AS-path becomes a set of the AS-paths of the contributing more-specifics. The set is written with curly braces: {64512,64513,64514}. A set means the ASes are unordered (the route may have transited any of them, not necessarily all of them).

The set format has consequences:

• The aggregate’s AS-path length is 1 (the aggregator’s AS), regardless of how many components contributed. This is the aggregation rule in RFC 4271: when summarising, the path is replaced with the path to the aggregator.
• The set is unordered: peers cannot perform longest-match on the path, only membership checks.
• The aggregator attribute is added (RFC 4271 Section 5.1.7): the router-id and AS of the router that performed the aggregation.
• The atomic-aggregate flag is not set when as-set is used, because the AS-path information is preserved (in set form). Without as-set, the atomic-aggregate flag is set because the path is incomplete.

Attribute inheritance via route-map

By default, the aggregate’s attributes are local-origin defaults (empty AS-path, weight 32768, origin incomplete, next-hop 0.0.0.0). The operator can override any of these with a route-map:

set policy route-map AGG-OUT rule 10 action 'permit'
set policy route-map AGG-OUT rule 10 set community replace '64512:200'
set policy route-map AGG-OUT rule 10 set metric '100'

set protocols bgp address-family ipv4-unicast aggregate-address 192.0.2.0/22 route-map 'AGG-OUT'

The route-map is matched against the aggregate itself (not the more-specifics) and applied before the aggregate enters the Loc-RIB.

Inheritance from components is not automatic. If the operator wants the aggregate to inherit a community from any of the more-specifics, the route-map must be written to set the community explicitly. There is no “inherit from any component” toggle in FRR.

A common pattern: tag the aggregate with a community that distinguishes it from the more-specifics:

set policy route-map AGG-COMMUNITY rule 10 action 'permit'
set policy route-map AGG-COMMUNITY rule 10 set community add '64512:200'

On VyOS 1.5 set community is not a single leaf: it takes an explicit add or replace (or none), so there is no default behaviour to get wrong by omission. add appends to whatever the route already carries; replace discards the existing list first. On a freshly created aggregate the community list starts empty, so the two produce the same result here — but write the one you mean, because the same route-map reused on learned routes will not be so forgiving.

An older config carrying set community 64512:200 additive as one value is pre-1.4 and will not commit.

summary-only and the suppress filter

When summary-only is set, the more-specifics are flagged as suppressed. The suppression is automatic: FRR walks the BGP table at commit time and flags every prefix that is a subnet of the aggregate.

vyos@r1:~$ show ip bgp

BGP table version is 7, 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, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.0.2.0/22     0.0.0.0                  0         32768 i
s> 192.0.2.0/24     0.0.0.0                  0         32768 i
s> 192.0.3.0/24     0.0.0.0                  0         32768 i
s> 192.0.4.0/24     0.0.0.0                  0         32768 i
s> 192.0.5.0/24     0.0.0.0                  0         32768 i

The s> flag means “suppressed, was best”. The more-specifics are still in the BGP table (they’re reachable from the kernel), but they are not advertised to peers.

This affects routing in subtle ways:

• Recursive resolution — The aggregate has the same next-hop as the more-specifics (typically 0.0.0.0 for locally originated), so the router’s recursive lookup for the aggregate resolves to the local router. Forwarding works.
• iBGP propagation — The aggregate is sent to iBGP peers (who will then propagate the more-specifics to eBGP peers unless the iBGP peers also have their own summary-only configuration). Suppression is per-router.
• External peer view — The peer sees the aggregate and installs it as the route to the prefix. The peer does not see the more-specifics.

atomic-aggregate flag

The atomic-aggregate flag (RFC 4271 Section 5.1.6) is a flag on the BGP path that indicates “the AS-path is incomplete because the route was aggregated”.

Read it out of the per-prefix view rather than the table listing — show ip bgp 192.0.2.0/22 prints the path’s attributes, and an aggregate that discarded path information carries an atomic-aggregate marker alongside the aggregated indication and the aggregator’s AS and router-id. The table listing (show ip bgp with no prefix) has no column for it.

When the flag is set, the receiver knows the path is incomplete and must not de-aggregate the prefix or reason about its AS-path length. The flag is set when the aggregate is configured without as-set, because then the contributing AS numbers were simply dropped. With as-set, they were carried forward in set form, so nothing was silently discarded and the flag is not set.

If what you need is to accept the aggregate and reject its components — a genuinely common inbound policy — that is a prefix-list match, and it is worth writing out because the prefix-list syntax has its own shape:

set policy prefix-list AGG-ONLY rule 10 action 'permit'
set policy prefix-list AGG-ONLY rule 10 prefix '192.0.2.0/22'
set policy route-map AGG-IN rule 10 action 'permit'
set policy route-map AGG-IN rule 10 match ip address prefix-list 'AGG-ONLY'

Each rule carries a separate action and prefix leaf; the one-line rule 10 permit 192.0.2.0/22 form some vendors use does not exist here. And note the implicit deny: a route-map whose last rule does not match drops the route, so this route-map accepts the /22 and rejects everything else — which is the behaviour a peer’s “only accept the aggregate” filter has, and the direct cause of the failure in the last scenario of this lesson’s quiz.

Validation

# 1. The aggregate exists in the local BGP table
show ip bgp 192.0.2.0/22

# 2. The components are present (and suppressed if summary-only)
show ip bgp 192.0.2.0/24
show ip bgp 192.0.3.0/24
show ip bgp 192.0.4.0/24
show ip bgp 192.0.5.0/24

# 3. The aggregate is advertised to the peer
show ip bgp neighbors 10.0.0.2 advertised-routes

# 4. The more-specifics are NOT advertised (summary-only check)
show ip bgp neighbors 10.0.0.2 advertised-routes | match 192.0.2
# Should show only the /22, not the /24s

# 5. The path attributes, including the atomic-aggregate marker
show ip bgp 192.0.2.0/22

The pipe modifier is match; VyOS operational mode does not give you grep or include after a |.

If the operator sees the /22 in advertised-routes but the peer reports receiving nothing, the next hop or AS-path is likely the problem. The aggregate’s next-hop is 0.0.0.0, which the peer may not accept (eBGP peers typically expect the next-hop to be reachable).

# A common fix: rewrite the next-hop on the aggregate to the
# interface address of the peering link
set policy route-map OUT-v4 rule 10 action 'permit'
set policy route-map OUT-v4 rule 10 set ip-next-hop '10.0.0.1'
set protocols bgp neighbor 10.0.0.2 address-family ipv4-unicast route-map export 'OUT-v4'

Neighbour policy is per address family on 1.5, and the directions are named import and export rather than in and out.

Production failure modes

The aggregate does not exist

show ip bgp 192.0.2.0/22 returns nothing. The most common cause: no components exist. The aggregate is generated only when at least one more-specific exists in the BGP table.

Diagnostic:

• show ip bgp 192.0.2.0/24 — does the /24 exist?
• show ip bgp 192.0.3.0/24 — does the /24 exist?
• If none of the components is in the BGP table, the aggregate has nothing to summarise.

The fix: bring the components into the BGP table (network statement, redistribute, peer session) or remove the aggregate if it is not needed.

The aggregate is generated but the more-specifics are also advertised

The operator wanted summary-only, but the more-specifics are still in advertised-routes. Likely cause: the summary-only keyword is missing or was mistyped.

Diagnostic:

• show configuration commands | grep aggregate
• Confirm the line ends with summary-only.

The peer rejects the aggregate

The peer receives the UPDATE but does not install the aggregate. Likely causes:

• Next-hop unreachable — The aggregate has a next-hop of 0.0.0.0. eBGP peers reject next-hops in their own address space (martian) or in 0.0.0.0/0. The fix is to set the next-hop to the peering interface address via a route-map.
• AS-path loop — The peer’s AS is in the AS-path. The peer discards the UPDATE to prevent a loop. The fix is to check the topology.
• Inbound prefix-list — The peer’s inbound policy rejects the aggregate prefix.

Attribute loss

The aggregate is advertised with default attributes (empty AS-path, weight 32768, origin incomplete). The operator expected the aggregate to carry a community, MED, or other attribute from the components.

Cause: FRR’s aggregate-address does not inherit attributes from components. The aggregate’s attributes are local defaults plus whatever the route-map (if any) explicitly sets.

Fix: write a route-map that explicitly sets the desired attribute on the aggregate.

Rollback

# Remove the aggregate
delete protocols bgp address-family ipv4-unicast aggregate-address 192.0.2.0/22
commit

# Remove summary-only but keep the aggregate (more-specifics
# are advertised again)
delete protocols bgp address-family ipv4-unicast aggregate-address 192.0.2.0/22 summary-only
commit

The rollback is reversible: adding summary-only back re-suppresses the more-specifics.

A subtle production issue: when summary-only is removed, the more-specifics are advertised to peers immediately. If the peer’s inbound policy rejects the more-specifics (a common “only allow the /22” filter), the prefix becomes unreachable at the peer.

The disciplined approach: before removing summary-only, audit the peer’s inbound prefix-list to confirm it allows the more-specifics.

Production discipline

Cross-course references

• Part XXV-01 (XXV-VyOS-BGPAdvertise / network statement) covers the other origination primitive.
• Part XXVI (XXVI-VyOS-BGPAttributes) covers the AS-path attribute that as-set modifies, and the origin attribute that an aggregate derives from its components.
• Part XXXIII (XXXIII-VyOS-RoutePolicy) covers the route-map primitives used to apply attribute policy to the aggregate.
• Part XXXV-03 (XXXV-VyOS-Summarisation / OSPF area range) covers route summarisation in IGPs (OSPF, IS-IS) and how it differs from BGP aggregation.

Quiz