Supported Platforms
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 (DCB) network. It is an extension of Link Layer Discovery Protocol (LLDP). DCB devices use DCBX to exchange configuration information with directly connected peers (switches and data center devices such as servers).
On Juniper Networks EX Series Ethernet Switches, you can use DCBX to:
- Discover the DCB capabilities of peers
- Detect DCB 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 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. Due to 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 EX4500 switches only (See EX4500 Switch Models for a list of CEE-capable models.)
- 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 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 must 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, you must 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 Supported in DCBX on the Switches
DCBX on the switches does not support:
- Enhanced transmission selection (ETS) (IEEE 802.1Qaz)—Two-tier hierarchical scheduling that defines the CoS properties for each priority group and for each priority
- 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.
