From: Curtis Call (curtiscall@xxxxxxxx)
Date: Fri Apr 27 2001 - 11:10:50 GMT-3
Just a thought, I believe that the priority subcommand is used to tell the
local router whether or not it should consider that particular neighbor to
be eligible for the DR election process. According to the RFC, a router is
supposed to know whether or not it's neighbor's are eligible to be DR, and
that determines whether or not hellos are sent to them. Someone might want
to test this, but according to my reading of the RFC, if an eligible router
is not the DR it will not send hellos to noneligible neighbors. Likewise,
a noneligible neighbor will never send a hello to another noneligible
neighbor (according to the RFC) except in replying to their hello packets,
they will only be sent to the DR and BDR. Of course, keep in mind that
this is only referring to NBMA networks.
9.5.1. Sending Hello packets on NBMA networks
Static configuration information may be necessary in order for the Hello
Protocol to function on non-broadcast networks (see Sections C.5 and C.6).
On NBMA networks, every attached router which is eligible to become
Designated Router becomes aware of all of its neighbors on the network
(either through configuration or by some unspecified mechanism). Each
neighbor is labelled with the neighbor's Designated Router eligibility. The
interface state must be at least Waiting for any Hello Packets to be sent
out the NBMA interface. Hello Packets are then sent directly (as unicasts)
to some subset of a router's neighbors. Sometimes an Hello Packet is sent
periodically on a timer; at other times it is sent as a response to a
received Hello Packet. A router's hello- sending behavior varies depending
on whether the router itself is eligible to become Designated Router. If
the router is eligible to become Designated Router, it must periodically
send Hello Packets to all neighbors that are also eligible. In addition, if
the router is itself the Designated Router or Backup Designated Router, it
must also send periodic Hello Packets to all other neighbors. This means
that any two eligible routers are always exchanging Hello Packets, which is
necessary for the correct operation of the Designated Router election
algorithm. To minimize the number of Hello Packets sent, the number of
eligible routers on an NBMA network should be kept small.
At 06:43 AM 4/27/01, you wrote:
>Nor is their any capability to secure or control this process. To me, it
>seems contrary to the rfc to allow one router to set anothers priority and
>I haven't seen any documentation that refers to that process. The command
>seems poorly documented on cco.
>
>*********** REPLY SEPARATOR ***********
>
>On 4/26/2001 at 7:49 PM Curtis Call wrote:
>
> >That makes sense since the OSPF peering process contains no mechanism for
> >a
> >router to influence the priority of another router.
> >
> >At 02:06 PM 4/26/01, you wrote:
> >>Did the save, reboot thing and the router with the highest RID becomes DR
> >in
> >>the scenario where all interface priorities are default. The neighbor
> >>priority statements didn't make any difference.
> >>
> >>
> >>----- Original Message -----
> >>From: "Mas Kato" <tealp729@home.com>
> >>To: <ccielab@groupstudy.com>
> >>Sent: Thursday, April 26, 2001 6:57 PM
> >>Subject: RE: OSPF neighbor priority
> >>
> >>
> >> > True, priority influences the DR election process, prior to everyone
> >> > going to the FULL state with the DR.
> >> >
> >> > Bob, another thing to note is once a DR is elected, there is no
> >> > preemption. So if an interface comes up in multi-access mode and
> >doesn't
> >> > hear from any other challengers to the DR election, it elects itself
> >the
> >> > DR. When others come on the line, the first thing they do is check to
> >> > see if a DR (and a BDR) already exists.
> >> >
> >> > If still want to prove the viability of setting the priority on the
> >> > neighbor statement, why don't you try setting it, saving it and then
> >> > rebooting all of the routers involved? 'clear ip ospf process' might
> >> > save you a reboot--I'm not sure...
> >> >
> >> > Mas Kato
> >> >
> >> > -----Original Message-----
> >> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> >> > adiment@uswest.com
> >> > Sent: Thursday, April 26, 2001 5:57 AM
> >> > To: ccielab@groupstudy.com
> >> > Subject: RE: OSPF neighbor priority
> >> >
> >> >
> >> > When the routers exchange lsa's don't they tell each other what their
> >> > priority is. I would think that the spoke router is telling the hub
> >> > router
> >> > what its priority is. I don't know if the hub router can tell the
> >spoke
> >> > router what its priority should be.
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: Bob Chahal [mailto:bob.chahal@ntlworld.com]
> >> > Sent: Wednesday, April 25, 2001 4:46 PM
> >> > To: ccielab@groupstudy.com
> >> > Subject: OSPF neighbor priority
> >> >
> >> >
> >> > I searched the archives and lab'd this extensively but in a
> >partial-mesh
> >> > frame-relay non-broadcast OPSF scenario i cannot get the
> >> >
> >> > neighbor x.x.x.x priority 10
> >> >
> >> > command to do what it should do. The config keeps changing back to the
> >> > priority that the neighbor router is actually set to. i.e
> >> >
> >> > neighbor x.x.x.x priority 1
> >> >
> >> > The issue is to get the hub router to be the DR. The way around this is
> >> > to
> >> > actaully change the priorities on the serial interfaces but that might
> >> > not
> >> > be an allowed option in a lab.
> >> >
> >> > Previous post have suggested bugs in certain IOS versions, I'm running
> >> > c2500-js-l.112-24.bin. Is there anything I am missing here. Basically
> >> > the
> >> > router with highest RID beomes DR even if I set the neighbor priority.
> >> >
> >> > People have said nail the basics and this is basic. Help?
> >> >
> >> > Thanks
> >> >
> >> > B
> >> > **Please read:http://www.groupstudy.com/list/posting.html
> >> > **Please read:http://www.groupstudy.com/list/posting.html
> >> > **Please read:http://www.groupstudy.com/list/posting.html
> >>**Please read:http://www.groupstudy.com/list/posting.html
> >**Please read:http://www.groupstudy.com/list/posting.html
>**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:59 GMT-3