Thanks Jonah - glad that helped a bit. But it sounds as if you did
the real heavy lifting with your protocol analysis. Good work.
>Your explanation is really clear.
Perhaps with a few exceptions! ;-) Every time my brain thought "multi-
access," my fingers apparently typed "NBMA." I think it would have
been more appropriate to just use the more generic term "multi-
access." Also, I said "two of these routers has DR/BDR Priority <
0." That would've been cute, eh? Let's try DR/BDR priority > 0. ;=]
>Do I need to know all this to be a CCIE? :)
Nah, probably not. Regardless of which router is Master and which is
Slave, the databases ultimately get synchronized. But I'll tell you
one thing: packet capture of protocol behavior in the wild (/lab) is
definitely your friend. Every time I thought I knew everything there
was to know about RIPv2 (etc), I would go grab some packets out of a
lab scenario and discover something subtle I hadn't ever thought about
before. It'll make you a better candidate and it'll definitely make
you a better CCIE to know how to perform this sort of analysis for
yourself. I'm closing out a consulting gig this very afternoon that
was 100% protocol (RTP) analysis - had nothing to do at all with my
R&S abilities, per se. But I definitely honed my Wiresharking skills
during lab prep, that's for sure.
Cheers,
Scott
____________________________________________
There are only 10 types of people in the world:
Those who understand binary and those who do not...
On May 17, 2011, at 2:54 , Jonah Dienye wrote:
> Wow! Thanks, Scott. Your explanation is really clear. A packet capture
> verifies this. Also, the first DBD packets sent during the exchange
> have
> randomized sequence numbers, but the Slave backs down and uses the
> Master's
> sequence number for the rest of the DBD exchange.
> Do I need to know all this to be a CCIE? :)
>
> On Tue, May 17, 2011 at 3:38 AM, Scott M Vermillion <
> scott_ccie_list_at_it-ag.com> wrote:
>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Jonah Dienye
> +2348069355435
>
>
> 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 Tue May 17 2011 - 09:42:53 ART
This archive was generated by hypermail 2.2.0 : Wed Jun 01 2011 - 09:01:11 ART