RFC 8971

Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN)

📅 published December 2020, from ietf

RFC 8971: Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN) 🎀

Category: Informational 📚 Date: December 2020 🗓️ ISSN: 2070-1721 ✨ Authors: S. Pallagatti, Ed. (VMware), G. Mirsky, Ed. (ZTE Corp.), S. Paragiri (Individual Contributor), V. Govindan (Cisco), and M. Mudigonda (Cisco) 🫶 Obsoletes and updates: the title block doesn't list anything this one obsoletes or updates 💅

Abstract

okay so this doc explains how to use BFD (Bidirectional Forwarding Detection) on point-to-point VXLAN tunnels that build an overlay network. it's giving "checking the path is still alive" energy 🦋

Status of This Memo

this one is not an Internet Standards Track spec. it's published for informational purposes, so it's more of a "here's the vibe, read it" situation 🌸

it's a product of the IETF (Internet Engineering Task Force) and represents the consensus of the IETF community. it got public review and was approved for publication by the IESG (Internet Engineering Steering Group). not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for the deets 👑

info about the current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8971 🧚

Copyright (c) 2020 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) as they stand on the publication date. please read these carefully, bestie, because they spell out your rights and restrictions for this doc. 📜 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⚠️

Table of Contents

1.  Introduction
2.  Conventions Used in This Document
  2.1.  Abbreviations
  2.2.  Requirements Language
3.  Deployment
4.  Use of the Management VNI
5.  BFD Packet Transmission over VXLAN Tunnel
6.  Reception of BFD Packet from VXLAN Tunnel
7.  Echo BFD
8.  IANA Considerations
9.  Security Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgments
Contributors
Authors' Addresses

1. Introduction ✨

so "Virtual eXtensible Local Area Network (VXLAN)" [RFC7348] is an encapsulation scheme that lets you build an overlay network by decoupling the address space of the attached virtual hosts from the address space of the network. it's main character energy 💖

one big use of VXLAN is in data centers, connecting the virtual machines (VMs) of a tenant. it handles the Layer 2 and Layer 3 data-center network needs when you've got VMs in a multi-tenant environment, by giving you a Layer 2 overlay scheme on top of a Layer 3 network [RFC7348]. another use is as an encapsulation for Ethernet VPN [RFC8365] 🌈

this doc is written with virtualized hosts in mind, so it talks about VMs and VXLAN Tunnel End Points (VTEPs) in hypervisors. but the concepts work just as well for non-virtualized hosts plugged into VTEPs in switches, so don't sleep on that 🍓

without a router in the overlay, a VM can only talk to another VM if they're on the same VXLAN segment. VMs don't know about VXLAN tunnels at all, because the tunnel ends on a VTEP. VTEPs handle the encapsulating and decapsulating of frames exchanged among VMs. they're the unsung heroes 🫶

being able to monitor path continuity is a big deal. that means proactive continuity check (CC) for point-to-point (p2p) VXLAN tunnels 🔥 the asynchronous mode of BFD, as defined in [RFC5880], is what gets used to monitor a p2p VXLAN tunnel.

if a Multicast Service Node (MSN) (as described in Section 3.3 of [RFC8293]) takes part in VXLAN, the mechanisms in this doc still apply. so they can be used to test the continuity of the path between the source Network Virtualization Endpoint (NVE) and the MSN 🦋

this doc describes how to use BFD to monitor path continuity between VXLAN VTEPs that act as NVEs, and/or between the source NVE and a replicator MSN, using a Management VXLAN Network Identifier (VNI) (Section 4). every other use of this spec to test toward other VXLAN endpoints is out of scope 🙈

2. Conventions Used in This Document ✨

2.1. Abbreviations

BFD:     Bidirectional Forwarding Detection

CC:      Continuity Check

FCS:     Frame Check Sequence

MSN:     Multicast Service Node

NVE:     Network Virtualization Endpoint

p2p:     Point-to-point

VFI:     Virtual Forwarding Instance

VM:      Virtual Machine

VNI:     VXLAN Network Identifier (or VXLAN Segment ID)

VTEP:    VXLAN Tunnel End Point

VXLAN:   Virtual eXtensible Local Area Network

2.2. Requirements Language

ok this part is important, so listen up 👑 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. so if you see them in lowercase, they're just normal words, no cap 💅

3. Deployment ✨

Figure 1 is a scenario with two servers, each hosting two VMs. the servers host VTEPs that terminate two VXLAN tunnels, with VNI numbers 100 and 200. separate BFD sessions can be set up between the VTEPs (IP1 and IP2) to monitor each VXLAN tunnel (VNI 100 and 200). using one BFD session to monitor a set of VXLAN VNIs between the same pair of VTEPs might help detect and localize problems caused by misconfiguration 🔍

an implementation that supports this specification MUST be able to control the number of BFD sessions that can be created between the same pair of VTEPs. this method works whether the VTEP is a virtual or physical device 🌸

      +------------+-------------+
      |        Server 1          |
      | +----+----+  +----+----+ |
      | |VM1-1    |  |VM1-2    | |
      | |VNI 100  |  |VNI 200  | |
      | |         |  |         | |
      | +---------+  +---------+ |
      |        VTEP (IP1)        |
      +--------------------------+
                            |
                            |   +-------------+
                            |   |   Layer 3   |
                            +---|   Network   |
                                +-------------+
                                    |
                                    +-----------+
                                                |
                                         +------------+-------------+
                                         |         VTEP (IP2)       |
                                         | +----+----+  +----+----+ |
                                         | |VM2-1    |  |VM2-2    | |
                                         | |VNI 100  |  |VNI 200  | |
                                         | |         |  |         | |
                                         | +---------+  +---------+ |
                                         |      Server 2            |
                                         +--------------------------+


                      Figure 1: Reference VXLAN Domain

at the same time, a service-layer BFD session can be used between the tenants of VTEPs IP1 and IP2 for end-to-end fault management. that use case is outside the scope of this doc. in that case, for VTEPs, the BFD Control packets of that session look exactly like data packets 🙃

for BFD Control packets encapsulated in VXLAN (Figure 2), the inner destination IP address SHOULD be set to one of the loopback addresses from the 127/8 range for IPv4, or to one of the IPv4-mapped IPv6 loopback addresses from the ::ffff:127.0.0.0/104 range for IPv6 🧚

4. Use of the Management VNI ✨

in most cases, one BFD session is enough for a given VTEP to monitor the reachability of a remote VTEP, no matter how many VNIs there are 💜 BFD control messages MUST be sent using the Management VNI, which acts as the control and management channel between VTEPs. an implementation MAY support running BFD on another (non-Management) VNI, though the implications of that are outside the scope of this doc 🦋

the selection of the VNI number for the Management VNI MUST be controlled through a management plane. an implementation MAY use VNI number 1 as the default value for the Management VNI. all VXLAN packets received on the Management VNI MUST be processed locally, and they MUST NOT be forwarded to a tenant. that's the Management VNI keeping its own lane, periodt 💅🌈

5. BFD Packet Transmission over VXLAN Tunnel ✨

okay bestie, this is where the BFD packets actually get dressed up and shipped off to the remote VTEP 🚀💖 Every BFD packet MUST be encapsulated and sent this way, and implementations SHOULD make sure the BFD packets take the same forwarding path as the VXLAN data packets inside the sender system 🦋

So BFD packets get wrapped in VXLAN, and the VXLAN packet format is defined in Section 5 of [RFC7348] 🎀 The VNI field in the VXLAN header MUST be set to whatever value was picked as the Management VNI 🌸 The outer IP/UDP and VXLAN headers MUST be encoded by the sender, as defined in [RFC7348] 💅

Here's the whole stack, layer by layer (it's giving onion, fr fr 🧅):

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                      Outer Ethernet Header                    ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                        Outer IPvX Header                      ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                        Outer UDP Header                       ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                           VXLAN Header                        ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                    Inner Ethernet Header                      ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                        Inner IPvX Header                      ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                         Inner UDP Header                      ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       BFD Control Packet                     ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Outer Ethernet FCS                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: VXLAN Encapsulation of BFD Control Packet 🖼️

The BFD packet MUST be carried inside the inner Ethernet frame of the VXLAN packet 🎁 And the destination MAC and destination IP addresses picked for that inner frame MUST make sure the BFD Control packet is not forwarded to a tenant, and is processed locally at the remote VTEP 🙅‍♀️👀 Here's what the inner Ethernet frame carrying the BFD Control packet looks like:

