What BGP summary-only actually hides

aggregate-address 10.0.0.0 255.255.252.0 summary-only is one line, it does two things, and most people only intend one of them. It originates an aggregate, and it suppresses every more-specific component route from being advertised. The usual mental model — “advertise one prefix instead of many” — is only true when the components exactly fill the aggregate. When they do not, you have configured a blackhole that the routing table will never show you.

What summary-only actually does

Two separate effects, and it is worth separating them:

• The aggregate is originated. A route for 10.0.0.0/22 appears, generated locally, with whatever attributes the policy gives it.
• Components are suppressed from advertisement. Every route that falls inside 10.0.0.0/22 stops being sent to peers. Suppressed, not withdrawn from the local table — locally the components are still there, so local forwarding still follows the more-specifics.

That asymmetry is the thing to hold on to: suppression is a property of what you send, not of what you know.

The hole

Suppose you originate three /24s — 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24 — and 10.0.3.0/24 belongs to someone else, or to a project that was cancelled.

The exact minimal cover is 10.0.0.0/23 plus 10.0.2.0/24. The single covering supernet is 10.0.0.0/22. Aggregating to the /22 with summary-only means you now advertise a quarter of address space you do not carry.

Peers route 10.0.3.0/24 to you because it is inside your /22. You have no route for it, so you drop it. Nothing in your routing table is wrong; the aggregate is simply wider than your component set, and the tool that would have told you is the one you skipped.

The fix is not a suppression trick, it is a smaller aggregate: advertise 10.0.0.0/23 and 10.0.2.0/24, which together cover exactly the space you carry. Two prefixes instead of one is a cheap price for not blackholing a peer.

as-set, and what the aggregate’s AS_PATH claims

Without as-set, the aggregate is originated as if it belonged to you: its AS_PATH is your own AS, full stop. That is a routing statement, not a formality.

• A peer that originally announced the component paths can receive its own space back with an AS_PATH that does not contain its AS. Loop detection has nothing to detect.
• Every other peer sees a path that is shorter than the real one, so your aggregate is preferred over the more-specific routes it was built from — which may be the intent, and may also be a traffic shift nobody planned.

With as-set, the aggregate carries an AS_SET containing the contributing paths. Loop detection works, at the cost of an attribute that grows with the component set and that different implementations count differently when they pick a best path. Neither option is free; the point is that the aggregate is a new route with a policy decision attached, and the decision is made when you leave as-set off.

summary-only is the blunt instrument

The selective alternatives exist for when the component set and the aggregate do not line up:

• suppress-map — suppress only the listed components and advertise the rest. The aggregate goes out, and the more-specifics you want visible stay visible.
• advertise-map — the inverse: advertise only the components you choose.
• attribute-map — set attributes on the aggregate itself, which is how an aggregate gets a community or a local preference without a route-map on every peer.

Vendor semantics for these differ, particularly about whether suppress-map combines with summary-only or replaces it. That is a documentation check on your platform, and it is exactly the kind of vendor-specific detail this site labels as documented or unverified rather than presenting as universal.

Verify what peers receive, not what you configured

The configuration tells you what you asked for. Two commands tell you what happened, and they are the only two that matter before a change window:

! what am I offering this peer? (IOS / IOS-XE)
Router# show ip bgp neighbors 192.0.2.1 advertised-routes

! what did this peer actually receive? (needs soft-reconfiguration inbound)
Router# show ip bgp neighbors 192.0.2.1 received-routes

Compare the set before and after the change. If the aggregate was meant to replace the components, the count should go down by the number of components and up by one. If it went up by one and stayed the same otherwise, summary-only did not do what you expected — usually because the aggregate mask was wrong and the components are not considered components at all.

The checklist

1. Does the component set cover the aggregate exactly? If not, use a narrower mask or a selective map.
2. Is the aggregate inside the space you are actually allocated? An aggregate that leaks a neighbour’s block is a phone call, not a routing problem.
3. as-set or not — and do you accept that the aggregate claims a path your components did not?
4. What do peers receive, verified with advertised-routes, rather than assumed from the configuration?