OSPF Hello

[bogdan_zglobiu]

Hello, OSPF Hello

I have a simple network in GNS3 with 2 routers connected by a Frame-Relay switch.

On router 1, the serial interface is configured as ospf network type broadcast, and I have static dlci mapping, broadcast keyword included.

On router 2, the serial interface is configured as ospf network type broadcast, and I have static dlci mapping, but the broadcast has been omited.

So, router 1 can send multicast hellos to 224.0.0.5 and router 2 will receive them. Router 2 tries to send hellos to multicast address 224.0.0.5, but they are not reaching the other side (due to the missing broadcast keyword). But from what I see, an adjacency is forming that is flapping every dead interval.

From the debug outputs and captures, I've concluded that when router 2 receives the multicast hello, it will reply with a unicast hello, which includes the router id of router 1 and the adjacency is forming. Further, the hellos wil be multicasted by both, router 1's dead interval will expire and the adjacency will fail. Then the process repeats.

Can you please confirm that the first time a router receives hello's from a new neighbor, it replies back as unicast ?

Thanks,

[Peter Paluch]

Hello Bogdan,

I can confirm the same finding, i.e. an OSPF neighbor on a multiaccess network sending an unicast Hello in response to receiving a hello from another OSPF speaker on the same segment. This behavior is not described by RFC 2328 (although it does not violate it) - rather, it seems to be a Cisco-specific optimization that is basically well-intended - to speed up the formation of adjacencies on a multiaccess medium.

Best regards,

Peter

[bogdan_zglobiu]

Hello Peter,

Thank you for your quick reply.

I have another thing that it is not clear to me. After the adjacency is established, R2 is still receiving multicast hellos from R1, so it's dead timer never timeout. R2 is also multicasting hellos, which are not reaching R1 - I see this from debug outputs. The dead timer on R1 reaches 0 and FULL->DOWN.

Why is R2 sending multicast hellos as long the adjacency is up from it's perspective (it's never going down), but is sending unicast hellos in reponse to R1' multicast hellos, when R1 loses the adjacency with R2 ? How can it tell when to send unicast hellos instead of multicast ?

Better said, are the hellos different before and after the establishement of the adjacency ? It has to do with the DR and BDR filelds in the Hello packet ?

Regards,

Bogdan

[Peter Paluch]

Hello Bogdan,

How can it tell when to send unicast hellos instead of multicast ?

I am speculating here. You know that each OSPF Hello packet sent by a router contains a list of neighbors whose Hello packets were correctly received and accepted by this router on a particular interface. Thus, R1 should list R2's RID in its Hello packets, and vice versa. This is used to check that both routers hear each other, and is the basis for the 2WAY state in OSPF.

It seems that the unicast Hello is sent when a router receives a Hello packet from its neighbor but does not see its own RID in the received Hello packet. This may explain what you are seeing: R1 and R2 are starting to establish an adjacency. R2's Hello packets are not reaching R1, therefore R1 is not listing R2 in its Hello packets. When R2 receives the Hello from R1 and does not see its own RID in it, it sends a unicast Hello to R1, finally helping to establish the adjacency.

From this moment on, R1 and R2 see each other in their Hello packets and revert back to pure multicast Hello operation.

Of course, the multicasted Hellos from R2 fail to reach R1 and after the Dead interval expires, R1 declares R2 down and removes its RID from the list of adjacent neighbors in its Hello packets. The next packet coming from R1 will no longer contain R2's RID, and R2 will again react by sending an unicasted Hello back to R1, repeating the cycle.

Does this make sense?

Best regards,

Peter

[bogdan_zglobiu]

Hello Peter,

That is exactly what I'm observing and it is making sense, but I've found it curios because everything I've read on OSPF didn't mention that.

Here is the chain of events, to be clear for anyyone that reads this post:

R1 - serial interface - IP: 1.1.1.1 <====FR SWITCH====> R2 - serial interface -IP: 1.1.1.2

*Jan 26 21:26:58.407: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.1

*Jan 26 21:26:58.535: OSPF: Rcv hello from 1.1.1.2 area 0 from Serial1/1 1.1.1.2

*Jan 26 21:26:58.543: OSPF: Send immediate hello to nbr 1.1.1.2, src address 1.1.1.2, on Serial1/1

*Jan 26 21:26:58.547: OSPF: Send hello to 1.1.1.2 area 0 on Serial1/1 from 1.1.1.1

*Jan 26 21:26:58.547: OSPF: End of hello processing

R1(config-if)#

*Jan 26 21:26:58.611: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.2 on Serial1/1 from LOADING to FULL, Loading Done

R1(config-if)#

*Jan 26 21:27:08.411: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.1

R1(config-if)#

*Jan 26 21:27:18.415: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.1

R1(config-if)#

*Jan 26 21:27:28.419: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.1

R1(config-if)#

*Jan 26 21:27:38.423: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.1

R1(config-if)#

