Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

Bug #1794478 reported by bugproxy on 2018-09-26
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
Undecided
Canonical Foundations Team
network-manager (Ubuntu)
Undecided
Unassigned
Bionic
Undecided
Olivier Tilloy

Bug Description

---Problem Description---
Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get automatic ipv4 assigned from dhcp server.

---uname output---
Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 2018 s390x s390x s390x GNU/Linux

Machine Type = s390x

---Debugger---
A debugger is not configured

---Steps to Reproduce---
 When user configures ipv4 as automatic and ipv6 as manual for bond interface automatic ipv4 is not getting assigned.
Looks like dhcp client request for ipv4 is not done to dhcp server after maunal ipv6 is assigned quickly to bond interface

This issue will not happen in below cases:
1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan interface.
2)with ipv4 automatic and ipv6 automatic configuration for bond interface
3)with ipv4 automatic and ipv6 disabled configuration for bond interface

Configuration:
Bond interface, ipv4 automatic mode and ipv6 automatic mode

root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond
[connection]
id=test_bond
uuid=63e54542-5135-47ac-a954-b861c3937be2
type=bond
interface-name=test_bond
permissions=
timestamp=1537944121

[ethernet]
mac-address-blacklist=

[bond]
downdelay=0
fail_over_mac=none
miimon=100
mode=active-backup
num_grat_arp=0
primary_reselect=always
updelay=0

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

From /var/log/syslog, we can see ip got assigned:

Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e)
Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e)
Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 10.2.3.1
Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPACK of 10.2.3.55 from 10.2.3.1

root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
28: test_bond: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
    inet 10.2.3.55/24 brd 10.2.3.255 scope global dynamic noprefixroute test_bond
       valid_lft 353sec preferred_lft 353sec
    inet6 fe80::ff:feb3:b522/64 scope link
       valid_lft forever preferred_lft forever

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Bond interface, ipv4 automatic mode and ipv6 manual mode

root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond
[connection]
id=test_bond
uuid=3efb153a-a6e4-48fb-aa04-f0b8cb549bab
type=bond
interface-name=test_bond
permissions=
timestamp=1537943300

[ethernet]
mac-address-blacklist=

[bond]
downdelay=0
fail_over_mac=none
miimon=100
mode=active-backup
num_grat_arp=0
primary_reselect=always
updelay=0

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
address1=fe81::32a5:bc5f:287f:8db8/64
dns-search=
method=manual

No automatic ip assigned to ipv4 and no requests to dhcp server seen in /var/log/syslog
root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
29: test_bond: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
    inet6 fe81::32a5:bc5f:287f:8db8/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

==> Correct LP-Package need to be assigned...!

bugproxy (bugproxy) on 2018-09-26
tags: added: architecture-s39064 bugnameltc-171765 severity-high targetmilestone-inin---
Changed in ubuntu:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
affects: ubuntu → linux (Ubuntu)
bugproxy (bugproxy) on 2018-09-26
tags: added: targetmilestone-inin1804
removed: targetmilestone-inin---
Frank Heimes (frank-heimes) wrote :

Which dhcp client is used? (affected package)
Notice that network-manager is not supported on Ubuntu Server 18.04,
please consider to move to netplan and networkd.
For now assuming that this is related to DHCP rather than nw mgr.

affects: linux (Ubuntu) → dhcpcd (Ubuntu)
Changed in ubuntu-z-systems:
assignee: nobody → Canonical Foundations Team (canonical-foundations)

------- Comment From <email address hidden> 2018-10-01 04:59 EDT-------
dhcp client package details:

root@NetworkTest:~# dpkg -l | grep dhcp-client
ii isc-dhcp-client 4.3.5-3ubuntu7 s390x DHCP client for automatically obtaining an IP address

Steve Langasek (vorlon) wrote :

This is not reproducible with netplan in an Ubuntu 18.04 container (on an Ubuntu cosmic host). With the following netplan config:

$ cat /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    ethernets:
        eth0:
            dhcp4: false
    bridges:
      br0:
          interfaces: [eth0]
          dhcp4: true
          addresses: ["fe81::32a5:bc5f:287f:8db8/64"]
$

The container network comes up with:

