OSPF Prefix Suppression


OSPF prefix suppression is a feature that not only is a good feature itself, but for a beginner in OSPF struggling to understand the SPF/IP interaction, LSA generation, path calculation and route installation etc, serves as a perfect example that brings all of these concepts together.

For this post, the following very simple topology will suffice.

Apart from the IP addressing visible on the drawing and verification of link local connectivity, the following initial configuration was applied to each router.

router ospf 1
 network 0.0.0.0 255.255.255.255 area 0

That is it, just every single interface in OSPF area 0.
To enforce the use of Prefix Suppression, the following goal was established.

“The mission is to get complete Loopback to Loopback connectivity between all routers with a minimal burden on the RIB/FIB”.

Most of the interesting verification etc will take place on R1 and R4. Also, as a side note, R3 was the DR during the verification process but it really does not matter which router is the DR. The configuration for prefix suppression will be applied to all the routers on the multi-access segment. The reason for this is not only the non-deterministic behavior associated with OSPF DR election (in that the DR is a product of when the router came online, regardless of its associated priority) but also the fact that if the DR was to go offline, the configuration has to be present on other routers as they then usurp the DR responsibility If the prefix suppression behavior needs to be reproduced consistently, then it becomes mandatory to configure the prefix suppression configuration on all routers with a priority greater than 0.

Right after OSPF converges (no prefix suppression yet), the following are the routing tables on R1 and R4 –

R1(config-if)#do sho ip route | b Gate
Gateway of last resort is not set

     34.0.0.0/30 is subnetted, 1 subnets
O      34.34.34.0 [110/74] via 123.123.123.3, 00:00:32, FastEthernet0/0
     1.0.0.0/24 is subnetted, 1 subnets
C      1.1.1.0 is directly connected, Loopback0
     2.0.0.0/32 is subnetted, 1 subnets
O      2.2.2.2 [110/11] via 123.123.123.2, 00:00:32, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets
O      3.3.3.3 [110/11] via 123.123.123.3, 00:00:32, FastEthernet0/0
     4.0.0.0/32 is subnetted, 1 subnets
O      4.4.4.4 [110/75] via 123.123.123.3, 00:00:12, FastEthernet0/0
     123.0.0.0/24 is subnetted, 1 subnets
C      123.123.123.0 is directly connected, FastEthernet0/0

----------------------------------------------------------------------

R4(config-if)#do sho ip route | be Gate
Gateway of last resort is not set

     34.0.0.0/30 is subnetted, 1 subnets
C       34.34.34.0 is directly connected, Serial0/0
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/75] via 34.34.34.1, 00:00:34, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/75] via 34.34.34.1, 00:00:34, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 34.34.34.1, 00:00:34, Serial0/0
     4.0.0.0/24 is subnetted, 1 subnets
C       4.4.4.0 is directly connected, Loopback0
     123.0.0.0/24 is subnetted, 1 subnets
O       123.123.123.0 [110/74] via 34.34.34.1, 00:00:34, Serial0/0
--------------------------------------------------------------------

The colored entries describe the Transit links, which need to be processes for the SPF algorithm but really do not need in the routing tables of endpoint routers. Thus, this is the moment where it is very important to realize that an SPF tree could consist entirely of unnumbered links and still function as before. If the large scheme of things, the SPF process running on the router creates the SPF tree first and formost and then each SPF router’s connected/stub network (advertised in LSA 1 entry of “Link Type 3” are added into the routing table of the root router performing the SPF algorithm.

Now, the following commands are applied on all routers

interface f0/0
 ip ospf prefix-suppression
interface s0/
 ip ospf prefix-suppression

Let us study the routing tables first.

R1(config-if)#do sho ip route | be Gate
Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback0
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/11] via 123.123.123.2, 00:12:48, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/11] via 123.123.123.3, 00:12:48, FastEthernet0/0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/75] via 123.123.123.3, 00:12:28, FastEthernet0/0
     123.0.0.0/24 is subnetted, 1 subnets
C       123.123.123.0 is directly connected, FastEthernet0/0

-----------------------------------------------------------------------

R4(config-if)#do sho ip route | be Gate
Gateway of last resort is not set

     34.0.0.0/30 is subnetted, 1 subnets
C       34.34.34.0 is directly connected, Serial0/0
     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/75] via 34.34.34.1, 00:13:51, Serial0/0
     2.0.0.0/32 is subnetted, 1 subnets
O       2.2.2.2 [110/75] via 34.34.34.1, 00:13:51, Serial0/0
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/65] via 34.34.34.1, 00:13:51, Serial0/0
     4.0.0.0/24 is subnetted, 1 subnets
C       4.4.4.0 is directly connected, Loopback0

---------------------------------------------------------------------

As can be seen, the transit links, not needed by our scenario are now gone. But the million dollar question is, is the connectivity affected? Only one way to tell.

Connectivity Tests

All routes in the routing table, essentially all loopbacks, should be reachable at this point, courtesy of the SPF process that has finished.

R1(config-if)#do ping 4.4.4.4 so l0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/18/48 ms

-----------------------------------------------------------------------

R4(config-if)#do ping 1.1.1.1 so l0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/20/48 ms

----------------------------------------------------------------------

Note – The source IP must be of the loopback as the routers have no information for the transit IPs to send the echo-replies.

R1(config-if)#do ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

