1286105 – ipv6 address on team.vlan interface disappear sometimes

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1286105 - ipv6 address on team.vlan interface disappear sometimes

Summary: ipv6 address on team.vlan interface disappear sometimes

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	NetworkManager
Sub Component:
Version:	7.2
Hardware:	Unspecified
OS:	Unspecified
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Beniamino Galvani
QA Contact:	Desktop QE
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1301628 1313485
TreeView+	depends on / blocked

Reported:	2015-11-27 10:51 UTC by Jiaochuandong
Modified:	2016-11-03 19:21 UTC (History)
CC List:	8 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2016-11-03 19:21:02 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2016:2581	0	normal	SHIPPED_LIVE	Low: NetworkManager security, bug fix, and enhancement update	2016-11-03 12:08:07 UTC

Description Jiaochuandong 2015-11-27 10:51:29 UTC

Description of problem:
After team.vlan interface is created, and assign it a static ipv6 address, wait for about 40 seconds, the Ipv6 address on the interface will disappear. All modes of team have this problem.
job link:
https://beaker.engineering.redhat.com/jobs/1157328
&
https://beaker.engineering.redhat.com/jobs/1157543

Version-Release number of selected component (if applicable):
RHEL-7.2-20151030.0

How reproducible:
sometimes

Steps to Reproduce:
1.switch configuration：
      sw-3750-2#show etherchannel summary

     Group  Port-channel  Protocol    Ports
------+-------------+-----------+-----------------------------------------------
47     Po47(SU)         -        Gi1/0/19(P) Gi1/0/20(P) 

2.on host A :
  team configuration：
       #nmcli con add type team ifname team0 con-name team0 autoconnect no config '{"runner":{"name":"roundrobin"}}'
       #ip link set ens2f0 mtu 1500
       #nmcli con add type team-slave ifname ens2f0 master team0
       #nmcli con up team-slave-ens2f0
       #ip link set ens2f1 mtu 1500
       #nmcli con add type team-slave ifname ens2f1 master team0
       #nmcli con up team-slave-ens2f1
       #nmcli con up team0
       #ip link set team0 mtu 1500     
  vlan configuration:
       #nmcli con add type vlan con-name team0.3 dev team0 id 3 mtu 1500 ip4 192.168.168.16/24 ip6 2168::16/64
       #nmcli con up team0.3
3.ping host B:
       #ping -c 10 -I team0.3 192.168.168.18 && ping6 -c 10 -I team0.3 2168::18

Actual results:
on host A:
#ip add sh team0.3 ;date
     15: team0.3@team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:10:18:4d:08:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.168.16/24 brd 192.168.168.255 scope global team0.3
       valid_lft forever preferred_lft forever
    inet6 2168::16/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::210:18ff:fe4d:80c/64 scope link 
       valid_lft forever preferred_lft forever
2015年 11月 27日 星期五 10:19:36 CST<=============at this time, the ipv6 address exist.

#ip add sh team0.3 ;date
     17: team0.3@team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:10:18:4d:08:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.168.16/24 brd 192.168.168.255 scope global team0.3
       valid_lft forever preferred_lft forever
2015年 11月 27日 星期五 10:20:03 CST<=============at this time, the ipv6 address disappear.

At frist,I can ping from host A to host B, then it failed

#ping -c 10 -I team0.3 192.168.168.18
PING 192.168.168.18 (192.168.168.18) from 192.168.168.16 team0.3: 56(84) bytes of data.
ping: sendmsg: No such device
ping: sendmsg: No such device
ping: sendmsg: No such device
ping: sendmsg: No such device
ping: sendmsg: No such device


Expected results:


Additional info:

Comment 2 Beniamino Galvani 2015-12-03 09:26:49 UTC

I looks like team0 is created with ipv4.method=auto and so NM will try
to get an address through DHCP on team0; if there's no DHCP server
available after 45 seconds the configuration will time-out and the
device will be disconnected. Can you please try to assign a static
address to the connection or set ipv4.method=disabled and see if it
makes any difference?

If the problem persists, please attach NM logs captured after running:

  nmcli general logging level debug

Comment 4 Beniamino Galvani 2015-12-10 22:17:46 UTC

Looking at the log, the problem is at lines:

[devices/nm-device-vlan.c:115] parent_hwaddr_changed(): [0x7ff41d87c3c0] (team0.3): parent hardware address changed
[devices/nm-device.c:7156] nm_device_take_down(): [0x7ff41d87c3c0] (team0.3): taking down device.

When we update the MAC of team0.3 the interface is taken down and loses
the IPv6 addresses. Probably the fix is to reapply the IP
configuration after the device is brought up again.

Comment 5 Beniamino Galvani 2015-12-11 10:14:30 UTC

Pushed upstream branch bg/vlan-hwaddr-ipv6-rh1286105, which contains a
couple of cherry-picks from lr/reapply and a new patch to update IPv6
configuration after hw address has been changed.

Comment 6 Dan Williams 2015-12-11 23:31:00 UTC

It would be worth tracking the error from nm_device_reapply_ip6_config() and logging it with a warning.  I'd just return TRUE/no-error if there was no IPv6 config, since it's obviously successful to apply nothing :)

Comment 7 Thomas Haller 2015-12-15 14:39:57 UTC

