Hi, can you please ask the customer to set 'level=TRACE' in the [logging] section of /etc/NetworkManager/NetworkManager.conf, reproduce the issue and then provide the output of 'journalctl -b' ? Thanks.

Hi. It seems the issue is caused by the presence of a bond0 interface
before NM starts. The interface is created when the bonding kernel
module is inserted at boot due to file /etc/modules-load.d/bonding.conf.

A possible workaround is:

 echo "options bonding max_bonds=0" > /etc/modprobe.d/bonding-opts.conf

This tells kernel to not create the interface automatically at boot,
but doesn't prevent NM from creating it later when needed. I tested it
in a VM and the default route comes up as expected, while it didn't
without the option.

Still, there is a bug in NM because a full activation of the bond0
connection (as performed by the network.service during boot) should
create the default route. I'm investigating why it doesn't work.

The bug is also present on git master. Reproducer:

#!/bin/sh                                                                                                                                                                         

nmcli connection delete bond0+
nmcli connection add type bond ifname bond0 con-name bond0+ ip4 172.26.1.1 gw4 172.26.1.254

systemctl stop NetworkManager
# clear NM runtime state
rm -rf /var/run/NetworkManager

# create bond0 externally before NM is started
ip link del bond0 2> /dev/null
ip link add bond0 type bond

systemctl start NetworkManager
sleep 10
nmcli connection up bond0+

# now check that default route via gw exists                                                                                                                                      
nmcli connection
ip route

Fix on review at:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/291

Hi,

I very much appreciate your assistance with this. I have another case with a slightly different issue where none of the ip info is being applied to the bond on boot, but gets applied after a restart. After looking over the patch you submitted I suspect it may be related to the issue in this bug. Would it be possible to build a test package with your patch that I can have that customer test?

- Colombo

this issue was fixed upstream before 1.22.0 (64a9dd38047a)

Also backported to 1.20.10 (722cddfad873) and 1.18.4 (f754f9790032).

This is hence part of rhel-7.8 (1:1.18.4-1)

bond_add_default_route_if_bond0_exists test added:
working on both 8.2 and 7.8 well.
failing on 7.7.

    @bond_add_default_route_if_bond0_exists
    Scenario: NM - bond - reconnect device
    * Add a new connection of type "bond" and options "con-name bond0 ifname bond0 ip4 1.2.3.4/24 gw4 1.2.3.1"
    * Stop NM
    * Execute "rm -rf /var/run/NetworkManager"
    * Execute "ip link del bond0 2> /dev/null ; ip link add bond0 type bond"
    * Start NM
    * Bring "up" connection "bond0"
    When "connected" is visible with command "nmcli -g GENERAL.STATE dev show bond0" in "40" seconds
    Then "default" is visible with command "ip r |grep bond0"

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1162