| Internet-Draft | VRRP and S-BFD | December 2024 |
| Serafini | Expires 14 June 2025 | [Page] |
Since the VRRP protocol depends on the availability of Layer 3 IPvX connectivity between redundant peers, the VRRP protocol can interact with the variant of S-BFD as described in [RFC7881] to achieve a much faster failure detection.¶
This document describes how to extend the Virtual Router Redundancy Protocol (VRRP) to support Seamless Bidirectional Forwarding Detection (S-BFD) as a detection system for Primary Router failure. To announce the use of this implementation, a new type (Section 5.2.2.) of VRRP packet and a new timer are defined. To facilitate and increase the user experience while deploying this implementation, an auto-calculation algorithm for the SBFD Discriminators is also implemented.¶
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 https://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 14 June 2025.¶
Copyright (c) 2024 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
BFD [RFC5880] is a specialized protocol to detect failures between a pair of systems in microseconds; [RFC5881] extends [RFC5880] to IPvX addresses in single-hop. BFD has a lot of implementations and they are the standard for the industry. As extension of BFD, [RFC7880] 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. [RFC7881] is the extension of [RFC7880] for IPvX and MPLS networks.¶
VRRP is the actual open standard for the FHRP implementation in IPvX networks; it's version two is defined in [RFC3768] and the version three is defined in [RFC9568]. VRRP provides an algoritmh for Primary election and also a standard for interoperability between vendors. VRRPv2 defined in [RFC3768] can detect failures in second and its succesor [RFC9568] in centisecond.¶
[RFC7881] meets [RFC3768] and [RFC9568] when the failure in a IPvX network MUST be detected in microseconds or milliseconds.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
When required, this implementation MUST allow S-BFD to bypass and replace the VRRP timers to achive a more fast Primary election.¶
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.¶
While in VRRP Secondary machine state, 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.¶
The auto generated S-BFD Discriminator MUST have a length of 32 bit, as defined in [RFC5880].¶
This implementation MUST support both version of VRRP, version 2 and 3; therefore, it MUST support IPv4 and IPv6.¶
This implementation MUST allow VRRPv2 and VRRPv3 to interoperate when using this specification or not.¶
Before using S-BFD as failure detection system with VRRP the following limitations MUST be considered.¶
The application that implements this specification SHOULD be responsable for monitoring the availability of both services and trigger an even when a potential inconsistency is detected between the state machine of VRRP and S-BFD.¶
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 machine state it MUST act as SBFDReflector or SBFDInitiator.¶
When VRRP is in Primary state and want the others to monitor this entity MUST start a SBFDReflector session with the previous generated local S-BFD Discriminator and MUST annunce the use of this implementation by sending a VRRP packet Type Two (2) defined below. When VRRP is in Secondary state, and it want 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 packet with Type Two (2) that it receives while in VRRP Seconday 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 packet. The guidelines 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 - the formula is also discussed.¶
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.¶
+---------------------+ +------------------------+
| Secondary | | Primary |
| +-----------------+ | | +-----------------+ |
| | SBFDInitiator |---S-BFD Ctrl pkt----->| SBFDReflector | |
| | +-------------+ |<--S-BFD Ctrl pkt------| +-------------+ | |
| | |S-BFD Discrim| | | | | |S-BFD Discrim| | |
| | | | |---S-BFD Echo pkt---+ | | | | |
| | +-^-----------+ | | | | | +----------^--+ | |
| +---|-------------+<-------------------+ +------------|----+ |
| | | | | |
| +---v----+ | | +---v----+ |
| | VRID | | | | VRID | |
| +---^----+ | | +----^---+ |
| | | | | |
| +----+ | | +----+ |
| | | | | |
+---------[^]---------+ +------------[v]---------+
| VRRP |
+-------------------//--------------------+
¶
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.¶
VRRP is in Primary state, it MUST initialize a SBFDReflector session with the local auto calculated S-BFD Discriminator; when it acts as Secondary Router, it MUST initialize a SBFDInitiator session with the local auto calculated S-BFD 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 (Secondary) for VRRP packets.¶
As defined in [RFC7880], S-BFS has also a machine state and it MUST not be confused with the operational mode; when S-BFD applies his machine state in SBFDInitiator operational mode it has three states: UP, DOWN and AdminDown; the AdminDown state is triggered when received from the remote Reflector session. The SBFDReflector has only two states machine: 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 except when the S-BFD session goes into AdminDown itself; in such case, S-BFD MUST notify VRRP and this one MUST trigger the Secondary state. This behavior is NOT RECCOMENDED and SHOULD always be VRRP to turn S-BFD state machine changes. When VRRP is in Secondary 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.¶
When VRRP is in Primary state and wants to send a priority zero (0) advertisement packet for releasing its state, it MUST first turn into AdminDown the corresponding S-BFD session and then it MUST send the advertisement with priority zero (0) as defined in the VRRP standard.¶
The application that implements this specifican is responsable for monitoring the availability of VRRP and S-BFD if aims to use this implementation. When one module fails, it MUST be threaded as inconsistency.¶
This specification does not define how VRRP and S-BFT are integrated; is up to the application that implements this document to decide how these protocols communicate their state changes one to the other.¶
The interoperability between state machines is discussed in detail in Section 12.¶
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 machine state; 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.¶
This section aims to clarify how the relations and the state variables are managed by each VRRP machine state.¶
To be able to create an association, VRRP MUST save those state variables on its Virtual Router instance and use those values to create o destroy the corresponding S-BFD session.¶
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 the "VRRP and S-BFD state machines interoperability" section of this document.¶
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.¶
From its binary format, each 16-bit of the IPv4 address are separated into two slices of 8bits 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 Cantor pairing function (in decimal format) 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 computed to the Cantor pairing function (in decimal format) 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) )¶
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. Always from its binary format, each 16-bit of the IPv6 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 and those two integers of one octet are then computed to the Cantor pairing function (in decimal format) 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 computed to the Cantor pairing function (in decimal format) and the result MUST be added to the total. If IPv6, also a static integer value of 294534 MUST also be added at the end.¶
The pairing function is not used in recursive mode for three main reasons: the first 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.¶
The SBFDInitiator Your Discriminator field is managed as defined in RFC7880 Section 7.2.¶
The VRRP election algorithm includes de advertisement interval (VRRP failure detection mechanism) and cannot directly be used to implement this specification. To avoid collisions, a dedicated S-BFD timer MUST be imlemented inside VRRP to be able to comply with this specification. This timer MUST be pre calculated and started only when the S-BFD in Initiator operational mode triggers the VRRP SBFD_Handler for a DOWN or AdminDown change on the Reflector.¶
VRRP in Secondary state machine MUST start this timer when the SBFDInitiator triggers the SBFD_Handler for a particual S-BFD session; when this happens, the timer SBFD_Primary_Down_Timer MUST replace the Primary_Down_Timer of VRRP specification in Secondary state. This new timer is definde below and its behavior is also described in the Operationl Requirement section.¶
The result of this calculation is almost the same as VRRP, except for the advertisement and the static tolerance multipler. The short difference in the SBFD_Primary_Down_Timer timer when two or more Secondary Routers are deployed can be a problem if those Routers are not able to receive the Primary VRRP packet before their timer fire; in that case, they will become Primary with a potencial service disruption. To avoid this situation when using two or more Secondary Routers, is RECCOMENDED to use a difference between each Secondary Router priority enougth to permit the Routers to receive the Primary packet before raising the SBFD_Primary_Down_Timer timer.¶
This section define the operational requirements of this specification and how these protocols are integrated.¶
+ If a Startup event is received, then:
+ If the Priority = 255, i.e., the router owns the IPvX
address(es) associated with the Virtual Router, 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
- 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.
[>]
[>] + endif // is S-BFD required?
- Transition to the {Secondary} state
+ endif // was priority 255?
+ endif // Startup event was received
¶
While in Secondary state, a VRRP Router MUST do the following:
+ If the protected IPvX address is an IPv4 address,
then:
- It MUST NOT respond to ARP requests for the IPv4
address(es) associated with the Virtual Router.
+ else // protected address is IPv6
- It MUST NOT respond to ND Neighbor Solicitation messages
for the IPv6 address(es) associated with the Virtual Router.
- It MUST NOT send ND Router Advertisement messages
for the Virtual Router.
+ endif // was protected address IPv4?
- It MUST discard packets with a destination link-layer
MAC address equal to the Virtual Router MAC address.
- It MUST NOT accept packets addressed to the IPvX
address(es) associated with the Virtual Router.
+ If a Shutdown event is received, then:
- Cancel the Primary_Down_Timer
[>] + 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:
[>]
[>] - Set the Primary_Down_Timer to SBFD_Primary_Down_Timer.
[>]
[>] + endif // SBFD_Handler event received
+ If the Primary_Down_Timer fires, then:
[>] + If S-BFD is required, then:
[>]
[>] - Destroy the previous session as SBFDInitiator.
[>]
[>] - Set 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 session as SBFDInitiator 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.
[>]
[>]
[>] + 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 // Secondary state
¶
While in Primary state, a VRRP Router MUST do the following:
+ If the protected IPvX address is an IPv4 address, then:
- It MUST respond to ARP requests for the IPv4
address(es) associated with the Virtual Router.
+ else // IPv6
- It MUST be a member of the Solicited-Node multicast
address for the IPv6 address(es) associated with the
Virtual Router.
- It MUST respond to ND Neighbor Solicitation messages (with
the Router Flag (R) set) for the IPv6 address(es) associated
with the Virtual Router.
- It MUST send ND Router Advertisements for the Virtual
Router.
+ If Accept_Mode is False: MUST NOT drop IPv6
Neighbor Solicitations and Neighbor Advertisements.
+ endif // IPv4?
- It MUST forward packets with a destination link-layer MAC
address equal to the Virtual Router MAC address.
- It MUST accept packets addressed to the IPvX address(es)
associated with the Virtual Router if it is the IPvX
address owner or if Accept_Mode is True. Otherwise,
MUST NOT accept these packets.
+ If a Shutdown event is received, then:
- Cancel the Adver_Timer
[>] + If S-BFD is required, then:
[>]
[>] - Put in AdminDown the SBFDReflector session.
[>]
[>] - 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
[>] + If S-BFD is required, then:
[>]
[>] - Turn in AdminDown the SBFDReflector session.
[>]
[>] + endif // is S-BFD required?
- Transition to the {Secondary} 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
¶
This memo includes no request to IANA.¶
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.¶
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.¶
This document is based on templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz and maintened thanks to the open source xml2rfc project.¶
Thanks to the RFC Authors of VRRP for their work on this Primary/Secondary 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.¶
Contributions are welcome.¶