Fast failure detection using peer learning in VRRP with BFD
draft-nitish-vrrp-bfd-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Nitish Gupta , Aditya Dogra , Colin Docherty | ||
| Last updated | 2015-06-12 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nitish-vrrp-bfd-00
Network Working Group N. Gupta
Internet-Draft A. Dogra
Intended status: Informational Cisco Systems, Inc.
Expires: December 14, 2015 C. Docherty
June 12, 2015
Fast failure detection using peer learning in VRRP with BFD
draft-nitish-vrrp-bfd-00
Abstract
This draft presents an enhanced failure detection mechanism to detect
the failure of VRRP Master router on the LAN using a peer learning
mode. Typically the VRRP protocol is able to perform the transparent
fail-over detection within a time period of 3 seconds with default
fail-over timers. Real-time protocols (voice/video/real-time
transactional) require a maximum network disruption in the order of
150ms for traffic on the network. A failure detection and fail-over
time of 150ms on conventionally configured VRRP protocol is extremely
aggressive and may impact the reliability and performance of the
network.
A more efficient mechanism for real-time failure detection can be
enabled in VRRP protocol by building a peer table, using a new VRRP
Advert packet type. This will help in forming a mesh of BFD
sessions. Once the BFD sessions are created, VRRP can receive faster
notification of failures, without the overhead of increased VRRP
protocol Advert messages.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 14, 2015.
Copyright Notice
Gupta, et al. Expires December 14, 2015 [Page 1]
Internet-Draft VRRP BFD June 2015
Copyright (c) 2015 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
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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Extension to VRRP protocol . . . . . . . . . . . . . . . . . . 6
3.1. VRRP Peer Table . . . . . . . . . . . . . . . . . . . . . 6
3.2. VRRP BACKUP ADVERTISEMENT Packet Type . . . . . . . . . . 7
4. Sample configuration . . . . . . . . . . . . . . . . . . . . . 8
5. Critical BFD session . . . . . . . . . . . . . . . . . . . . . 10
6. Operational Considerations . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Informative References . . . . . . . . . . . . . . . . . . 15
10.2. Normative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Gupta, et al. Expires December 14, 2015 [Page 2]
Internet-Draft VRRP BFD June 2015
1. Introduction
Fast failure detection in the network is becoming increasingly
important. VRRP helps in providing redundant Virtual gateways in the
LAN, which is typically the first point of failure for end-hosts
sending traffic out of the LAN. A faster failure detection of VRRP
master becomes very critical as it can isolate all end-hosts that are
unable to detect any alternate path. In VRRP [RFC5798] protocol
specification, Backup routers depends on Advert packets generated at
a regular interval by the Master router, to detect the health of the
VRRP Master. Faster failure detection can be achieved within VRRP
protocol by reducing the Advert and hold down timers. But Aggressive
timers can put extra load on the network bandwidth which may not be
desirable.
As the VRRP protocol depends on the availability of L3 IPv4 or IPv6
between redundant peers, VRRP protocol can interact with the L3
variant of BFD as described in [RFC5881], to achieve a much faster
failure detection of the VRRP Master in the LAN. BFD as specified by
the RFC [RFC5880] can provide a much faster failure detection in the
range of 150ms.
BFD IPv4 or IPv6 [RFC5881] requires that for a BFD session to be
formed, both peers participating in a BFD session need to know to its
peer IPv4 or IPV6 address. This poses a unique problem with the
definition of the VRRP [RFC5798] protocol, that makes the operation
with BFD IPv4 or IPv6 [RFC5881] more challenging. As in VRRP it is
only the Master peer that sends Advert packets. This means that a
Master peer is not aware of any Backup peers, and Backup peers are
only aware of the Master peer. This also means that Backup peers are
not aware of other Backups in the Network.
Since BFD IPv4 or IPv6 [RFC5881] requires that a session be formed by
both peers using a full destination and source address, there needs
to be some external means to provide this information to BFD on
behalf of VRRP. Once the peer information is made available, VRRP
can form BFD sessions with each of the peers that exist in the
Virtual Router. The most important BFD session for a given Virtual
Router is identified as the Critical Path BFD Session, which is the
session that forms between the current VRRP Master, and the highest
priority Backup. Should the Critical Path BFD Session be identified
by the VRRP as having changed state from UP to DOWN, then this will
be interpreted by the VRRP state machine on the highest priority
Backup peer as a Master Down event. A Master Down event means that
the highest priority Backup peer will immediately become the new
Master for the Virtual Router.
NOTE: At all times, the normal fail-over mechanism defined in the
Gupta, et al. Expires December 14, 2015 [Page 3]
Internet-Draft VRRP BFD June 2015
VRRP [RFC5798] will be unaffected, and the BFD fail-over mechanism
will always resort to normal VRRP fail-over.
This draft defines the mechanism used by VRRP protocol to Build a
peer table that will help in forming a mesh of BFD sessions and the
detection of Critical Path BFD session. If the Critical Path BFD
session were to go down it will signal a Master down event and make
the most preferred Backup router as the VRRP Master. This requires
an extension to the VRRP protocol.
This can be achieved by defining a new type in the VRRP Advert
packet, and allowing VRRP peers to build a peer table in any of the
operational state, Master or Backup.
Gupta, et al. Expires December 14, 2015 [Page 4]
Internet-Draft VRRP BFD June 2015
2. Requirements Language
In this document, several words are used to signify the requirements
of the specification. 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
RFC 2119. [RFC2119]
Gupta, et al. Expires December 14, 2015 [Page 5]
Internet-Draft VRRP BFD June 2015
3. Extension to VRRP protocol
In this mode of operation VRRP peers learn the adjacent peers, and
form BFD sessions between the learnt peers. In order to build the
peer table, all peers send VRRP Advert packets whilst in any of the
operational states (Master or Backup). Normally VRRP [RFC5798] peers
only send Advert packets whilst in the Master state, however in this
mode VRRP Backup peers will also send Advert packets with the type
field set to BACKUP ADVERTISEMENT type defined in Section 3.2. VRRP
Master peer will still continue to send packets with Advert type as
ADVERTISEMENT as defined in the VRRP [RFC5798] protocol. This is to
maintain inter-operability with peers complying to VRRP [RFC5798]
protocol.
Additionally Advert packets sent from Backup Peers must not use the
Virtual router MAC address as the source address. Instead it must
use the Interface MAC address as the source address from which the
packet is sent from. This is because the source MAC override feature
is used by the Master to send Advert packets from the Virtual Router
MAC address, which is used to keep the bridging cache on LAN switches
and bridging devices refreshed with the destination port for the
Virtual Router MAC.
3.1. VRRP Peer Table
VRRP peers can now form the peer table by learning the source address
in the ADVERTISEMENT or BACKUP ADVERTISEMENT packet sent by VRRP
Master or Backup peers. This allows all peers to create a mesh of
BFD sessions with all other operational peers.
Gupta, et al. Expires December 14, 2015 [Page 6]
Internet-Draft VRRP BFD June 2015
3.2. VRRP BACKUP ADVERTISEMENT Packet Type
The following figure shows the VRRP packet as defined in VRRP
[RFC5798] RFC.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Fields or IPv6 Fields |
... ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|(rsvd) | Max Advert Int | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPvX Address(es) |
+ +
+ +
+ +
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type field specifies the type of this VRRP packet. The type
field can have two values. Type 1 (ADVERTISEMENT) is used by the
VRRP Master Router. Type 2 (BACKUP ADVERTISEMENT) is used by the
VRRP Backup router. This is to distinguish the packets sent by the
VRRP backup Router. Rest of the fields in Advert packet remain the
same.
1 ADVERTISEMENT
2 BACKUP ADVERTISEMENT
A packet with unknown type MUST be discarded.
Gupta, et al. Expires December 14, 2015 [Page 7]
Internet-Draft VRRP BFD June 2015
4. Sample configuration
The following figure shows a simple network with three VRRP routers
implementing one virtual router.
+-----------+ +-----------+ +-----------+
| Rtr1 | | Rtr2 | | Rtr3 |
|(MR VRID=1)| |(BR VRID=1)| |(BR VRID=1)|
| (PR=200) | | (PR=150) | | (PR=100) |
| VRIPVX= A | | VRIPVX= A | | VRIPVX= A |
+-----------+ +-----------+ +-----------+
B C D
| | |
| | |
| | |
---------+--------+--------+---------+--------+---------
Legend:
---+---+---+-- = Ethernet, Token Ring, or FDDI
MR = Master Router
BR = Backup Router
PR = VRRP Router priority
VRID = VRRP Router ID
VRIPVX= IPv4 or IPv6 address protected by
the VRRP Router
B,C,D = Interface IPv4 or IPv6 address of
the Virtual Router
In the above configuration there are three routers on the LAN
protecting an IPv4 or IPv6 address associated to a Virtual Router ID
1. The Rtr1 is the master router as it has the highest priority
compared the Rtr2 and Rtr3. Now if peer learning extension is
enabled on all the peers. Rtr1 will send the Advert packet with type
field set to 1. While Rtr2 and Rtr3 will send the Advert packet with
type field set to 2. In the above configuration the peer table built
at each router is shown below:
Rtr1 Peer table
+------------------------------------+
| Peer Address | Priority |
+------------------------------------+
| C | 150 |
+------------------------------------+
| D | 100 |
+------------------------------------+
Gupta, et al. Expires December 14, 2015 [Page 8]
Internet-Draft VRRP BFD June 2015
Rtr2 Peer table
+------------------------------------+
| Peer Address | Priority |
+------------------------------------+
| B | 200 |
+------------------------------------+
| D | 100 |
+------------------------------------+
Rtr3 Peer table
+------------------------------------+
| Peer Address | Priority |
+------------------------------------+
| B | 200 |
+------------------------------------+
| C | 150 |
+------------------------------------+
Once the peer tables are formed, VRRP on each router can form a mesh
of BFD sessions with all the learnt peers.
Gupta, et al. Expires December 14, 2015 [Page 9]
Internet-Draft VRRP BFD June 2015
5. Critical BFD session
Critical BFD Session is determined to be the session between the VRRP
Master and the next best VRRP Backup. Failure of the Critical BFD
session indicates that the Master is no longer available and the most
preferred Backup will now become Master.
In the above example the Critical BFD session is shared between Rtr1
and Rtr2. If the BFD Session goes from UP to DOWN state, Rtr2 can
treat it as a Master down event and immediately assume the role of
VRRP Master router for VRID 1 and Rtr3 will become the critical
backup.
Gupta, et al. Expires December 14, 2015 [Page 10]
Internet-Draft VRRP BFD June 2015
6. Operational Considerations
A VRRP [RFC5798] peer that forms a member of this Virtual Router, but
does not support this feature or extension must be configured with
the lowest priority, and will only operate as the Router of last
resort on failure of all other VRRP routers supporting this
functionality.
Gupta, et al. Expires December 14, 2015 [Page 11]
Internet-Draft VRRP BFD June 2015
7. IANA Considerations
This draft includes no request to IANA.
Gupta, et al. Expires December 14, 2015 [Page 12]
Internet-Draft VRRP BFD June 2015
8. Security Considerations
Security considerations are discussed in the Section 9 of VRRP
protocol [RFC5798] specification. There are no additional security
considerations identified by this draft.
Gupta, et al. Expires December 14, 2015 [Page 13]
Internet-Draft VRRP BFD June 2015
9. Acknowledgements
The authors gratefully acknowledge the contributions of Gerry Meyer,
and Mouli Chandramouli, for their contributions to the draft.
Gupta, et al. Expires December 14, 2015 [Page 14]
Internet-Draft VRRP BFD June 2015
10. References
10.1. Informative References
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880.
10.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881.
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798.
Gupta, et al. Expires December 14, 2015 [Page 15]
Internet-Draft VRRP BFD June 2015
Authors' Addresses
Nitish Gupta
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
India
Phone: +91 80 4429 2530
Email: nitisgup@cisco.com
URI: http://www.cisco.com/
Aditya Dogra
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
India
Phone: +91 80 4429 2166
Email: addogra@cisco.com
URI: http://www.cisco.com/
Colin Docherty
25 George Grieve Way
Tranent
East Lothian, Scotland EH332QT
United Kingdom
Email: colin@doch.org.uk
Gupta, et al. Expires December 14, 2015 [Page 16]