RE: [OSPF] OSPF GR query
"Khan Amir-G20247" <amirkhan@motorola.com> Thu, 05 October 2006 14:58 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUg1-0007iR-QQ; Thu, 05 Oct 2006 10:58:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUg0-0007c0-N2 for ospf@ietf.org; Thu, 05 Oct 2006 10:58:20 -0400
Received: from mail125.messagelabs.com ([85.158.136.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVUdU-0003nW-9F for ospf@ietf.org; Thu, 05 Oct 2006 10:55:45 -0400
X-VirusChecked: Checked
X-Env-Sender: amirkhan@motorola.com
X-Msg-Ref: server-8.tower-125.messagelabs.com!1160060140!16662174!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 13393 invoked from network); 5 Oct 2006 14:55:40 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-125.messagelabs.com with SMTP; 5 Oct 2006 14:55:40 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k95EtdHb001638 for <ospf@ietf.org>; Thu, 5 Oct 2006 07:55:39 -0700 (MST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k95Etc0m014469 for <ospf@ietf.org>; Thu, 5 Oct 2006 09:55:39 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [OSPF] OSPF GR query
Date: Thu, 05 Oct 2006 22:55:23 +0800
Message-ID: <988EE2C769AC284ABAE9328BFC10703F011AAD88@ZMY16EXM66.ds.mot.com>
In-Reply-To: <452516EC.5070000@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OSPF] OSPF GR query
Thread-Index: AcboisdOAMkiNdx7S8+RjPh/zxYBIwAAkSiQ
From: Khan Amir-G20247 <amirkhan@motorola.com>
To: Acee Lindem <acee@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org
Hi Ace But reaching to a FULL state is not one of the conditions for Helper to quit Helper mode, I guess a Helper who has reached to FULL state with its restarting router will wait for Grace LSAs to be flushed or GR timeout to happen for exiting Helper mode. Regards Aamir -----Original Message----- From: Acee Lindem [mailto:acee@cisco.com] Sent: Thursday, October 05, 2006 8:00 PM To: Khan Amir-G20247 Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF GR query Hello Amir, Khan Amir-G20247 wrote: > > > Hi > > I have query related to OSPF Graceful Restart. > > Consider this scenario: > > > > - Three Routers R1, R2 and R3 connected via Broadcast networks. > > > > > > > > - Where R1 is a DR on both the segments, where as R2 and R3 are in > DR-other > - Now R1 wants to perform GR, R2 and R3 agrees to be its Helpers. > - Now after restart R1 will try to form adjacency with both R2 and R3. > - Lets say R1 and R2 had become FULL, while R1 and R3 had reached > Exstart state. Now at this time R2 receives an LSA (any type 1-5 and > 7, from some other router existing in the same area, not pictured > here) which he needs to flood to R1. > - This will force R2 to quit Helper Status, while R1 and R3 are still > in process of forming adjacency. > Since he has reached FULL state, he is no longer a helper router. > > > Considering above scenario, my doubts are: > > - How will R1 come to know that its Helper R2 has quit? > Since he has reached FULL state, he is no longer a helper router. > - Will the adjacency between R1 and R2 needs to go down, as R2 quits > helper mode? > No > - Will this effect the adjacency formation of R1 and R3? > No. R3 MAY exit helper status and re-originate a new router LSA if he receives the new LSA before reaching FULL state with R1 AND he is has strict-LSA-checking configured. Hope this helps, Acee > > > Regards > Aamir > > > > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf
- [OSPF] OSPF GR query Khan Amir-G20247
- RE: [OSPF] OSPF GR query Don Goodspeed
- Re: [OSPF] OSPF GR query Acee Lindem
- [OSPF] OSPF GR query Khan Amir-G20247
- Re: [OSPF] OSPF GR query Acee Lindem
- RE: [OSPF] OSPF GR query Khan Amir-G20247
- Re: [OSPF] OSPF GR query Acee Lindem
- Re: [OSPF] OSPF GR query sujay gupta
- [OSPF] OSPF GR query Khan Amir-G20247
- Re: [OSPF] OSPF GR query Abhay D.S
- Re: [OSPF] OSPF GR query sujay gupta
- Re: [OSPF] OSPF GR query Vivek Dubey
- Re: [OSPF] OSPF GR query Abhay D.S
- Re: [OSPF] OSPF GR query Vivek Dubey
- Re: [OSPF] OSPF GR query Acee Lindem
- Re: [OSPF] OSPF GR query Abhay D.S
- Re: [OSPF] OSPF GR query sujay gupta
- Re: [OSPF] OSPF GR query Acee Lindem