BUM Traffic in a VMWare NSX Environment

Each logical_switch created by the OVSDB controller has an associated unknown-dst MAC entry in the Mcast_Macs_Remote table. This entry gives the set of VTEP that handle BUM traffic for this logical_switch. In an NSX controller deployment, these VTEP are from the replication cluster and are called service nodes. Unencapsulated BUM traffic received from the overlay network is encapsulated to VXLAN traffic and sent to only one of these service nodes. The receiving service node then replicates the BUM traffic to other VTEPs in the network.

In order to decide which service node to use for BUM traffic for a logical_switch, ExtremeXOS uses a selection routine to determine which ones are “better”. This routine takes into account the status of the BFD session and the value of cpath_down (for information about the meaning of these fields, see Tunnel Table).

The order of precedence is:

Tunnel is UP and cpath_down is not set.
Tunnel is UP and cpath_down is set.
Tunnel status is unknown (BFD is not enabled or session not currently established).

This selection routine is used at the following events:

New Mcast_Mac_Remote is installed.
A Physical_Locator in the Physical_Locator_Set for the MAC is changed such that the tunnels using that Physical_Locator may be affected.
Tunnel status for Physical_Locator changes (for example, BFD status is updated)
The use of Physical_Locator_Set is rebalanced to ensure efficient distribution of traffic across the Physical_Locators in the Physical_Locator_Set. Rebalancing is done on a Physical_Locator_Set when BFD status changes to UP for a tunnel used to reach a Physical_Locator in that Physical_Locator_Set.

Published March 2020prev | next

Email this topic

Print this page Print this page

Leave feedback Feedback