*Jan 26 21:27:43.915: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.2 on Serial1/1 from FULL to DOWN, Neighbor Down: Dead timer expired

R1(config-if)#

*Jan 26 21:27:48.427: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.1

*Jan 26 21:27:48.479: OSPF: Rcv hello from 1.1.1.2 area 0 from Serial1/1 1.1.1.2

*Jan 26 21:27:48.483: OSPF: Send immediate hello to nbr 1.1.1.2, src address 1.1.1.2, on Serial1/1

*Jan 26 21:27:48.487: OSPF: Send hello to 1.1.1.2 area 0 on Serial1/1 from 1.1.1.1

*Jan 26 21:27:48.491: OSPF: End of hello processing

R1(config-if)#

*Jan 26 21:27:48.583: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.2 on Serial1/1 from LOADING to FULL, Loading Done

R1(config-if)#

*Jan 26 21:27:58.431: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.1

R2(config-if)#

*Jan 26 21:26:58.567: OSPF: Rcv hello from 1.1.1.1 area 0 from Serial1/1 1.1.1.1

*Jan 26 21:26:58.571: OSPF: Send immediate hello to nbr 1.1.1.1, src address 1.1.1.1, on Serial1/1

*Jan 26 21:26:58.575: OSPF: Send hello to 1.1.1.1 area 0 on Serial1/1 from 1.1.1.2

*Jan 26 21:26:58.579: OSPF: End of hello processing

*Jan 26 21:26:58.675: OSPF: Rcv hello from 1.1.1.1 area 0 from Serial1/1 1.1.1.1

*Jan 26 21:26:58.679: OSPF: End of hello processing

R2(config-if)#

*Jan 26 21:26:58.739: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial1/1 from LOADING to FULL, Loading Done

R2(config-if)#

*Jan 26 21:27:00.435: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.2

R2(config-if)#

*Jan 26 21:27:08.571: OSPF: Rcv hello from 1.1.1.1 area 0 from Serial1/1 1.1.1.1

*Jan 26 21:27:08.575: OSPF: End of hello processing

R2(config-if)#

*Jan 26 21:27:10.439: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.2

R2(config-if)#

*Jan 26 21:27:18.563: OSPF: Rcv hello from 1.1.1.1 area 0 from Serial1/1 1.1.1.1

*Jan 26 21:27:18.567: OSPF: End of hello processing

R2(config-if)#

*Jan 26 21:27:20.443: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.2

R2(config-if)#

*Jan 26 21:27:28.567: OSPF: Rcv hello from 1.1.1.1 area 0 from Serial1/1 1.1.1.1

*Jan 26 21:27:28.571: OSPF: End of hello processing

R2(config-if)#

*Jan 26 21:27:30.447: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.2

R2(config-if)#

*Jan 26 21:27:38.591: OSPF: Rcv hello from 1.1.1.1 area 0 from Serial1/1 1.1.1.1

*Jan 26 21:27:38.595: OSPF: End of hello processing

R2(config-if)#

*Jan 26 21:27:40.451: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.2

R2(config-if)#

*Jan 26 21:27:48.551: OSPF: Rcv hello from 1.1.1.1 area 0 from Serial1/1 1.1.1.1

*Jan 26 21:27:48.555: OSPF: Send immediate hello to nbr 1.1.1.1, src address 1.1.1.1, on Serial1/1

*Jan 26 21:27:48.559: OSPF: Send hello to 1.1.1.1 area 0 on Serial1/1 from 1.1.1.2

*Jan 26 21:27:48.563: OSPF: End of hello processing

*Jan 26 21:27:48.611: OSPF: Rcv hello from 1.1.1.1 area 0 from Serial1/1 1.1.1.1

*Jan 26 21:27:48.619: OSPF: End of hello processing

R2(config-if)#

*Jan 26 21:27:48.719: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial1/1 from LOADING to FULL, Loading Done

R2(config-if)#

*Jan 26 21:27:50.455: OSPF: Send hello to 224.0.0.5 area 0 on Serial1/1 from 1.1.1.2

R2(config-if)#

*Jan 26 21:27:58.547: OSPF: Rcv hello from 1.1.1.1 area 0 from Serial1/1 1.1.1.1

*Jan 26 21:27:58.547: OSPF: End of hello processing

Thank you Peter for your support !

[Peter Paluch · Accepted solution]

Hi Bogdan,

That is exactly what I'm observing and it is making sense, but I've  found it curios because everything I've read on OSPF didn't mention  that. 

I am not surprised - this is not strictly RFC 2328-compliant behavior, although it is perfectly interoperable with pure RFC 2328 implementations.

The advantage of this behavior can be nicely seen anytime you want two routers to discover themselves as soon as possible: with the unicasted Hello, the two routers do not need to mutually wait for their Hello packets. Rather, their discovery time is, at worst, the time of a single Hello interval (this first router will take at most Hello interval to send a Hello packet, with the second router replying immediately).

Best regards,

Peter