Network Working Group N. Gupta Internet-Draft A. Dogra Intended status: Informational Cisco Systems, Inc. Expires: December 27, 2015 C. Docherty June 25, 2015 Fast failure detection using peer learning in VRRP with BFD draft-nitish-vrrp-bfd-01 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 27, 2015. Copyright Notice Gupta, et al. Expires December 27, 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. Scalability Considerations . . . . . . . . . . . . . . . . . . 11 7. Operational Considerations . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Informative References . . . . . . . . . . . . . . . . . . 16 11.2. Normative References . . . . . . . . . . . . . . . . . . . 16 Appendix A. Using Multipoint BFD sessions . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Gupta, et al. Expires December 27, 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 27, 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 27, 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 27, 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. 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). Gupta, et al. Expires December 27, 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 27, 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 27, 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 27, 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 27, 2015 [Page 10] Internet-Draft VRRP BFD June 2015 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. Gupta, et al. Expires December 27, 2015 [Page 11] Internet-Draft VRRP BFD June 2015 7. 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. 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. Gupta, et al. Expires December 27, 2015 [Page 12] Internet-Draft VRRP BFD June 2015 8. IANA Considerations This draft includes no request to IANA. Gupta, et al. Expires December 27, 2015 [Page 13] Internet-Draft VRRP BFD June 2015 9. 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 27, 2015 [Page 14] Internet-Draft VRRP BFD June 2015 10. Acknowledgements The authors gratefully acknowledge the contributions of Gerry Meyer, 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. Gupta, et al. Expires December 27, 2015 [Page 15] Internet-Draft VRRP BFD June 2015 11. References 11.1. Informative References [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880. 11.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. [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. Gupta, et al. Expires December 27, 2015 [Page 16] Internet-Draft VRRP BFD June 2015 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. Gupta, et al. Expires December 27, 2015 [Page 17] 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 27, 2015 [Page 18]