Inspect and Set Port DCBX State with dcb dcbx

Run dcb dcbx set with only one keyword and you have just cleared every other flag on that port, whether you meant to or not. This guide builds a repeatable way to inspect, and when needed set, the DCBX flags for one network port, using dcb dcbx from iproute2 6.1.0, packaged here as 6.1.0-1ubuntu6.4. Allow about ten minutes for inspection, longer if you need to coordinate a live network change.

You need iproute2, a shell, and a network interface whose driver supports the Linux DCBX object. Replace IFACE with the name of that physical or virtual Ethernet port, such as enp0s31f6. The loopback device and most virtual interfaces do not implement DCBX, so a failed probe there is expected, not a sign of a useful configuration.

1. Check the installed command

Start with read-only checks. None of these need elevated privileges:

$ command -v dcb
/usr/sbin/dcb
$ dcb -V
dcb utility, iproute2-6.1.0
$ dcb dcbx help
Usage: dcb dcbx help

Usage: dcb dcbx show dev STRING

Usage: dcb dcbx set dev STRING
           [ host | lld-managed ]
           [ cee | ieee ] [ static ]

The subcommand has one read operation, show, and one state-changing operation, set. The accepted flags describe management mode, DCB specification family, and static configuration support. Do not add a flag because it sounds plausible: this object will not accept an arbitrary DCB feature bolted onto dcbx.

Checkpoint: if dcb -V reports a different iproute2 release, treat the local help output, not this guide, as the authority for the command actually installed on that host.

2. Choose a DCB-capable interface

List interfaces without changing anything:

$ ip -br link
IFACE           STATE      MAC
enp0s31f6       UP         3c:97:0e:12:34:56
docker0         UP         02:42:1a:2b:3c:4d

The names and addresses above are just this run's example; yours will be host-specific. Prefer the physical port that is actually wired to the DCB-capable switch. A bridge, a container veth, or the loopback interface is usually the wrong target. Interface names are shell input, so quote the variable when you use it:

$ IFACE='enp0s31f6'
$ ip link show dev "$IFACE"
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> ...

Now inspect its current DCBX object:

$ dcb dcbx show dev "$IFACE"
host ieee

Output varies by driver. Each enabled flag is printed by name; an empty result means no listed flag is enabled. Attribute read: Operation not supported means the driver does not expose this object at all. Pick a different interface or check the driver documentation; do not treat that message as an invitation to force a setting through anyway.

3. Understand the flags before you touch them

host means the host LLDP agent implements DCBX. lld-managed means the device itself handles the configuration and the host-side interface is mainly for inspection and initial parameters. The manpage describes these two as conceptually exclusive, but the command will happily accept both and leave the driver to sort out the combination. That is a reason to pick one deliberately, not to set both just to see what happens.

cee selects the CEE version of the DCB specification and ieee selects the IEEE version. They are normally alternatives too, although again the command does not enforce it. static says the engine supports static configuration: no negotiation happens, and the values you set are the values that stay.

These flags are a compact one-byte-per-port object. They do not configure priority flow control, traffic classes, or application mappings by themselves. Those live in separate DCB objects and need their own subcommands and their own plan.

Checkpoint: record the output of show before any write. It is the simplest rollback reference you will get:

$ dcb dcbx show dev "$IFACE" | tee "${IFACE}.dcbx.before"
host ieee

4. Plan the change and its risk

set needs elevated privileges because it changes a port attribute, and it has one sharp edge: every keyword you leave out of the command counts as disabled. A command containing only host clears lld-managed, cee, ieee and static rather than leaving them as they were.

Warning: changing DCBX management can alter how the host and switch negotiate lossless Ethernet settings. Use a maintenance window or an approved change procedure on a production link, and confirm which LLDP/DCBX agent actually owns the port first. Do not apply a setting to a port carrying real traffic just to see whether the command works.

There is no dry-run flag in the dcbx interface. If you cannot state the complete flag set you want and the exact recovery command, stop at inspection and go no further.

5. Apply one complete flag set

For a host-managed port using IEEE DCBX without static mode, the complete command is:

# sudo dcb dcbx set dev "$IFACE" host ieee

Success can mean no output at all, so the shell status is your first check:

$ printf 'exit status: %s\n' "$?"
exit status: 0
$ dcb dcbx show dev "$IFACE"
host ieee

The exact output depends on the driver. A successful exit status means the command and kernel interface accepted the request; the follow-up show confirms what the driver actually reports afterwards. If it differs, trust the driver over your intention and investigate before you carry on.

6. Recover from a wrong setting

Restore the exact flag set you recorded before the change. If the saved output was lld-managed cee static, use all three keywords:

# sudo dcb dcbx set dev "$IFACE" lld-managed cee static
$ dcb dcbx show dev "$IFACE"
lld-managed cee static

If the original output was empty, the recovery command is sudo dcb dcbx set dev "$IFACE" with no flags at all, which clears every flag: check the before file carefully before you run that. If the change already disrupted a service, follow the site's network recovery procedure first, since DCBX flags alone cannot restore switch-side configuration or a lost link.

These settings are normally port state, not a persistent config file. A reboot, driver reload, NetworkManager profile, firmware policy, or switch management system can quietly reapply different values. If a setting must survive a restart, find out which configuration system owns that and test persistence separately.

7. Diagnose the common failures

For Operation not supported, switch to a physical DCB-capable port and confirm its driver exposes DCB netlink attributes. For a missing or invalid device, check ip link show dev "$IFACE" and fix the name. For permission errors, use sudo only for the set operation: it will not make an unsupported driver gain DCBX support out of nowhere.

If a set command fails, do not assume partial success. Run dcb dcbx show dev "$IFACE" and compare it with the saved state. A non-zero exit status means the operation failed, but the driver and kernel message are still the evidence you need for the next step.

Done means