Internet DRAFT - draft-kothari-vrrp-graceful-failover
draft-kothari-vrrp-graceful-failover
Internet-Draft A. Kothari
Updates: 5798, 6527 (if approved) Cisco Systems
Intended Status: Standards Track August 2, 2013
Expires: February 3, 2014
VRRP Graceful Failover
draft-kothari-vrrp-graceful-failover-00
Abstract
This memo defines the use of priority zero in VRRP to failover from
the Master router to one of the Backup routers either by operator
input (i.e. manual failover) or automatically (e.g. on uplink
interface going down). The procedure tries to be graceful (i.e.
minimize outage) wherever possible. It is especially helpful in cases
where preemption is disabled to avoid unnecessary churn.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Kothari Expires February 3, 2014 [Page 1]
Internet Draft VRRP Graceful Failover August 2, 2013
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Summary of Updates . . . . . . . . . . . . . . . . . . . . 3
2.2. Updates to RFC5798: . . . . . . . . . . . . . . . . . . . 4
2.2.1. Updates to Section 6-4-2 of RFC5798: Backup . . . . . 4
2.2.2. Updates to Section 6-4-3 of RFC5798: Master . . . . . 5
2.3. Updates to RFC6527: . . . . . . . . . . . . . . . . . . . 6
2.3.1. Updates to Section 10 of RFC6527: Definitions . . . . 6
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 Normative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Kothari Expires February 3, 2014 [Page 2]
Internet Draft VRRP Graceful Failover August 2, 2013
1. Introduction
Virtual Router Redundancy Protocol (VRRP) [RFC5798] defines priority
zero for the purpose of indicating that the Master router has stopped
participating in VRRP and the Backup routers should quickly
transition to Master without waiting for the current Master to
timeout. It defines it's use only during the Shutdown event in Master
State.
This memo defines a new "Change event" and also makes priority zero
for VRRP a user configurable value. It defines it use under this new
"Change event" in Master state to initiate a failover to the Backup
router especially when preemption is disabled. It uses a make before
break approach to minimize outage wherever possible.
This document is being discussed on the vrrp@ietf.org mailing list.
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Updates
2.1. Summary of Updates
This memo updates the following RFC sections:
1) Section 6.4.2. of [RFC5798]:
o Update steps 425, and 440 of Backup State.
2) Section 6.4.3. of [RFC5798]:
o Define Change event.
o Update step 680, 695, 705, and 720 of Master State.
3) Section 10. of [RFC6527]:
o Update vrrpv3OperationsPriority OBJECT-TYPE.
o Update vrrpv3FullCompliance MODULE-COMPLIANCE.
Kothari Expires February 3, 2014 [Page 3]
Internet Draft VRRP Graceful Failover August 2, 2013
2.2. Updates to RFC5798:
2.2.1. Updates to Section 6-4-2 of RFC5798: Backup
<snip>
(420) - If an ADVERTISEMENT is received, then:
(425) + If the Priority in the ADVERTISEMENT is zero, and Local
Priority is greater than zero, then:
(430) * Set the Master_Down_Timer to Skew_Time
(440) + else // ADVERTISEMENT priority non-zero or local
priority was zero
<snip>
Kothari Expires February 3, 2014 [Page 4]
Internet Draft VRRP Graceful Failover August 2, 2013
2.2.2. Updates to Section 6-4-3 of RFC5798: Master
A Change event would be triggered by change in any one of the
following parameters of the VRRP Packet:
1) "Priority" Section 5.2.4 of [RFC5798]
2) "Maximum Advertisement Interval (Max Adver Int)" Section 5.2.7
of [RFC5798]
3) "IPvX Address(es)" Section 5.2.9 of [RFC5798]
Handling of the Change event is only applicable in Master state as
VRRP packets are not sent in other states.
<snip>
(680) - If the Adver_Timer fires, or Change event is received,
then:
(685) + Send an ADVERTISEMENT
(690) + Reset the Adver_Timer to Advertisement_Interval
(695) -endif // advertisement timer fired or Change event received
(700) - If an ADVERTISEMENT is received, then:
(705) -+ If the Priority in the ADVERTISEMENT is zero, and
Local Priority is greater than zero, then:
(710) -* Send an ADVERTISEMENT
(715) -* Reset the Adver_Timer to Advertisement_Interval
(720) -+ else // ADVERTISEMENT priority non-zero or local
priority was zero
<snip>
Kothari Expires February 3, 2014 [Page 5]
Internet Draft VRRP Graceful Failover August 2, 2013
2.3. Updates to RFC6527:
2.3.1. Updates to Section 10 of RFC6527: Definitions
-- VRRPv3 Operations Table
<snip>
vrrpv3OperationsPriority OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies the priority to be used for the
virtual router master election process; higher values
imply higher priority.
A priority of '0', is sent by the master router to
indicate that it wants to release the Master
responsibility, and a backup virtual router should
transition to become a new master.
A priority of 255 is used for the router that owns the
associated IP address(es) for VRRP over IPv4 and hence
is not setable.
Setting the values of this object to 255 should be
rejected by the agents implementing this MIB module.
For example, an SNMP agent would return 'badValue(3)'
when a user tries to set the values 255 for this
object."
REFERENCE "RFC 5798, Section 6.1"
DEFVAL { 100 }
::= { vrrpv3OperationsEntry 7 }
<snip>
Kothari Expires February 3, 2014 [Page 6]
Internet Draft VRRP Graceful Failover August 2, 2013
-- Compliance Statements
vrrpv3FullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement"
MODULE -- this module
MANDATORY-GROUPS {
vrrpv3OperationsGroup,
vrrpv3StatisticsGroup,
vrrpv3InfoGroup,
vrrpv3NotificationsGroup
}
OBJECT vrrpv3OperationsPriority
WRITE-SYNTAX Unsigned32 (0..254)
DESCRIPTION "Setable values are from 0 to 254."
::= { vrrpv3Compliances 1 }
<snip>
Kothari Expires February 3, 2014 [Page 7]
Internet Draft VRRP Graceful Failover August 2, 2013
3. Acknowledgements
The Author would like to thank Peter Hunt (one of the original
authors of VRRP) for his inputs and review.
4. Security Considerations
No new Security Considerations are introduced by this memo. The
Security Considerations from [RFC5798] and [RFC6527] are still
applicable.
5. IANA Considerations
No new IANA Considerations are introduced by this memo. The IANA
Considerations from [RFC5798] and [RFC6527] are still applicable.
6. References
6.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol
(VRRP) Version 3 for IPv4 and IPv6", RFC 5798,
March 2010.
[RFC6527] Tata, K., "Definitions of Managed Objects for
Virtual Router Redundancy Protocol Version 3
(VRRPv3)", RFC 6527, March 2012.
Author's Address
Anurag Kothari
Cisco Systems
7200 Kit Creek Road
RTP, NC 27709
USA
EMail: ankothar@cisco.com
Kothari Expires February 3, 2014 [Page 8]