Ethernet Header:

  • Destination MAC: A Management VNI, which does not have any tenants, will have no dedicated MAC address for decapsulated traffic. The value 00-52-02 SHOULD be used in this field. 🧚
  • Source MAC: MAC address associated with the originating VTEP. 🌈
  • Ethertype: This is set to 0x0800 if the inner IP header is IPv4 and set to 0x86DD if the inner IP header is IPv6. 💜

IP header:

  • Destination IP: This IP address MUST NOT be of one of tenant's IP addresses. The IP address SHOULD be selected from the range 127/8 for IPv4 and from the range ::ffff:127.0.0.0/104 for IPv6. Alternatively, the destination IP address MAY be set to VTEP's IP address. 🌸
  • Source IP: IP address of the originating VTEP. 🫶
  • TTL or Hop Limit: MUST be set to 255, in accordance with [RFC5881]. 🔥

The destination UDP port is set to 3784, and the fields of the BFD Control packet are encoded as specified in [RFC5881] 🦋✨

6. Reception of BFD Packet from VXLAN Tunnel 📥

once a packet shows up, the VTEP MUST validate it 🔍 If the packet came in on the Management VNI and it's identified as a BFD Control packet addressed to the VTEP, then it can be processed further 💅 BFD Control packets received on a non-Management VNI are outside the scope of this specification, so that's not our problem here 🙈

Then the received packet's inner IP payload gets validated according to Sections 4 and 5 in [RFC5881] 🎀

7. Echo BFD 🪞

Support for echo BFD is outside the scope of this document. 🙅‍♀️ Not doing it here, periodt 💀

8. IANA Considerations 🗂️

IANA has assigned a single MAC address of the value 00-52-02 from the "Unassigned (small allocations)" block of the "IANA Unicast 48-bit MAC Addresses" registry 💖 The "Usage" field is "BFD for VXLAN", and the "Reference" is this document 🌷

9. Security Considerations 🔐

Okay, this section is serious, so no cap, read every word 😭🚨 Security issues discussed in [RFC5880], [RFC5881], and [RFC7348] apply to this document 🛡️

This document recommends using an address from the internal host loopback addresses 127/8 range for IPv4, or an IP4-mapped IPv6 loopback address from the ::ffff:127.0.0.0/104 range for IPv6, as the destination IP address in the inner IP header 🧿 Using such an address prevents the forwarding of the encapsulated BFD control message by a transient node, in case the VXLAN tunnel is broken, in accordance with [RFC1812] ⭐ Here's what [RFC1812] says about it:

A router SHOULD NOT forward, except over a loopback interface, any packet that has a destination address on network 127. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks.

The use of IPv4-mapped IPv6 addresses has the same property as using the IPv4 network 127/8 🌈 Moreover, the IPv4-mapped IPv6 addresses' prefix is not advertised in any routing protocol 🫧

If the implementation supports establishing multiple BFD sessions between the same pair of VTEPs, there SHOULD be a mechanism to control the maximum number of such sessions that can be active at the same time 🚦 Set a limit, bestie 💅

10. References 📚

10.1. Normative References

10.2. Informative References

Acknowledgments 🫶

The authors would like to thank Jeff Haas of Juniper Networks for his reviews and feedback on this material 💜

The authors would also like to thank Nobo Akiya, Marc Binderberger, Shahram Davari, Donald E. Eastlake 3rd, Anoop Ghanwani, Dinesh Dutt, Joel Halpern, and Carlos Pignataro for the extensive reviews and the most detailed and constructive comments 👑

Contributors 🌸

Reshad Rahman Cisco

Email: rrahman@cisco.com

Authors' Addresses 🦋

Santosh Pallagatti (editor) VMware

Email: santosh.pallagatti@gmail.com

Greg Mirsky (editor) ZTE Corp.

Email: gregimirsky@gmail.com

Sudarsan Paragiri Individual Contributor

Email: sudarsan.225@gmail.com

Vengada Prasad Govindan Cisco

Email: venggovi@cisco.com

Mallik Mudigonda Cisco

Email: mmudigon@cisco.com

📦 where this page comes from