OSPF Prefix Suppression

Lessons Discussion
21

Hello Team,
Thank you for the excellent topic in detail.

one question: do we need to enable on all the routers in broadcast and in each network segment ?

i labbed and enabled the prefix suppression only on DR
on P2P , enabled only one R3 interface facing R4
and added one more segment behind R4 ( broadcast ) where i enabled only on DR

it worked and has been filtered the transit prefix throughout the ospf domain.

Please confirm that do we need to enable on all routers or not ?

22

Hello Sathish

Your experiment seems to have the expected results. Prefix suppression in OSPF doesnā€™t necessarily need to be enabled on all routers. It is typically enabled on transit routers to prevent unnecessary LSAs from being propagated throughout the OSPF domain.

In a broadcast network, it is typically enabled on the DR thus preventing the propagation of transit prefix LSAs to other routers in the OSPF domain.

So, to answer your question: no, prefix suppression doesnā€™t need to be enabled on all routers. However, it should be enabled strategically on transit routers and/or DRs to efficiently suppress transit prefix LSAs.

I hope this has been helpful!

Laz

23

Hello, everyone.

On IOS-XE, when prefix suppresion is enabled under the OSPF process, it will supress all Type 1/2 LSA transit prefixes apart from:

  • Prefixes on interfaces that are configured as passive

  • Prefixes on a loopback interface

  • Secondary-address prefixes.

Iā€™ve labbed this on XE and connected a switch to a router to act as a LAN segment. Iā€™ve then configured prefix suppression on that router.

Prefixes on physical interfaces are suppressed if they arenā€™t configured as passive. So other routers could never reach that network until I configured that interface as passive, even though it was connected to a switch.

Now, this makes sense but then I tried it on XR ā†’ XR advertised the prefix connected to the switch even when prefix suppression was enabled under the OSPF process or even under the interface.

So XR will advertise prefixes on links that arenā€™t configured as passive or is this some sort of bug? Iā€™ve purposely connected a router to that LAN segment and then it suppressed the prefix (since I guess it realized that this is a transit link). Could anyone help me confirm this?

RP/0/RP0/CPU0:R2-XR(config-ospf-ar-if)#do show ip ospf int G0/0/0/0 | i Primary

Mon Dec 15 13:27:34.433 UTC
Label stack Primary label 0 Backup label 0 SRTE label 0
Primary addresses not advertised

It says that Primary addresses arenā€™t advertised but they areā€¦ under the circumstances mentioned above.

Thank you
David

24

Hello David

This is another situation where IOS-XE and IOS-XR behave differently because of the specific roles that they are designed to play.

Specifially, IOS-XR uses intelligent stub vs. transit network detection, while IOS-XE applies prefix suppression more literally.

IOS-XR is able to distinguish between stub networks, that is, segments where NO OSPF neighbors exist, and transit networks, where OSPF adjacencies exist (actual router-to-router links). When you enable prefix suppression on XR, stub networks are still advertised (to maintain reachability to hosts on that LAN) while transit networks are suppressed (because the prefix is only needed for OSPF operations, not as a destination).

This is why your switch-connected interface was advertised initially. XR detected no OSPF neighbors and treated it as a stub network that needs to remain reachable. When you connected a second router and formed an OSPF adjacency, the segment became a transit network, and XR then suppressed the prefix.

IOS-XE on the other hand, takes a more aggressive less intelligent approach. When prefix suppression is enabled, it suppresses ALL non-exempt interface prefixes (except passive interfaces, loopbacks, and secondary addresses). It does NOT automatically distinguish between stub and transit segments. You must explicitly configure passive-interface on stub networks to keep them advertised.

This message indicates the feature is enabled on the interface, but the actual suppression behavior is conditional based on neighbor state. Itā€™s not saying the prefix is absolutely suppressed in all cases.

From a network design perspective, XRā€™s behavior is actually more intelligent. The purpose of prefix suppression in XR is to hide unnecessary transit link prefixes to reduce LSDB/routing table sizes, which is critical for service provider networks. Stub networks with hosts should remain advertised for reachability, and transit networks (router-to-router links) can be safely suppressed.

The prefix suppression feature (RFC 6860) was designed to hide transit-only networks. XR interprets this more literally by actually checking whether a network is transit before suppressing it.

Your lab testing methodology was perfect. Connecting a second router is exactly how you confirm itā€™s working as designed!

I hope this has been helpful!

Laz