Re: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other.
Bharath R <rbharath@juniper.net> Tue, 18 June 2013 15:58 UTC
Return-Path: <rbharath@juniper.net>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF8C21F9B6A for <ospf@ietfa.amsl.com>; Tue, 18 Jun 2013 08:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.302
X-Spam-Level:
X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=0.965, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nboB36IYEH01 for <ospf@ietfa.amsl.com>; Tue, 18 Jun 2013 08:58:39 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6665F21E8054 for <OSPF@ietf.org>; Tue, 18 Jun 2013 08:58:39 -0700 (PDT)
Received: from mail35-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE026.bigfish.com (10.236.130.89) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Jun 2013 15:58:38 +0000
Received: from mail35-co9 (localhost [127.0.0.1]) by mail35-co9-R.bigfish.com (Postfix) with ESMTP id 5F7B54E02C4 for <OSPF@ietf.org>; Tue, 18 Jun 2013 15:58:38 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -24
X-BigFish: VPS-24(zz98dI9371Ic85fh4015I179cIzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hz8dhz8275ch1033IL17326ah18c673h1c8fb4h8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail35-co9: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=rbharath@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ;
X-Forefront-Antispam-Report-Untrusted: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail35-co9 (localhost.localdomain [127.0.0.1]) by mail35-co9 (MessageSwitch) id 1371571116110980_18860; Tue, 18 Jun 2013 15:58:36 +0000 (UTC)
Received: from CO9EHSMHS002.bigfish.com (unknown [10.236.132.240]) by mail35-co9.bigfish.com (Postfix) with ESMTP id 1831D320073 for <OSPF@ietf.org>; Tue, 18 Jun 2013 15:58:36 +0000 (UTC)
Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.54) by CO9EHSMHS002.bigfish.com (10.236.130.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Jun 2013 15:58:35 +0000
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 18 Jun 2013 08:58:34 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 18 Jun 2013 08:58:34 -0700
Received: from DB8EHSOBE024.bigfish.com (213.199.154.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 18 Jun 2013 09:02:06 -0700
Received: from mail125-db8-R.bigfish.com (10.174.8.228) by DB8EHSOBE024.bigfish.com (10.174.4.87) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Jun 2013 15:58:31 +0000
Received: from mail125-db8 (localhost [127.0.0.1]) by mail125-db8-R.bigfish.com (Postfix) with ESMTP id 054213402DA for <OSPF@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Tue, 18 Jun 2013 15:58:31 +0000 (UTC)
Received: from mail125-db8 (localhost.localdomain [127.0.0.1]) by mail125-db8 (MessageSwitch) id 1371571108508737_15188; Tue, 18 Jun 2013 15:58:28 +0000 (UTC)
Received: from DB8EHSMHS023.bigfish.com (unknown [10.174.8.236]) by mail125-db8.bigfish.com (Postfix) with ESMTP id 71407160049; Tue, 18 Jun 2013 15:58:28 +0000 (UTC)
Received: from BN1PRD0512HT003.namprd05.prod.outlook.com (132.245.2.21) by DB8EHSMHS023.bigfish.com (10.174.4.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Jun 2013 15:58:27 +0000
Received: from BN1PRD0512MB620.namprd05.prod.outlook.com ([169.254.16.70]) by BN1PRD0512HT003.namprd05.prod.outlook.com ([10.255.193.36]) with mapi id 14.16.0324.000; Tue, 18 Jun 2013 15:58:16 +0000
From: Bharath R <rbharath@juniper.net>
To: Tanmoy Kundu <tanmoycs@gmail.com>
Thread-Topic: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other.
Thread-Index: AQHObC0C41RYLKFrTEaZ1XtgO25hy5k7l4bg
Date: Tue, 18 Jun 2013 15:58:17 +0000
Message-ID: <B39429F1A3EA1A4A9110CEC3D99263EA14C81239@BN1PRD0512MB620.namprd05.prod.outlook.com>
References: <B39429F1A3EA1A4A9110CEC3D99263EA14C81146@BN1PRD0512MB620.namprd05.prod.outlook.com> <CAOyRfUwbxrA=Og9kfNwiQdqVBJ9+pUT4v6L_hOR=M26_EFnQHg@mail.gmail.com>
In-Reply-To: <CAOyRfUwbxrA=Og9kfNwiQdqVBJ9+pUT4v6L_hOR=M26_EFnQHg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [116.197.178.83]
Content-Type: multipart/alternative; boundary="_000_B39429F1A3EA1A4A9110CEC3D99263EA14C81239BN1PRD0512MB620_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-OriginatorOrg: juniper.net
Cc: "OSPF@ietf.org" <OSPF@ietf.org>, Dileep Singh <dsachan@juniper.net>
Subject: Re: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other.
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 15:58:45 -0000
Hi Tanmoy, Thank you for your quick response. Let me give a few clarifications: Under the below mentioned scenario, we would definitely expect a network convergence delay. But, here, the question is regarding the adjacency flap between DR-Other and BDR on DR interface down. If adjacency is anyway going to flap between DR -Other and BDR under some scenarios(It is definitely possible that in a network some routers detect events faster than the others), then is there a significant advantage that we derive from having a BDR? Regarding NeighborChange Event: Sorry If I was not clear, I totally agree that NeighborChange Event should be triggered after DR fail is detected. But, the question really is should the neighbor Change event be triggered when R2(new DR ) sent a new Hello. Please note that NeighborChange event I am referring to is in response to the Hello as received from the Neighbor and not a result of our DR calculation. So, If a Neighbor was previously declaring itself a BDR and is now declaring itself a DR(to both of which we are expected to be adjacent), should the NeighborChange event still be triggered? And I don't think having DR-priority non-zero in DR-Others would have made any difference to the above scenario. R2 instead of declaring BDR NULL would have declared some other router as BDR(considering a more generic LAN case), and DR other would have still flapped the adjacency with the new DR(R2) since R2 was BDR before and is no longer BDR. I am not claiming that the behavior noticed is incorrect. I am actually trying to understand the below lines of the RFC: o One of the bidirectional neighbors is newly declaring itself as either Designated Router or Backup Designated Router. This is detected through examination of that neighbor's Hello Packets. o One of the bidirectional neighbors is no longer declaring itself as Designated Router, or is no longer declaring itself as Backup Designated Router. This is again detected through examination of that neighbor's Hello Packets. Whether these two bullets are mentioning transition from {DR to (BDR or DR-Other)}, and {BDR to (DR or DR-other)} Or does it just mean a transition from Non-DR-Other to DR-Other and DR-Other to Non-DR-Other. Where Non-DR-Other means (DR and BDR). Also, given that some DR-Others may detect Neighbor Down later than BDR, is adjacency flap with BDR expected(though there was no problem in link to BDR). Thanks and Regards, Bharath R. From: Tanmoy Kundu [mailto:tanmoycs@gmail.com] Sent: Tuesday, June 18, 2013 7:30 PM To: Bharath R Cc: OSPF@ietf.org; Dileep Singh Subject: Re: [OSPF] Query regarding behavior of OSPF DR-Other's neighbor-State with BDR when DR fails, when DR down detection is delayed at DR-Other. Hi Bharath, Few queries. As you mentioned "R2(The current BDR) detects the DR-down.", how did R2 sensed that R1 is down ? a. first possible option is dead timer expiry in R2. In that case R3 should also get the expiry soon and till that time the network won't converge. isn't that expected? b. Another option is having BFD session between R1 and R2, hence it comes to know. Why don't we run BFD between all the routers in the network ? As we know in OSPF the DR and BDR is not guaranteed. This typical scenario is due to the DR-other is with priority zero. But when received hello packet from DR, both BDR and DR-Other should reset the dead timer. Even if we consider the link transmission delay and ASIC processing, the dead timer expiry difference between R2 and R3 should not be more than milisecond, isn't it ? * Is it right to trigger the NeighborChange event at R3? - I feel yes, other than few typical scenarios the network will at least not be used, until its converged. If Nbr-chg event is not sent then all DR other feels that DR is still active and the same will be used for forwarding the traffic. If someone in the network sensed that DR/BDR is down, why don't tell others immediately? * Is this transition from FULL to 2-WAY is expected? - As per RFC, DR others should not be FULL with other routers than DR and BDR, hence YES. It is expected. * Can DR-Others flap adjacency with BDR if DR down detection happens later than reception of new Hello from the new DR? - * Intuitively, it may seem desirable to continue to be adjacent to a neighbor as long as it is still DR or BDR. Is this a fair call? - As mentioned above, its not fair to use a disturbed or unsettled network for forwarding. Due to backlink check failure the LAN wont be used for forwarding during SPF. Hence as per me its proper behavior. Thanks, Tanmoy On Tue, Jun 18, 2013 at 5:26 PM, Bharath R <rbharath@juniper.net<mailto:rbharath@juniper.net>> wrote: Hi, Please consider the scenario: R1(DR) R2(BDR) | I1 I2 | | | |______________________ | | | I3 | R3(DR-Other) Here: R1 is the DR. R2 is the BDR R3 is DR-Other, with DR-priority 0 and hence ineligible to become DR/BDR. Following are the is the set of operations and a sequence of events: 1. Interface I1 is disabled. So, DR connectivity is lost to the rest of the network. 2. R2(The current BDR) detects the DR-down. a. Declares itself the DR. b. Declares BDR as NULL. c. Sends out a Hello with DR as I2 interface address, and BDR as 0.0.0.0 3. R3(DR-Other) receives Hello from R2. As per, section 9.2 of RFC 2328: o One of the bidirectional neighbors is newly declaring itself as either Designated Router or Backup Designated Router. This is detected through examination of that neighbor's Hello Packets. o One of the bidirectional neighbors is no longer declaring itself as Designated Router, or is no longer declaring itself as Backup Designated Router. This is again detected through examination of that neighbor's Hello Packets. Triggers a NeighborChange event, which in-turn results in a DR election at R3. Please note that at this time R3 has not yet detected R1 down. Now result of DR-election at R3: DR: R1 BDR: 0.0.0.0 Since R2 is no longer the BDR, R3 transitions from FULL to 2-WAY with R2(the new DR). Of course, on detection of DR down at R3, R3 will elect R2 as DR and then again transition to ExStart, to Exchange to Full with R2. Can you please let me know: * Is it right to trigger the NeighborChange event at R3 ? * Is this transition from FULL to 2-WAY is expected? * Can DR-Others flap adjacency with BDR if DR down detection happens later than reception of new Hello from the new DR? * Intuitively, it may seem desirable to continue to be adjacent to a neighbor as long as it is still DR or BDR. Is this a fair call? Please correct me if I have missed out something. Thanks and Regards, Bharath R. _______________________________________________ OSPF mailing list OSPF@ietf.org<mailto:OSPF@ietf.org> https://www.ietf.org/mailman/listinfo/ospf
- [OSPF] Query regarding behavior of OSPF DR-Other'… Bharath R
- Re: [OSPF] Query regarding behavior of OSPF DR-Ot… Tanmoy Kundu
- Re: [OSPF] Query regarding behavior of OSPF DR-Ot… Bharath R
- Re: [OSPF] Query regarding behavior of OSPF DR-Ot… Acee Lindem
- Re: [OSPF] Query regarding behavior of OSPF DR-Ot… Acee Lindem
- Re: [OSPF] Query regarding behavior of OSPF DR-Ot… Bharath R
- Re: [OSPF] Query regarding behavior of OSPF DR-Ot… Acee Lindem
- Re: [OSPF] Query regarding behavior of OSPF DR-Ot… Bharath R