Bug 1908302
| Summary: | interface looses link-local address when DHCPv6 fails | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Derek Higgins <derekh> | ||||
| Component: | NetworkManager | Assignee: | NetworkManager Development Team <nm-team> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 8.3 | CC: | acardace, atragler, bbreard, bfournie, bgalvani, ferferna, fge, imcleod, jligon, lrintel, mcornea, miabbott, nstielau, rkhan, sukulkar, till, tsedovic | ||||
| Target Milestone: | rc | Keywords: | Triaged | ||||
| Target Release: | 8.4 | Flags: | pm-rhel:
mirror+
|
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | No Doc Update | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2021-11-03 13:31:06 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Derek Higgins
2020-12-16 11:27:18 UTC
We'll need to investigate this further, but I would be surprised if this behavior is limited to just RHCOS, as we are using the same NetworkManager that is available in RHEL8. It would be useful if it you could try to reduce this problem to its most simple reproducer and see if it reproduces on a vanilla RHEL 8.3 system with the same version of NetworkManger (NetworkManager-1.26.0-9.el8_3) as found in RHCOS 47.83.202012030221-0 (In reply to Micah Abbott from comment #1) > We'll need to investigate this further, but I would be surprised if this > behavior is limited to just RHCOS, as we are using the same NetworkManager > that is available in RHEL8. > > It would be useful if it you could try to reduce this problem to its most > simple reproducer and see if it reproduces on a vanilla RHEL 8.3 system with > the same version of NetworkManger (NetworkManager-1.26.0-9.el8_3) as found > in RHCOS 47.83.202012030221-0 Yup, the same thing happens on RHEL 8.3 (although this time ipv6.addr-gen-mode is set to stable-privacy) [root@h2 ~]# cat /etc/redhat-release Red Hat Enterprise Linux release 8.3 (Ootpa) [root@h2 ~]# rpm -qa | grep -i networkma NetworkManager-libnm-1.26.0-12.el8_3.x86_64 NetworkManager-team-1.26.0-12.el8_3.x86_64 NetworkManager-1.26.0-12.el8_3.x86_64 NetworkManager-tui-1.26.0-12.el8_3.x86_64 [root@h2 ~]# ip -o addr show dev enp7s0 3: enp7s0 inet6 fd00:1101::64b7/128 scope global dynamic noprefixroute \ valid_lft 550sec preferred_lft 550sec 3: enp7s0 inet6 fe80::2a7:ad19:3892:6777/64 scope link noprefixroute \ valid_lft forever preferred_lft forever [root@h2 ~]# cat /proc/sys/net/ipv6/conf/enp7s0/addr_gen_mode 1 [root@h2 ~]# nmcli con show ethernet | grep -i ipv6.addr-gen-mode ipv6.addr-gen-mode: stable-privacy # After killing the dhcpserver (which was also sending out the router adverts) # Both ipaddresses are lost, the link local address eventually comes back for a few minutes # and is then lost again [root@h2 ~]# while true ; do sleep 10 ; date ; ip -o addr show dev enp7s0 ; done Fri 8 Jan 07:21:58 EST 2021 3: enp7s0 inet6 fd00:1101::64b7/128 scope global dynamic noprefixroute \ valid_lft 14sec preferred_lft 14sec 3: enp7s0 inet6 fe80::2a7:ad19:3892:6777/64 scope link noprefixroute \ valid_lft forever preferred_lft forever Fri 8 Jan 07:22:08 EST 2021 3: enp7s0 inet6 fd00:1101::64b7/128 scope global dynamic noprefixroute \ valid_lft 4sec preferred_lft 4sec 3: enp7s0 inet6 fe80::2a7:ad19:3892:6777/64 scope link noprefixroute \ valid_lft forever preferred_lft forever Fri 8 Jan 07:22:18 EST 2021 3: enp7s0 inet6 fe80::2a7:ad19:3892:6777/64 scope link noprefixroute \ valid_lft forever preferred_lft forever ... Fri 8 Jan 07:25:58 EST 2021 3: enp7s0 inet6 fe80::2a7:ad19:3892:6777/64 scope link noprefixroute \ valid_lft forever preferred_lft forever Fri 8 Jan 07:26:08 EST 2021 ... Fri 8 Jan 07:30:58 EST 2021 Fri 8 Jan 07:31:08 EST 2021 3: enp7s0 inet6 fe80::2a7:ad19:3892:6777/64 scope link noprefixroute \ valid_lft forever preferred_lft forever ... Fri 8 Jan 07:33:52 EST 2021 3: enp7s0 inet6 fe80::2a7:ad19:3892:6777/64 scope link noprefixroute \ valid_lft forever preferred_lft forever Fri 8 Jan 07:34:02 EST 2021 Fri 8 Jan 07:34:12 EST 2021 Fri 8 Jan 07:34:22 EST 2021 Created attachment 1745581 [details] journal output associated with comment 2 Thanks for the additional data, Derek. Based on your findings, I am going to send this over to the NetworkManager team for additional action. When the DHCPv6 server goes away, the connection fails and the device is disconnected removing IPv6 addresses. To avoid that the connection fails, you can set ipv6.dhcp-timeout to infinity. From kernel command line this can be done by adding option 'rd.net.timeout.dhcp=infinity'. Derek, please confirm that using the infinity timeout solves the issue for you. Thanks. Hi Derek, Please try commands which should fix your problem. nmcli connection modify <connection_name> ipv6.ra_timeout infinity ipv6.dhcp-timeout infinity We are also working in bug 1900038 to improve the user experience on DHCP timeout. Thank you! Closing as duplicate of bug 1900038 . Please feel free to reopen this bug if you think other help is required. *** This bug has been marked as a duplicate of bug 1900038 *** |