Look at your routing table and count how many of those prefixes anyone actually sends traffic to. In a typical service provider or large enterprise core, a large fraction of the OSPF routing table is transit link subnets - the /30s and /31s between routers. Nothing lives on them. No host has an address there. They exist only to carry packets between two routers, and yet every router in the area carries a route for every one of them.
Prefix suppression deletes them. It is a single command, it can cut a core routing table substantially, and it has one consequence that will bite you in a troubleshooting session if you do not know about it. This article shows it working on Cisco IOS XE with real lab output, including the failure mode nobody warns you about. For the fundamentals, start at the complete OSPF guide.
Why transit prefixes are dead weight
A router-to-router link needs IP addresses so the two routers can form an adjacency and forward packets to each other. It does not need to be routable from the rest of the network. Nobody outside those two routers ever needs to send a packet to 10.0.24.1.
But OSPF advertises the prefix anyway, because that is what the protocol was designed to do in 1998. Every transit link becomes a stub network in a Router LSA (or a prefix on a Network LSA), floods to every router in the area, and consumes a routing table entry, a FIB entry, and a slot in every SPF calculation, on every router, forever.
In a 200-router core with a full mesh of point-to-point links, that is thousands of routes that serve no forwarding purpose whatsoever.
What prefix suppression does
Defined in RFC 6860 for OSPFv2, prefix suppression tells the router to stop advertising the IP prefixes associated with its transit links. The topology information stays - the adjacency, the link, the cost, everything SPF needs to compute a path. Only the reachability information for the link subnet is removed.
Loopbacks and other stub networks are never suppressed. Those are the things that carry actual services and are the things you actually want to reach.
Configuration
Process-wide, which is what you almost always want:
router ospf 1
prefix-suppressionOr per interface, if you need to be selective:
interface Ethernet0/2
ip ospf prefix-suppressionIt must be configured on both ends of a link to remove the prefix entirely. If only one router suppresses, the other still advertises the subnet and the prefix survives in the area.
The lab
Five OSPF routers, multi-area, with R1 in area 0 watching. Before:
R1#show ip route ospf
O IA 10.0.23.0/30 [110/20] via 10.0.12.2, Ethernet0/1
O 10.0.24.0/30 [110/20] via 10.0.14.2, Ethernet0/2
[110/20] via 10.0.12.2, Ethernet0/1
O IA 10.0.45.0/30 [110/20] via 10.0.14.2, Ethernet0/2
O IA 10.0.234.0/24 [110/20] via 10.0.12.2, Ethernet0/1
O E2 172.20.20.0 [110/20] via 10.0.12.2, Ethernet0/1Now enable prefix-suppression on R2 and R4 (both ends of the 10.0.24.0/30 link):
R1#show ip route ospf
O 2.2.2.2 [110/11] via 10.0.12.2, Ethernet0/1
O IA 3.3.3.3 [110/21] via 10.0.12.2, Ethernet0/1
O 4.4.4.4 [110/11] via 10.0.14.2, Ethernet0/2
O IA 5.5.5.5 [110/21] via 10.0.14.2, Ethernet0/2
O IA 10.0.23.0/30 [110/20] via 10.0.12.2, Ethernet0/1
O IA 10.0.45.0/30 [110/20] via 10.0.14.2, Ethernet0/210.0.24.0/30 is gone. Every loopback is still there. The adjacencies are untouched:
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
4.4.4.4 1 FULL/DR 00:00:32 10.0.14.2 Ethernet0/2
2.2.2.2 1 FULL/DR 00:00:33 10.0.12.2 Ethernet0/1And forwarding through the suppressed link works perfectly - because SPF still knows the link exists, it just has no route to it:
R1#ping 4.4.4.4 source Loopback0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/3 msThe consequence: you cannot ping your own transit links
R1#ping 10.0.24.2 source Loopback0
.....
Success rate is 0 percent (0/5)That is not a bug. It is the entire mechanism working as designed. There is no route to 10.0.24.0/30, so packets addressed to 10.0.24.2 have nowhere to go.
The operational impact is real and you must plan for it:
- Traceroute through the core produces asterisks. Each hop replies to a TTL-exceeded from its ingress interface address - which is now unroutable, so the reply never gets back to you.
- Monitoring that pings interface addresses breaks. Point your NMS at loopbacks instead. You should have been doing that anyway.
- An engineer debugging at 3 a.m. will conclude the network is broken. Document it. Prominently.
The standard mitigation is to source everything from loopbacks and monitor loopbacks. On IOS you can also make ICMP replies come from the loopback with ip ospf prefix-suppression left off on a small number of deliberately-reachable links, but the cleaner answer is to accept the trade and change your operational habits.
The trap: prefix suppression can silently kill an external route
This is the finding from the lab that is genuinely worth knowing, and it does not appear in any Cisco document.
In our topology, an ASBR (R3) redistributes a static route to 172.20.20.0/24 whose next-hop is a non-OSPF device sitting on a shared broadcast segment. Because all the conditions are met, the resulting Type-5 LSA carries a non-zero forwarding address - the address of that non-OSPF device, 10.0.234.6. (If that is unfamiliar, read the OSPF forwarding address first.)
The forwarding address lives on the shared segment, 10.0.234.0/24. Prefix suppression removes that subnet from the routing table. And now:
R1#show ip route 172.20.20.0
% Network not in table
R1#show ip ospf database external 172.20.20.0 | include Forward|Advertising
Advertising Router: 3.3.3.3
Forward Address: 10.0.234.6
R1#show ip route 10.0.234.6
% Subnet not in tableThe LSA is right there in the database. The route is gone from the RIB. RFC 2328 §16.4 requires that a non-zero forwarding address resolve to an intra-area or inter-area OSPF route. Suppress the prefix, and the forwarding address becomes unresolvable, and the router discards the external route entirely. Silently. With no log message.
We verified the causality by removing prefix suppression and watching both the transit prefix and the external route come straight back, and then reproduced the same failure a second way (with an area range not-advertise) to confirm it is the FA lookup and not something specific to prefix suppression.
The rule to take away: if any external route in your network has a non-zero forwarding address, the subnet that forwarding address lives on must remain a routable OSPF prefix. Do not suppress it, do not summarise it away, do not filter it. Check before you deploy:
show ip ospf database external | include Forward AddressIf every line says 0.0.0.0, you are safe. If any of them names a real address, find out which subnet it is on and protect it.
When to use it, when not to
The alternatives
Prefix suppression is not the only way to shrink a core table:
- Unnumbered interfaces (
ip unnumbered Loopback0) mean there is no transit subnet to advertise in the first place. Cleaner in principle, but changes your addressing model and complicates some tooling. - /31 addressing halves the address consumption but does not reduce the route count.
- Passive interfaces do the opposite of what you want here: they advertise the prefix but form no adjacency.
- Summarisation at ABRs reduces inter-area routes, which is complementary. Prefix suppression works inside an area; summarisation works between them.
OSPFv3, incidentally, has this built in: link-local addressing means transit links have nothing to advertise by default, and you have to go out of your way to leak them. IPv6 got this one right.
Key takeaways
prefix-suppressionunder the OSPF process removes transit-link prefixes from the LSDB and the RIB, while leaving the topology, adjacencies and forwarding completely intact.- Loopbacks and stub networks are never suppressed. Only transit links.
- It must be enabled on both ends of a link for the prefix to actually disappear.
- The cost is that you can no longer ping or traceroute transit interfaces. Source and monitor from loopbacks, and document it before someone else discovers it during an outage.
- Any external route with a non-zero forwarding address will be silently discarded if the forwarding address subnet is suppressed. Run
show ip ospf database external | include Forward Addressbefore you deploy. - In a core with hundreds of transit links, the RIB and FIB saving is significant. In a small network, it is not worth the operational cost.
Next: the OSPF stub router and max-metric router-lsa, the correct way to take a router out of service without dropping a packet. The full cluster index lives on the OSPF pillar guide.
