From: Dmitry Volkov (dmitry.volkov@rogers.com)
Date: Sat Dec 27 2003 - 22:00:00 GMT-3
David,
I tested it:
Both routers - without neighbor statement and with it will move from DOWN to
ATTEMPT to INIT state and after that to 2WAY upon startup. Only boxes with
neighbor priority >0 configured will send hellos immediately after startup
to their neighbors.
So I think it's really subject how routers on NBMA handle hellos within
first 120 sec after comming up.
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
> Behalf Of David Porta
> Sent: Saturday, December 27, 2003 6:49 PM
> To: Dmitry Volkov
> Cc: 'Mike Williams'; 'P729'; 'Bob Sinclair'; 'Ashok Verma
> (ashoverm)'; ccielab@groupstudy.com
> Subject: Re: OSPF in NBMA networks
>
>
> I think that your conclusion sounds correct.
>
> Also, something else you mentioned made me think of something else.
> 1. The DR/BDR election process is triggered by the Interface
> State machine, and
> not the Neighbor State machine.
> 2. The first purpose of the Hello packet is to identify
> neighboring routers, in
> order to establish neighbor relationships, and later on adjacencies.
> Therefore, in the NBMA networks, since the routers already
> "know" who their
> neighbors are thanks to the static configuration of neighbor
> statements, by
> giving a priority value to the neighbor we force the routers
> to exchange Hellos
> immediately in order to transition to the 2-WAY state, and
> since all the
> necessary information for the DR/BDR election was also
> statically configured,
> the routers can immediately move on to electing the DR/BDR.
>
> I think I am going to lab it and check it with a protocol
> analyser in order to
> see the exact differences in the communication behaviour.
>
> Cheers,
> David
>
>
>
> Dmitry Volkov wrote:
>
> > Well, I read it earlier and didn't understand exactly what
> did they mean...
> > DR/BDR election starts after 2-WAY state established - i.e.
> after each
> > router received neighbor's hello with priority inside (state INIT)
> > and after each router got hello from neighbor with his own
> RID (state
> > 2-WAY). This is true whenever priority configured or not.
> >
> > > "When the router first starts up, it sends only hello packets
> > > to those routers
> > > with nonzero priority,
> >
> > This is partially true. Word "ONLY" here is not correct
> > When we configure "neighbor x.x.x.x" (i.e. with prior 0)
> and reload router,
> > it doesn't send any hellos within wait interval (120 sec on
> non-broad) after
> > that router starts sending each hellointerval (30 sec on
> non-broadc) within
> > 120 sec until dead timer expired and later sending each
> poolinterval (120
> > sec on non-broadcast)
> > when we configure "neighbor x.x.x.x priority > 0" it starts
> sending hellos
> > upon startup until dead interval expired (120 sec on
> non-broadc) and after
> > that continue to send each poolinterval (120 sec on non-broadc)
> >
> > Since we usually configure "neighbor x.x.x.x" on Hub and
> "ip ospf priority
> > 0" on Spoke's interface or "ip ospf priority >1" on Hub
> interface, nothing
> > happens within first 120 sec on NBMA after hub came on-line
> (spoke doesn't
> > send anything to hub because it doesn't have neighbor
> configured) and only
> > after wait interval expired hub sends hello to spoke,
> receive reply, etc.
> >
> > So, "weird" conclusion comes in mind:
> > looks like to expedite process of building adj between hub and spoke
> > "neighbor x.x.x.x priority >0" has to be on BOTH (to be
> able to send hellos
> > upon startup) hub and spoke and NO "ip ospf priority 0" on
> spoke's interface
> > (default "1") and something >1 priority on hub's interface. This way
> > whenever hub or spoke come on-line hello exchanges happens
> immediately.
> > Because it's not very scalable - to put something on spokes
> - at least
> > "neighbor x.x.x.x priority >0" has to be on Hub and "ip
> ospf priority >1"
> > also on Hub.
> >
> > Any comments ??
> >
> > Dmitry
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
> > > Behalf Of David Porta
> > > Sent: Saturday, December 27, 2003 7:27 AM
> > > To: Dmitry Volkov
> > > Cc: 'Mike Williams'; 'P729'; 'Bob Sinclair'; 'Ashok Verma
> > > (ashoverm)'; ccielab@groupstudy.com
> > > Subject: Re: OSPF in NBMA networks
> > >
> > >
> > > Hello everyone,
> > >
> > > I think I understand the purpose of the optional priority
> > > value on the neighbor
> > > command.
> > >
> > > Please refer to the following link on your Doc CD and under
> > > "Usage Guidelines"
> > > read paragraph 4:
> > > http://127.0.0.1:8080/cc/td/doc/product/software/ios122/122cgc
> > > r/fiprrp_r/1rfospf.htm#xtocid31
> > >
> > > "When the router first starts up, it sends only hello packets
> > > to those routers
> > > with nonzero priority, that is, routers that are eligible to
> > > become designated
> > > routers (DRs) and backup designated routers (BDRs). ... "
> > >
> > > This is what understand:
> > > In an effort to expedite the DR / BDR election process and
> > > adjacency formations
> > > with them on NBMA networks when routers first start up, we
> > > can specify the
> > > neighboring router's priority value on the neighbor statement.
> > > This way, when the router boots up and loads the OSPF
> > > configuration, the router
> > > does not have to wait for Hello's to be sent to it in order
> > > to know the
> > > priority value of its neigbors, plus the wait timer to expire
> > > before commencing
> > > the DR / BDR election process.
> > >
> > > Therefore the priority option on the neighbor command is
> > > meant to fill in the
> > > priority value information for the neighbors as soon as it
> > > boots up, instead of
> > > waiting for this value to arrive from the Hello packets, and
> > > move on with the
> > > adjacency formation process with the DR and BDR.
> > >
> > >
> > > What do you guys think?
> > >
> > >
> > > Cheers,
> > > David.
> > >
> > >
> > >
> > > Dmitry Volkov wrote:
> > >
> > > > routers send their own priority to each other inside
> hello packets.
> > > > there is no way that one dictates to another what priority
> > > is should have.
> > > > one router can't alter priority of other router.
> > > > there is also no way that one can alter priority it
> > > received from other
> > > > let say A------B
> > > > B's interface has default priority "1"
> > > > You configure on A: neighbor x.x.x.x priority 10 (where
> > > x.x.x.x - ip of B's
> > > > interface)
> > > >
> > > > when You do "sh run" immediatelly after You did put neigbor
> > > statement You
> > > > will see exactly what You did configure
> > > > and "sh ip ospf nei" shows configured priority but as soon
> > > A received hello
> > > > packet from B - everything is reverted back
> > > >
> > > > Dmitry
> > > >
> > > > > -----Original Message-----
> > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
> > > > > Behalf Of Mike Williams
> > > > > Sent: Saturday, December 27, 2003 12:53 AM
> > > > > To: 'Dmitry Volkov'; 'P729'; 'Bob Sinclair'; 'Ashok Verma
> > > (ashoverm)'
> > > > > Cc: ccielab@groupstudy.com
> > > > > Subject: RE: OSPF in NBMA networks
> > > > >
> > > > >
> > > > > Is it possible that by specifying a priority with the
> > > neigbor command
> > > > > that it's overriding the priority that's being sent?
> I know this
> > > > > doesn't seem to make sense as it would be silly to do so, but
> > > > > possible?
> > > > > Otherwise, I'd agree that there's really no reason to
> specify the
> > > > > priority on the neighbor command (not only no reason to
> > > > > specify, but no
> > > > > reason for Cisco to even have that command as a option
> > > unless there's
> > > > > *some* functionality, although it wouldn't be the
> first time =)
> > > > >
> > > > > Mike W.
> > > > >
> > > > > -----Original Message-----
> > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > > > > Behalf Of
> > > > > Dmitry Volkov
> > > > > Sent: Friday, December 26, 2003 10:24 PM
> > > > > To: 'P729'; 'Bob Sinclair'; 'Ashok Verma (ashoverm)'
> > > > > Cc: ccielab@groupstudy.com
> > > > > Subject: RE: OSPF in NBMA networks
> > > > >
> > > > >
> > > > > Ok. This is all true. But what is the purpose of such
> > > "indication" ??
> > > > > Surprisingly enough that Syed Faraz Shamim - author of
> > > > > "Troubleshooting
> > > > > IP routing protocols" also follows Doyle's "mistake"
> > > (page 557-558)
> > > > > http://www.cisco.com/en/US/tech/tk365/tk480/technologies_confi
> > > > > guration_e
> > > > > xamp
> > > > > le09186a0080094054.shtml#4
> > > > > router ospf 1
> > > > > network 1.1.1.0 0.0.0.255 area 0
> > > > > neighbor 1.1.1.2 priority 2
> > > > > !--Used to manually configure neighbors and assign
> > > > > the priority. In case of a Hub and Spoke topology,
> > > > > the Hub should be elected as the DR as it has
> > > > > connectivity to all the spokes. This can be done
> > > > > by assigning higher priority to the Hub using the
> > > > > neighbor command on the Spoke routers
> > > > >
> > > > > Dmitry
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: nobody@groupstudy.com
> > > > > [mailto:nobody@groupstudy.com]On Behalf Of
> > > > >
> > > > > > P729
> > > > > > Sent: Friday, December 26, 2003 2:24 PM
> > > > > > To: Bob Sinclair; Ashok Verma (ashoverm);
> ccielab@groupstudy.com
> > > > > > Subject: Re: OSPF in NBMA networks
> > > > > >
> > > > > >
> > > > > > Great explanation Bob. Another clue is there is no
> > > provision in the
> > > > > > OSPF Hello protocol for telling a neighbor what the
> neighbor's
> > > > > > priority should
> > > > > > be. You only indicate what your own priority is.
> > > > > >
> > > > > > Happy holidays,
> > > > > >
> > > > > > Mas Kato
> > > > > > https://ecardfile.com/id/mkato
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Bob Sinclair" <bsin@cox.net>
> > > > > > To: "Ashok Verma (ashoverm)" <ashoverm@cisco.com>;
> > > > > > <ccielab@groupstudy.com>
> > > > > > Sent: Friday, December 26, 2003 8:03 AM
> > > > > > Subject: Re: OSPF in NBMA networks
> > > > > >
> > > > > >
> > > > > > > Ashok,
> > > > > > >
> > > > > > > What you are seeing is common and probably not a "bug".
> > > > > > >
> > > > > > > Much of the documentation seems to say that you
> can control
> > > > > > the priority
> > > > > > of
> > > > > > > a neighbor with this command. But the command docs
> > > > > > actually say that the
> > > > > > > neighbor priority command "indicates the router priority
> > > > > > value of the
> > > > > > > nonbroadcast neighbor associated with the IP address
> > > > > specified". In
> > > > >
> > > > > > > practice, it "indicates" the same way a speedometer
> > > > > "indicates" your
> > > > > > speed:
> > > > > > > it shows but does not determine.
> > > > > > >
> > > > > > > Even Doyle seems to say that you can control a neighbor's
> > > > > > priority with
> > > > > > this
> > > > > > > command, but I have never seen it actually work.
> > > > > > >
> > > > > > > In practice, you will find that only entering the priority
> > > > > > on the local
> > > > > > > interface will actually determine a priority. You will
> > > > > > also find that the
> > > > > > > local neighbor priority command reflects the priority
> > > > > > configured on the
> > > > > > > remote neighbor interface, and will change with it.
> > > > > > >
> > > > > > > HTH,
> > > > > > >
> > > > > > > -Bob Sinclair
> > > > > > > CCIE #10427, CISSP, MCSE
> > > > > > > www.netmasterclass.net
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "Ashok Verma (ashoverm)" <ashoverm@cisco.com>
> > > > > > > To: <ccielab@groupstudy.com>
> > > > > > > Sent: Friday, December 26, 2003 5:20 AM
> > > > > > > Subject: OSPF in NBMA networks
> > > > > > >
> > > > > > >
> > > > > > > > Hi All
> > > > > > > >
> > > > > > > > I have a query about NEIGHBOR command, which is used in
> > > > > > the NBMA network
> > > > > > > > to make the ospf peering
> > > > > > > >
> > > > > > > > When we define the #neighbour x.x.x.x priority 0
> > > > > > > >
> > > > > > > > What is the priority 0 means . Is it mean the other side
> > > > > > router can not
> > > > > > > > become the DR .
> > > > > > > >
> > > > > > > > One more observation I have is even if configure the #
> > > > > > neighbour x.x.x.x
> > > > > > > > priority 0
> > > > > > > >
> > > > > > > > When I check the configuration I see it as #neighbour
> > > > > > x.x.x.x priority 1
> > > > > > > > .....is it a bug ?
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanx
> > > > > > > >
> > > > > > > > Ashok Kumar Verma
> > > > > > > > CCIP,CCDP,CCNP
> > > > > > > > Network Consulting Engineer
> > > > > > > > Customer Advocacy Advanced Service Dep.
> > > > > > > > Service Provider AS Div.2
> > > > > > > > Cisco Systems, K.K.Japan.
> > > > > > > >
> > > > > > > > Tel: +81-3-5324-4583
> > > > > > > > e-mail: ashoverm@cisco.com
> > >
> > >
> > > -------------------------------
> > > This email message and any attachment(s) is intended only for the
> > > person(s) or entity(entities) to whom it is addressed. The
> > > information it contains may be classified as IN
> CONFIDENCE and may be
> > > legally privileged. If you are not the intended
> recipient any use,
> > > disclosure or copying of the message or attachment(s) is strictly
> > > prohibited. If you have received this message in error please
> > > notify us immediately and destroy it and any attachment(s).
> > > Thank you. The Ministry of Social Development accepts no
> > > responsibility for changes made to this message or to any
> > > attachment(s) after transmission from the Ministry.
> > > -------------------------------
>
>
> -------------------------------
> This email message and any attachment(s) is intended only for the
> person(s) or entity(entities) to whom it is addressed. The
> information it contains may be classified as IN CONFIDENCE and may be
> legally privileged. If you are not the intended recipient any use,
> disclosure or copying of the message or attachment(s) is strictly
> prohibited. If you have received this message in error please
> notify us immediately and destroy it and any attachment(s).
> Thank you. The Ministry of Social Development accepts no
> responsibility for changes made to this message or to any
> attachment(s) after transmission from the Ministry.
> -------------------------------
>
> ______________________________________________________________
> _________
> Please help support GroupStudy by purchasing your study
> materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Jan 03 2004 - 08:25:45 GMT-3