Re: Exit-Graceful Restart Condition
Acee Lindem <acee@CISCO.COM> Tue, 31 May 2005 22:29 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 SAA06031 for <ospf-archive@LISTS.IETF.ORG>; Tue, 31 May 2005 18:29:53 -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 <13.01069FF9@cherry.ease.lsoft.com>; Tue, 31 May 2005 18:29:51 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 73560668 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 May 2005 18:29:49 -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 31 May 2005 18:28:48 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 31 May 2005 18:28:49 -0400
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 j4VMSll6000486 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 31 May 2005 18:28:47 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 18:28:46 -0400
Received: from [10.82.242.48] ([10.82.242.48]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 18:28:46 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000801c564cd$ffb0d760$ca04120a@china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 May 2005 22:28:46.0808 (UTC) FILETIME=[1C3BED80:01C56630]
Message-ID: <429CE51E.8010909@cisco.com>
Date: Tue, 31 May 2005 18:28:46 -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: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <000801c564cd$ffb0d760$ca04120a@china.huawei.com>
Precedence: list
Content-Transfer-Encoding: 7bit
sujay wrote: >Hi Padma, > >Guess we *must* run the dead interval timer on a per neighbor basis, > > Hi Sujay, IMHO, this is the norm rather than the exception. >else > for the maximum configured dead interval amongst all possible >neighbours. >It could be of course implementation specific. > >Solves more than the one issue mentioned in this thread ! > >Regds, >Sujay > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma >Pillay-Esnault >Sent: Friday, May 27, 2005 8:40 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Exit-Graceful Restart Condition > > >Kishore Rao wrote: > > > >>----- Original Message ----- >>From: "Padma Pillay-Esnault" <ppe@cisco.com> >>To: <OSPF@peach.ease.lsoft.com> >>Sent: Wednesday, May 25, 2005 11:54 AM >>Subject: Re: Exit-Graceful Restart Condition >> >> >> >> >> >> >>>Kishore Rao wrote: >>> >>> >>> >>> >>> >>>>----- Original Message ----- >>>>From: "Acee Lindem" <acee@cisco.com> >>>>To: <OSPF@peach.ease.lsoft.com> >>>>Sent: Wednesday, May 25, 2005 10:10 AM >>>>Subject: Re: Exit-Graceful Restart Condition >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Padma Pillay-Esnault wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>sujay wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi All, >>>>>>> >>>>>>>Considering RFC3623, Graceful Restart for OSPF V2 I have a >>>>>>>problem; >>>>>>> >>>>>>>Ex: >>>>>>> >>>>>>>(network)---- DUT ---- RTA >>>>>>> >>>>>>>(All in the same area) >>>>>>> >>>>>>>Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's >>>>>>>to RTA and other routers in the 'network' >>>>>>> >>>>>>>At the instant RTA recvs the Grace-LSA it also goes down. >>>>>>> >>>>>>>Is there a way in the RFC 3623 specified as to how DUT could >>>>>>>Detect this topology change and Exit GR *before* grace period >>>>>>>expiry?? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>I do not think the RFC covers this case. You are in a double >>>>>>failure situation. >>>>>> >>>>>>I can think of a simple solution. When DUT reacquires its >>>>>>router-lsa. It can determine its previous neighbors. It can then >>>>>>decide that if within DeadRouterInterval that neighbor did not >>>>>>respond to hellos to abort GR. This would be equivalent to the >>>>>>normal situation when a router goes down and its >>>>>>neigbors takes DeadInterval to bring down their adjacency >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I agree completely with Padma. One point, if RTA comes back up and >>>>>originates a new router LSA then the DUT will detect the >>>>>inconsistency (as specified in RFC 3623) with it's pre-restart LSA >>>>>and terminate graceful restart. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Acee, >>>> >>>>Will this work ? >>>>In case there is another router RTB, scan the Hello from RTB for all >>>>neighbors on the network and then make sure Hello from RTA has been >>>> >>>> >>>> >>>> >>received >> >> >> >> >>>>within a Hello interval + 2 (say) . If not, exit GR. >>>> >>>> >>>> >>>> >>>> >>>> >>>It is not clear to me. Do you mean that RTB has the same neighbors as >>>DUT and is on the same network link ? >>> >>> >>> >>> >>Yes. >> >> >> >> > >This is not a solution that you can rely one. For one - you can only use > >it on a BCAST interface where there are >2+ neighbors possible. It will not work for p2p for example. > >I prefer a generic solution. > >Padma > > > >> >> >> >> >>>Padma >>> >>> >>> >>> >>> >>>>This would be faster than using the reacquired Router and Network >>>>LSAs to determine the neighbors, isnt it ? >>>> >>>>Kishore >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Padma. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>For other routers in the network RTA is still reachable and >>>>>>>traffic Will be eventually dropped. >>>>>>> >>>>>>>Kindly correct me, >>>>>>> >>>>>>>Regds, >>>>>>>Ashok/Sujay >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> >>>> >>>> >>>> >> >> >> >> > > >
- Waiting State Question John Smith
- Re: Waiting State Question Anthony Baire
- Re: Waiting State Question Kishore Rao
- Re: Waiting State Question Mukul Goyal
- Re: Waiting State Question Erblichs
- Re: Waiting State Question Kishore Rao
- Re: Waiting State Question Mukul Goyal
- Re: Waiting State Question Kishore Rao
- Re: Waiting State Question Mukul Goyal
- Re: Waiting State Question Kishore Rao
- Re: Waiting State Question Erblichs
- Re: Waiting State Question Kishore Rao
- Re: Waiting State Question John Smith
- Re: Waiting State Question Erblichs
- Re: Waiting State Question Erblichs
- Re: Waiting State Question Mukul Goyal
- Re: Waiting State Question Kishore Rao
- Re: Waiting State Question Erblichs
- Exit-Graceful Restart Condition sujay
- Re: Exit-Graceful Restart Condition Padma Pillay-Esnault
- Re: Exit-Graceful Restart Condition Acee Lindem
- Re: Exit-Graceful Restart Condition Kishore Rao
- Re: Exit-Graceful Restart Condition Padma Pillay-Esnault
- Re: Exit-Graceful Restart Condition ashok holla
- Re: Exit-Graceful Restart Condition Padma Pillay-Esnault
- Re: Exit-Graceful Restart Condition Kishore Rao
- Re: Exit-Graceful Restart Condition Kishore Rao
- Re: Exit-Graceful Restart Condition Padma Pillay-Esnault
- Re: Exit-Graceful Restart Condition sujay
- Re: Exit-Graceful Restart Condition Acee Lindem
- Re: Exit-Graceful Restart Condition Padma Pillay-Esnault