Glossary

DCBX

Data Center Bridging Exchange

What is DCBX

DCBX (Data Center Bridging Exchange) is a link-layer protocol, based on IEEE 802.1Qaz, purpose-built to keep Data Center Bridging (DCB) configuration consistent across the two ends of a link. It works by extending LLDP with dedicated fields for exchanging DCB configuration, ensuring that settings like flow control and Quality of Service (QoS) stay aligned between neighboring devices.

DCBX exists to solve a specific automation problem in converged data center networks. Lossless Ethernet — the foundation for storage and RDMA-style traffic sharing a fabric with ordinary Ethernet traffic — depends on PFC (Priority-based Flow Control) and ETS (Enhanced Transmission Selection) parameters matching exactly on both ends of every link. Configuring this by hand, port by port, across a large fabric is both labor-intensive and highly error-prone: a single mismatched parameter can silently break lossless behavior on that link. DCBX removes this burden by having neighboring devices automatically discover and exchange their DCB configuration, cutting operator workload and reducing the chance of the kind of configuration mismatch that leads to network outages.

How DCBX Works

DCBX operates as an extension of LLDP: DCB information is carried inside a dedicated LLDP TLV, identified by a fixed Type value of 127 and an OUI of 0x0080C2 (the IEEE-assigned organizationally unique identifier). Within that structure, DCBX defines four specific TLVs:

  • ETS Configuration TLV: the local ETS configuration — priority queue IDs and their bandwidth allocation.

  • ETS Recommendation TLV: a recommended ETS configuration, using the same priority queue ID and bandwidth structure.

  • PFC Configuration TLV: the local PFC configuration — how many queues support PFC, and whether PFC is enabled on each.

  • Application Priority TLV: carried when PFC is set to auto-negotiate, specifying the business priority level carried by the DCB protocol's APP TLV.

DCBX's discovery, negotiation, and update behavior runs as a state machine on every DCBX-enabled port, cycling through five states:

  1. Local configuration collection: initializes local configuration, capability, and willingness-to-sync settings, then moves on once a peer is detected.

  2. Local configuration advertisement: advertises the local configuration to the peer.

  3. Peer configuration collection: initializes the peer's configuration, capability, and willingness-to-sync settings as learned from the peer.

  4. Local configuration update: negotiates the peer's configuration against the local configuration; if the negotiated result differs from what's currently stored, the local database is updated to match.

  5. Configuration change monitoring: watches for any change in local or peer configuration; detecting one restarts the cycle from local configuration collection.

A key tie-breaking rule governs this negotiation: when both sides are willing to synchronize and their configurations conflict, the side with the smaller local MAC address is the one whose configuration is updated to match its peer — giving the negotiation a deterministic outcome rather than leaving both sides to guess who should defer to whom.

Why DCBX is Beneficial

The core value of DCBX lies in turning DCB configuration consistency from a manual, error-prone task into an automatic, self-correcting one:

· Eliminates manual PFC/ETS mismatch risk: Without DCBX, a link where PFC is enabled on only one end can silently accumulate congestion — the switch sends PFC Pause frames while the unaware server keeps transmitting, eventually overflowing switch buffer and forcing drops and retransmissions that raise latency or trigger a broader failure. DCBX's automatic capability discovery and negotiation closes this gap by construction.

· End-to-end consistency, not just point configuration: Because DCBX runs on every enabled port — server-to-switch and switch-to-switch alike — it keeps DCB settings consistent across an entire forwarding path, not just a single link.

· Deterministic conflict resolution: The MAC-address tie-breaking rule means configuration mismatches resolve automatically and predictably, without requiring an operator to intervene or decide which side is "correct."

· Lower operational burden at scale: In a large fabric with many ports, DCBX removes the need to manually configure and audit DCB parameters port by port, directly reducing both operator workload and the failure surface from configuration drift.

At Asteraix

What We Can Do at Asteraix

AsterNOS implements DCBX as the automated configuration-consistency layer underlying its lossless Ethernet capabilities:

· Standard DCBX TLV support: AsterNOS exchanges ETS Configuration, ETS Recommendation, PFC Configuration, and Application Priority information via the standard LLDP-based DCBX TLV set, interoperating with any DCBX-compliant peer.

· Server-facing negotiation: On server-facing ports, AsterNOS can be configured with PFC parameters and DCBX enabled so that servers with DCBX capability automatically receive and align to the switch's PFC/ETS configuration, removing the failure mode where a server simply isn't aware it needs PFC enabled.

· Switch-to-switch consistency: Between AsterNOS switches, DCBX keeps PFC and ETS settings — for example, which priority queues have PFC enabled — synchronized automatically across a link, even where the two sides start out configured differently.

· Foundation for RoCE deployment at scale: In multi-card, multi-node GPU clusters, keeping RoCE-related DCB configuration synchronized across many devices is critical to a stable lossless fabric. DCBX is the underlying mechanism AsterNOS relies on to make that configuration synchronization automatic at scale, rather than something operators track manually across the fabric.

· Typical deployment: In an AI training or storage cluster requiring lossless Ethernet, DCBX runs on every server-facing and switch-to-switch link in the fabric, automatically discovering and reconciling PFC/ETS settings end to end — reducing manual DCB configuration work and the risk of a mismatched-parameter outage as the fabric scales.