Understanding Data Center Bridging Capability Exchange Protocol for EX Series Switches
Data Center Bridging Capability Exchange protocol (DCBX) is a discovery and exchange protocol for communicating configuration and capabilities among neighbors to ensure consistent configuration across the data center bridging network. It is an extension of Link Layer Discovery Protocol (LLDP). If you attempt to enable DCBX on an interface on which LLDP is disabled, the configuration commit fails. Data center bridging devices use DCBX to exchange configuration information with directly connected peers (devices such as switches and servers in a data center bridging network).
This topic applies only to DCBX on EX Series switches that do not support the Enhanced Layer 2 Software (ELS) configuration style. EX4500 and EX4550 switches are the only non-ELS EX Series switches that support DCBX.
DCBX support on ELS EX Series switches and QFX Series switches is described in Understanding DCBX.
You can use DCBX to:
Discover the data center bridging capabilities of peers
Detect data center bridging feature misconfiguration or mismatches between peers
Automatically enable or disable priority-based flow control (PFC) on an interface depending on whether the PFC configuration of the local interface is the same as the PFC configuration of the DCB peer
This topic describes:
Basic DCBX Functioning
DCBX features support PFC, the Fibre Channel over Ethernet (FCoE) application, and other Layer 2 or Layer 4 applications (such as iSCSI). DCBX is enabled or disabled on a per-interface basis. The default autonegotiation behavior is: DCBX is enabled if the peer device connected to the interface also supports DCBX.
If the peer device connected to the interface does not support
DCBX, DCBX remains enabled on the switch, but the switch detects that
DCBX is not enabled on the peer and reports a misconfiguration for
that interface when you issue the show dcbx neighbors
command.
During negotiation of capabilities, the switch pushes the PFC configuration to an attached peer if the peer is configured as willing to learn the PFC configuration from other peers. The switch does not support autoprovisioning and does not change its own configuration during autonegotiation to match the peer configuration—that is, the switch is not willing to learn the PFC configuration from peers.
DCBX and PFC
After you enable PFC on a switch interface, DCBX uses autonegotiation to control the operational state of PFC functionality.
DCB devices must use the same traffic class (code point) on both the local and peer device. If the peer device connected to the interface supports PFC and is provisioned for the same traffic class as the switch interface, DCBX sets the PFC operational state to enabled. If the peer device connected to the interface does not support PFC or is not provisioned for the same traffic class, DCBX sets the operational state to disabled.
If the peer advertises that it is willing to learn its PFC configuration from the switch, DCBX pushes the switch’s PFC configuration to the peer and does not check the peer’s administrative state.
You can manually override DCBX control of the PFC operational state on a per-interface basis by disabling autonegotiation. If you disable autonegotiation on an interface on which you have configured PFC, then PFC remains enabled on that interface regardless of the peer configuration. To disable PFC on an interface, delete any PFC configuration on the interface.
DCBX and FCoE
DCBX is mandatory for running FCoE applications, because FCoE traffic requires PFC to ensure lossless transport and PFC is a component of DCBX.
The FCoE application is configured by default on DCBX interfaces. Because of the FCoE requirement for lossless transport, we recommend that you configure the interfaces that carry FCoE traffic for PFC. See Configuring Priority-Based Flow Control for an EX Series Switch (CLI Procedure).
DCBX advertisement of the FCoE application functions as follows:
If you configure the
fcoe
forwarding class and PFC congestion notification profile and assign these components to the interfaces that carry FCoE traffic, DCBX advertises their FCoE capability and assigned 802.1p code points to the DCB peer, and DCBX reports the FCoE capability and assigned 802.1p code points of the DCB peer to the switch.
DCBX and iSCSI
DCBX is not essential for iSCSI applications. These applications provide a method for linking data storage facilities over IP networks. Unlike Fibre Channel (FC) communications, which require special-purpose cabling, iSCSI can be run over long distances by using existing network infrastructure.
You might want to use iSCSI over DCB to reduce latency in a network that is oversubscribed. You might also want to use it to provide predictable and certain application responsiveness, eliminating Ethernet’s dependence on TCP/IP for the retransmission of dropped Ethernet frames.
DCBX advertises switch interfaces that are configured to support the iSCSI application, their PFC capability, and their assigned 802.1p code points.
How DCBX Is Implemented on the Switches
On the switches, the implementation of DCBX is:
Supported on aggregated Ethernet interfaces composed of 10-Gigabit Ethernet interfaces
Enabled by default on all 10-Gigabit Ethernet interfaces
On the switches, DCBX supports the application type-length-value (TLV) — thus, DCBX interfaces on the switch can exchange information with their DCB peers about application capability, PFC capability, and 802.1p code-point settings. This implementation includes the following:
The FCoE application is enabled by default on DCBX interfaces on the switch. Therefore, you do not configure an application map for the default FCoE application.
The switches do not have a default FCoE forwarding class—therefore, you must explicitly configure a forwarding class with the name
fcoe
and associate that class with the interfaces carrying FCoE traffic. If PFC is enabled, the 802.1p code points are assigned, and the interfaces are associated with a forwarding class, the switch negotiates FCoE application capability on the DCBX interface.Do not explicitly configure an FCoE application map, because that generates a commit error.
You can configure additional Layer 2 or Layer 4 applications to be supported by the DCBX application TLV feature. To do this, explicitly configure an application map and associate the application map with one of the DCBX interfaces. DCBX then advertises the application capabilities of the associated interface and checks the capabilities of the connected peer device.
If the peer device connected to the local interface does not support PFC or the peer’s PFC configuration is not the same as the local interface’s PFC configuration, DCBX automatically disables PFC for the local interface.
Note:You can manually override DCBX control of the PFC operational state on a per-interface basis. See Disabling DCBX to Disable PFC Autonegotiation on EX Series Switches (CLI Procedure).
Features That Are Not Fully Supported by DCBX on EX Series Switches
The implementation of DCBX on EX Series switches does not fully support the following features:
Enhanced transmission selection (ETS) (IEEE 802.1Qaz)—ETS is a bandwidth management mechanism to support dynamic allocation of bandwidth for DCBX traffic classes.
EX Series switches do not support using ETS to dynamically allocate bandwidth to specified traffic classes. Instead, the switches handle all DCBX traffic as a single default traffic class, group 7.
However, the switches do support the ETS Recommendation TLV. The ETS Recommendation TLV communicates the ETS settings that the switch wants the connected DCBX peer interface to use.
If the peer interface is willing, it changes its configuration to match the configuration in the ETS Recommendation TLV sent by the switch (group 7).
The switch also advertises that it is not willing to change its ETS settings.
The advertisement of ETS TLV is enabled by default for DCBX interfaces. If you want, you can disable this advertisement. See Disabling the ETS Recommendation TLV.
A default FCoE forwarding class—The switch does not have a default FCoE forwarding class with default mapping to a priority queue for FCoE traffic.
Note:Because the switches do not support a default FCoE forwarding class, you must explicitly configure a forwarding class and name it
fcoe
.