bond parameters are not changed by 'netplan apply'

Bug #1746419 reported by Daniel Axtens on 2018-01-31
50
This bug affects 7 people
Affects Status Importance Assigned to Milestone
netplan
Undecided
Unassigned
nplan (Ubuntu)
Undecided
Unassigned
systemd (Ubuntu)
Undecided
Unassigned

Bug Description

I have a yaml file as follows:

network:
    version: 2
    ethernets:
        bonddevs:
            match:
                name: ens[78]
    bonds:
        bond0:
            interfaces: [bonddevs]
            parameters:
                mode: active-backup
                mii-monitor-interval: 1
            addresses:
                - 10.10.10.1/24

Say I decide that 1s is too frequent for the MII interval, and I want to change the interval to 2s.

If I change that in the yaml, then run
# netplan generate
# netplan apply
# cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
MII Polling Interval (ms): 1000

In other words, the change has not been applied.

Running netplan --debug apply prints:
DEBUG:device bond0 operstate is up, not replugging

So I wondered if bringing the bond down would help. It does not:
# ip link set dev bond0 down
# netplan apply
# cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
MII Polling Interval (ms): 1000

However, deleting the link works:
# ip link del dev bond0
# netplan apply
# cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
MII Polling Interval (ms): 2000

This is counter-intuitive behaviour.
Ideally, I would like a regular netplan apply to work without deleting the bond.
However, a changed to the docs to make this clear would be OK.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: nplan 0.32~17.10.1
ProcVersionSignature: User Name 4.13.0-32.35-generic 4.13.13
Uname: Linux 4.13.0-32-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
Date: Wed Jan 31 05:47:42 2018
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=C.UTF-8
 SHELL=/bin/bash
SourcePackage: nplan
UpgradeStatus: No upgrade log present (probably fresh install)

Daniel Axtens (daxtens) wrote :

Sounds like this is a bug in systemd, since it's what will deal with the actual devices.

Dimitri John Ledkov (xnox) wrote :

I believe this is systemd intentional to not change bond parameters if the bond already exists. It is assumed that something else has already created the bond, and thus networkd should not be "updating" the params. Despite networkd creating the bond in the first place...

Changed in systemd (Ubuntu):
status: New → Won't Fix

Right, so netplan should tell networkd to tear down the bond first?

On Thu, Feb 15, 2018 at 7:06 AM, Dimitri John Ledkov
<email address hidden> wrote:
> I believe this is systemd intentional to not change bond parameters if
> the bond already exists. It is assumed that something else has already
> created the bond, and thus networkd should not be "updating" the params.
> Despite networkd creating the bond in the first place...
>
> ** Changed in: systemd (Ubuntu)
> Status: New => Won't Fix
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1746419
>
> Title:
> bond parameters are not changed by 'netplan apply'
>
> Status in nplan package in Ubuntu:
> New
> Status in systemd package in Ubuntu:
> Won't Fix
>
> Bug description:
> I have a yaml file as follows:
>
> network:
> version: 2
> ethernets:
> bonddevs:
> match:
> name: ens[78]
> bonds:
> bond0:
> interfaces: [bonddevs]
> parameters:
> mode: active-backup
> mii-monitor-interval: 1
> addresses:
> - 10.10.10.1/24
>
>
> Say I decide that 1s is too frequent for the MII interval, and I want to change the interval to 2s.
>
> If I change that in the yaml, then run
> # netplan generate
> # netplan apply
> # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
> MII Polling Interval (ms): 1000
>
> In other words, the change has not been applied.
>
> Running netplan --debug apply prints:
> DEBUG:device bond0 operstate is up, not replugging
>
> So I wondered if bringing the bond down would help. It does not:
> # ip link set dev bond0 down
> # netplan apply
> # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
> MII Polling Interval (ms): 1000
>
> However, deleting the link works:
> # ip link del dev bond0
> # netplan apply
> # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
> MII Polling Interval (ms): 2000
>
> This is counter-intuitive behaviour.
> Ideally, I would like a regular netplan apply to work without deleting the bond.
> However, a changed to the docs to make this clear would be OK.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 17.10
> Package: nplan 0.32~17.10.1
> ProcVersionSignature: User Name 4.13.0-32.35-generic 4.13.13
> Uname: Linux 4.13.0-32-generic x86_64
> ApportVersion: 2.20.7-0ubuntu3.7
> Architecture: amd64
> Date: Wed Jan 31 05:47:42 2018
> ProcEnviron:
> TERM=xterm-256color
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=C.UTF-8
> SHELL=/bin/bash
> SourcePackage: nplan
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1746419/+subscriptions

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nplan (Ubuntu):
status: New → Confirmed
Dimitri John Ledkov (xnox) wrote :

networkd does not have a toggle to tear down the bond first =/ or to force changing the parameters of it. Maybe a toggle like that should be added to really-really reload all the settings.

Daniel Axtens (daxtens) on 2018-07-23
Changed in netplan:
status: New → Confirmed
Dimitri John Ledkov (xnox) wrote :

Netplan could delete the bond, which would then be recreated by networkd with all parameters applied.

Daniel Axtens (daxtens) wrote :

Should it though? That will, for example, terminate any tcpdump processes bound to the bond, it will disrupt currently running connections, etc. Maybe we could do it but we'd want to put it behind a --force option or something, I think.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers