| Internet-Draft | VRRP and S-BFD | April 2026 |
| Serafini & Dogra | Expires 13 October 2026 | [Page] |
The Virtual Router Redundancy Protocol (VRRP) protocol depends on IPv4 or IPv6 connectivity between redundant peers and can use Seamless Bidirectional Forwarding Detection (S-BFD) to detect a Primary Router failure faster than the base VRRP advertisement timers.¶
This document describes an extension that allows VRRP to use S-BFD as an additional failure-detection mechanism. It defines a new VRRP packet type, a dedicated timer, and a mechanism for a VRRP Primary Router to advertise an S-BFD reflector discriminator to Backup Routers. Local discriminator allocation is left to the implementation.¶
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 13 October 2026.¶
Copyright (c) 2026 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.¶
Bidirectional Forwarding Detection (BFD), defined in [RFC5880], is a protocol for rapid failure detection between a pair of systems. [RFC5881] specifies its use for single-hop IPv4 and IPv6 sessions. Seamless BFD (S-BFD), defined in [RFC7880], reduces setup and negotiation overhead and enables simpler provisioning. [RFC7881] extends S-BFD to IPv4, IPv6, and MPLS networks.¶
VRRP is a standardized first-hop redundancy protocol for IPv4 and IPv6 networks. VRRP defined in [RFC9568] provides a standard election procedure for selecting a Primary Router and interoperable behavior across implementations. In the base protocol, failure detection depends on advertisement processing and associated timers.¶
This document combines S-BFD with VRRP for deployments that need failure detection in the millisecond or sub-second range without relying only on aggressive VRRP advertisement timers.¶
Similar to the S-BFD discriminator advertisements defined for IS-IS in [RFC7883] and OSPF in [RFC7884], the extension defined in this document allows a VRRP Primary Router to advertise an S-BFD reflector discriminator that Backup Routers can use to create SBFDInitiator sessions. The selection of local S-BFD discriminators remains implementation specific.¶
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 lists the features that guided the design of this specification.¶
There is no implied priority among them, and all of the features below MUST be supported by an implementation of this specification.¶
When enabled, this specification MUST allow S-BFD to accelerate failure detection independently of the normal VRRP advertisement timers.¶
Every Router in a VRRP domain MUST be able to allocate a local S-BFD discriminator for use as an SBFDInitiator or SBFDReflector. The allocation method is implementation specific, but the selected value MUST satisfy the local uniqueness requirements of [RFC7880] and [RFC7881].¶
A Router in VRRP Backup state MUST be able to learn the remote S-BFD discriminator for the VRRP Primary Router acting as an SBFDReflector from the VRRP packet type defined in this document.¶
The locally allocated and remotely advertised S-BFD discriminator MUST be 32 bits long, as defined in [RFC5880].¶
Before S-BFD is used as a failure-detection mechanism with VRRP, the following limitation MUST be considered.¶
The implementation SHOULD raise an event when it detects an inconsistency between the VRRP state machine and the corresponding S-BFD operating mode.¶
Each VRRP Router that uses S-BFD for failure detection MUST allocate a local S-BFD discriminator and MUST operate as an SBFDReflector or SBFDInitiator according to its VRRP state.¶
When VRRP is in Primary state and the router wants other peers to monitor it, it MUST start an SBFDReflector session using the locally allocated discriminator and MUST advertise that discriminator by sending the VRRP packet type defined in this document. When VRRP is in Backup state, the router MUST start an SBFDInitiator session to monitor the Primary Router.¶
To start a new session, the SBFDInitiator MUST learn the Primary Router's SBFDReflector discriminator and source IPvX address from the VRRP S-BFD Advertisement defined in this document. The SBFDInitiator MUST use a locally allocated discriminator as My Discriminator and the learned reflector discriminator as Your Discriminator, and it MUST monitor the learned source address. When the SBFDReflector receives a control packet from an SBFDInitiator, it MUST locate the corresponding SBFDReflector session by using the incoming Your Discriminator value.¶
This document also defines how VRRP and S-BFD state changes interact, how the new handler and timer are used, and how the new packet type advertises the reflector discriminator needed by VRRP peers. This document does not define a deterministic algorithm for deriving S-BFD discriminators from VRRP fields.¶
The following figure illustrates the high-level behavior.¶
+---------------------+ +------------------------+
| Backup | | 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 interoperability between the two protocols, this document defines a direct relationship between the VRRP state machine and the S-BFD operating mode.¶
When VRRP is in Primary state, the router MUST initialize an SBFDReflector session using the locally allocated discriminator. When VRRP is in Backup state, the router MUST initialize an SBFDInitiator session using a locally allocated discriminator as My Discriminator and the value advertised by the VRRP Primary Router as Your Discriminator. The destination of the Initiator session is the source IPvX address from which the corresponding VRRP S-BFD Advertisement was received. When VRRP is in Initialize state, no S-BFD session is associated with that Virtual Router instance, including its VRID, VRRP version, address family, and applicable interface, bridge-domain, or VRF context.¶
An implementation that uses this specification is responsible for maintaining the relationship between VRRP and S-BFD. When an inconsistency is detected, it MUST be treated as a critical error.¶
As defined in [RFC7880], S-BFD also has its own state machine. In SBFDInitiator mode, the relevant states are Up and Down. The Down state is entered when a timer expires or when an AdminDown indication is received from the remote Reflector session. In SBFDReflector mode, the session can indicate Up or AdminDown.¶
When VRRP is in Primary state and S-BFD is operating as an SBFDReflector, VRRP MUST drive the associated S-BFD session behavior. When VRRP is in Backup state and S-BFD is operating as an Initiator, S-BFD MUST trigger the SBFD_Handler and VRRP MUST start and monitor the SBFD_Primary_Down_Timer.¶
When VRRP is in Primary state and sends an advertisement with priority 0 in order to relinquish the role, it MUST continue to follow the base VRRP behavior. In that case, the election behavior remains the one defined by the corresponding VRRP version rather than the timer defined in this document.¶
The implementation is responsible for defining how VRRP and S-BFD communicate state changes internally.¶
The implementation is responsible for maintaining the relationship among the S-BFD session, the current VRID, the VRRP version, the address family, the applicable interface, bridge-domain, or VRF context, and the applicable S-BFD operating mode. When VRRP changes state, the implementation MUST destroy the old S-BFD session, initialize the new one as needed, and continue to apply the base VRRP state machine behavior.¶
This relationship is maintained by using the two state variables SBFD_My_Discriminator and SBFD_Your_Discriminator. Their precise behavior depends on the current operating mode.¶
When operating as an Initiator, the learned destination IPvX address of the SBFDReflector need not be retained after the S-BFD session has been initialized.¶
This section clarifies how the relationship and state variables are managed for each VRRP state.¶
To create and maintain the association, VRRP MUST store the state variables in the Virtual Router instance and use them to identify, create, or destroy the corresponding S-BFD session.¶
In this state, the implementation MUST NOT maintain a relationship, and any previous S-BFD sessions MUST be destroyed.¶
VRRP might terminate abnormally and therefore be unable to notify S-BFD. The behavior for handling such inconsistencies is discussed in Section 7.¶
This specification does not define a deterministic algorithm for deriving S-BFD discriminators from the VRID, IP addresses, or other VRRP state. A Router that implements this specification MUST allocate SBFD_My_Discriminator according to local implementation policy and MUST ensure that the selected value is a valid non-zero 32-bit S-BFD discriminator that satisfies the local uniqueness requirements of [RFC7880] and [RFC7881].¶
Similar to the S-BFD discriminator advertisements defined for IS-IS in [RFC7883] and OSPF in [RFC7884], the VRRP packet type defined in this document explicitly carries the SBFDReflector discriminator selected by the VRRP Primary Router.¶
A VRRP S-BFD Advertisement reuses the advertisement format of the applicable VRRP version and appends a 32-bit S-BFD Reflector Discriminator field after the protected IPvX address list. All other fields are identical to the corresponding VRRP Advertisement and are processed according to [RFC9568].¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ VRRP Advertisement fields for the applicable version ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S-BFD Reflector Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
The checksum processing for the corresponding VRRP version MUST cover the S-BFD Reflector Discriminator field.¶
When a Backup Router receives a VRRP S-BFD Advertisement, it MUST copy the advertised S-BFD Reflector Discriminator value into SBFD_Your_Discriminator and use that value as the S-BFD Your Discriminator, as defined in Section 7.2 of [RFC7880].¶
The same VRID can be reused on different interfaces or bridge domains, and overlapping IPv4 or IPv6 addresses can exist in different VRF contexts. Therefore, deriving S-BFD discriminators only from the VRID and IP addressing information is not sufficient to guarantee uniqueness across VRRP deployments. Explicit advertisement avoids this ambiguity and leaves local discriminator allocation to the implementation.¶
A point-to-multipoint BFD solution, such as one based on [RFC8562], can make a different design choice because the Primary Router itself originates BFD Control packets and a Backup Router can demultiplex the received session by using the source IPvX address together with locally defined rules.¶
S-BFD has a different operational model. An SBFDInitiator MUST know the discriminator allocated by the remote SBFDReflector before it can send an S-BFD Control packet with the correct Your Discriminator value, as described in [RFC7880]. Because the same VRID can be reused in different interface, bridge-domain, or VRF contexts, and because overlapping IP addressing is possible, this document does not attempt to infer the remote reflector discriminator from VRRP state alone.¶
For that reason, this specification carries the SBFDReflector discriminator explicitly in the VRRP S-BFD Advertisement. A specification that uses point-to-multipoint BFD instead of S-BFD could avoid that advertisement, but it would define a different failure-detection mechanism.¶
The standard VRRP election procedure uses the advertisement interval as part of its failure-detection behavior and cannot directly provide the behavior required by this specification. To avoid collisions between the two mechanisms, a dedicated timer named SBFD_Primary_Down_Timer MUST be implemented in the VRRP Router. This timer MUST be equal to the Skew_Time for the applicable VRRP version and MUST be started only when an S-BFD Initiator session triggers the VRRP SBFD_Handler because of a Down or AdminDown indication from the Reflector.¶
This section defines the operational requirements of this specification and summarizes how VRRP and S-BFD are integrated.¶
For IPv6 procedures, the Solicited-Node multicast address is the one defined in [RFC4291].¶
+ 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:
>>
>> - Allocate the SBFD_My_Discriminator according to local
>> implementation policy.
>>
>> - Start a new SBFDReflector session with
>> SBFD_My_Discriminator as My Discriminator.
>>
>> - Set the VRRP packet type to 2
>>
>> - Include SBFD_My_Discriminator as the
>> S-BFD Reflector Discriminator field
>>
>> + 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
¶
While in Backup 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:
>>
>> - 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:
>>
>> - Allocate the SBFD_My_Discriminator according to local
>> implementation policy.
>>
>> - Start a new SBFDReflector session with
>> SBFD_My_Discriminator as My Discriminator.
>>
>> - Set the VRRP packet type to 2
>>
>> - Include SBFD_My_Discriminator as the
>> S-BFD Reflector Discriminator field
>>
>> + 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 defined in 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:
>>
>> - Allocate the SBFD_My_Discriminator according to local
>> implementation policy.
>>
>> - Set the SBFD_Your_Discriminator to the
>> S-BFD Reflector Discriminator field carried in the
>> ADVERTISEMENT.
>>
>> - Create or update the 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
¶
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:
>>
>> - Set the VRRP packet type to 2
>>
>> - Include SBFD_My_Discriminator as the
>> S-BFD Reflector Discriminator field
>>
>> + 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
>>
>> - Include SBFD_My_Discriminator as the
>> S-BFD Reflector Discriminator field
>>
>> + 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
>>
>> - Include SBFD_My_Discriminator as the
>> S-BFD Reflector Discriminator field
>>
>> + 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
>>
>> - Include SBFD_My_Discriminator as the
>> S-BFD Reflector Discriminator field
>>
>> + 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 document requests IANA to assign a new VRRP packet type for use with S-BFD-enabled VRRP advertisements.¶
The requested value is 2, with a description of "S-BFD Advertisement". If IANA assigns a different value, implementations of this specification MUST use the IANA-assigned value.¶
This document does not define a new security mechanism. It specifies how VRRP can use S-BFD to accelerate failure detection.¶
Implementations inherit the security considerations of [RFC9568], [RFC5880], [RFC5881], [RFC7880], and [RFC7881]. A false or spoofed S-BFD Advertisement can inject an incorrect reflector discriminator or misdirect monitoring traffic, and a false failure indication can still trigger unnecessary VRRP state transitions. For that reason, operators should apply the same filtering, integrity, and control plane protections recommended for the base protocols.¶
This document was inspired by earlier work on VRRP and BFD, including draft-ietf-rtgwg-vrrp-bfd-p2p-xx and draft-ietf-rtgwg-vrrp-p2mp-bfd-xx.¶
This document uses templates written by Pekka Savola, Elwyn Davies, and Henrik Levkowetz and relies on the open source xml2rfc project.¶
Thanks to the authors of the VRRP specifications for their work on the Primary and Backup election procedure.¶
Thanks to the authors of the BFD specifications for their work on rapid failure detection.¶
Thanks to the authors of the S-BFD specifications for their work on a streamlined BFD mode that can be applied to VRRP.¶
Thanks to G. Mirsky, J. Tantsura, G. Mishra, N. Gupta, A. Dogra, and C. Docherty for their earlier work on VRRP and BFD.¶
Thanks to the open source maintainers of VRRP and BFD implementations for their efforts.¶
Contributions are welcome.¶