OSPF邻居的DOWN状态定义为在最后一个routerdeadinteraval时间内没有看到hello的状态。OSPF 邻居的 INIT 状态定义为在间隔内听到第一个 hello 时达到的状态。
因此，对于从 DOWN 到 INIT 的转换，必须在 down 接口上听到 hello。
但与此相矛盾的是，Jeff Doyle坚持认为 hellos 不会发送到广播网络上的下行接口。NBMA 是个例外，它将在polltimeinteraval 中发送hellos。
这令人困惑。如果下行接口没有发送 hello，它们如何在广播多路访问网络上听到 hello 并转换为 INIT？
我非常不愿意批评像杰夫·多伊尔这样的人，但我正在阅读你提到的那一段，我认为他本可以更好地选择他的话。
请记住，OSPF 路由器从自己的角度维护其每个邻居的状态。因此，从 R1 的角度来看，当 R1 听到来自 R2 的问候时，R2 转换为 INIT，而不是当 R1 向 R2 发送问候时。
引用 RFC 2328：
在广播网络上，每个路由器通过定期多播 Hello 数据包来通告自己。这允许动态发现邻居。
因此，即使 R1 的邻居宕机，R1 仍在该广播网络上发送 hellos。
这是来自 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
如您所见，即使 R1 的邻居关闭（由于 hello 计时器不匹配），R1 仍在该接口上发送 hello。