OSPF. Neighbors on a “point-to-broadcast” network

When it comes to basic OSPF troubleshooting the first-aid kit is Neighbor states and things, that should match to form an adjacency. And on one early morning while refreshing my memory on OSPF neighbor states I accidentally ran into quite interesting problem.

But before we start, answer the short question:

Will adjacency be formed between directly connected via Gig. Ethernet interfaces routers R1 and R2 if

  • R1’s OSPF interface type configured as point-to-point
  • R2’s OSPF interface type configured as broadcast

 Time’s up. The answer is – yes and no. Wanna know why? Jump in, I have to show you something.

Take a look at this topology which consists of two directly connected Cisco routers.

At first, topology seems as simple as a first figure in a CCNA book. But take a closer look at this OSPF interfaces, their types are different. Hm, definitely not a case you would find covered in an everyday OSPF configuration guide.

I will not go into details about what are all the differences between various OSPF interface types, you already know it, or can read about 1-click away. Though I should remind you the key difference between point-to-point and broadcast interfaces behavior which is the necessity to elect DR/BDR routers for the latter.

Also it is worth mention that it is best-practice nowadays to set “broadcast-by-nature” Ethernet interfaces to operate in a point-to-point fashion. Why would one do it? To reduce convergence time. Ethernet interface once configured as point-to-point won’t go into DR/BDR election which effectively means that neighbor relationships will reach FULL state 40 seconds faster (40s is the default wait interval for interface to elect DR/BDR routers).

Therefore this particular case with different interface types isn’t some artificial Lab exercise, you can easily meet this interface mix in the real world. Let’s say you simply forgot to configure another interface with p2p type, or your neighbor is under administration of the 3rd party who knows nothing about best practices and leave you with default broadcast behavior.

Ok, different link types mean different networks with different behavior, rules and so forth, there is every indication that adjacency should not form. But it is not that simple. Let’s Lab!

Lab time

I booted up two Cisco routers running IOS 15.2(4)S simultaneously and first thing checked R1’s OSPF neighbors, expecting to see zero active neighbors:

Look at this, R1 has a neighbor in FULL state, which means that it has recognized R2 as a valid neighbor and successfully accomplished exchange of Link State Updates! As a precaution lets check OSPF interfaces parameters on both routers to confirm that they indeed operate in different types:

Yes, interfaces operate in different types as seen in highlighted strings above. And R2’s output also says us that R2 elected DR (itself) and BDR (R1).  But what about R2, does it have a neighbor?

Apparently, yes, its neighbor is R1 with RID 1.1.1.1 and the state of this adjacency is also FULL. Well, does it mean that despite routers R1 and R2 have different OSPF interface types configured adjacency will be successfully formed and OSPF routes will populate the routing table? To ensure this conclusion lets check routers OSPF databases:

Both routers (as they must) have identical databases: 2 Router LSA’s (one from each router) and one Network LSA produced by Designated Router R2. Healthy-looking OSPF database. Now lets see if we have OSPF routes in each router’s routing table to wrap this case up:

Oops, no OSPF routes in routing tables for both routers, how this even possible if we have just seen OSPF databases? Lets examine them one more time, now with detailed look to neighbor’s Router LSA:

 

Busted

Gotcha, look at highlighted string #7, both routers tell us that they cant reach advertising router based on their calculated topology! And if we recall that every OSPF router builds its own network diagram based on LSA’s it received we should understand what happened behind the scenes.

R1 thinks that R2 is its directly connected on point-to-point network to R2, but R2 thinks the other way, that it is connected to a broadcast network. Given that, when Dijkstra algorithm comes in play to build a network topology it literally got lost, because topology data does not match. And this is the very reason behind the absence of OSPF routes in R1&R2 tables, SPF algorithm have not produced anything meaningful.

Now let me zip this all to a single sentence: Cisco routers successfully form neighbor relationships even if OSPF interfaces configured with different types, however no OSPF routes will be installed into routing tables since OSPF database information is inconsistent.

This was a totally strange behavior to see for me, yet Cisco didnt brake any rules. RFC 2328 OSPF Version 2 does not explicitly restrict to form adjacency for different network types, I think that authors thought it would be obvious not to mix different types on a single network segment. Moreover, OSPF Hello message does not contain any field for interface type, so routers do not know what interface type is on the other side.

