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 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:
- 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”
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?
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.
/John
Hi. Nice post, but i don’t understand one moment. For example we have R1 and R2.
1) R1 send hello to 224.0.0.5
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?
Thanks.
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
Thank for your answer, John. And support immediate hello depends on the version of IOS, or depends of series of routers? Or both?
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’.
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.
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 224.0.0.5/224.0.0.6.
I resolved an issue last week with an adjacency cycling every 50 seconds. ACL was the root cause. Hope this helps.
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.
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