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

Thirumavalavan Periyannan <tperiyannan@extremenetworks.com> Mon, 25 February 2013 15:07 UTC

Return-Path: <tperiyannan@extremenetworks.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 91E1721F9352 for <vrrp@ietfa.amsl.com>; Mon, 25 Feb 2013 07:07:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.932
X-Spam-Level:
X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001]
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 EMTwr55hTcWO for <vrrp@ietfa.amsl.com>; Mon, 25 Feb 2013 07:07:43 -0800 (PST)
Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id D7FCB21F9325 for <vrrp@ietf.org>; Mon, 25 Feb 2013 07:07:43 -0800 (PST)
Received: from USSC-CASHT-P3.corp.extremenetworks.com (10.0.4.78) by ussc-casht-p2.corp.extremenetworks.com (10.255.181.88) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 25 Feb 2013 07:07:43 -0800
Received: from inch-casht-p1.corp.extremenetworks.com (10.120.89.28) by ussc-casht-p3.corp.extremenetworks.com (10.0.4.78) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 25 Feb 2013 07:07:42 -0800
Received: from INEXCHANGE.corp.extremenetworks.com ([192.168.131.111]) by inch-casht-p1.corp.extremenetworks.com ([10.120.89.28]) with mapi; Mon, 25 Feb 2013 20:37:38 +0530
From: Thirumavalavan Periyannan <tperiyannan@extremenetworks.com>
To: "Anurag Kothari (ankothar)" <ankothar@cisco.com>, "vrrp@ietf.org" <vrrp@ietf.org>
Date: Mon, 25 Feb 2013 20:37:37 +0530
Thread-Topic: [VRRP] vrrp Digest, Vol 81, Issue 3
Thread-Index: Ac4RBGKo4P5hWc5lTiSJPUEgi0SCSQADvuFgAA80cgAADFd4oP//qQAAgABMd9D//JbYQP/4vEBg
Message-ID: <617438426768D648ABBC00E677AA014902697FB19C66@INEXCHANGE.corp.extremenetworks.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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_004_617438426768D648ABBC00E677AA014902697FB19C66INEXCHANGEc_"; 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:07:45 -0000


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

[cid:image001.jpg@01CE1397.F2FD5080]


-----Original Message-----
From: Anurag Kothari (ankothar) [mailto:ankothar@cisco.com]
Sent: Saturday, February 23, 2013 12:57 AM
To: Thirumavalavan Periyannan; 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.