Re: DR election

Acee Lindem <acee@CISCO.COM> Tue, 03 May 2005 12:54 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13007 for <ospf-archive@LISTS.IETF.ORG>; Tue, 3 May 2005 08:54:28 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0103163B@cherry.ease.lsoft.com>; Tue, 3 May 2005 8:54:28 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69107057 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 May 2005 08:54:27 -0400
Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 3 May 2005 08:54:27 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 03 May 2005 09:07:48 -0400
X-IronPort-AV: i="3.92,148,1112587200"; d="scan'208"; a="47182927:sNHT34116648"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j43CsMRS026740 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 3 May 2005 08:54:24 -0400 (EDT)
Received: from xfe-rtp-211.amer.cisco.com ([64.102.31.113]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 08:54:22 -0400
Received: from [10.82.241.73] ([10.82.241.73]) by xfe-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 08:54:22 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <7F17177AC9AC2F4CB4A1A33C936D038D7E2275@nevismail01.pune.nevisnetworks.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 May 2005 12:54:22.0198 (UTC) FILETIME=[3A28C960:01C54FDF]
Message-ID: <4277747D.5040101@cisco.com>
Date: Tue, 03 May 2005 08:54:21 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: DR election
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <7F17177AC9AC2F4CB4A1A33C936D038D7E2275@nevismail01.pune.nevisnetworks.com>
Precedence: list
Content-Transfer-Encoding: 7bit

All,

This has been discussed before on this list and you could search
the archives to get all the gritty details. In summary:

   - The protocol attempts to avoid BDR/DR churn and the BDR/DR election
      gives the current BDR/DR precedence. The reason is obvious - you 
want to
     avoid the network overhead/convergence delay of bringing up
     adjacencies with the new BDR/DR as well as  the 
overhead/convergence delay
     of flooding and recalculating the intra-area route table with a new 
DR's
     network-LSA.
   - While it is not part of the protocol specification, an 
implementation could
      force a BDR/DR election by ignoring the fact that there is a 
BDR/DR and
     asserting themselves as BDR/DR. They would cause a NeighborChange
     event (Section 9.2, RFC 2328) causing RFC 2328 compliant 
implementations
     to perform a BDR/DR election.

Thanks,
Acee

Naresh Paliwal wrote:

>Erblich,
>
>I didn't get your reply, can u please give the references of the idea.
>
>I mean to ask, is it possible to enforce DR/BDR-election without
>changing configuration of existing DR/BDR?
>
>Regards
>-Naresh
>
>
>-----Original Message-----
>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of
>Erblichs
>Sent: Monday, May 02, 2005 10:07 PM
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: Re: DR election
>
>Yes and no,
>
>If a router "really wants to be the DR", the protocol does
>allow this through a back door. The router must act like
>it was already also elected as the DR. This can happen in
>what was a split area. By coming up later, the later router
>SHOULD know the other's priority and router-id. It can then
>boost its broadcasted priority and/or its router-id to gurantee
>re-election.
>
>Mitchell Erblich
>----------------------
>
>
>"Krishnan, Vijay G." wrote:
>  
>
>>The first router does not become the DR immediately. It waits for its
>>configurable "wait timer" to expire, before electing the DR. Others
>>    
>>
>routers
>  
>
>>could come up during this time. Once the DR is elected, addition of
>>    
>>
>new
>  
>
>>routers would not change the DR. This will reduce the instability due
>>    
>>
>to the
>  
>
>>DR changes.
>>
>>regards
>>Vijay
>>
>>-----Original Message-----
>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ilan
>>Bercovich
>>Sent: Monday, May 02, 2005 11:51 AM
>>To: OSPF@PEACH.EASE.LSOFT.COM
>>Subject: DR election
>>
>>Hello
>>If all routers accept the DR regardless of their Router Priority,
>>It means that actually the first active router on the LAN is the DR.
>>Isn't this makes the Router Priority parameter somewhat irrelevant?
>>(In RSTP for instance, when priority is changed - network is
>>re-calculated).
>>Ilan
>>    
>>
>
>  
>