Now that everyone seems to have setled on an understanding of the
election process, I would like to restate that there is no DR election,
just BDR.
If you follow the RFC, the only way to become DR is by having been
elected (or autonominated) BDR first. If I'm mistaken, I would like to know.
-Carlos
Marko Milivojevic @ 23/02/2014 02:14 -0300 dixit:
> Yup, correct. Much more interesting is to observe what happens with the
> state machine on those spokes that were, form hub's perspective, DR and BDR
> :-). Look at that one.
>
> And as Brian said - this is a broken setup, but it's an interesting to
> observe the process and understand WHY. And to add to Brian's list of
> places where this may be relevant today: PVLAN.
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor / Managing Partner - iPexpert
> :: Free Video Training: http://youtube.com/iPexpertInc
> :: Social: http://twitter.com/@icemarkom | http://fb.me/ccie18427
> :: iPexpert: http://www.ipexpert.com/Communities | +1-810-326-1444
>
>
>
> On Sat, Feb 22, 2014 at 8:56 AM, Tony Singh <mothafungla_at_gmail.com> wrote:
>
>>
>> Marko
>>
>> if we make the HUB priority 0 then each spoke would see the following in
>> the election debugs...
>>
>> Spoke 1
>> *Mar 1 05:15:25.278: OSPF: Elect BDR 0.0.0.0
>> *Mar 1 05:15:25.278: OSPF: Elect DR 2.2.2.2
>> *Mar 1 05:15:25.278: DR: 2.2.2.2 (Id) BDR: none
>>
>> Spoke 2
>> *Mar 1 05:15:26.774: OSPF: Elect BDR 0.0.0.0
>> *Mar 1 05:15:26.774: OSPF: Elect DR 3.3.3.3
>> *Mar 1 05:15:26.774: DR: 3.3.3.3 (Id) BDR: none
>>
>> where in fact the HUB see's
>>
>> R1#show ip ospf neighbor
>>
>> Neighbor ID Pri State Dead Time Address Interface
>> 2.2.2.2 200 FULL/DR 00:00:33 172.168.18.2 Serial1/0
>> 3.3.3.3 100 2WAY/DROTHER 00:00:35 172.168.18.3 Serial1/0
>>
>>
>> so each spoke declares themselves as DR but the HUB elects one DR in
>> precedence of of priority/highest router-id
>>
>> the non DR/BDR spoke from HUBS perspective goes into a EXSTART and keeps
>> re-transmitting his DBD packet but stays in a DOWN state
>>
>> If the HUB remains as DR or BDR then we can get full LSA LSDB replication
>> from each spoke in this design = NBMA ip ospf network broadcast
>>
>> Let me know if that's not right..
>>
>> BR
>>
>> Tony
>>
>>
>>
>> On 22 February 2014 01:47, Marko Milivojevic <markom_at_ipexpert.com> wrote:
>>
>>> Things do get a bit more tricky in hub and spoke configurations when all
>>> routers don't see all the hellos. Try setting up hub-and-spoke making sure
>>> hub is NOIT the DR. See what the result will be. Now, ignore for a second
>>> the fact your routing will be broken, but observe DR/BDR status on the 3
>>> devices. It's really entertaining!
>>>
>>> --
>>> Marko Milivojevic - CCIE #18427 (SP R&S)
>>> Senior CCIE Instructor / Managing Partner - iPexpert
>>> :: Free Video Training: http://youtube.com/iPexpertInc
>>> :: Social: http://twitter.com/@icemarkom | http://fb.me/ccie18427
>>> :: iPexpert: http://www.ipexpert.com/Communities | +1-810-326-1444
>>>
>>>
>>>
>>> On Fri, Feb 21, 2014 at 5:41 PM, vishal bhugra <vishal.bhugra_at_gmail.com
>>>> wrote:
>>>
>>>> Thanks Marko and Brian
>>>>
>>>> Now I understood the complete election process
>>>>
>>>>
>>>> On Fri, Feb 21, 2014 at 4:28 PM, Marko Milivojevic <markom_at_ipexpert.com
>>>> wrote:
>>>>
>>>>>
>>>>> During the WAIT state (dead-interval duration), all routers will be
>>>>> sending hellos with DR/BDR set to 0.0.0.0. However, all routers can see
>>>>> each other's hellos and since noone is claiming DR/BDR they will hold
>>> the
>>>>> election - basically. each router will decide what's going to be the
>>>>> topology based on hellos they've observed. One that is at that time
>>>>> considered the best will claim DR and the second best will claim BDR.
>>>>> That's how they will populate the fields once they leave the WAIT
>>> state.
>>>>>
>>>>> --
>>>>> Marko Milivojevic - CCIE #18427 (SP R&S)
>>>>> Senior CCIE Instructor / Managing Partner - iPexpert
>>>>> :: Free Video Training: http://youtube.com/iPexpertInc
>>>>> :: Social: http://twitter.com/@icemarkom | http://fb.me/ccie18427
>>>>> :: iPexpert: http://www.ipexpert.com/Communities | +1-810-326-1444
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 21, 2014 at 3:58 PM, vishal bhugra <
>>> vishal.bhugra_at_gmail.com>wrote:
>>>>>
>>>>>> Hello Brian
>>>>>>
>>>>>> Thanks for your kind answer.
>>>>>>
>>>>>> If I configure 5 routers on broadcast network, all with same priority.
>>>>>> They
>>>>>> all are new in the segment and now the election start. Now my
>>> questions
>>>>>> are:-
>>>>>>
>>>>>> 1) Do all of them put their Router ID in DR field of Hello? and
>>> highest
>>>>>> RID
>>>>>> will become the DR and lower one will be the BDR ?
>>>>>>
>>>>>> OR
>>>>>>
>>>>>> 2) Will some one put his router ID in BDR field ? and if yes how will
>>> he
>>>>>> decide that it has to put the RID in BDR field of Hello packet and
>>> not
>>>>>> the
>>>>>> DR.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 21, 2014 at 2:28 PM, Brian McGahan <bmcgahan_at_ine.com>
>>> wrote:
>>>>>>
>>>>>>> In general the first router to join the segment becomes DR and the
>>>>>> second
>>>>>>> router to join becomes BDR. If DR fails the BDR is promoted to DR
>>> and
>>>>>> there
>>>>>>> is a new election for BDR. There are some odd corner cases where
>>> this
>>>>>> wont
>>>>>>> happen though.
>>>>>>>
>>>>>>> When the router joins the segment it listens for WAIT timer to
>>> expire.
>>>>>> If
>>>>>>> during this interval it receives a hello from another router on the
>>>>>>> segment, it will accept the DR information in the packet and start
>>> to
>>>>>> send
>>>>>>> hellos. If however no one is heard during WAIT, the router elects
>>>>>> itself DR
>>>>>>> and inserts this in its own hello.
>>>>>>>
>>>>>>> This mean that if for some reason communication is broken during
>>> WAIT
>>>>>>> interval, two routers can elect themselves as both DR, in which case
>>>>>> there
>>>>>>> *will* be a preemptive election once they both hear each others
>>> hellos.
>>>>>>>
>>>>>>> For example this could happen if your OSPF DEAD/WAIT interval is
>>> lower
>>>>>>> than your STP Forward Delay, WAIT would expire before the router can
>>>>>>> receive packets and it would elect itself as DR.
>>>>>>>
>>>>>>> This is not the normal case though. For more info see
>>>>>>> https://tools.ietf.org/html/rfc2328#page-75
>>>>>>>
>>>>>>>
>>>>>>> Brian McGahan, 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13
>>>>>>> bmcgahan_at_INE.com
>>>>>>>
>>>>>>> Internetwork Expert, Inc.
>>>>>>> http://www.INE.com <http://www.ine.com/>
>>>>>>
>>>>>>>
>>>>>>> On Feb 21, 2014, at 6:01 AM, "Carlos G Mendioroz" <tron_at_huapi.ba.ar
>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I don't know where are you reading this, but I thought that there is
>>>>>>> only BDR election process. Once you are BDR, then you can jump to
>>> DR if
>>>>>>> the current DR fails.
>>>>>>>
>>>>>>> So that is why, I guess. You don't opt, you have no choice :)
>>>>>>> -Carlos
>>>>>>>
>>>>>>> vishal bhugra @ 20/02/2014 20:28 -0300 dixit:
>>>>>>>
>>>>>>> Hello Experts
>>>>>>>
>>>>>>>
>>>>>>> While going through the DR and BDR election process. I gone through
>>> a
>>>>>> line
>>>>>>>
>>>>>>> wherein during the process of election the router will segregate the
>>>>>> list
>>>>>>>
>>>>>>> of routers who have mentioned themselves as BDR and those who have
>>>>>>>
>>>>>>> mentioned themselves as DR.
>>>>>>>
>>>>>>>
>>>>>>> After segregation out of the list of BDR, the elected BDR will be
>>> with
>>>>>> the
>>>>>>>
>>>>>>> highest priority and if not then highest Router ID.
>>>>>>>
>>>>>>>
>>>>>>> Now my question is .. Why would a router will opt himself for BDR
>>> and
>>>>>> not
>>>>>>>
>>>>>>> for DR. Or we can say how a router will come to conclusion that it
>>> has
>>>>>> to
>>>>>>>
>>>>>>> go for be a BDR not the DR.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>>>>>>
>>>>>>>
>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>
>>>>>>>
>>> _______________________________________________________________________
>>>>>>> Subscription information may be found at:
>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks®ards
>>>>>>
>>>>>> Vishal
>>>>>> +91 8587900305
>>>>>>
>>>>>> Best way to predict the future ..... is to create it
>>>>>> _______________________________________________
>>>>>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos
>>> ::
>>>>>>
>>>>>> iPexpert on YouTube: www.youtube.com/ipexpertinc
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks®ards
>>>>
>>>> Vishal
>>>> +91 8587900305
>>>>
>>>> Best way to predict the future ..... is to create it
>>>>
>>> _______________________________________________
>>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos ::
>>>
>>> iPexpert on YouTube: www.youtube.com/ipexpertinc
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
-- Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina Blogs and organic groups at http://www.ccie.netReceived on Mon Feb 24 2014 - 18:29:44 ART
This archive was generated by hypermail 2.2.0 : Sat Mar 01 2014 - 08:41:48 ART