One document matched: draft-nitish-vrrp-bfd-02.xml
<?xml version="1.0"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="std" docName="draft-nitish-vrrp-bfd-02"
ipr="trust200902">
<front>
<title abbrev="VRRP BFD">Fast failure detection in VRRP with BFD</title>
<author initials="N" surname="Gupta" fullname="Nitish Gupta">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Sarjapur Outer Ring Road</street>
<city>Bangalore</city>
<code>560103</code>
<country>India</country>
</postal>
<phone>+91 80 4429 2530</phone>
<email>nitisgup@cisco.com</email>
<uri>http://www.cisco.com/</uri>
</address>
</author>
<author initials="A" surname="Dogra" fullname="Aditya Dogra">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Sarjapur Outer Ring Road</street>
<city>Bangalore</city>
<code>560103</code>
<country>India</country>
</postal>
<phone>+91 80 4429 2166</phone>
<email>addogra@cisco.com</email>
<uri>http://www.cisco.com/</uri>
</address>
</author>
<author initials="C" surname="Docherty" fullname="Colin Docherty">
<address>
<postal>
<street>25 George Grieve Way</street>
<street>Tranent</street>
<city>East Lothian</city>
<region>Scotland</region>
<code>EH332QT</code>
<country>United Kingdom</country>
</postal>
<email>colin@doch.org.uk</email>
</address>
</author>
<author initials="G." surname="Mirsky" fullname="Greg Mirsky">
<organization>Ericsson</organization>
<address>
<email>gregory.mirsky@ericsson.com</email>
</address>
</author>
<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
<organization>Ericsson</organization>
<address>
<email>jeff.tantsura@ericsson.com</email>
</address>
</author>
<date month="October" year="2015" />
<area>General</area>
<keyword>RFC</keyword>
<keyword>VRRP</keyword>
<keyword>BFD</keyword>
<keyword>Peer learning</keyword>
<abstract>
<t>
This document describes how Bidirectional Forwarding Detection (BFD) can be used to support sub-second detection of a Master Router failure in the Virtual Router Redundancy Protocol (VRRP).
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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 Master is critical in supporting high availability of services and improved Quality of Experience to users.
In VRRP <xref target="RFC5798"></xref> specification, Backup routers depend on VRRP 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 Advertisement Interval and hold down timers. However, aggressive timers can put extra load on CPU and the network bandwidth which may not be desirable.
</t>
<t>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 <xref target="RFC5881"></xref> or [I-D.draft-ietf-bfd-multipoint] to achieve a much faster failure detection of the VRRP Master on the LAN. BFD, as specified by the <xref target="RFC5880"></xref> or [I-D.draft-ietf-bfd-multipoint] 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 aggressive timers are used.
</t>
</section>
<section title="Requirements Language" anchor="reqlang">
<t>
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.
<xref target="RFC2119"/>
</t>
</section>
<section title="Applicability of Single-hop BFD">
<t>BFD for IPv4 or IPv6 (Single Hop) <xref target="RFC5881"></xref> requires that in order 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 protocol, that makes the use of BFD for IPv4 or IPv6 <xref target="RFC5881"></xref> more challenging. In VRRP it is only the Master router that sends Advert packets. This means that a Master router is not aware of any Backup routers, and Backup routers are only aware of the Master router. This also means that a Backup router is not aware of any other Backup routers in the Network.
</t>
<t>Since BFD for IPv4 or IPv6 <xref target="RFC5881"></xref> 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 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 Master Down event. A Master Down event means that the highest priority Backup peer will immediately become the new Master for the Virtual Router.</t> <t>NOTE: At all times, the normal fail-over mechanism defined in the VRRP <xref target="RFC5798"></xref> will be unaffected, and the BFD fail-over mechanism will always resort to normal VRRP fail-over.
</t>
<t>This draft defines the mechanism used by the 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 router. This requires an extension to the VRRP protocol.
</t>
<t>
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.
</t>
<section title="Extension to VRRP protocol">
<t>
In this mode of operation VRRP peers learn the adjacent routers, and form BFD sessions between the learnt routers. In order to build the peer table, all routers send VRRP Advert packets whilst in any of the operational states (Master or Backup). Normally VRRP 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 <xref target="format"></xref> of this document. The VRRP Master 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.</t>
<t>
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.</t>
</section>
<section title="VRRP Peer Table">
<t>
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.
</t>
<t>
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).
</t>
</section>
<section anchor="format" title="VRRP BACKUP ADVERTISEMENT Packet Type">
<figure>
<preamble>The following figure shows the VRRP packet as defined in VRRP <xref target="RFC5798"></xref> RFC.</preamble>
<artwork><![CDATA[
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) |
+ +
+ +
+ +
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure>
<preamble>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.</preamble>
<artwork><![CDATA[
1 ADVERTISEMENT
2 BACKUP ADVERTISEMENT
]]></artwork>
<postamble>A packet with unknown type MUST be discarded.</postamble>
</figure>
</section>
<section title="Sample configuration">
<figure>
<preamble>The following figure shows a simple network with three VRRP routers implementing one virtual router.</preamble>
<artwork><![CDATA[
+-----------+ +-----------+ +-----------+
| 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
]]></artwork>
</figure>
<t>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 Master 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:</t>
<figure>
<preamble>Rtr1 Peer table</preamble>
<artwork><![CDATA[
+------------------------------------+
| Peer Address | Priority |
+------------------------------------+
| C | 150 |
+------------------------------------+
| D | 100 |
+------------------------------------+
]]></artwork>
</figure>
<figure>
<preamble>Rtr2 Peer table</preamble>
<artwork><![CDATA[
+------------------------------------+
| Peer Address | Priority |
+------------------------------------+
| B | 200 |
+------------------------------------+
| D | 100 |
+------------------------------------+
]]></artwork>
</figure>
<figure>
<preamble>Rtr3 Peer table</preamble>
<artwork><![CDATA[
+------------------------------------+
| Peer Address | Priority |
+------------------------------------+
| B | 200 |
+------------------------------------+
| C | 150 |
+------------------------------------+
]]></artwork>
</figure>
<t>Once the peer tables are formed, VRRP on each router can form a mesh of BFD sessions with all the learnt peers.</t>
</section>
<section title="Critical BFD session">
<t>The 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.
</t>
<t>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.
</t>
</section>
</section>
<section anchor="p2mp" title="Applicability of p2mp BFD">
<t>
<xref target="I-D.draft-ietf-bfd-multipoint"/>
provides an alternative solution that uses default route rather than dynamic routing. This approach can be an efficient in some network deployments. Each redundancy group presents itself as p2mp BFD session with its Master being the root and Backup routers being tails of the p2mp BFD session. The Master router starts transmitting BFD control packets with VRID as source IP address. Backup router demultiplexes p2mp BFD test sessions based on VRID that it been configured with. Once Backup router accepts p2mp session from the new Master router backup router the Backup router MAY use My Discriminator from received p2mp BFD control packet to demultiplex p2mp BFD sessions. When a Backup router detects failure of the Master router it re-evaluates its role in the VRID. As result, the Backup router may become the Master router of the given VRID or continue as a Backup router. If the former is the case, then the new Master router MUST select My Discriminator and start transmitting p2mp BFD control packets using Master IP address as source IP address for p2mp BFD control packets. If the latter is the case, then the Backup router MUST wait for p2mp BFD control packet with source IP address set to VRID.
</t>
</section>
<section title="Scalability Considerations">
<t>
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 of the VRRP instance.
</t>
<t>
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.
</t>
<t>
In a Data Centre with VXLAN extending the Layer 2 network, when implementing <xref target="p2mp"></xref> of this document, inherently multicast traffic is flooded or replicated to all the Virtual Tunneling End Points by means of multicast traffic in the underlay network. The amount of replication or flooding depends on the number of Virtual Tunnelling End Points connected to the VXLAN network. VRRP is typically deployed on the Virtual Tunneling End Points. If Multipoint BFD is used for tracking the state of VRRP Master Router the Multipoint BFD packets will get carried over the Layer 2 Overlay, this can lead to a lot of traffic getting flooded on the overlay as the rate at which BFD packets are generated will be typically in sub second range. Which is the problem if VRRP is configured with sub second timers. So in such scenarios where flooding of Multicast traffic is a concern, it is recommended to use Point to Point BFD sessions to avoid inherent flooding of Multicast traffic and configure VRRP to default or slow timers.
</t>
</section>
<section title="Operational Considerations">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="IANA Considerations">
<t>This draft includes no request to IANA.</t>
</section>
<section title="Security Considerations">
<t>
Security considerations discussed in <xref target="RFC5798"></xref>, <xref target="RFC5880"></xref> and <xref target="I-D.draft-ietf-bfd-multipoint"/>, apply to this document. There are no additional security considerations identified by this draft. </t>
</section>
<section title="Acknowledgements">
<t>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 and Vengada Prasad Govindan for their comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC5880">
<front>
<title>Bidirectional Forwarding Detection (BFD)</title>
<author initials="D." surname="Katz" fullname="Dave Katz">
<organization>Juniper Networks</organization>
</author>
<author initials="D." surname="Ward" fullname="Dave Ward">
<organization>Juniper Network</organization>
</author>
<date year="2010" />
<area>BFD Working Group</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>This document describes a protocol intended to detect faults in the
bidirectional path between two forwarding engines, including
interfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<seriesInfo name="RFC" value="5880" />
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date year="1997" />
<area>Network Working Group</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>This document describes a protocol intended to detect faults in the
bidirectional path between two forwarding engines, including
interfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="RFC5881">
<front>
<title>Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)</title>
<author initials="D." surname="Katz" fullname="Dave Katz">
<organization>Juniper Networks</organization>
</author>
<author initials="D." surname="Ward" fullname="Dave Ward">
<organization>Juniper Network</organization>
</author>
<date year="2010" />
<area>BFD Working Group</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t> This document describes the use of the Bidirectional Forwarding
Detection (BFD) protocol over IPv4 and IPv6 for single IP hops.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<seriesInfo name="RFC" value="5881" />
</reference>
<reference anchor="RFC5798">
<front>
<title>Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6</title>
<author initials="S." surname="Nadas" fullname="Stephen Nadas">
<organization>Ericsson</organization>
</author>
<date year="2010" />
<area>VRRP Working Group</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>
This memo defines the Virtual Router Redundancy Protocol (VRRP) for
IPv4 and IPv6. It is version three (3) of the protocol, and it is
based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in
"Virtual Router Redundancy Protocol for IPv6". VRRP specifies an
election protocol that dynamically assigns responsibility for a
virtual router to one of the VRRP routers on a LAN. The VRRP router
controlling the IPv4 or IPv6 address(es) associated with a virtual
router is called the Master, and it forwards packets sent to these
IPv4 or IPv6 addresses. VRRP Master routers are configured with
virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the
address family of the virtual addresses being carried based on the
transport protocol. Within a VRRP router, the virtual routers in
each of the IPv4 and IPv6 address families are a domain unto
themselves and do not overlap. The election process provides dynamic
failover in the forwarding responsibility should the Master become
unavailable. For IPv4, the advantage gained from using VRRP is a
higher-availability default path without requiring configuration of
dynamic routing or router discovery protocols on every end-host. For
IPv6, the advantage gained from using VRRP for IPv6 is a quicker
switchover to Backup routers than can be obtained with standard IPv6
Neighbor Discovery mechanisms.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<seriesInfo name="RFC" value="5798" />
</reference>
<reference anchor="I-D.draft-ietf-bfd-multipoint">
<front>
<title>BFD for Multipoint Networks</title>
<author initials="D." surname="Katz" fullname="Dave Katz">
<organization>Juniper Networks</organization>
</author>
<author initials="D." surname="Ward" fullname="Dave Ward">
<organization>Cisco System</organization>
</author>
<author initials="S." surname="Pallagatti" fullname="Santosh Pallagatti (editor)">
<organization>Cisco System</organization>
</author>
<date year="2015" />
<area>BFD Working Group</area>
<workgroup>Internet Engineering Task Force</workgroup>
<abstract>
<t>This document describes extensions to the Bidirectional Forwarding
Detection (BFD) protocol for its use in multipoint and multicast
networks. Comments on this draft should be directed to rtg-
bfd@ietf.org.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<seriesInfo name="Work in Progress" value="draft-ietf-bfd-multipoint-07" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:23 |