Understanding BFD in a VMware NSX Environment with OVSDB and VXLAN
Within a Virtual Extensible LAN (VXLAN) managed by the Open vSwitch Database (OVSDB) protocol, by default, Layer 2 broadcast, unknown unicast, and multicast (BUM) traffic is replicated and forwarded by one or more software virtual tunnel endpoints (VTEPs) or service nodes in the same VXLAN. (In this topic, software VTEPs and service nodes are known collectively as replicators.)
To prevent a Juniper Networks switch that functions as a hardware VTEP in a VMware NSX environment from forwarding BUM packets to a non-functional replicator, starting in Junos OS Release 14.1X53-D40 for QFX5100 switches and 18.1R1 for QFX5110, QFX5200, and QFX5210 switches, these switches can use the Bidirectional Forwarding Detection (BFD) protocol.
By exchanging BFD control messages with replicators at regular intervals, the hardware VTEP can monitor the replicators to ensure that they are functioning and are, therefore, reachable. If the replicator does not respond to three BFD control messages, the BFD status of the replicators is considered to be down. The hardware VTEP does not forward BUM packets to a replicator with a BFD status of down.
To monitor the status of the replicators, the hardware VTEP, NSX controllers, and replicators must all be BFD-capable. In addition, the NSX controller must enable BFD on the hardware VTEP and replicators. When the NSX controller has enabled BFD on the hardware VTEP and replicators, their BFD status is considered to be enabled. If the NSX controller cannot enable BFD on these entities (for example, the entity is not BFD-capable), their BFD status is considered to be disabled.
With the BFD protocol enabled on a hardware VTEP, upon receipt of a BUM packet on an OVSDB-managed interface, the hardware VTEP can choose one of the functioning replicators to handle the packet.
When the hardware VTEP and a replicator exchange BFD control messages, the packets are encapsulated and transported through a VXLAN tunnel. The hardware VTEP and the NSX controller to which it is connected collect Information about this tunnel, such as source and destination IP addresses, the status of the BFD protocol, the status of the tunnel, and so on. The hardware VTEP and NSX controller push their collected information to the tunnel table in the OVSDB schema.
To view the tunnel information collected by the hardware VTEP,
you can use the show ovsdb tunnels command. This command
can help you to determine when there is an issue with the BFD protocol
or a replicator.
The VXLAN packet format for BFD control messages is different from the format used for data packets. Moving from the inner part of the packet to the outer, the differences are as follows:
Addition of UDP port header—UDP port 3784.
Addition of IP header—Source and destination IP addresses of the devices at the end of each tunnel.
Addition of Ethernet header—Source and destination MAC addresses of the devices at the end of each tunnel.
VXLAN—VXLAN network identifier (VNI) of 0.
Figure 1 shows the VXLAN packet format for BFD control messages.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.