Re: OSPF DBDs

After sending the below, a theoretical scenario occurred to me and I
thought (hope) it might help clarify the issue:

Suppose an NBMA network exists with three established OSPF speakers.
Assuming at least two of these routers has DR/BDR Priority < 0, then
one has been elected DR, one BDR, and the other is DRother. Now a
fourth OSPF speaker, R4, is brought online. It will learn of the
existing DR and BDR via OSPF Hellos and thus no DR/BDR election will
be necessary (regardless of its configured priority). Naturally, R4
still needs to become adjacent with the existing DR and BDR routers on
the NBMA segment. Suppose that this new R4 has a higher RID than the
existing DR. In this case, R4 should be the Master during the
database exchange process, while at the same time be DRother. So here
we see a case where the DR would not, at least theoretically, assert
the M/S Bit (I say theoretically because I don't at the moment have
relevant packet capture to back this exact scenario up).

Bear in mind that DR/BDR are somewhat persistent states (all things
remaining equal), whereas I would consider Master/Slave to be a
transient state, existing and important only during the brief database
synchronization process. I would think that if you were to raise the
DR/BDR Priority of R4 to be the highest on the NBMA, but at the same
time lower its RID relative to the old DR, and then force all the
adjacencies to reform...R4 would become the new DR but now be Slave
for the purposes of database synchronization with the former DR.

____________________________________________
There are only 10 types of people in the world:
Those who understand binary and those who do not...

On May 16, 2011, at 8:04 , Scott M Vermillion wrote:

> Gents,
>
> Not 100% sure that I'm correctly tracking the discussion here, but
> as far as I can tell there's a slight muddling of two distinct
> concepts:
>
> 1. DR/BDR election
> 2. Master/Slave election
>
> The former occurs only on a subset of network types (and even then
> only in a subset of cases - namely when no DR/BDR already exists),
> whereas the latter occurs every time two OSPF routers neighbor up.
> In other words, on a p-t-p network (for example), although there
> won't be a DR/BDR election, there will still be a Master/Slave
> election so that the database synchronization process can move
> forward in an orderly fashion.
>
> In the below discussion, when it is said that "only the DR sets the
> MASTER bit," it's would be more technically correct to say that
> "only the Master sets the M/S Bit," as it has won the Master/Slave
> election by virtue of its higher RID. Note that while the criteria
> for DR/BDR election and Master/Slave election are essentially the
> same (highest RID (assuming equal priority in the case of DR/BDR
> election)), it's again important to note that DR/BDR election may or
> may not be necessary (depending on both the network type and whether
> or not a DR/BDR has already been elected), while Master/Slave
> election will always be necessary in the formation of a new neighbor
> relationship, regardless of network type and DR/BDR election status.
>
> That last sentence was a doozy - hopefully it makes sense with a
> careful reading or two. Heck, hopefully it makes sense at all! ;-)
>
> Scott
>
> ____________________________________________
> There are only 10 types of people in the world:
> Those who understand binary and those who do not...
>
>
> On May 16, 2011, at 2:14 , Paul Negron wrote:
>
>> That's right. I forgot about the "INIT" bit.
>>
>> I'm not sure but....
>> This may be an implementation issue. I see it as being a
>> deterministic
>> behavior thing since this still happens on a point-to-point link as
>> well.
>> Just no election of the DR.
>>
>> Where is Peter Lapukhov. He usually pretty good at explaining some
>> of these
>> details.
>>
>> Paul
>> --
>> Paul Negron
>> CCIE# 14856 CCSI# 22752
>> Senior Technical Instructor
>> www.micronicstraining.com
>>
>>
>>
>>> From: <jnhdny_at_gmail.com>
>>> Reply-To: <jnhdny_at_gmail.com>
>>> Date: Mon, 16 May 2011 18:25:47 +0000
>>> To: Paul Negron <negron.paul_at_gmail.com>, <ccielab_at_groupstudy.com>
>>> Subject: Re: OSPF DBDs
>>>
>>> I think that's right Paul. Was looking at a capture and trying to
>>> make sense
>>> of it all. The INIT, MORE, and MASTER bit are set in the first two
>>> DBDs (one
>>> by each router). Subsequently, only the DR sets the MASTER bit.
>>> Why is the election done at this time, when information needed to
>>> decide
>>> DR/BDR is contained in Hello packets?
>>>
>>>
>>> Sent from my BlackBerry wireless device from MTN
>>>
>>> -----Original Message-----
>>> From: Paul Negron <negron.paul_at_gmail.com>
>>> Date: Mon, 16 May 2011 12:14:44
>>> To: <jnhdny_at_gmail.com>; <ccielab_at_groupstudy.com>
>>> Subject: Re: OSPF DBDs
>>>
>>> DBD's are also used to enforce the "Mastership" of an OSPF peering
>>> relationship. During the "Exstart" phase of the peering, OSPF
>>> sends DBD's to
>>> enforce a Master and Slave state for peers that will Start the
>>> Exchange.
>>>
>>> The "Master" bit and the "More Bit" are sent initially by both
>>> peers in a
>>> DBD but will negotiate based on the higher router-id. The peer
>>> with the
>>> higher router-id has its "More" bit and "Master" bit remain set.
>>> The lower
>>> router-id does not set the "Master" bit on the next DBD just prior
>>> to
>>> exchanging LSA's.
>>>
>>> If this is seen as not being correct by another CCIE or CCIE
>>> Candadite.
>>> Please let me know. I am always looking for different explanations
>>> or views
>>> or correction if NEEDED.
>>>
>>>
>>> Paul
>>> --
>>> Paul Negron
>>> CCIE# 14856 CCSI# 22752
>>> Senior Technical Instructor
>>> www.micronicstraining.com
>>>
>>>
>>>
>>>> From: <jnhdny_at_gmail.com>
>>>> Reply-To: <jnhdny_at_gmail.com>
>>>> Date: Mon, 16 May 2011 17:45:33 +0000
>>>> To: <ccielab_at_groupstudy.com>
>>>> Subject: OSPF DBDs
>>>>
>>>> Please, does anyone know *why* DBDs have to be exchanged before
>>>> actual LS
>>>> requests and updates are sent? Why not just send all the LSAs in
>>>> the database
>>>> to the neighbour?
>>>> Sent from my BlackBerry wireless device from MTN
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Mon May 16 2011 - 20:38:05 ART