Acee Lindem <[email protected]> wrote on 2012/07/08 20:40:59: > > Hi Joakim, > > On Jul 8, 2012, at 8:30 AM, Joakim Tjernlund wrote: > > >> From: Joakim Tjernlund <[email protected]> > >> To: [email protected], > >> Date: 2012/07/08 13:07 > >> Subject: [OSPF] OSPF Hello questions > >> Sent by: [email protected] > >> > >> > >> 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? > > 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. > > >> > >> 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? > > 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)? > > > > > 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). > > 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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
