3

The DOWN state of an OSPF neighbor is defined as a state when no hellos are seen in the last routerdeadinteraval time. The INIT state of an OSPF neighbor is defined as state attained when the first hellos are heard in interval.

So for the transition from DOWN to INIT, a hello must be heard on the down interface.

But contradicting this, Jeff Doyle insists that hellos are not sent to down interfaces on broadcast networks. The exception is NBMA, which will send hellos in polltimeinteraval.

This is confusing. If down interfaces are not sent a hello, how can they hear hellos and transform to INIT on broadcast multiaccess networks?

Ryan Foley
  • 5,479
  • 4
  • 23
  • 43
Downey_HUff
  • 203
  • 1
  • 2
  • 6
  • 1
    Please give an exact quote including book, chapter and page, because it's impossible to respond to this concern without assuming that you are quoting the source correctly – Mike Pennington Mar 18 '14 at 20:47
  • @MikePennington The exact quote is "Hellos are not sent to dead neighbors except on NBMA networks, where Hellos are sent to dead neighbors at some rate well below that of the Hello interval." From "OSPF and IS-IS: Choosing an IGP for Large Scale Networks," Doyle, 2006, Ch 6, page 190. – Ron Trunk Mar 19 '14 at 11:55
  • @Ron thanks much for quotting the text and explanation – Downey_HUff Mar 19 '14 at 14:40
  • The quote is inadequate. We need paragraphs, not a bare sentence. Downey, this is your question; it's your responsibility to explain what you're asking about. Three paragraphs of relevant context please. – Mike Pennington Mar 20 '14 at 00:02
  • 1
    Sorry mike do you really need more info than @ron gave?? Y this has to be not so user friendly , one of questions marked as locked, user given no option to explain himself. Sorry if i have been harsh..please lock this if you want., if this is not a site for newbies let it be – Downey_HUff Mar 20 '14 at 05:00
  • @Downey_HUff, if you have complaints, please consider voicing them in [meta]. I cannot understand how you came up with this question if you can't give us the source material. Regarding the [locked question](http://networkengineering.stackexchange.com/q/6888/775); my apologies, I attempted to migrate it to [su]. However, it seems that you're question-blocked on [su], so the system automatically locked it when the migration was rejected. – Mike Pennington Mar 20 '14 at 17:55

1 Answers1

4

I'm very reluctant to criticize someone like Jeff Doyle, but I'm reading that very same paragraph you mention, and I think he could have chosen his words better.

Remember that an OSPF router maintains the state of each its neighbors from its own point of view. So from R1's point of view, R2 transitions to INIT when R1 hears a hello from R2, not when R1 sends a hello to R2.

Quoting from RFC 2328:

On broadcast networks, each router advertises itself by periodically multicasting Hello Packets. This allows neighbors to be discovered dynamically.

So even if R1's neighbor is down, R1 is still sending hellos on that broadcast network.

Here's an example from GNS3:

*Mar 18 14:36:55.615: %OSPF-5-ADJCHG: Process 1, Nbr 10.4.1.1 on Ethernet1/1 from FULL to DOWN, Neighbor Down: Dead timer expired
R1#debug ip ospf hello
OSPF hello events debugging is on
R1#
*Mar 18 14:37:53.255: OSPF: Rcv hello from 10.4.1.1 area 0 from Ethernet1/1 10.1.2.2
*Mar 18 14:37:53.255: OSPF: Mismatched hello parameters from 10.1.2.2
*Mar 18 14:37:53.259: OSPF: Dead R 48 C 40, Hello R 12 C 10  Mask R 255.255.255.0 C 255.255.255.0
R1#
*Mar 18 14:37:55.603: OSPF: Send hello to 224.0.0.5 area 0 on Ethernet1/0 from 10.1.1.1
*Mar 18 14:37:55.607: OSPF: Send hello to 224.0.0.5 area 0 on Ethernet1/1 from 10.1.2.1
*Mar 18 14:37:55.715: OSPF: Rcv hello from 2.2.2.2 area 0 from Ethernet1/0 10.1.1.2
*Mar 18 14:37:55.719: OSPF: End of hello processing

As you can see, even though R1's neighbor is down (due to hello timer mismatch), R1 is still sending hellos on that interface.

Ron Trunk
  • 66,852
  • 5
  • 65
  • 126