Fast failure detection in VRRP with Point to Point BFD

Introduction The Virtual Router Redundancy Protocol (VRRP) provides redundant Virtual gateways in the Local Area Network (LAN), which is typically the first point of failure for end-hosts sending traffic out of the LAN. Fast failure detection of VRRP Active is critical in supporting high availability of services and improved Quality of Experience to users. In VRRP specification, Backup routers depend on VRRP packets generated at a regular interval by the Active router, to detect the health of the VRRP Active. Faster failure detection can be achieved within VRRP protocol by reducing the Advertisement and Active Down Interval. However, sub second Advert timers, can put extra load on CPU and the network bandwidth which may not be desirable. Since the VRRP protocol depends on the availability of Layer 3 IPv4 or IPv6 connectivity between redundant peers, the VRRP protocol can interact with the Layer 3 variant of BFD as described in to achieve a much faster failure detection of the VRRP Active on the LAN. BFD, as specified by the can provide a much faster failure detection in the range of 150ms, if implemented in the part of a Network device which scales better than VRRP when sub second Advert timers are used. Terminology of this draft has been updated conform to inclusive language guidelines for VRRP Inclusive Terminologies . The IETF has designated National Institute of Standards and Technology (NIST) "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" for its inclusive language guidelines.

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.

Applicability of Point to Point BFD BFD for IPv4 or IPv6 (Single Hop) requires that in order for a BFD session to be formed both peers participating in a BFD session need to know its peer IPv4 or IPV6 address. This poses a unique problem with the definition of the VRRP protocol, that makes the use of BFD for IPv4 or IPv6 more challenging. In VRRP it is only the Active router that sends Advert packets. This means that a Active router is not aware of any Backup routers, and Backup routers are only aware of the Active router. This also means that a Backup router is not aware of any other Backup routers in the Network. Since BFD for IPv4 or IPv6 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 its peer Virtual Router. The 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 Active router, and the highest priority Backup router. When the Critical Path BFD Session identified by VRRP as having changed state from Up to Down, then this will be interpreted by the VRRP state machine on the highest priority Backup router as a Active Down event. A Active Down event means that the highest priority Backup peer will immediately become the new Active for the Virtual Router. NOTE: At all times, the normal fail-over mechanism defined in the VRRP will be unaffected, and the BFD fail-over mechanism will always resort to normal VRRP fail-over. This draft defines the mechanism used by the VRRP protocol to build a peer table that will help in forming of BFD session and the detection of Critical Path BFD session. If the Critical Path BFD session were to go down, it will signal a Active Down event and make the most preferred Backup router as the VRRP Active router. 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, Active or Backup.

Extension to VRRP protocol In this mode of operation VRRP peers learn the adjacent routers, and form BFD session between the learnt routers. In order to build the peer table, all routers send VRRP Advert packets whilst in any of the operational states (Active or Backup). Normally VRRP peers only send Advert packets whilst in the Active state, however in this mode VRRP Backup peers will also send Advert packets with the type field set to BACKUP ADVERTISEMENT type defined in of this document. The VRRP Active router will still continue to send packets with the Advert type as ADVERTISEMENT as defined in the VRRP protocol. This is to maintain inter-operability with peers complying to VRRP 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 Active 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.

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 Active or Backup peers. This allows peers to create BFD sessions with 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).

VRRP BACKUP ADVERTISEMENT Packet Type The following figure shows the VRRP packet as defined in VRRP RFC. 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 Active Router. Type 2 (BACKUP ADVERTISEMENT) is used by the VRRP Backup router. This is to distinguish the packets sent by the VRRP backup Router. VRRP Backup fills Backup_Advertisement_Interval in the Max Advert Int of BACKUP ADVERTISEMENT packet. Rest of the fields in Advert packet remain the same. A packet with unknown type MUST be discarded.

Sample configuration The following figure shows a simple network with three VRRP routers implementing one 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. Rtr1 is the Active router since it has the highest priority compared to 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 Rtr2 Peer table Rtr3 Peer table Once the peer tables are formed, VRRP on each router can form a BFD sessions with the learnt peers.

Critical BFD session The Critical BFD Session is determined to be the session between the VRRP Active and the next best VRRP Backup. Failure of the Critical BFD session indicates that the Active is no longer available and the most preferred Backup will now become Active. 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 Active down event and immediately assume the role of VRRP Active router for VRID 1 and Rtr3 will become the critical Backup. If the priorities of two Backup routers are same then the primary IPvX Address of the sender is used to determine the highest priority Backup. Where higher IPvX address has higher priority.

Protocol State Machine

Parameters Per Virtual Router Following parameters are added to the VRRP protocol to support this mode of operation.

Timers Following timers are added to the VRRP protocol to support this mode of operation.

VRRP State Machine with Point to Point BFD Following State Machine replaces the state Machine outlined in section 6.4 of the VRRP protocol to support this mode of operation. Please refer to the section 6.4 of for State description.

Initialize Following state machine replaces the state machine outlined in section 6.4.1 of

Backup Following state machine replaces the state machine outlined in section 6.4.2 of

Active Following state machine replaces the state machine outlined in section 6.4.3 of

Scalability Considerations 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 Active.

Operational Considerations A VRRP 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 Active. 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.

Applicability to VRRPv2 The workings of this Draft can be extended to VRRPv2 defined in RFC3768, with the introduction of BACKUP ADVERTISEMENT and Peer Table as outlined in the Draft.

IANA Considerations This document requests IANA to create a new name space that is to be managed by IANA. The document defines a new VRRP Packet Type. The VRRP Packet Types are discussed below.

A New Name Space for VRRP Packet Types This document defines in Section 3.3 a "BACKUP ADVERTISEMENT" VRRP Packet Type. The new name space has to be created by the IANA and they will maintain this new name space. The field for this namespace is 4-Bits, and IANA guidelines for assignments for this field are as follows: Future allocations of values in this name space are to be assigned by IANA using the "Specification Required" policy defined in

Implementation Status This section is to be removed before publishing as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. There is a prototype implementation of this draft that has been completed and verified.

Security Considerations Security considerations discussed in , , apply to this document. There are no additional security considerations identified by this draft.

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 Haas, Maik Pfeil, Chris Bowers, Vengada Prasad Govindan and Alexander Vainshtein for their comments and suggestions.