----------------------------------------------------------------

R4(config-if)#do ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

----------------------------------------------------------------

The OSPF LSAs

So, the above essentially shows that the feature works and that is indeed very satisfying. But understanding the underlying OSPF database manipulations that take place to make this happen is what is really the focus of this post.

Thus, it is time to take a look at the OSPF database itself.

Let us tackle the easier manipulation first. This would be how R4 and R3 manipulate their respective Router LSAs (Type 1) to remove the IP information for the Point-to-Point Serial0/0 link.

Router LSA Manipulation

First a look at the Router LSA for R4. Remember, under normal circumstances, there should be two link entries describing Serial 0/0; an entry of “Link Type 1” or Point-to-Point entry, identifying the attached remote OSPF router with its Router ID (the Link ID) and the second a “Link Type 3” or Stub network link identifying the IP subnet and Mask of the interface.

R4(config-if)#do sh ip os dat router self

            OSPF Router with ID (34.34.34.2) (Process ID 1)

                Router Link States (Area 0)

  LS age: 1269
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 34.34.34.2
  Advertising Router: 34.34.34.2
  LS Seq Number: 80000003
  Checksum: 0x2102
  Length: 48
  Number of Links: 2

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 4.4.4.4
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 123.123.123.3
     (Link Data) Router Interface address: 34.34.34.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

As can be observed, the only entry describing Serial 0/0 is “Link Type 1” entry, which I have colored. But there is no corresponding “Link Type 3” entry, which is being “suppressed”. What has to be realized, the “Type 3” entry only facilitates the installation of the IP route in the routing table; it has no effect on the SPF tree calculation. So that is why, R4 is sharing all the data that other routers need to create an SPF tree with R4 in it. They will not be installing the actual subnet of the point to point link in their routing table, meeting our stated goal.

Network LSA Manipulation

Now for the trickier network type, the broadcast multiaccess network. Remember that an entry of “Type 2” or “Transit” will describe the broadcast network in the Router LSAs/LSA 1s of all the routers that have a presence on the multiaccess network. This entry will provide the IP address of the DR as its Link-ID. What it does, OSPF wise, is points the calculating router to the proper LSA 2/Network LSA for the subnet. But the actual subnet IP address, will be advertised in Network LSA/LSA type 2 which is generated by the DR. Using the LSA-ID of this LSA, (the IP address of the DR on the segment) with the Subnet-mask field of the LSA, OSPF routers can determine the subnet being advertised.

First a look at the Router LSA of R1 (All others have similar info)

R1(config-if)#do sho ip os dat rou self

            OSPF Router with ID (123.123.123.1) (Process ID 1)

                Router Link States (Area 0)

  LS age: 236
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 123.123.123.1
  Advertising Router: 123.123.123.1
  LS Seq Number: 80000004
  Checksum: 0x9FA2
  Length: 48
  Number of Links: 2

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 1.1.1.1
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 123.123.123.3
     (Link Data) Router Interface address: 123.123.123.1
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

Colored portion describes the Link type 2 and as can be seen, the DR IP is described in the Link-ID field.

Now for the big one, the LSA Type 2/Network LSA produced by the DR. Usually, you would expect a mask consistent with the mask configured on the transit link, i.e. /24 in this case. Let us see how this “manipulated” LSA is different.

Note – DR is R3 but it really does not matter which one it is.

R3(config-if)#do sho ip os dat net self

            OSPF Router with ID (123.123.123.3) (Process ID 1)

                Net Link States (Area 0)

  LS age: 389
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 123.123.123.3 (address of Designated Router)
  Advertising Router: 123.123.123.3
  LS Seq Number: 80000003
  Checksum: 0xEA01
  Length: 36
  Network Mask: /32
        Attached Router: 123.123.123.3
        Attached Router: 123.123.123.1
        Attached Router: 123.123.123.2

So everything is exactly the same but for the colored portion. It will always have a mask of /32, regardless of the configured mask of the link. This is how the information is being “suppressed”. Now, the routers that support the Prefix Suppression feature identify this type of LSA 2 as a product of Prefix Suppression being enabled and will not bother to install the route. Viola, the transit route will not be installed in the routing table and our stated goal is met.

Note – A problem occurs when you have an odd router that does not recognize this feature. They will be fooled into installing a /32 route to the IP address of the DR, basically a side effect of the above manipulation.

And that is how OSPF prefix suppression works.

Leave a comment

8 Comments

  1. Sssnki

     /  June 9, 2013

    Why did you stop writing this blog? Based on the first two articles, this could have been one of the best out there. The way you are explaining different technologies and the style of your articles is extraordinary. You are either CCIE with 20 years of experience or a teacher at a university 🙂

    Do you publish somewhere else now?

    Reply
  2. Fab

     /  December 12, 2014

    Thank you for this really great explained post. Hope to read you again in the future !

    Reply
  3. Great post. Thanks for putting this together.

    Reply
  4. Hei, multumim pt impartasirea acestor detalii de interes.

    Reply
  5. Grunt Gut

     /  September 21, 2016

    Fantastic explanation. Thank you.

    Reply
  1. OSPF Design Challenge - Network Design and Architecture
  2. OSPF Design Challenge - Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net
  3. CCDE Success: References Used – localpref.net

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

  • Categories

  • Archives

  • Meta

%d bloggers like this: