Fast failure detection in VRRP with S-BFD

Fast failure detection in VRRP with S-BFD Individual

n.serafini@tutanota.com

General Internet Engineering Task Force VRRP BFD S-BFD The Virtual Router Redundancy Protocol (VRRP) protocol depends on the availability of layer three (3) IPvX connectivity between redundant peers and it can interact with the variant of Seamless Bidirectional Forwarding Detection (S-BFD) protocol to achieve a much faster failure detection. This document describes how to extend the VRRP protocol to support S-BFD as a detection system for Primary Router failures. To announce the use of this implementation, a new VRRP packet type and a new timer are defined. To facilitate and increase the user experience while deploying this implementation, an auto-calculation algorithm for the S-BFD Discriminators is also implemented.

Introduction Bidirectional Forwarding Detection (BFD) defined in is a specialized protocol to detect failures between a pair of systems in microseconds; extends to IPvX addresses in single-hop. BFD has a lot of implementations and they are the standard for the industry. As an extension of BFD, the Seamless Bidirectional Forwarding Detection (S-BFD) protocol defined in was developed to allow a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring; is the extension of for IPvX and MPLS networks. The Virtual Router Redundancy Protocol (VRRP) protocol is the actual open standard for the First Hop Redundancy Protocol (FHRP) implementation in IPvX networks; it's version two (2) is defined in and the version three (3) is defined in ; VRRP provides an algoritmh for Primary election and also a standard for interoperability between vendors. VRRP version two (2) defined in can detect failures in second and its succesor in centisecond. meets and when the failure in a IPvX networks MUST be detected in microseconds or milliseconds.

Terminology

VRRP: Virtual Router Redundancy Protocol
BFD: Bidirectional Forwarding Detection
S-BFD: Seamless Bidirectional Forwarding Detection
FHRP: First Hop Redundancy Protocol
SBFD_Handler: New handler added to the Virtual Router. It is triggered when S-BFD in Initiator operational mode detects a failure.
SBFD_My_Discriminator: New state variable added to the Virtual Router when it aims to use S-BFD as failure detection system. Depending on the S-BFD operating mode, this value has different meanings.
SBFD_Your_Discriminator: New state variable added to the Virtual Router when it aims to use S-BFD as failure detection system. This values is only used when VRRP aims to use S-BFD as Initiator.
SBFD_Primary_Down_Timer: New timer added to the Virtual Router. It starts when S-BFD triggers the SBFD_Handler and is used as election algorithm.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Required Features This section outlines the set of features that were considered mandatory and that guided the design of this document. There is no particular order and all required features listed below MUST be supported by this implementation.

Timers for Primary election When required, this implementation MUST allow S-BFD to bypass the VRRP timers.

Local S-BFD Discriminator generation All Router member of a specified VRRP domain MUST be able to calculate and generate a local S-BFD Discriminator that MUST be used as SBFDInitiator or SBFDReflector without previous knowledge of the other members, aknowledge or data exchange in the network.

Remote S-BFD Discriminator generation While in VRRP Backup state machine, all Routers member of a specified VRRP domain MUST be able to calculate and generate the remote S-BFD Discriminator for the VRRP Primary Router acting as SBFDReflector with the standard VRRP packet type two (2) defined in this document.

S-BFD Discriminator length The auto generated S-BFD Discriminator MUST have a length of 32-bit, as defined in .

VRRP support This implementation MUST support both version of VRRP, version two (2) and three (3); therefore, it MUST support IPv4 and IPv6.

Known Limitations Before using S-BFD as failure detection system with VRRP the following limitations MUST be considered.

Inconsistency The application that implements this specification SHOULD be responsable for triggering an even when an inconsistency is detected between the state machine of VRRP and the S-BFD operational mode.

Overview Each VRRP Router that wants to use S-BFD as failure detection system MUST calculate it's local S-BFD Discriminator and depending on the VRRP state machine it MUST act as SBFDReflector or SBFDInitiator. When VRRP is in Primary state and want the others to monitor this entity, it MUST start a new SBFDReflector session with the previous generated local S-BFD Discriminator and MUST annunce the use of this implementation by sending a VRRP advertisement packet type two (2). When VRRP is in Backup state and it wants to monitor the Primary it MUST start a SBFDInitiator session againt this one. To start a new session, the SBFDInitiator MUST learn the Primary SBFDReflector Discriminator and source IPvX troughthout the VRRP advertisement packet with type two (2) that it receives while in VRRP Backup state. The SBFDInitiator MUST be responsible for compute the correct Your Discriminator field and monitor the Primary SBFDReflector for the learnt IPvX address. When the SBFDReflector receives the control packet from a SBFDInitiator, it MUST lookup the incoming packet to locate a corresponding SBFDReflector session based on the value from the Your Discriminator field in the table describing S-BFD Discriminators. The SBFDReflector allocate this value before transmitting the VRRP Primary advertisement packet. The guidelines and the formula for the generation of the local and remote S-BFD Discriminator for both IPv4 and IPv6 VRRP Routers and how it is used to maintain the relation between those protocols states are discussed in this document. After an S-BFD session is established, if a state machine change of VRRP or S-BFD is triggered a Leader/Follower logic is implemented to increase the compatibility; this document also aims to clarify how strictly VRRP interoperate with the S-BFD operational mode and state machine; therefore, a new handler and a new timer are defined in conjuction with a new VRRP packet type. The following diagram may clarify how this specification works at high level.

VRRP and S-BFD | SBFDReflector | | | | +-------------+ |<--S-BFD Ctrl pkt------| +-------------+ | | | | |S-BFD Discrim| | | | | |S-BFD Discrim| | | | | | | |---S-BFD Echo pkt---+ | | | | | | | +-^-----------+ | | | | | +----------^--+ | | | +---|-------------+<-------------------+ +------------|----+ | | | | | | | | +---v----+ | | +---v----+ | | | VRID | | | | VRID | | | +---^----+ | | +----^---+ | | | | | | | | +----+ | | +----+ | | | | | | | +---------[^]---------+ +------------[v]---------+ | VRRP | +-------------------//--------------------+ ]]>

VRRP state machine and S-BFD operational mode To facilitate the interoperability between this two protocols a reverse relation between the state machine of VRRP and the operational mode of S-BFD is developed. If VRRP is in Primary state, it MUST initialize a SBFDReflector session with the local auto calculated S-BFD Discriminator; when it acts as Backup Router, it MUST initialize a SBFDInitiator session with the local auto calculated S-BFD Discriminator as My Discriminator against the Primary Router; the destination of the initiator session is always the source IPvX from where the Primary VRRP packet with type two (2) is received and the value of Your Discriminator is calculated with the logic defined in this specification. When VRRP is in Init state, means there are no S-BFD sessions linked with this VRID, VRRP version and IPvX. This is because the S-BFD session can be initialized when trasmitting (Primary) or listening (Backup) for VRRP packets. The application that implements this specifican is responsable for maintaining the relation between VRRP and S-BFD if aims to use this specification; when an inconsistency is detected, it MUST be threaded as critical error.

VRRP and S-BFD state machines interoperability As defined in , S-BFS has also a state machine; when operating in SBFDInitiator mode, it has two states: UP and DOWN; the DOWN state is triggered when a timer expires or when an AdminDown status is received from the remote Reflector session. When in SBFDReflector operational mode, it can responde with: UP and AdminDown. In the case of SBFDReflector operational mode and VRRP Primary state machine, VRRP MUST be responsable for triggering the change on the corresponding S-BFD session. When VRRP is in Backup state and S-BFD in Initiator operational mode, S-BFD MUST be responsable for triggering the SBFD_Handler and VRRP MUST be responsable for starting the SBFD_Primary_Down_Timer timer and monitor it. When VRRP is in Primary state and wants to send a priority zero (0) advertisement packet for releasing its state, it MUST relay over it's own mechanism defined in the VRRP standard. The side effects is that the election algorithm is the same as the VRRP version used and not the one defined in this document. Is up to the application that implements this specification to decide how these protocols communicate their state changes one to each other.

Relation maintenance The application that implements this specification is responsable for maintaining the relation between the S-BFD session, the current VRID and VRRP version for a given IPvX, and the operational mode of S-BFD for this particular VRRP state machine; in case of VRRP transitions, the application MUST relay over S-BFD to destroy the previous session and/or initialize a new one and, in case of SBFDInitiator transitions it MUST relay over the existing VRRP specification for state changes. The maintenance of this relation MUST be done throughout two state variables: SBFD_My_Discriminator and SBFD_Your_Discriminator; the behavior of these state variables depends on the current operational mode and is detailed in the next section. When acting as Initiator, the destination IPvX of the SBFDReflector learnt with the previous VRRP packet MAY NOT be saved and MAY only be used to initialize the S-BFD session.

Relation requirements This section aims to clarify how the relations and the state variables are managed by each VRRP state machine. To be able to create an association, VRRP MUST save those state variables on its Virtual Router instance and use those values to identify, create or destroy the corresponding S-BFD session.

Primary state

SBFD_My_Discriminator: SBFDReflector Discriminator calculated for this Virtual Router. This state variable MUST be initialized if the Primary Router wants the other to monitor its state throughout S-BFD and MUST be used to start the corresponding SBFDReflector session as My Discriminator.

Backup state

SBFD_My_Discriminator: Required - SBFDInitiator Discriminator.
SBFD_Your_Discriminator: Required - SBFDReflector Discriminator learnt for this VRRP instance.

Initialize state In this state the implementation MUST NOT maintain a relation and the previous sessions MUST be destroyed throughout S-BFD. There might be the case where VRRP is abnormally terminated and it is not able to notify S-BFD of this change; this behavior is discussed in of this document.

S-BFD Discriminator calculation The calculation used to generate the SBFD_My_Discriminator or SBFD_Your_Discriminator state variables is applicable to the remote as well to the local Router. Based on the IPvX that send or receive VRRP packets troughthout the VRRP multicast group, the VRID and the VRRP version, with the below formula the Router MUST be able to calculate those values. This calculation is implementad to facilitate the provision of VRRP with S-BFD without affecting the standard packet. In the case of IPv6, an exception MUST be applied.

Pairing function The pairing function used in this document is calculated as follows, where x and y are non-negative integer. ( (x + y) * ( x + y + 1)/2 + y )

IPv4 From its binary format, each 16-bit of the IPv4 address are separated into two slices of 8-bit and then each slice converted to decimal; the result of this conversation are two integer number between 0 and 255; those two integers of one octet are then computed to the pairing function defined below as x and y; the previous operations MUST be repited for each group of 16-bit and the result of each operation MUST be added to the previous one. At the end of the previous calculation, the VRID and the VRRP version are also computed (in decimal format) to the pairing function previously defined and the result MUST be added to the total. The following example may clarify the formula for IPv4. ( ((x+y)*(x+y+1)/2 + y) + ((x1+y1)*(x1+y1+1)/2 + y1) + ((vrid+vrrp_version)*(vrid+vrrp_version+1)/2 + vrrp_version) )

IPv6 The logic for the IPv6 addresses is almost the same as for IPv4, except for the additional static value added at the end and required to differentiate IPV6 from IPv4. If IPv6, a static integer value of 294534 MUST also be added at the end.

Recursive calculation The pairing function defined in above is not used in recursive mode for three (3) main reasons: the first one is that we have a fix length of values - 32-bit for IPv4 and 128-bit for IPv6 - and it does not change, the second is because the result generated from the calculation detailed in this document is smaller then the result of a recursive calculation where the previous result is paired with the next number; finally, in this way the calculation for IPvX requires one step less.

Learning the SBFDInitiator Your Discriminator field The SBFDInitiator Your Discriminator field is managed as defined in RFC7880 Section 7.2.

Timers The VRRP election algorithm includes the advertisement interval (VRRP failure detection mechanism) and cannot directly be used to implement this specification. To avoid collisions, a dedicated S-BFD timer called SBFD_Primary_Down_Timer MUST be imlemented inside the VRRP Router to be able to comply with this specification. This timer MUST be equal to the Skew_Time for the given VRRP version and MUST be started only when S-BFD in the Initiator operational mode triggers the VRRP SBFD_Handler for a DOWN or AdminDown change on the Reflector.

Operational requirements This section define the operational requirements of this specification and how these protocols are integrated.

Initialize state ] + If S-BFD is required, then: [>] [>] - Compute the SBFD_My_Discriminator. [>] [>] - Start a new SBFDReflector session with SBFD_My_Discriminator as My Discriminator. [>] [>] - Set the VRRP packet type to 2 [>] [>] + else [>] [>] - Set the VRRP packet type to 1 [>] [>] + endif // is S-BFD required? - Send an ADVERTISEMENT + If the protected IPvX address is an IPv4 address, then: - For each IPv4 address associated with the Virtual Router, broadcast a gratuitous ARP message containing the Virtual Router MAC address and with the target link-layer address set to the Virtual Router MAC address. + else // IPv6 - For each IPv6 address associated with the Virtual Router, send an unsolicited ND Neighbor Advertisement with the Router Flag (R) set, the Solicited Flag (S) clear, the Override flag (O) set, the target address set to the IPv6 address of the Virtual Router, and the target link-layer address set to the Virtual Router MAC address. + endif // was protected address IPv4? - Set the Adver_Timer to Advertisement_Interval - Transition to the {Primary} state + else // Router is not the address owner - Set Primary_Adver_Interval to Advertisement_Interval - Set the Primary_Down_Timer to Primary_Down_Interval [>] + If S-BFD is required, then: [>] [>] - Set the SBFD_Primary_Down_Timer to Skew_Time [>] [>] + endif // is S-BFD required? - Transition to the {Backup} state + endif // was priority 255? + endif // Startup event was received ]]>

VRRP Backup state ] + If S-BFD is required, then: [>] [>] - Destroy the previous SBFDInitiator session. [>] [>] - Cancel the SBFD_Primary_Down_Timer. [>] [>] + endif // is S-BFD required? - Transition to the {Initialize} state + endif // Shutdown event received [>] + If the SBFD_Handler event is received, then: [>] [>] - Start the SBFD_Primary_Down_Timer. [>] [>] + endif // SBFD_Handler event received [>] + If the Primary_Down_Timer OR the SBFD_Primary_Down_Timer fires, then: [>] + If S-BFD is required, then: [>] [>] - Compute the SBFD_My_Discriminator. [>] [>] - Start a new SBFDReflector session with SBFD_My_Discriminator as My Discriminator. [>] [>] - Set the VRRP packet type to 2 [>] [>] + else [>] [>] - Set the VRRP packet type to 1 [>] [>] + endif // is S-BFD required? - Send an ADVERTISEMENT + If the protected IPvX address is an IPv4 address, then: - For each IPv4 address associated with the Virtual Router, broadcast a gratuitous ARP message containing the Virtual Router MAC address and with the target link-layer address set to the Virtual Router MAC address. + else // IPv6 - Compute and join the Solicited-Node multicast address [RFC4291] for the IPv6 address(es) associated with the Virtual Router. - For each IPv6 address associated with the Virtual Router, send an unsolicited ND Neighbor Advertisement with the Router Flag (R) set, the Solicited Flag (S) clear, the Override flag (O) set, the target address set to the IPv6 address of the Virtual Router, and the target link-layer address set to the Virtual Router MAC address. + endif // was protected address IPv4? - Set the Adver_Timer to Advertisement_Interval [>] + If S-BFD is required, then: [>] [>] - Cancel the SBFD_Primary_Down_Timer timer. [>] [>] + endif // is S-BFD required? - Transition to the {Primary} state + endif // Primary_Down_Timer fired + If an ADVERTISEMENT is received, then: [>] + If VRRP packet type is 2, then: [>] [>] - Set the SBFD_My_Discriminator. [>] [>] - Set the SBFD_Your_Discriminator. [>] [>] - Start a new SBFDInitiator session against the Primary [>] Router using SBFD_My_Discriminator as My Discriminator [>] and SBFD_Your_Discriminator as Your Discriminator; the destination [>] IPvX of the new session is the source IPvX learnt from the [>] advertisement packet and the port is the same defined in [RFC7881]. [>] [>] + endif // is VRRP packet type 2? + If the Priority in the ADVERTISEMENT is 0, then: - Set the Primary_Down_Timer to Skew_Time + else // priority non-zero + If Preempt_Mode is False, or if the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then: - Set Primary_Adver_Interval to Max Advertise Interval contained in the ADVERTISEMENT - Recompute the Skew_Time - Recompute the Primary_Down_Interval, - Set the Primary_Down_Timer to Primary_Down_Interval + else // preempt was true and priority was less than the local priority - Discard the ADVERTISEMENT + endif // preempt test + endif // was priority 0? + endif // was advertisement received? endwhile // Backup state ]]>

Primary state ] + If S-BFD is required, then: [>] [>] - Set the VRRP packet type to 2 [>] [>] + else [>] [>] - Set the VRRP packet type to 1 [>] [>] + endif // is S-BFD required? [>] - Send an ADVERTISEMENT with Priority = 0 - Transition to the {Initialize} state + endif // shutdown received + If the Adver_Timer fires, then: [>] + If S-BFD is required, then: [>] [>] - Set the VRRP packet type to 2 [>] [>] + else [>] [>] - Set the VRRP packet type to 1 [>] [>] + endif // is S-BFD required? - Send an ADVERTISEMENT - Reset the Adver_Timer to Advertisement_Interval + endif // advertisement timer fired [>] + If an ADVERTISEMENT type 1 or 2 is received, then: + If the Priority in the ADVERTISEMENT is 0, then: [>] + If an ADVERTISEMENT type 2, then: [>] [>] - Set the VRRP packet type to 2 [>] [>] + else [>] [>] - Set the VRRP packet type to 1 [>] [>] + endif // is ADVERTISEMENT type 2? - Send an ADVERTISEMENT - Reset the Adver_Timer to Advertisement_Interval + else // priority was non-zero + If the Priority in the ADVERTISEMENT is greater than the local Priority or the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IPvX Address of the sender is greater than the local primary IPvX Address (based on an unsigned integer comparison of the IPvX addresses in network-byte order), then: - Cancel Adver_Timer - Set Primary_Adver_Interval to Max Advertise Interval contained in the ADVERTISEMENT - Recompute the Skew_Time - Recompute the Primary_Down_Interval - Set Primary_Down_Timer to Primary_Down_Interval - Transition to the {Backup} state + else // new Primary Router logic - Discard the ADVERTISEMENT [>] + If an ADVERTISEMENT type 2, then: [>] [>] - Set the VRRP packet type to 2 [>] [>] + else [>] [>] - Set the VRRP packet type to 1 [>] [>] + endif // is ADVERTISEMENT type 2? - Send an ADVERTISEMENT immediately to assert Primary state to the sending VRRP Router and to update any learning bridges with the correct Primary VRRP Router path. + endif // new Primary Router detected + endif // was priority zero? + endif // advert received endwhile // in Primary state ]]>

IANA Considerations This memo includes request to IANA.

Security Considerations This document aims to define how to accelerate the detection of a failure that affects VRRP functionality using S-BFD. The operation of either base protocols is not changed; therefore, there are not additional security considerations.

References Normative References

Previous works This document was inspired by the previous work on VRRP and BFD done here: draft-ietf-rtgwg-vrrp-bfd-p2p-xx and draft-ietf-rtgwg-vrrp-p2mp-bfd-xx.

Tools This document is based on templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz and maintened thanks to the open source xml2rfc project.

Acknowledgements Thanks to the RFC Authors of VRRP for their work on this Primary/Backup election protocol which helped since 1998. Thanks to the RFC Authors of BFD for their work on this failure detection protocol that helped to improve the Internet. Thanks to the RFC Authors of S-BFD for their work on this seamless BFD implementation that can be used in VRRP for a fast failure detection. Thanks to G. Mirsky, J. Tantsura, G. Mishra, N. Gupta, A. Dogra and C. Docherty for their previous work on VRRP and BFD. Thanks to the open source mainteners of VRRP and [S]BFD for their effort.

Contributors Contributions are welcome.