In general, it seems to me that "nm_device_reapply_ip6_config()" is something that happens as response to "Reapply" D-Bus call.
I don't think that internal code should call to it as a mean to update the IP configuration. I merely mean, that there should be a common public function "nm_device_reactivate_ip6_config()" (with a better name, but not "reapply"), that gets called both by "parent_hwaddr_changed()" and "nm_device_reapply_ip6_config()".

Maybe sync this patch with lr/reapply branch.

Comment 8 Jiaochuandong 2015-12-29 09:19:28 UTC

Based on comment 3,what do I need to do?

Comment 9 Beniamino Galvani 2016-01-11 13:51:50 UTC

(In reply to Thomas Haller from comment #7)
> I merely mean, that there should be a common public
> function "nm_device_reactivate_ip6_config()" (with a better name, but not
> "reapply"), that gets called both by "parent_hwaddr_changed()" and
> "nm_device_reapply_ip6_config()".
> 
> Maybe sync this patch with lr/reapply branch.

Re-pushed branch bg/vlan-hwaddr-ipv6-rh1286105.

(In reply to Jiaochuandong from comment #8)
> Based on comment 3,what do I need to do?

Could you please test if setting:

  nmcli c mod team0 ipv4.method disabled ipv6.method ignore

solves the issue? Because in this case it seems that team0 is only used to provide L2 connectivity for the VLAN and there's no DHCP server on team0.

Then there's the issue that sometimes when the team0 MAC changes the IPv6 configuration on VLAN gets cleared. This is fixed by the branch above, which will be probably available in RHEL 7.3.

Comment 10 Thomas Haller 2016-01-11 14:18:20 UTC

(In reply to Beniamino Galvani from comment #9)
> (In reply to Thomas Haller from comment #7)
> > I merely mean, that there should be a common public
> > function "nm_device_reactivate_ip6_config()" (with a better name, but not
> > "reapply"), that gets called both by "parent_hwaddr_changed()" and
> > "nm_device_reapply_ip6_config()".
> > 
> > Maybe sync this patch with lr/reapply branch.
> 
> Re-pushed branch bg/vlan-hwaddr-ipv6-rh1286105.
> 

LGTM

Comment 11 Beniamino Galvani 2016-01-15 08:49:53 UTC

Merged to upstream master:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=49832fd3943d3551f81e31c9ab8366ff6d8d49b9

Comment 12 Jiaochuandong 2016-01-29 07:22:38 UTC

(In reply to Beniamino Galvani from comment #9)
> (In reply to Thomas Haller from comment #7)
> > I merely mean, that there should be a common public
> > function "nm_device_reactivate_ip6_config()" (with a better name, but not
> > "reapply"), that gets called both by "parent_hwaddr_changed()" and
> > "nm_device_reapply_ip6_config()".
> > 
> > Maybe sync this patch with lr/reapply branch.
> 
> Re-pushed branch bg/vlan-hwaddr-ipv6-rh1286105.
> 
> (In reply to Jiaochuandong from comment #8)
> > Based on comment 3,what do I need to do?
> 
> Could you please test if setting:
> 
>   nmcli c mod team0 ipv4.method disabled ipv6.method ignore
> 
> solves the issue? Because in this case it seems that team0 is only used to
> provide L2 connectivity for the VLAN and there's no DHCP server on team0.
> 
> Then there's the issue that sometimes when the team0 MAC changes the IPv6
> configuration on VLAN gets cleared. This is fixed by the branch above, which
> will be probably available in RHEL 7.3.

No such issue

Steps to test:
on host A:
1.nmcli con add type team ifname team0 con-name team0 autoconnect no config '{"runner":{"name":"activebackup"}}'
2.nmcli con add type team-slave ifname ens2f0 master team0
3.nmcli con add type team-slave ifname ens2f1 master team0
4.nmcli con mod team0 ipv4.method disabled ipv6.method ignore
5.nmcli con up team0
#ip a
[...]
10: team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:c0:dd:1a:44:8c brd ff:ff:ff:ff:ff:ff
    inet6 2001::2c0:ddff:fe1a:448c/64 scope global mngtmpaddr dynamic 
       valid_lft 86384sec preferred_lft 14384sec
    inet6 fe80::2c0:ddff:fe1a:448c/64 scope link 
       valid_lft forever preferred_lft forever

6.nmcli con add type vlan con-name team0.3 dev team0 id 3 mtu 1500 ip4 192.168.168.16/24 ip6 2168::16/64
7.nmcli con up team0.3
#ip a
[...]
10: team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:c0:dd:1a:44:8c brd ff:ff:ff:ff:ff:ff
    inet6 2001::2c0:ddff:fe1a:448c/64 scope global mngtmpaddr dynamic 
       valid_lft 86399sec preferred_lft 14399sec
    inet6 fe80::2c0:ddff:fe1a:448c/64 scope link 
       valid_lft forever preferred_lft forever
11: team0.3@team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:c0:dd:1a:44:8c brd ff:ff:ff:ff:ff:ff
    inet 192.168.168.16/24 brd 192.168.168.255 scope global team0.3
       valid_lft forever preferred_lft forever
    inet6 2168::16/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::2c0:ddff:fe1a:448c/64 scope link 
       valid_lft forever preferred_lft forever

IPV6 does not disappear.

Comment 15 Vladimir Benes 2016-09-14 10:38:26 UTC

IPv6 is correctly preserved on vlan over team when team slave is attached into team.

Comment 17 errata-xmlrpc 2016-11-03 19:21:02 UTC

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://rhn.redhat.com/errata/RHSA-2016-2581.html

Note You need to log in before you can comment on or make changes to this bug.