$ ip addr show dev br0
2: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether da:af:7e:76:48:8a brd ff:ff:ff:ff:ff:ff
    inet 10.141.225.180/24 brd 10.141.225.255 scope global dynamic br0
       valid_lft 3341sec preferred_lft 3341sec
    inet6 fd42:c560:e275:f583:d8af:7eff:fe76:488a/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 3340sec preferred_lft 3340sec
    inet6 fe81::32a5:bc5f:287f:8db8/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::d8af:7eff:fe76:488a/64 scope link
       valid_lft forever preferred_lft forever
$

As NetworkManager is not the supported network renderer for Ubuntu Server, please provide a reproducer for this using netplan and systemd-networkd.

affects: dhcpcd (Ubuntu) → network-manager (Ubuntu)
Changed in network-manager (Ubuntu):
status: New → Incomplete
Changed in ubuntu-z-systems:
status: New → Incomplete
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2018-10-04 05:03 EDT-------
Vorlon,

Yes i agree that nmcli is being used by me for managing the interfaces.
The issue is not seen with ETHERNET and VLAN type of interfaces.
This is happening only with BOND interfaces (auto ipv4 and manual ipv6 assigned.) Is is possible for you to try with this configuration and check? If its not happening then probably its a nmcli bug?

I have to yet work on netplan tool and see if i can reproduce.

Steve Langasek (vorlon) wrote :

Indeed, sorry about that, I overlooked that this was on a bond and tested with a bridge instead.

Here are the results with a bond:

$ cat /etc/netplan/50-cloud-init.yaml
network:
    version: 2
    ethernets:
        eth0:
            dhcp4: false
    bonds:
        bond0:
            interfaces: [eth0]
            dhcp4: yes
            addresses: ["fe81::32a5:bc5f:287f:8db8/64"]
$ ip addr show dev bond0
2: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether a2:83:94:5d:cc:de brd ff:ff:ff:ff:ff:ff
    inet 10.141.225.183/24 brd 10.141.225.255 scope global dynamic bond0
       valid_lft 3540sec preferred_lft 3540sec
    inet6 fe81::32a5:bc5f:287f:8db8/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::a083:94ff:fe5d:ccde/64 scope link
       valid_lft forever preferred_lft forever
$

Again, the dhcp4 address and the static ipv6 address are both present.

Sebastien Bacher (seb128) wrote :

The issue looks like it could be what is fixed by https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/34ca1680 (the change is included in 1.10.8 which is currently not yet in bionic but being SRUed)

Eric Desrochers (slashd) wrote :

The new stable version indicate the fix mentioned by seb128 is there but no indication has been made in the debian/changelog to automatically change the status, which breaks the SRU machinery for this particular bug.

--- network-manager-1.10.6/src/nm-manager.c 2018-03-12 08:59:48.000000000 -0400
+++ network-manager-1.10.14/src/nm-manager.c 2018-11-20 05:23:31.000000000 -0500

+ if ( old_state == NM_DEVICE_STATE_UNMANAGED
+ && new_state > NM_DEVICE_STATE_UNMANAGED)
+ retry_connections_for_parent_device (self, device);
+

I'll change the bug status from "Incomplete" to "Fix Committed" as the package is now found in bionic-proposed.

- Eric

Changed in network-manager (Ubuntu):
status: Incomplete → Fix Committed
assignee: Skipper Bug Screeners (skipper-screen-team) → Olivier Tilloy (osomon)
tags: added: verification-needed verification-needed-bionic
Eric Desrochers (slashd) on 2019-02-06
Changed in network-manager (Ubuntu Bionic):
status: New → Fix Committed
Changed in network-manager (Ubuntu):
status: Fix Committed → Fix Released
Changed in network-manager (Ubuntu Bionic):
assignee: nobody → Olivier Tilloy (osomon)
Changed in network-manager (Ubuntu):
assignee: Olivier Tilloy (osomon) → nobody
Changed in ubuntu-z-systems:
status: Incomplete → Fix Committed
Sebastien Bacher (seb128) wrote :

> The new stable version indicate the fix mentioned by seb128 is there but no indication has been made in
> the debian/changelog to automatically change the status, which breaks the SRU machinery for this
> particular bug.

@Eric, I didn't handle it ine SRU because I don't understand the issue enough to be confident it's fixed in that update, I was just adding a side comment because the change looks like it could impact on the behaviour described there. Did you confirm the SRU does address the problem and that it's indeed fix commited? (and that it's really resolved in newer series)

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

Other bug subscribers