Concept Guide

Propagation of DCB Information
When an auto-upstream or auto-downstream port receives a DCB conguration from a peer, the port acts as a DCBx client and checks if a
DCBx conguration source exists on the switch.
• If a conguration source is found, the received conguration is checked against the currently congured values that are internally
propagated by the conguration source. If the local conguration is compatible with the received conguration, the port is enabled for
DCBx operation and synchronization.
• If the conguration received from the peer is not compatible with the internally propagated conguration used by the conguration
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 conguration is later received from the peer, the port is
enabled for DCBx operation.
NOTE: DCB congurations internally propagated from a conguration source do not overwrite the conguration on a DCBx port
in a manual role. When a conguration source is elected, all auto-upstream ports other than the conguration source are marked
as willing disabled . The internally propagated DCB conguration is refreshed on all auto-conguration ports and each port may
begin conguration negotiation with a DCBx peer again.
Auto-Detection and Manual Conguration 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 recongures 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-congured CLI commands require the version negotiation to restart.
• The peer times out.
• Multiple peers are detected on the link.
If you congure a DCBx port to operate with a specic version (the DCBx version {cee | cin | ieee-v2.5} command in the
Conguring DCBx), DCBx operations are performed according to the congured version, including fast and slow transmit timers and
message formats. If a DCBx frame with a dierent 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 eort, it is possible that CIN frames may be processed when DCBx is congured 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 dened 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 FN IOM 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 congured as DCBx auto-upstream
ports. The FN IOM 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 congured as auto-downstream ports.
On the FN IOM switch, PFC and ETS use DCBx to exchange link-level conguration with DCBx peer devices.
FC Flex IO Modules
1021