Reference Guide

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.
Behavior of Tagged Packets
The below is example for enabling PFC for priority 2 for tagged packets. Priority (Packet Dot1p) 2 will be mapped to PG6 on
PRIO2PG setting. All other Priorities for which PFC is not enabled are mapped to default PG – PG7.
Classification rules on ingress (Ingress FP CAM region) matches incoming packet-dot1p and assigns an internal priority (to
select queue as per Table 1 and Table 2).
The internal Priority assigned for the packet by Ingress FP is used by the memory management unit (MMU) to assign the packet
to right queue by indexing the internal-priority to queue map table (TABLE 1) in hardware.
PRIO2COS setting for honoring the PFC protocol packets from the Peer switches is as per above Packet-Dot1p->queue table
(Table 2).
The packets that come in with packet-dot1p 2 alone will be assigned to PG6 on ingress.
The packets that come in with packet-dot1p 2 alone will use Q1 (as per dot1p to Queue classification – Table 2) on the egress
port.
● When Peer sends a PFC message for Priority 2, based on above PRIO2COS table (TABLE 2), Queue 1 is halted.
● Queue 1 starts buffering the packets with Dot1p 2. This causes PG6 buffer counter to increase on the ingress, since P-dot1p
2 is mapped to PG6.
● As the PG6 watermark threshold is reached, PFC will be generated for dot1p 2.
Configuration Example for DSCP and PFC Priorities
Consider a scenario in which the following DSCP and PFC priorities are necessary:
DSCP
0 – 5, 10 - 15 20 – 25, 30 – 35
Data Center Bridging (DCB) 219