Re: [VRRP] vrrp Digest, Vol 81, Issue 3

"Anurag Kothari (ankothar)" <ankothar@cisco.com> Mon, 25 February 2013 15:13 UTC

Return-Path: <ankothar@cisco.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B093621F84B6 for <vrrp@ietfa.amsl.com>; Mon, 25 Feb 2013 07:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.098
X-Spam-Level:
X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUHPheRhPnIW for <vrrp@ietfa.amsl.com>; Mon, 25 Feb 2013 07:13:42 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 11F9221F9445 for <vrrp@ietf.org>; Mon, 25 Feb 2013 07:13:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20864; q=dns/txt; s=iport; t=1361805222; x=1363014822; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ddKc8D0kJssjiFCrRWL83xaq8PBM8O4Xqmrp0jxXJhk=; b=DAiZI7cAE+FGLihJKrmEEjkhFr6Dg2Fl12UjYh22W+eCysHo4xo79HHH 9UOWkqAs5SHDk+uv1c0moPPfymaiEryhsImYxhgpiK3T9YSxW5jRo57xX dhSyAUAUjNOrB5QAiNOJnbPFLH/HgpyvSqNYPqn8aEzAxk7BBpIDiyogL Y=;
X-Files: image001.jpg : 3541
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFALJ+K1GtJXG9/2dsb2JhbABFgkO/EYEFFnOCHwEBAQQFIAgBVwQCAQgOAwICAQEGAQEBAggVBwIFEAEMAgwUCQgCBAERAQYCAQWIBQy+L400GYEQCA4QEQEGgllhA5BJAVKIbI0agweBcjU
X-IronPort-AV: E=Sophos; i="4.84,735,1355097600"; d="jpg'145?scan'145,208,217,145"; a="180825544"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 25 Feb 2013 15:13:41 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1PFDfw4027871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 15:13:41 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.93]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 09:13:41 -0600
From: "Anurag Kothari (ankothar)" <ankothar@cisco.com>
To: Thirumavalavan Periyannan <tperiyannan@extremenetworks.com>, "vrrp@ietf.org" <vrrp@ietf.org>
Thread-Topic: [VRRP] vrrp Digest, Vol 81, Issue 3
Thread-Index: Ac4RBGKo4P5hWc5lTiSJPUEgi0SCSQADvuFgAA80cgAADFd4oP//qQAAgABMd9D//JbYQP/4vEBg//F3tKA=
Date: Mon, 25 Feb 2013 15:13:40 +0000
Message-ID: <A2BB90B33FFDF740876C5AAE307D83DB1C293C32@xmb-rcd-x05.cisco.com>
References: <mailman.7259.1361533310.3383.vrrp@ietf.org> <14CA6619-DB7C-40ED-85E4-535CB689AC86@extremenetworks.com> <A2BB90B33FFDF740876C5AAE307D83DB1C292B8C@xmb-rcd-x05.cisco.com> <F547EC1D-C8F0-4468-AFB9-CC1115833704@gmail.com> <A2BB90B33FFDF740876C5AAE307D83DB1C292D70@xmb-rcd-x05.cisco.com> <91BD27DC-D555-49C7-8B40-F74F4D8B596F@extremenetworks.com> <A2BB90B33FFDF740876C5AAE307D83DB1C292E5E@xmb-rcd-x05.cisco.com> <617438426768D648ABBC00E677AA014902697FB19C66@INEXCHANGE.corp.extremenetworks.com>
In-Reply-To: <617438426768D648ABBC00E677AA014902697FB19C66@INEXCHANGE.corp.extremenetworks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.82.240.69]
Content-Type: multipart/related; boundary="_004_A2BB90B33FFDF740876C5AAE307D83DB1C293C32xmbrcdx05ciscoc_"; type="multipart/alternative"
MIME-Version: 1.0
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Feb 2013 15:13:44 -0000

Hi Thirumavalavan

The Master_Down_Timer is set to Skew_Time by the backup router on receiving an ADVERTISEMENT with Priority = 0. That is why I said will have to wait Skew_Time in the thread below. I am copy pasting the relevant section from the RFC for easy reference:

(420) - If an ADVERTISEMENT is received, then:

   (425) + If the Priority in the ADVERTISEMENT is zero, then:

      (430) * Set the Master_Down_Timer to Skew_Time

   (440) + else // priority non-zero

Yes the Priority on the Master router will have to be set to zero to initiate a graceful failover.

Thanks
-Anurag

From: Thirumavalavan Periyannan [mailto:tperiyannan@extremenetworks.com]
Sent: Monday, February 25, 2013 10:08 AM
To: Anurag Kothari (ankothar); vrrp@ietf.org
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3



Hi Anurag,



Sorry for the late response.



See the inline [Thiru]



Here, I have a question,



1.Do We have to configure priority Zero on Master router to do graceful failover?

Thanks & Regards,
Thirumavalavan Periyannan
Associate SQA Engineer  - VRRP Module Owner

[Description: Description: Description: Description: Description: Description: Description: Description: cid:image001.png@01CBF547.656FF3F0]


-----Original Message-----
From: Anurag Kothari (ankothar) [mailto:ankothar@cisco.com]
Sent: Saturday, February 23, 2013 12:57 AM
To: Thirumavalavan Periyannan; vrrp@ietf.org<mailto:vrrp@ietf.org>
Cc: Peter Hunt
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3



Hi Thirumavalavan



Here are couple of points:



1) With something like "disable vrrp" or "shutdown vrrp" it will not be graceful as the router will treat it as a shutdown event (which is a break before you make approach) and the router will "Transition to the {Initialize} state". The backup router will wait for "Skew_Time"[Thiru]I think, it's Master_Down_interval time. before it becomes master; So we probably will have traffic loss for a period approximately equal to "Skew_Time"[Thiru]I think, it's Master_Down_interval time. Even with Default configuration this will be close to 609 ms which would be a duration long enough for to impact time sensitive applications (e.g. voice calls). For sure the actual failover time will depend upon the size of the Network and the switches in between but with the method proposed below we can try to improve that time.



2) This will also improve convergence in scenarios where we want the failover to trigger because of up uplink interface from the router going down (tracking interface and decrementing the priority).



I am not sure if you saw the modified proposal which was sent out today early morning. Here is the link to it in case you need it http://www.ietf.org/mail-archive/web/vrrp/current/msg01489.html



Thanks

~Anurag





________________________________
DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.