Summarisation is a trade. You send one prefix instead of fifty, which shrinks the routing table and hides internal churn from your spokes. But you also lose the granularity: everything inside the summary now looks equally distant, and if two hubs advertise the same summary, a spoke has no way to tell which one is actually closer to any particular subnet.
A leak map lets you have both. Advertise the summary and punch through one or two specific prefixes that need to remain visible. It is a single keyword and it solves a real design problem elegantly. This article shows it working on Cisco IOS XE with real DMVPN lab output. For the fundamentals, start at the complete EIGRP guide.
EIGRP summarisation is per-interface
Unlike OSPF, where summarisation happens at area boundaries and only at area boundaries, EIGRP can summarise on any interface, on any router. That flexibility is one of EIGRP's genuine advantages, and it is why EIGRP scales well in hub-and-spoke WANs where OSPF needs careful area design.
In classic mode:
interface Tunnel0
ip summary-address eigrp 100 10.99.0.0 255.255.0.0In named mode, which is what you should be writing in 2026:
router eigrp DMVPN
address-family ipv4 unicast autonomous-system 100
af-interface Tunnel0
summary-address 10.99.0.0 255.255.0.0The moment you configure it, two things happen. The specific prefixes covered by the summary stop being advertised out that interface, and the summarising router installs a discard route.
The discard route (and its unusual AD)
HUB1#show ip route 10.99.0.0 255.255.0.0
Routing entry for 10.99.0.0/16
Known via "eigrp 100", distance 5, metric 1280, type internal
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 1280, traffic share count is 1Administrative distance 5. Not 90, not 170, not 254. EIGRP's summary discard route has its own AD, and it is very low - lower than almost everything else on the box.
That is deliberate anti-loop protection: the summarising router is telling the world "I can reach all of 10.99.0.0/16", so it must never follow a less-specific route (like a default) back out for an address inside the summary that does not actually exist. The Null0 route with AD 5 guarantees it drops the packet instead of looping it.
It also means that an EIGRP summary will beat almost any other route to the same prefix on the summarising router. If you configure summary-address 10.0.0.0 255.0.0.0 on a router that also has a static route to 10.0.0.0/8 with AD 1, the static still wins (1 < 5). But an OSPF route (110), a BGP route (20), even an eBGP route - all lose to it. Configure a summary that is broader than you intended and you can black-hole a chunk of your network on that router alone. You can change it with the summary-metric ... distance option, but the right answer is to get the summary right.
(Contrast with OSPF, whose summary discard route has AD 254 - deliberately worse than everything, so it only takes effect if nothing else exists. Two protocols, two philosophies, and it is worth knowing which one you are dealing with.)
The problem a leak map solves
Our lab is a dual-hub DMVPN. HUB1 sits in front of a campus with several subnets in 10.99.0.0/16. Before summarisation, the spokes see every one of them:
SPOKE1#show ip route eigrp | include 10.99
D 10.99.1.0/24 [90/76800640] via 10.0.0.1, 00:01:24, Tunnel0
D 10.99.2.0/24 [90/76800640] via 10.0.0.1, 00:01:24, Tunnel0
D 10.99.3.0/24 [90/76800640] via 10.0.0.1, 00:01:24, Tunnel0Three subnets today. In a real network, three hundred. Every one of them floods to every spoke, and every time one flaps, every spoke runs DUAL.
Summarise, and the spokes see one prefix. Perfect - except that 10.99.2.0/24 is the data centre subnet, and there is a design requirement that spokes must be able to prefer a direct path to it when one exists. Collapse it into the summary and that granularity is gone.
The leak map
ip prefix-list LEAK-92 seq 5 permit 10.99.2.0/24
!
route-map LEAK-SPECIFIC permit 10
match ip address prefix-list LEAK-92
!
router eigrp DMVPN
address-family ipv4 unicast autonomous-system 100
af-interface Tunnel0
summary-address 10.99.0.0 255.255.0.0 leak-map LEAK-SPECIFICAnd the result:
SPOKE1#show ip route eigrp | include 10.99
D 10.99.0.0/16 [90/76800640] via 10.0.0.1, 00:00:15, Tunnel0
D 10.99.2.0/24 [90/76800640] via 10.0.0.1, 00:01:54, Tunnel0The summary and the one prefix that needed to stay visible. 10.99.1.0/24 and 10.99.3.0/24 are suppressed as intended. Two routes on the spoke instead of three hundred, and the one that matters is still there in full detail.
The leak map is a permit list, not a filter
This trips people up. The route-map in a leak map answers the question "which specific prefixes should additionally be advertised alongside the summary?" A permit clause means "leak this one". Prefixes that do not match are simply not leaked - they stay suppressed under the summary, which is the default behaviour anyway.
You do not need a terminating permit clause here, and adding one would leak everything and defeat the summary entirely. This is the opposite of every other route-map convention in IOS, and it catches people out. Keep the leak map tight.
Where leak maps earn their keep
The dual-hub case is the one that matters most and is the one most people get wrong. Without leaking, both hubs advertise 10.99.0.0/16 with equal metrics, and every spoke picks a hub effectively at random (by metric tiebreak). Half your branches take the long way to the data centre and nobody notices until someone complains about latency.
The suppression is per-interface, not global
An important property: summarising on Tunnel0 suppresses the specifics out of Tunnel0. The router still has them in its own routing table, still advertises them out other interfaces, and other routers reached by other paths still see them in full.
That means you can summarise aggressively toward the spokes while keeping full detail toward the core, from the same router, with one command per interface. It is one of the things EIGRP does genuinely better than OSPF.
The metric of the summary
By default, the summary's metric is the lowest metric among the component routes. That sounds sensible and is usually what you want, but it has a consequence: if the single closest component route disappears, the summary's metric jumps, which triggers an update to every spoke. The summary hides the existence of churn, not its metric.
If you want the summary to be genuinely stable, pin its metric:
af-interface Tunnel0
summary-address 10.99.0.0 255.255.0.0 leak-map LEAK-SPECIFIC
summary-metric 10.99.0.0/16 100000 100 255 1 1500Now the summary advertises a fixed metric regardless of what happens to the components. It only withdraws when every component route is gone. In a large hub-and-spoke WAN, that is often the difference between a stable overlay and one that recalculates all day.
Key takeaways
- EIGRP summarises per interface, on any router - no area boundaries required. This is a real advantage over OSPF in hub-and-spoke designs.
- The summary installs a Null0 discard route with administrative distance 5, which beats almost everything else on the summarising router. A too-broad summary can black-hole traffic locally.
- A
leak-mapadvertises the summary plus specific prefixes you name. The route-map is a permit-list of things to leak, not a filter - do not add a terminating permit clause. - The killer use case is dual-hub path selection: both hubs advertise the summary, each leaks the specifics it is genuinely closest to, and spokes stop guessing.
- The summary's metric defaults to the best component metric, so component churn still moves it. Pin it with
summary-metricif you want a genuinely stable advertisement. - Suppression is per-interface. You can summarise toward the spokes and keep full detail toward the core, from the same router.
Next: EIGRP offset lists, for surgical metric manipulation. The full cluster index lives on the EIGRP pillar guide.
