NetworkSherpa

OSPF – Immediate hellos

John Harrington

Unicast Hello packets

I was debugging an issue recently and ran across something unusual. I had thought that all OSPF hellos on BCAST and P2P intefaces were sent as multicasts.  However as you can see from the wireshark capture below, packet 10 is clearly sent as a unicast.

#   Time       Source	      Dest             Proto Info
04  15.503997  192.168.12.2   224.0.0.5        OSPF  Hello Packet
09  23.507483  192.168.12.1   224.0.0.5        OSPF  Hello Packet
10  23.518430  192.168.12.2   192.168.12.1     OSPF  Hello Packet
14  25.400245  192.168.12.2   224.0.0.5	       OSPF  Hello Packet


Time to check out the OSPF RFC again.  RFC 2328 section 8.1. states;

…. on these [broadcast] networks Hello packets are sent to the multicast destination AllSPFRouters.

I can’t be 100% sure but it seems that IOS [12.4(22)T5 in this case], isn’t conforming to RFC2328. I did a “debug ip ospf event” on one router and saw the following message:

OSPF: Send immediate hello to nbr 1.1.1.1,
src address 192.168.12.1on GigabitEthernet1/0

So what’s an ‘immediate hello’?

Immediate Hello

Immediate hellos are part of an IETF draft OSPF tuning mechanism proposed in draft-kou-ospf-immediately-replying-hello.  The general idea here is that once you see a hello from a neighbor you should immediately reply to it, rather than waiting for your next hello timer interval.  By reducing the time-to reach 2-WAY state, this mechanism speeds up convergence and seems to be a common sense proposal.
If we look again at the packet trace timings, we see that R1 was due to send it’s periodic hello to R2 at packet 14.  The hellos are set to default inteval of 10 seconds.  However, as soon as R1 receives packet 9,  it immediately replies with a packet directly to R2s unicast ip address 192.168.12.1

#   Time       Source	      Dest             Proto Info
04  15.503997  192.168.12.2   224.0.0.5        OSPF  Hello Packet
09  23.507483  192.168.12.1   224.0.0.5        OSPF  Hello Packet
10  23.518430  192.168.12.2   192.168.12.1     OSPF  Hello Packet
14  25.400245  192.168.12.2   224.0.0.5	       OSPF  Hello Packet

As for the unicast, the language of the draft RFC text is pretty ambiguous.

“The Hello Packet of the Immediately Replying Hello is replied respectively to each neighbor address”

However, it seems an IETF reviewer felt the same, and the author clarified that ‘to each neighbor address’ did in fact mean ‘unicast’.  I’m not 100% sure why there’s a need for unicast here, but for at least we know that this is ‘acceptable’ behaviour.

Edge Cases

Looks like I’m not the first blogger to stumble across this. Daniel Dib discovered that it can lead to an usual edge case.  If a device receives a multicast hello, but isn’t capable of sending a multicast hello, it can send a unicast immediate reply.  However the adjacency times out as all further hellos are attempted as multicasts.

Sherpa Summary

Ahem…well…. I’m not sure how I got into this particular rathole. I guess the only real takeaways here are: