Problem statement / current behavior:

Currently, nmcli and NetworkManager expose only configuration-level information about bonding interfaces (mode, slaves, options, connection status). Runtime status information — such as which slave is active, per-slave MII link state, failover events, and counters — is only available by reading /proc/net/bonding/<bond> or the corresponding sysfs files.

Operators and monitoring systems therefore need to parse /proc directly or write custom scripts. This creates inconsistency: all other link/device state is available via NetworkManager’s D-Bus API, except bonding runtime internals.

Requested enhancement / desired behaviour:

Add support in NetworkManager to expose runtime bonding internals through its D-Bus API and surface them in nmcli.

At a minimum, include fields such as:

• Active slave interface name

• MII link state of each slave (up/down)

• Link failure counters (per slave)

• Up/Down delay timers

• {{Bonding Mode and }}Transmit hash policy and currently selected slave (for active-backup, XOR, etc.)
• Slave link speed and duplex (as reported by ethtool)

• Aggregator ID
•  {{Permanent HW }}
• Bond configuration status: It would be helpful to display the bond mode status, like 'good' or 'degraded', depending on the bond mode conditions. For instance, in "active-backup' mode, there should be at least two interfaces. If one interface goes down, the bond status should reflect 'degraded".

Proposed CLI extensions:

• A new subcommand, such as:

            nmcli bond status <bond>

     D-Bus API additions: expose /sys/class/net/<bond>/bonding/* values in NMDeviceBond objects.

Use cases / justification:

• Unified monitoring and diagnostics through NetworkManager API instead of relying on /proc.

• Easier integration with automation, monitoring systems 

• Faster operator troubleshooting: no need to correlate nmcli and /proc/net/bonding.

• Aligns bonding with other device types where runtime state is already exposed by NetworkManager.

Impact of not fixing:

• Operators must use two tools (nmcli + manual /proc parsing) to get complete bond status.

• Monitoring cannot rely solely on NetworkManager D-Bus API.

• Inconsistency with other device types managed by NetworkManager.

Suggested implementation approach:

• Read runtime attributes from /sys/class/net/<bond>/bonding/* (preferred over parsing /proc).

• Extend NMDeviceBond object in D-Bus to carry these values.

• Update nmcli to display them in a human-friendly format.

KCS: The following KCS is an example where we see many cases created because the customer was unsure whether the bond was functioning correctly or not. During bond configuration, it was working; however, later the customer faced a bond network flipping because the bond was in a degraded mode. The customer was unaware of the bond's actual status, and we did not have an easy command to check it https://access.redhat.com/solutions/631283