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

Thirumavalavan Periyannan <tperiyannan@extremenetworks.com> Mon, 25 February 2013 16:19 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 D8D1321F9505 for <vrrp@ietfa.amsl.com>; Mon, 25 Feb 2013 08:19:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 D0UpEZtyoW1D for <vrrp@ietfa.amsl.com>; Mon, 25 Feb 2013 08:19:28 -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 28DAA21F9524 for <vrrp@ietf.org>; Mon, 25 Feb 2013 08:19:28 -0800 (PST)
Received: from inch-casht-p1.corp.extremenetworks.com (10.120.89.28) 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 08:19:28 -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 21:49:24 +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 21:49:21 +0530
Thread-Topic: [VRRP] vrrp Digest, Vol 81, Issue 3
Thread-Index: Ac4RBGKo4P5hWc5lTiSJPUEgi0SCSQADvuFgAA80cgAADFd4oP//qQAAgABMd9D//JbYQP/4vEBg//F3tKD/4t/KMA==
Message-ID: <617438426768D648ABBC00E677AA014902697FB19C70@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> <617438426768D648ABBC00E677AA014902697FB19C66@INEXCHANGE.corp.extremenetworks.com> <A2BB90B33FFDF740876C5AAE307D83DB1C293C32@xmb-rcd-x05.cisco.com>
In-Reply-To: <A2BB90B33FFDF740876C5AAE307D83DB1C293C32@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_617438426768D648ABBC00E677AA014902697FB19C70INEXCHANGEc_"; 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 16:19:36 -0000

Yes Anurag, I agree that backup router will reset Master_Down_timer value as Skew_Time and
It will be become master when Master_Down_timer fired and will send VRRP Advertisements with their own priority.

After VRRP Master elected, What could be the VRRP state of priority ZERO configured router? Is it Backup?

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

[cid:image001.jpg@01CE13A0.CD29B200]

From: Anurag Kothari (ankothar) [mailto:ankothar@cisco.com]
Sent: Monday, February 25, 2013 8:44 PM
To: Thirumavalavan Periyannan; vrrp@ietf.org
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

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

[cid:image001.jpg@01CE13A0.CD29B200]


-----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.

________________________________
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.