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 >> >> > > >
- DR election Dror
- Re: DR election Igor Miroshnik
- Re: DR election Russ White
- Re: DR election Zebaida, Dror (Dror)
- Re: DR election Acee Lindem
- Re: DR election Phil Chen
- Re: DR election Zebaida, Dror (Dror)
- Re: DR election Vivek Dubey
- Re: DR election Michael J Barnes
- Re: DR election kamatchi soundaram
- Re: DR election kamatchi soundaram
- DR election Ilan Bercovich
- Re: DR election Krishnan, Vijay G.
- Re: DR election Erblichs
- Re: DR election Naresh Paliwal
- Re: DR election Acee Lindem
- Re: DR election Erblichs
- A writeup on interface state machine (Re: DR elec… Mukul Goyal
- Re: DR election Acee Lindem
- Re: A writeup on interface state machine (Re: DR … Filippo Cugini