Re: OSPF DBDs

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