Subject: [OSPF] OSPF Hello questions

From: Joakim Tjernlund <[email-masked]>
Date: Sun, 8 Jul 2012 13:07:15 +0200

In RFC2328, last part of chapter 10.5 it reads:

        o   Each Hello Packet causes the neighbor state machine to be
            executed with the event HelloReceived.

        o   Then the list of neighbors contained in the Hello Packet is
            examined.  If the router itself appears in this list, the
            neighbor state machine should be executed with the event 2-
            WayReceived.  Otherwise, the neighbor state machine should
            be executed with the event 1-WayReceived, and the processing
            of the packet stops.

        o   Next, if a change in the neighbor's Router Priority field
            was noted, the receiving interface's state machine is
            scheduled with the event NeighborChange.

        o   If the neighbor is both declaring itself to be Designated
            Router (Hello Packet's Designated Router field = Neighbor IP
            address) and the Backup Designated Router field in the
            packet is equal to 0.0.0.0 and the receiving interface is in
            state Waiting, the receiving interface's state machine is
            scheduled with the event BackupSeen.  Otherwise, if the
            neighbor is declaring itself to be Designated Router and it
            had not previously, or the neighbor is not declaring itself
            Designated Router where it had previously, the receiving
            interface's state machine is scheduled with the event
            NeighborChange.

        o   If the neighbor is declaring itself to be Backup Designated
            Router (Hello Packet's Backup Designated Router field =
            Neighbor IP address) and the receiving interface is in state
            Waiting, the receiving interface's state machine is
            scheduled with the event BackupSeen.  Otherwise, if the
            neighbor is declaring itself to be Backup Designated Router
            and it had not previously, or the neighbor is not declaring
            itself Backup Designated Router where it had previously, the
            receiving interface's state machine is scheduled with the
            event NeighborChange.

Some questions:
 1) Is it important that the above events are generated in this order? Is moving
    HelloReceived futher down allowed?

 2) Following this list to the letter it seems that one could generate the same
    event several times. There could be 3 NeighborChange and 2 BackupSeen, is this
    the intentions or is it enough to generate each type at most once?

 Jocke

---

From: Joakim Tjernlund <[email-masked]>
Date: Sun, 8 Jul 2012 14:30:16 +0200

> From: Joakim Tjernlund <[email-masked]>
> To: [email-masked],
> Date: 2012/07/08 13:07
> Subject: [OSPF] OSPF Hello questions
> Sent by: [email-masked]
>
>

Follow up questions:
   3) At what point should the hello options be saved into the internal neighbor state?

   4) When should prio, DR and BDR be saved? The text mentions saving these a bit earlier but
      it is unclear if this should be undone when hello pkg should be stopped( see OneWayRecived for
      and example).

---

From: Acee Lindem <[email-masked]>
Date: Sun, 8 Jul 2012 14:40:59 -0400

Hi Joakim,

>>    HelloReceived futher down allowed?

I don't see any advantage to moving it. HelloReceived is a Neighbor FSM event and the other events are Interface FSM events.

>>    the intentions or is it enough to generate each type at most once?

Notice that the events are scheduled and not executed. You only need schedule one of each type. 

>      it is unclear if this should be undone when hello pkg should be stopped( see OneWayRecived for

This is implementation dependent but you must be able to denote differences from the previous state. If you want to look at a good open source reference implementation, go to:   http://www.ospf.org/

Good Luck, 
Acee 

> 
> 
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Joakim Tjernlund <[email-masked]>
Date: Sun, 8 Jul 2012 21:44:56 +0200

> I don't see any advantage to moving it. HelloReceived is a Neighbor FSM event and the other events are Interface FSM events.

ahh, sorry I meant the Router Prio and its NeighborChange.

> Notice that the events are scheduled and not executed. You only need schedule one of each type.

Yes they are scheduled. Ok, so I only need one of NeighborChange and BackupSeen but is the
order significant? Could I just always send BackupSeen(if needed) and then NeighborChange(if needed)?

> This is implementation dependent but you must be able to denote differences from the previous state. If you want to look at a good open source reference implementation, go to:   http://www.ospf.org/

How is the first received Hello seen w.r.t changed prio, DR and BDR? Either one accepts those first
values as is and consider prio, DR and BDR equal or you consider them all changed?

Thanks for pointer to the reference impl.

 Jocke

---

From: Acee Lindem <[email-masked]>
Date: Sun, 8 Jul 2012 16:28:54 -0400

Hi Joakim,
See inline. 

> order significant? Could I just always send BackupSeen(if needed) and then NeighborChange(if needed)?

You need to process BackupSeen first as you don't even recognize NeighborChange in Waiting state. BackupSeen signals an end of Waiting state prior to the wait timer expiring. 

> values as is and consider prio, DR and BDR equal or you consider them all changed?

It doesn't really matter.  Either the first received hello packet includes you as a neighbor from which it has received a hello. In this case, you have a new bi-directional neighbor and you generate a NeighborChange event. If the first hello doesn't include you, you don't generate the NeighborChange event. In either case, you save the values. 

Hope this helps, 
Acee

---

From: Joakim Tjernlund <[email-masked]>
Date: Sun, 8 Jul 2012 22:35:44 +0200

> You need to process BackupSeen first as you don't even recognize NeighborChange in Waiting state. BackupSeen signals an end of Waiting state prior to the wait timer expiring.

Ahh, so the RFC is a bit off then as it checks prio first, now it is starting to make some sense.

> It doesn't really matter.  Either the first received hello packet includes you as a neighbor from which it has received a hello. In this case, you have a new bi-directional neighbor and you generate a NeighborChange event. If the first hello doesn't include you, you don't generate the
NeighborChange event. In either case, you save the values.
> Hope this helps,

Yes, it does. Thanks!

 Jocke