0

Dealing with a weired issue where netplan is not detecting the uplink going down for one of it's primary slave and not selecting the other slave. I also tried setting up all parameters of mii-monitor-interval but that doesn't seems to be working either.

root@core2:~# lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic
root@core2:~# uname -a
Linux core2 4.15.0-121-generic #123-Ubuntu SMP Mon Oct 5 16:16:40 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
root@core2:~# dpkg -l | grep netplan
ii netplan.io0.98-0ubuntu1~18.04.1 amd64 YAML network configuration abstraction for various backends
root@core2:~#
Config file ->
  network:  
    version: 2   
    renderer: networkd   
    ethernets:   
      enp6s0f0:   
         dhcp4: no   
       enp6s0f1:
        dhcp4: no    
    
    bonds:
      bond0:
        addresses:   
        - 10.10.10.250/24
    
        gateway4: 10.10.10.1
    
        nameservers:    
          addresses: [8.8.8.8]
      interfaces:    
      - enp6s0f0    
      - enp6s0f1
    
      parameters:
        mode: active-backup    
        primary: enp6s0f0
        mii-monitor-interval: 10s    
        min-links: 1
        down-delay: 50

Interesting issue is that event after setting mii-monitor-interval value to 10s, it's not updating on bond interface. It's shows 0ms and that means netplan is not monitoring the mii uplink.

root@core2:~# cat /proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: enp6s0f0 (primary_reselect always)
Currently Active Slave: enp6s0f0
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: enp6s0f1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:1b:21:3e:3f:29
Slave queue ID: 0
Slave Interface: enp6s0f0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:1b:21:3e:3f:28
Slave queue ID: 0
root@core2:~#
4
  • Does your .yaml file actually look like what you posted... with everything starting in column #1, or do you have some indentation?
    – heynnema
    Oct 15, 2020 at 13:51
  • Yes, it has indentation. It's just the way I posted here on the forum. Oct 15, 2020 at 15:56
  • To be clear, 'netplan' does not monitor anything. But the /proc/net/bonding/bond0 contents do show that the monitoring value is not set, which means the kernel is not monitoring. Can you check that MIIMonitorSec= has been properly set under /run/systemd/network?
    – slangasek
    Oct 15, 2020 at 19:20
  • Yes, it was there. But still didn't work. We end up using ifenslave Nov 5, 2020 at 1:47

2 Answers 2

1

Long time after the question was asked, but I ran into a similar problem.

Changing the value in netplan's config and doing a netplan apply did not change the existing mii-monitor-interval, leaving it at 0 (and thus off)

A reboot would make it live. As would deleting the bond device (ip link delete interfacename) then a netplan apply.

Netplan isn't good for changes this way. If the bond exists, it won't change it.

0

Edit 3

I had the same problem with ubuntu 20.04.

I could change the primary device of the bond but if I disconnect the nic's cable no failover routing happens.

MIIMonitorSec is properly set up in /run/systemd/network

Ah, after a full reboot and carefully restarting a ping probe it started to work.

Here is my configuration:

  network:
  version: 2
  renderer: networkd
  ethernets:
        eno1:
            addresses: []
            dhcp4: false
            dhcp6: false
        eno2:
            addresses: []
            dhcp4: false
            dhcp6: false
  bonds:
    bond0:
      dhcp4: no
      interfaces: [eno2, eno1]
      parameters:
        mode: active-backup
        primary: eno1
        mii-monitor-interval: 200
  bridges:
    br0:
      interfaces: [bond0]
      dhcp4: false
      dhcp6: false
      addresses: [192.168.1.2/24]
      gateway4: 192.168.1.1
      nameservers:
        addresses: [192.168.1.1]

test case1:

i. ping foo.bar ii. (remove cable from primary bonding nic)

ping get stucks

iii. CTRL-C (abort ping)

iv. ping foo.bar # restart ping probe

Expect:

ping foo.bar
0.2 ms success
(..)
NIC Copper is down
package loss

ping foo.bar
0.2 ms success

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .