OSPF – Immediate hellos

OSPF – Immediate hellos

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        OSPF  Hello Packet
09  23.507483        OSPF  Hello Packet
10  23.518430     OSPF  Hello Packet
14  25.400245	       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,
src address 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

#   Time       Source	      Dest             Proto Info
04  15.503997        OSPF  Hello Packet
09  23.507483        OSPF  Hello Packet
10  23.518430     OSPF  Hello Packet
14  25.400245	       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:

  • Vendors will implement strong ideas from draft RFCs, some of which may contradict other RFCs.
  • Don’t always believe what you read (even on this blog!). Test it for yourself.
  • Use all the tools at your disposal to find an reasonable answer. (GNS3/Wireshark/RFC/Google)

11 thoughts on “OSPF – Immediate hellos

  1. Nice finding. Just one thing escapes my mind – I heard (a.k.a. rumors say 🙂 I mean I need to verify further once I get there) that if router receives unicast hello from neighbor, it switches to unicast communication as well, which could be solution to some weird ccie lab scenarios. This seems not to be the case though, apparently by purpose. Or are there some gotchas like having specific neighbor command?

    1. Hi Alex,
      In the edge case Daniel Dib describes, it does a unicast reply, but doesn’t ‘switch over’ to unicast. All further hello’s are multicast, until the remote neighbor drops and starts again.
      However, I haven’t tested any of the NBMA scenarios myself, so I can’t speak authoritatively about them. I guess it’s something to keep in the back of your mind for now. You can lab it up when you get to the topics yourself.

  2. Hi. Nice post, but i don’t understand one moment. For example we have R1 and R2.
    1) R1 send hello to
    2) R2 recived hello from R1 and does not see its own Router ID (RID)
    3) R2 send unicast immediate hello to R1, and R1 sees own RID in the neighbor list
    Then, R1 need send hello to R2 (unicast or multicast?) which is contain RID R2 as neighbor for adjacency?

    1. Hi Stan,
      The immediate hello process is designed to speed up the process of getting to ExStart. However it doesn’t skip any steps – each router must see it’s own RID in a received hello before it moves to 2-WAY. In your scenario above, it’s entirely possible that R2 doesn’t support immediate hello. R2 should still be able to process the unicast hello in this case, but wouldn’t reply until the next hello interval.
      Hope this helps,
      John H

      1. Thank for your answer, John. And support immediate hello depends on the version of IOS, or depends of series of routers? Or both?

        1. I’m afraid I don’t know Stan. It’s not really documented anywhere that Cisco supports this, I would just keep it in the back of your mind as an implementation-specific ‘feature’.

  3. I got the same issue, between cisco routers.
    It seems there is a limit to the number of immediate hellos , 2.
    i get this “Cannot see ourself in hello” with the two immediate hellos to sort of save the moment After it does that multicast seem to start but with a warning
    “No more immediate hello for nbr “ip-address”, which has been sent on this intf 2 times”
    Then I get the “cannot see oureslf ” message again, and since there are no more immediate hellos, the ADJ restarts ..disrupting everyone
    Any new ideas?
    From your explaination
    R1 receive d multicast hello from r2, but is not able to reply via multicast –>
    OR – >> R1 cannot see it self that is why it tried unicast [immediate]??
    sends immediate hello via unicast to R2
    received multicast from R2
    R1 cannot send multicast still
    send 1 more immediate unicast
    R2 replies with multicast
    r1 cannot reply using multicast, and reached limit of 2 unicast
    adj resets.

    1. Hey Dude (great name by the way),
      It’s been quite a while since I looked at this in detail. The limit of 2 x unicast replies seems strange.
      The immediate hellos should only happen if you’re below 2-WAY, as their purpose is the re-establish an adjacency quickly, but they shouldn’t be sent after that point. Any hello’s received after 2-WAY is reached won’t get a unicast response, so periodic hellos will not be responded to …. leading to a constancy adjacency bounce if one side can’t receive multicast hello’s.
      Each vendor (or platform from same vendor) can have different choices for unicast or multicast for DBD/LSUpdates. However I suggest you have a close look at your ACL policy to ensure that you’re not denying multicast OSPF traffic to
      I resolved an issue last week with an adjacency cycling every 50 seconds. ACL was the root cause. Hope this helps.

      1. Hey John.. your reply was pretty much a compilation of info i read from many forums since.
        I am still thinking it is an ACL.
        But why does it work with multicast at the very beginning and establish adj? And at random times it says it cannot see itself in hello packet.
        Every hello i receive the length of the packet is 48. The hello i receive right before the “cannot see ourself” shows to 44.
        Thinking that the rid is really not in the packet, therefore not seeing itself.
        The strange thing is that it keeps sending unicast to establish and then breaks.
        I check and there are system type ACL not sure where that came. From that shows it’s ask allowing the multi cast. Because it’s system i doubt i can stop it.
        My interface is p2p ans due to some issues routes not being built installed on a remote router’s table we have decided to put the connected Networks as ospf network under the router config. That way the r connected network became inter area networks and were then installed on the remote router. It was only when we did this the adj be issu occurred. I placed the connected as passive as well.

        1. Hey Dude,
          I’m not able to help further on the ACL avenue, if you can find a way to sniff/SPAN/or tcpdump, I’m sure that’ll help you clarify.
          In your last paragraph you describe routes not being installed in the routing table. This often happens when one side of adjacency has a network type of P2P but the other is type Broadcast, in this instance you’ll have routes not installed, because OSPF cannot get a full bi-directional map of the inter-router link. LSAs in this LSDB learned across such a link, are are marked with ‘routing bit not set’.
          Look for a show ip ospf neighbor on the peer and verify they are P2P or BCAST?
          /John H

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.