Administrator Guide
Propagation of DCB Information
When an auto-upstream or auto-downstream port receives a DCB conguration from a peer, the port acts as a DCBx client and
checks if a DCBx conguration source exists on the switch.
• If a conguration source is found, the received conguration is checked against the currently congured values that are internally
propagated by the conguration source. If the local conguration is compatible with the received conguration, the port is
enabled for DCBx operation and synchronization.
• If the conguration received from the peer is not compatible with the internally propagated conguration used by the
conguration source, the port is disabled as a client for DCBx operation and synchronization and a syslog error message is
generated. The port keeps the peer link up and continues to exchange DCBx packets. If a compatible conguration is later
received from the peer, the port is enabled for DCBx operation.
NOTE: DCB congurations internally propagated from a conguration source do not overwrite the conguration on a
DCBx port in a manual role. When a conguration source is elected, all auto-upstream ports other than the conguration
source are marked as
willing disabled
. The internally propagated DCB conguration is refreshed on all auto-conguration
ports and each port may begin conguration negotiation with a DCBx peer again.
Auto-Detection and Manual Conguration of the DCBx Version
When operating in Auto-Detection mode (the DCBx version auto command), a DCBx port automatically detects the DCBx
version on a peer port. Legacy CIN and CEE versions are supported in addition to the standard IEEE version 2.5 DCBx.
A DCBx port detects a peer version after receiving a valid frame for that version. The local DCBx port recongures to operate with
the peer version and maintains the peer version on the link until one of the following conditions occurs:
• The switch reboots.
• The link is reset (goes down and up).
• User-congured CLI commands require the version negotiation to restart.
• The peer times out.
• Multiple peers are detected on the link.
If you congure a DCBx port to operate with a specic version (the DCBx version {cee | cin | ieee-v2.5} command in
the Conguring DCBx), DCBx operations are performed according to the congured version, including fast and slow transmit timers
and message formats. If a DCBx frame with a dierent version is received, a syslog message is generated and the peer version is
recorded in the peer status table. If the frame cannot be processed, it is discarded and the discard counter is incremented.
NOTE: Because DCBx TLV processing is best eort, it is possible that CIN frames may be processed when DCBx is
congured to operate in CEE mode and vice versa. In this case, the unrecognized TLVs cause the unrecognized TLV
counter to increment, but the frame is processed and is not discarded.
Legacy DCBx (CIN and CEE) supports the DCBx control state machine that is dened to maintain the sequence number and
acknowledge the number sent in the DCBx control TLVs.
DCBx Example
The following gure shows how DCBX is used on an MXL Switch installed in a PowerEdge M1000e chassis in which servers are also
installed.
The external 40GbE ports on the base module (ports 33 and 37) of two switches are used for uplinks congured as DCBx auto-
upstream ports. The MXL switch is connected to third-party, top-of-rack (ToR) switches through 40GbE uplinks. The ToR switches
are part of a Fibre Channel storage network.
The internal ports (ports 1-32) connected to the 10GbE backplane are congured as auto-downstream ports.
On the MXL switch, PFC and ETS use DCBx to exchange link-level conguration with DCBx peer devices.
228
Data Center Bridging (DCB)