Acee Lindem <[email protected]> wrote on 2012/07/08 22:28:54: > > Hi Joakim, > See inline. > > On Jul 8, 2012, at 3:44 PM, Joakim Tjernlund wrote: > > > 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)? > > 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. > > > > >> > >>> > >>> 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? > > > 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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
