Ethernet interface ignores disable setting after reboot

Bugs
1

Hello,

I noticed what appears to be a configuration inconsistency related to interface disable state persistence.

Version:

Version:          VyOS 2026.06.10-0053-rolling
Release train:    rolling
Release flavor:   generic

Built by:         autobuild@vyos.net
Built on:         Wed 10 Jun 2026 00:53 UTC
Build UUID:       c824595f-01ce-4f7e-b0ca-4d20bfad9abe
Build commit ID:  0b27f39ae61acc

Architecture:     x86_64
Boot via:         installed image
System type:      bare metal

Hardware vendor:  Dell Inc.
Hardware model:   PowerEdge R630

Network adapter:

  • Intel X520-DA2

Steps to reproduce:

  1. Disable interface eth5.

  2. Commit and save the configuration.

  3. Reboot the router.

Expected behavior:

eth5 should remain administratively down after reboot because the configuration contains the disable option.

Actual behavior:

After reboot, eth5 comes up and becomes active, even though the configuration still shows the interface as disabled.

Configuration after reboot:

set interfaces ethernet eth5 description 'Bond0'
set interfaces ethernet eth5 disable
set interfaces ethernet eth5 disable-flow-control
set interfaces ethernet eth5 hw-id '90:e2:ba:35:01:a0'
set interfaces ethernet eth5 offload gro
set interfaces ethernet eth5 offload gso
set interfaces ethernet eth5 offload sg
set interfaces ethernet eth5 offload tso
set interfaces ethernet eth5 ring-buffer rx '4096'
set interfaces ethernet eth5 ring-buffer tx '4096'

or:

interfaces {
    ethernet eth5 {
        description Bond0
        disable
        disable-flow-control
        hw-id 90:e2:ba:35:01:a0
        offload {
            gro
            gso
            sg
            tso
        }
        ring-buffer {
            rx 4096
            tx 4096
        }
    }
}

However, the operational state shows the interface as up after the reboot:

Interface    IP Address  MAC                VRF      MTU   S/L   Description
eth5         -           90:e2:ba:35:01:a0  default  1500  u/u   Bond0

As shown above, the interface is configured with disable, but its operational state is u/u after reboot.

Has anyone seen similar behavior, or is this a known issue?

2

Additional information:

  • eth5 is configured as a member of a bonding interface.
3

Does this happen on your hardware even for interface who is not part of a bond?

I have seen that some Intel NICs have an issue where the link can become electrically active even if its administratively down. But in those cases it would still say in the show commands as down as I recall it and also not forward any traffic (until the interface is configured as “no shutdown” or the equal).

4

I tested this on a standalone interface that is not a member of any bonding interface, and I was unable to reproduce the issue.

After configuring disable, committing, saving, and rebooting, the interface remained administratively down as expected.

Based on my testing, the problem appears to occur only when the interface is configured as a member of a bonding interface. In that case, after reboot, the configuration still contains the disable statement, but the member interface comes up and is shown as u/u in the operational state.

This makes me suspect that the bonding configuration may be overriding or reactivating the member interface during boot.

5

I can imagine that the reasoning behind it could be that if the bond interface is not administratively down, its underlying interfaces shouldn’t be to.

Which of course isn’t the case, you could have a a bond with several interfaces, one of them being down for whatever reason. But I have to admit it comes across as quite an edge case, I can’t really come up with a reason why you would want to disable a single interface of a bond.

6

In my case, the reason was a damaged fiber patch cord that was causing packet loss. The quickest workaround was to disable the affected interface on the server side while troubleshooting.

After a server reboot, I noticed that the interface came back up/up even though it was still configured as disabled. Only afterwards did I shut down the port on the switch side.

I agree that this is a rare edge case, but there can be situations where access to the switch is unavailable, while access to the server is still possible. In those cases, having a disabled interface remain administratively down across reboots would be the expected behavior.

7

I see your case, a flapping interface impacting the performance of the bond is indeed a valid reason.