Filter
Top Products
A newly elected configuration source propagates configuration changes received from a peer to the
other auto-configuration ports. Ports receiving auto-configuration information from the configuration
source ignore their current settings and use the configuration source information.
Propagation of DCB Information
When an auto-upstream or auto-downstream port receives a DCB configuration from a peer, the port
acts as a DCBx client and checks if a DCBx configuration source exists on the switch.
• If a configuration source is found, the received configuration is checked against the currently
configured values that are internally propagated by the configuration source. If the local configuration
is compatible with the received configuration, the port is enabled for DCBx operation and
synchronization.
• If the configuration received from the peer is not compatible with the internally propagated
configuration used by the configuration 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 configuration is later received from the peer,
the port is enabled for DCBx operation.
NOTE: DCB configurations internally propagated from a configuration source do not overwrite the
configuration on a DCBx port in a manual role. When a configuration source is elected, all auto-
upstream ports other than the configuration source are marked as willing disabled. The internally
propagated DCB configuration is refreshed on all auto-configuration ports and each port may begin
configuration negotiation with a DCBx peer again.
Auto-Detection and Manual Configuration 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
reconfigures 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-configured CLI commands require the version negotiation to restart.
• The peer times out.
• Multiple peers are detected on the link.
If you configure a DCBx port to operate with a specific version (the DCBx version {cee | cin |
ieee-v2.5}
command in the Configuring DCBx), DCBx operations are performed according to the
configured version, including fast and slow transmit timers and message formats. If a DCBx frame with a
different 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 effort, it is possible that CIN frames may be processed
when DCBx is configured 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 defined to maintain the
sequence number and acknowledge the number sent in the DCBx control TLVs.
Data Center Bridging (DCB)
263