|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Narendra Narayana (nanaraya
CISCO.COM)Date: Wed Jul 04 2001 - 00:46:15 CDT
Curtis,
You are correct regarding the point that eventhough a router cannot
elect itself as both DR and BDR, a router can still elect some other
router as both DR and BDR.
However, this is a transient state which lasts until the next Hello is
received from the router that has been chosen as both DR and BDR.
I had asked a similar question earlier and Alex replied to it. (The
subject of the mail was "DR/BDR election").
I am attaching Alex's response at the end of this mail.
-
Narendra A
Curtis Call wrote:
>
> I have a Question about the DR Election procedure as detailed in RFC 2328
> Section 9.4. The fourth step of the process specifies that if the router
> performing the procedure has been elected as BDR or DR, or lost it's position
> as such that it should repeat the process once more in order to ensure that it
> does not advertise itself as both the BDR and the DR. My question is, why is
> this not done by other routers as well in order to keep them from believing
> that the DR and the BDR are the same?
>
> For instance, if router X, determines that router Y is the BDR, and then
> promotes it to be the DR as well, why is there not an immediate check to redo
> the BDR election? Is the reason this isn't considered necessary due to the
> fact that router Y will go through the election procedure again and will pick
> a new BDR so it's hello packets will cause router X to generate a
> NeighborChange event and recalculate the BDR and DR?
>
> Thanks.
--------
-------- Original Message --------
Subject: Re: DR/BDR election
Date: Mon, 28 May 2001 01:58:45 -0700
From: Alex Zinin <azinin
nexsi.com>
Reply-To: Alex Zinin <azinin
nexsi.com>
Organization: Nexsi Systems
To: Narendra <nanaraya
cisco.com>
CC: OSPF
DISCUSS.MICROSOFT.COM, cs-ospf
cisco.com
References: <OSPF%2001052803370396
DISCUSS.MICROSOFT.COM>
Narendra,
> I am new to OSPF and am currently reading RFC2328.
> I have some questions regarding the DR/BDR election (section 9.4 of
> RFC2328).
> (1) Why does the step (4) of the election process apply only to the router
> doing the calculation and not to other routers.
Repeating steps 2 and 3 on other router would give the same results,
as they have the same input until they receive different info in
Hello packets, while if the calculating router changes its "personal
opinion about himself" during the first iteration, the results of
the second will be different.
> Specifically, why do we
> disallow the calculating router from becoming both DR and BDR
Because otherwise there would be no real BDR on the segment.
> but allow some
> other router to become both DR/BDR ?
We just allow other routers to _think_ that the same router is both
DR and BDR until the ex-BDR understands he is the DR and the new BDR
accepted his new responsibilities.
> (2) I can understand that steps (2) and (3) are required to be re-run when
> the calculating router becomes DR/BDR. But why are steps (2) and (3)
> required to be re-run when the calculating router is **no longer** a DR/BDR?
Think about it this way---the DR election algorithm considers all
routers on the segment, and only what _they_ explicitly say about
themselves (which may be different from what the calculating router
thinks at the moment). Whenever some router changes its opinion
(e.g., some router announces or stops announcing itself as the BDR),
we need to recalculate DR/BDR pair. We know about the change in
opinion when we see that the contents of the Hellos from the nbr changed
and this happens when the neighbor has completed the DR election
algo on its side and got new results. Now, the calculating router
itself is "a router" from the DR election algo perspective, so we
need to rerun the algo when our self changes the opinion, but we do
not process any Hello packets from ourselves, so we check the results
explicitly.
Hope this helps a bit :)
Alex.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]