< draft-nitish-vrrp-bfd-00.txt   draft-nitish-vrrp-bfd-01.txt >
Network Working Group N. Gupta Network Working Group N. Gupta
Internet-Draft A. Dogra Internet-Draft A. Dogra
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: December 14, 2015 C. Docherty Expires: December 27, 2015 C. Docherty
June 12, 2015 June 25, 2015
Fast failure detection using peer learning in VRRP with BFD Fast failure detection using peer learning in VRRP with BFD
draft-nitish-vrrp-bfd-00 draft-nitish-vrrp-bfd-01
Abstract Abstract
This draft presents an enhanced failure detection mechanism to detect This draft presents an enhanced failure detection mechanism to detect
the failure of VRRP Master router on the LAN using a peer learning the failure of VRRP Master router on the LAN using a peer learning
mode. Typically the VRRP protocol is able to perform the transparent 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 detection within a time period of 3 seconds with default
fail-over timers. Real-time protocols (voice/video/real-time fail-over timers. Real-time protocols (voice/video/real-time
transactional) require a maximum network disruption in the order of transactional) require a maximum network disruption in the order of
150ms for traffic on the network. A failure detection and fail-over 150ms for traffic on the network. A failure detection and fail-over
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 14, 2015. This Internet-Draft will expire on December 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Extension to VRRP protocol . . . . . . . . . . . . . . . . . . 6 3. Extension to VRRP protocol . . . . . . . . . . . . . . . . . . 6
3.1. VRRP Peer Table . . . . . . . . . . . . . . . . . . . . . 6 3.1. VRRP Peer Table . . . . . . . . . . . . . . . . . . . . . 6
3.2. VRRP BACKUP ADVERTISEMENT Packet Type . . . . . . . . . . 7 3.2. VRRP BACKUP ADVERTISEMENT Packet Type . . . . . . . . . . 7
4. Sample configuration . . . . . . . . . . . . . . . . . . . . . 8 4. Sample configuration . . . . . . . . . . . . . . . . . . . . . 8
5. Critical BFD session . . . . . . . . . . . . . . . . . . . . . 10 5. Critical BFD session . . . . . . . . . . . . . . . . . . . . . 10
6. Operational Considerations . . . . . . . . . . . . . . . . . . 11 6. Scalability Considerations . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Operational Considerations . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Informative References . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.2. Normative References . . . . . . . . . . . . . . . . . . . 15 11.1. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 11.2. Normative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. Using Multipoint BFD sessions . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Fast failure detection in the network is becoming increasingly Fast failure detection in the network is becoming increasingly
important. VRRP helps in providing redundant Virtual gateways in the important. VRRP helps in providing redundant Virtual gateways in the
LAN, which is typically the first point of failure for end-hosts LAN, which is typically the first point of failure for end-hosts
sending traffic out of the LAN. A faster failure detection of VRRP 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 master becomes very critical as it can isolate all end-hosts that are
unable to detect any alternate path. In VRRP [RFC5798] protocol unable to detect any alternate path. In VRRP [RFC5798] protocol
specification, Backup routers depends on Advert packets generated at specification, Backup routers depends on Advert packets generated at
skipping to change at page 7, line 5 skipping to change at page 6, line 35
and bridging devices refreshed with the destination port for the and bridging devices refreshed with the destination port for the
Virtual Router MAC. Virtual Router MAC.
3.1. VRRP Peer Table 3.1. VRRP Peer Table
VRRP peers can now form the peer table by learning the source address VRRP peers can now form the peer table by learning the source address
in the ADVERTISEMENT or BACKUP ADVERTISEMENT packet sent by VRRP in the ADVERTISEMENT or BACKUP ADVERTISEMENT packet sent by VRRP
Master or Backup peers. This allows all peers to create a mesh of Master or Backup peers. This allows all peers to create a mesh of
BFD sessions with all other operational peers. BFD sessions with all other operational peers.
A peer entry should be removed from the peer table if Advert is not
received from a peer for a period of (3 * the Advert interval).
3.2. VRRP BACKUP ADVERTISEMENT Packet Type 3.2. VRRP BACKUP ADVERTISEMENT Packet Type
The following figure shows the VRRP packet as defined in VRRP The following figure shows the VRRP packet as defined in VRRP
[RFC5798] RFC. [RFC5798] RFC.
0 1 2 3 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 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 | | IPv4 Fields or IPv6 Fields |
... ... ... ...
skipping to change at page 11, line 5 skipping to change at page 11, line 5
Master and the next best VRRP Backup. Failure of the Critical BFD Master and the next best VRRP Backup. Failure of the Critical BFD
session indicates that the Master is no longer available and the most session indicates that the Master is no longer available and the most
preferred Backup will now become Master. preferred Backup will now become Master.
In the above example the Critical BFD session is shared between Rtr1 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 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 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 VRRP Master router for VRID 1 and Rtr3 will become the critical
backup. backup.
6. Operational Considerations 6. Scalability Considerations
When forming mesh of BFD sessions one possible scenario can occur if
the system is not able to scale well with the increased load of
multiple BFD sessions. To mitigate this problem sharing of BFD
sessions with other protocols and opening less number of BFD sessions
should be considered, i.e between Master and the most preferred
Backup router part of the VRRP instance.
To reduce the number of packets generated at a regular interval,
Backup Advert packets may be sent at a reduced rate as compared to
Advert packets sent by the VRRP Master.
7. Operational Considerations
A VRRP [RFC5798] peer that forms a member of this Virtual Router, but A VRRP [RFC5798] peer that forms a member of this Virtual Router, but
does not support this feature or extension must be configured with does not support this feature or extension must be configured with
the lowest priority, and will only operate as the Router of last the lowest priority, and will only operate as the Router of last
resort on failure of all other VRRP routers supporting this resort on failure of all other VRRP routers supporting this
functionality. functionality.
7. IANA Considerations It is recommended that mechanism defined by this draft, to interface
VRRP with BFD should be used when BFD can support more aggressive
monitoring timers than VRRP. Otherwise it is desirable not to
interface VRRP with BFD for determining the health of VRRP Master.
This Draft does not preclude the possibility of the peer table being
populated by means of manual configuration, instead of using the
BACKUP ADVERTISEMENT as defined by the Draft.
8. IANA Considerations
This draft includes no request to IANA. This draft includes no request to IANA.
8. Security Considerations 9. Security Considerations
Security considerations are discussed in the Section 9 of VRRP Security considerations are discussed in the Section 9 of VRRP
protocol [RFC5798] specification. There are no additional security protocol [RFC5798] specification. There are no additional security
considerations identified by this draft. considerations identified by this draft.
9. Acknowledgements 10. Acknowledgements
The authors gratefully acknowledge the contributions of Gerry Meyer, The authors gratefully acknowledge the contributions of Gerry Meyer,
and Mouli Chandramouli, for their contributions to the draft. and Mouli Chandramouli, for their contributions to the draft. The
authors will also like to thank Jeffrey Hass, Maik Pfeil and Vengada
Prasad Govindan for their comments and suggestions.
10. References 11. References
10.1. Informative References 11.1. Informative References
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880. (BFD)", RFC 5880.
10.2. Normative References 11.2. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119. Requirement Levels", RFC 2119.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881. (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881.
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798. Version 3 for IPv4 and IPv6", RFC 5798.
[I-D.draft-ietf-bfd-multipoint]
Katz, D., Ward, D., and S. Pallagatti, "BFD for Multipoint
Networks", Work in Progress draft-ietf-bfd-multipoint-06.
Appendix A. Using Multipoint BFD sessions
Possibility of detecting the failure of VRRP Master using Multipoint
BFD [I-D.draft-ietf-bfd-multipoint] sessions is still under
consideration.
Authors' Addresses Authors' Addresses
Nitish Gupta Nitish Gupta
Cisco Systems, Inc. Cisco Systems, Inc.
Sarjapur Outer Ring Road Sarjapur Outer Ring Road
Bangalore 560103 Bangalore 560103
India India
Phone: +91 80 4429 2530 Phone: +91 80 4429 2530
Email: nitisgup@cisco.com Email: nitisgup@cisco.com
 End of changes. 14 change blocks. 
20 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/