Bug 1286105 - ipv6 address on team.vlan interface disappear sometimes
ipv6 address on team.vlan interface disappear sometimes
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
7.2
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Beniamino Galvani
Desktop QE
:
Depends On:
Blocks: 1301628 1313485
  Show dependency treegraph
 
Reported: 2015-11-27 05:51 EST by Jiaochuandong
Modified: 2016-11-03 15:21 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-03 15:21:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jiaochuandong 2015-11-27 05:51:29 EST
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 04:26:49 EST
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 17:17:46 EST
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 05:14:30 EST
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 18:31:00 EST
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 09:39:57 EST
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 04:19:28 EST
Based on comment 3,what do I need to do?
Comment 9 Beniamino Galvani 2016-01-11 08:51:50 EST
(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 09:18:20 EST
(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 12 Jiaochuandong 2016-01-29 02:22:38 EST
(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 06:38:26 EDT
IPv6 is correctly preserved on vlan over team when team slave is attached into team.
Comment 17 errata-xmlrpc 2016-11-03 15:21:02 EDT
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.