And what about Alcatel-Lucent and Juniper?

But there are other vendors who managed to distinguish between different network interfaces to prevent such a bad situation when adjacency seems to be formed yet no routes are present. And we start with Alcatel-Lucent’s SR-OS v12.0.R8 (If you are new to ALU routers, check this OSPF configuration tutorial).

Network topology and routers configuration area the same. Booting up routers simultaneously and checking adjacency right after that several times:

Look at this, R1 goes into Exchange Start phase very quickly, this is because its interface is operating in p-t-p mode and do not need to elect DR/BDR. Therefore right after R1 sees itself in received Hello message from R2 it immediately starts to send to R2 its Database Description messages.

But R2 cant answer to R1, it needs to elect DR/BDR first, since it is thinking that it is on a broadcast network segment. At the same time R2 sees itself in coming Hello messages – that is why R2 is in 2Way state for a period of time.

And then we see that R1 drops off its neighbor R1 (line #41), effectively putting adjacency to DOWN state. Why would R1 do this? Because it noticed that R2 operates in a different mode and there is no point to peer with it.

How point-to-point interface detects broadcast interface?

But how did R1 figured out that R2’s interface is broadcast if Hello messages do not communicate that information?  Well, it took some intellectual analysis from R1. And to get down to the truth we have to dig into debug output of R1:

Debug shows incoming OSPF packets, I left only two of them which show the difference. Look, the second OSPF Hello message has DR and BDR IP addresses filled in, and that is why this packet got dropped. R1 knows that it is operating on a point-to-point network, thus it should not receive any Hello messages with DR and BDR IP addresses other then 0.0.0.0. That is why R1 drops this packets and control plane never sees them. And if Hello packets are not coming for Dead interval, R1 thinks that neighbor is down and breaks the neighboring process.

This underlying logic effectively stops useless adjacency to form and keeps network administrators from unnecessary troubleshooting.

JUNOS

Juniper routers (I am running Junos 14.1 on vMX) acts in the same as ALU manner. They reject “foreign” Hello packets on point-to-point interface if they contain DR/BDR addresses.

Summary

  • Nowadays it is best-practice to configure Ethernet interfaces between directly connected OSPF routers in a point-to-point type to reduce convergence time.
  • It is possible to configure different interface’s type on a single network segment between OSPF routers. Especially interesting the case when one interface configured with point-to-point type and the other with broadcast.
  • Cisco routers form neighbor relationships even if OSPF interfaces configured with different types, however no OSPF routes will be installed into routing tables since OSPF database information is inconsistent.
  • This Cisco’s behavior can lead to unnecessary troubleshooting since adjacency seems up yet no OSPF routes will be seen in routing table.
  • Alcatel-Lucent and Juniper routers effectively prevent adjacency to form in such case. They drop incoming to point-to-point interface Hello packets if they contain DR/BDR IP addresses other then zero.

Useful links:

noshut# exit all

 

Roman Dodin

Network engineer at Nokia
Eagerness to learn multiplied by passion to share.
You can reach me at LinkedIn

You Might Also Like

  • http://dmitryfigol.blogspot.com/ Dmitry Figol

    Thanks for the post. I configured OSPF over 9000 times in a lab, but I have never paid attention to this behaviour on Cisco routers.
    To be fair, even though they will form full adjacency, there will be a log message about mismatched network type. It is at least something.

    • http://hellt.ru/ Roman Dodin

      What IOS version are you running? I havnt seen any log message on console during this test (IOS 15.2(4)S)

      *Jun 15 09:55:28.995: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet1/0 from LOADING to FULL, Loading Done

      *Jun 15 09:56:53.995: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet1/0 from FULL to DOWN, Neighbor Down: Interface down or detached

      *Jun 15 09:56:54.055: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet1/0 from LOADING to FULL, Loading Done

      • http://dmitryfigol.blogspot.com/ Dmitry Figol

        15.4(2)T

        *Jun 15 06:10:52.706: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Ethernet0/0 from LOADING to FULL, Loading Done
        *Jun 15 06:10:57.842: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 1.1.1.1 on Ethernet0/0 indicating a potential network type mismatch

        • http://hellt.ru/ Roman Dodin

          Thanks, Dmitry, useful info!