Bug 1261809
| Summary: | NetworkManager removes IPv6LL address from device | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Vladimir Benes <vbenes> |
| Component: | NetworkManager | Assignee: | Beniamino Galvani <bgalvani> |
| Status: | CLOSED NOTABUG | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.2 | CC: | bgalvani, dcbw, kzhang, rkhan, thaller, vbenes |
| Target Milestone: | rc | ||
| Target Release: | 7.3 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-05-17 09:01:00 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1301628, 1313485 | ||
I think this is a minor problem and the user can fix it by tweaking NM configuration. This behavior was introduced to fix bug 1138426; before the change, when a device was found at startup having only an IPv6LL address, NM assumed the connection and kept its configuration, ignoring other on-disk connections for the same device. This caused many problems because it happened frequently that users complained that NM was not activating connections and the reason was that the device was already up with a IPv6LL address automatically assigned by kernel. Now NM ignores IPv6LL configurations, takes ownership of the device and tries to activate on-disk connections, but if there are no available connections, the devices remains without the initial IPv6LL address. This can be fixed by setting the device as 'assume-ipv6ll-only' in configuration, which will revert to old behavior; or by creating a persistent connection that will be activated. In my opinion, we can try to be better at not interfering with existing configuration and, for example, don't touch the interface if we don't have candidate connections for the device. But this requires some bigger changes that may not be appropriate for 7.2. My proposal is to consider this as an improvement for the next NM 1.2 release. After thinking longer about it, I'm convinced that the current behavior is reasonable. Since NM is not assuming the IPv6LL-only device and there are no candidate connections, the device goes to DISCONNECTED state and therefore there can't be any addresses assigned to it. In order to keep the existing address NM has to assume the connection, and this must be enabled explicitly in configuration with the 'assume-ipv6ll-only' option. Vladimir, what's your opinion? Hi Vlad, I believe that the current behavior is acceptable for reasons explained in comment 2. In other words, either the connection gets assumed (and in that case we keep the IPv6LL address) or it doesn't (and then it will be disconnected when there aren't available connections). The behavior can be changed by the 'assume-ipv6ll-only' flag. What do you think? Thanks. Patch posted on upstream bz https://bugzilla.gnome.org/show_bug.cgi?id=763236 This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions (In reply to Beniamino Galvani from comment #5) > Patch posted on upstream bz https://bugzilla.gnome.org/show_bug.cgi?id=763236 The upstream patch was wrong since it left the device configured while in DISCONNECTED state. Yeah, I think at the moment this is working as designed. Maybe we can re-think how devices are managed and assumed, but that would be a different bug (the one mentioned in comment 8). I'm for closing this. Vladimir, do you agree? (In reply to Beniamino Galvani from comment #9) > Yeah, I think at the moment this is working as designed. Maybe we can > re-think how devices are managed and assumed, but that would be a different > bug (the one mentioned in comment 8). I'm for closing this. Vladimir, do you > agree? Do whatever you like, I just reported suspicious behavior. If it's not buggy and there is no way to preserve IPv6LL address when assuming connection w/o touching the device then close it. I was just expecting to preserve IPv6LL while still receiving RA in such reported scenario. Probably just corner case. |
Description of problem: If there is an just IPv6LL address on device and NM service stopped device's IPv6LL address is removed upon NM service start. Version-Release number of selected component (if applicable): NetworkManager-1.0.6-2.el7.x86_64 How reproducible: always Steps to Reproduce: nmcli c del eth0 # delete existing connections on eth0 systemctl stop NetworkManager ip a flush dev eth0 # delete all addresses on eth0 ip l set eth0 down ip l set eth0 up # now eth0 should have an IPv6 link-local address systemctl start NetworkManager Actual results: [root@qe-dell-ovs5-vm-5 ~]# ip a s eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000 link/ether 52:54:02:2c:e1:2d brd ff:ff:ff:ff:ff:ff Expected results: [root@qe-dell-ovs5-vm-5 ~]# ip a s eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000 link/ether 52:54:02:2c:e1:2d brd ff:ff:ff:ff:ff:ff inet6 fe80::5054:2ff:fe2c:e12d/64 scope link valid_lft forever preferred_lft forever Additional info: