"unconfigured" NIC can still get IPv6 addresses via RA
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | MAAS |
Wishlist
|
Unassigned | ||
| | curtin |
Undecided
|
Unassigned | ||
| | netplan |
High
|
Mathieu Trudel-Lapierre | ||
| | nplan (Ubuntu) |
High
|
Mathieu Trudel-Lapierre | ||
| | Xenial |
High
|
Mathieu Trudel-Lapierre | ||
| | Zesty |
Undecided
|
Unassigned | ||
Bug Description
[Impact]
Some users omit configuration for some interfaces, and expect that the lack of configuration translates to "no IP address" on the interface, as per netplan documentation.
[Test case]
/!\ Requires an IPv6-capable network.
1) Update nplan.
2) Ensure the nplan configure includes the 'accept-ra: no' option.
3) Run 'netplan apply'
4) Verify that there is no IPv6 address set for the interface where 'accept-ra: no is set; using 'ip -6 addr'.
[Regression potential]
Incorrect configuration of the IPv6 addresses on a device would consistute a regression: for instance, getting an IPv6 SLAAC address when 'accept-ra: no' is set; or no IPv6 address when RAs are being received and 'accept-ra' is not set. Furthermore, possible regressions may look like incorrect IPv6 configuration or missing options on IPv6 or IPv4 setups, in the form of not retrieving an IP address or getting the wrong IP.
---
TL;DR A MAAS NIC that is set to "unconfigured" (or "link up") will get no IPv4 address, but it might still get an IPv6 address via router advertisements (RA), if there is such a service in that network segment.
Whether this is a bug or not is up for discussion. That's the point of this ticket, actually, so that this discussion can be had and be recorded.
We found out about this when we couldn't get any connectivity to instances of an openstack cloud deployed by the autopilot.
After much debugging, we found that the problem was with the br-data bridge on the neutron-gateway node: it didn't have the external NIC (eth1) as part of the bridge.
The neutron-gateway charm, before adding any NIC to a bridge, performs certain checks to see if it's really unused. One of these checks looks for IP addresses on the NIC, both IPv4 and IPv6. In MAAS, that node had eth1 set to "unconfigured", so that eth1 is just "up", but has no IP (v4) address. Turns out this NIC had gotten an IPv6 ULA from an openwrt router in that network segment. That was enough for the charm to not add it to the br-data bridge, thus breaking connectivity to openstack instances that were later brought up.
We shut down the RA service on the openwrt router and then everything worked as expected.
| Mike Pontillo (mpontillo) wrote : | #1 |
| Changed in maas: | |
| status: | New → Triaged |
| importance: | Undecided → Wishlist |
| Mike Pontillo (mpontillo) wrote : | #2 |
Also adding 'netplan'; from what I've seen so far, this is not yet possible to configure.
| Mike Pontillo (mpontillo) wrote : | #3 |
For the record, there is a workaround in MAAS if you want your deployed nodes to be IPv6-free: use the "ipv6.disable=1" kernel parameter. This can be done as a tag if you want it to happen on a per-machine basis, or you can use the settings page to create a global default kernel setting.
Related is bug #1663340, however; MAAS itself currently uses IPv4-mapped IPv6 addresses in its operation, so is not able to operate in such an environment.
Please avoid disabling IPv6 using "ipv6.disable=1". This breaks socket() AF_INET6, which can cripple other software depending on the ability to open sockets() of the AF_INET6 family, even if the system should not use IPv6. It is usually safer to use "ipv6.disable_
We can look into toggling receiving RAs as IPv6-specific settings.
| Changed in netplan: | |
| status: | New → Triaged |
| importance: | Undecided → High |
| assignee: | nobody → Mathieu Trudel-Lapierre (cyphermox) |
| Mike Pontillo (mpontillo) wrote : | #5 |
Indeed, this workaround also breaks the MAAS region itself. ;-)
+1 to ipv6.disable_ipv6 if this is necessary, just note that this allows IPv6 to be enabled without a reboot via sysctl (which apparantly isn't acceptable in some highly-strict environments).
| Changed in nplan (Ubuntu): | |
| status: | New → Triaged |
| importance: | Undecided → High |
| assignee: | nobody → Mathieu Trudel-Lapierre (cyphermox) |
| Launchpad Janitor (janitor) wrote : | #6 |
This bug was fixed in the package nplan - 0.25
---------------
nplan (0.25) artful; urgency=medium
* tests/generate.py: add a test to validate that correct blacklist entries
are added when creating virtual devices.
* tests/integrati
the remaining interface and udev configuration can confuse NetworkManager
now that it seems to manage random devices it did not create again.
(LP: #1699371)
* src/nm.c: set the MTU even though we also specify it in systemd-networkd
for consumption by udev. NetworkManager will try to set it and might
otherwise default to the wrong value.
* src/networkd.c: Set IPv6AcceptRA=no anytime we don't do DHCPv6 (or by the
same config, SLAAC), and don't have static addresses set. This should fix
the cases where unconfigured devices still get an IPv6 address.
(LP: #1655440)
* src/nm.c: Explicitly set IPv6 method=ignore when IPv6 is otherwise not
configured; this follows the same logic as setting IPv6AcceptRA=no in
networkd, with the exception that NM does not currently disable RAs. When
it does, an unconfigured device for IPv6 will truly be left with no config.
-- Mathieu Trudel-Lapierre <email address hidden> Thu, 13 Jul 2017 16:22:18 -0400
| Changed in nplan (Ubuntu): | |
| status: | Triaged → Fix Released |
Uploaded in nplan 0.25 to artful, so it's Fix Released upstream as well...
| Changed in netplan: | |
| status: | Triaged → Fix Released |
| Changed in nplan (Ubuntu Xenial): | |
| importance: | Undecided → High |
| status: | New → In Progress |
| assignee: | nobody → Mathieu Trudel-Lapierre (cyphermox) |
| description: | updated |
After much thought, I think it's better to keep the default as being as "open" as possible, and taking any step we can to provide some working network by default (that is, accepting RAs by default).
I'll be adding a key in netplan to allow disabling RAs independently.
| description: | updated |
| tags: | added: id-5966b7c8f96a052f6904d7cb |
Hello Andreas, or anyone else affected,
Accepted nplan into zesty-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
| Changed in nplan (Ubuntu Zesty): | |
| status: | New → Fix Committed |
| tags: | added: verification-needed verification-needed-zesty |
| Brian Murray (brian-murray) wrote : | #10 |
Hello Andreas, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
| Changed in nplan (Ubuntu Xenial): | |
| status: | In Progress → Fix Committed |
| tags: | added: verification-needed-xenial |
Verification-done on xenial for nplan 0.29~16.04.1:
With accept-ra: no; RAs are no longer used to configure an IPv6 address. Network and kernel behave normally when accept-ra: is not set.
| tags: |
added: verification-done-xenial removed: verification-needed-xenial |
Verification-done on zesty for nplan 0.29~17.04.1:
With accept-ra: no; RAs are no longer used to configure an IPv6 address. Network and kernel behave normally when accept-ra: is not set.
| tags: |
added: verification-done-zesty removed: verification-needed verification-needed-zesty |
| Łukasz Zemczak (sil2100) wrote : | #13 |
Hello Andreas, or anyone else affected,
Accepted nplan into zesty-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
| tags: |
added: verification-needed verification-needed-zesty removed: verification-done-zesty |
| Łukasz Zemczak (sil2100) wrote : | #14 |
Hello Andreas, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
| tags: |
added: verification-needed-xenial removed: verification-done-xenial |
| tags: |
added: verification-failed-xenial removed: verification-needed-xenial |
nplan 0.32~16.04.2 fails to build because I mismerged 0.32 and broke the code skipping the test_routes_v6 test in the NetworkManager case. Therefore, it can't possibly pass SRU verification.
| Brian Murray (brian-murray) wrote : | #16 |
Hello Andreas, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
| tags: |
added: verification-needed-xenial removed: verification-failed-xenial |
Autopktests still failing for xenial; the test is still not being skipped (we know it won't work on Xenial due to the version of NM shipped there). Marking verification-
| tags: |
added: verification-failed-xenial removed: verification-needed-xenial |
| Łukasz Zemczak (sil2100) wrote : | #18 |
Hello Andreas, or anyone else affected,
Accepted nplan into xenial-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-
Further information regarding the verification process can be found at https:/
| tags: |
added: verification-needed-xenial removed: verification-failed-xenial |
Verification-done on xenial for nplan 0.32~16.04.3:
Verification-done on zesty for nplan 0.32~17.04.1:
With accept-ra: no; RAs are no longer used to configure an IPv6 address. Network and kernel behave normally when accept-ra: is not set.
| tags: |
added: verification-done-xenial verification-done-zesty removed: verification-needed verification-needed-xenial verification-needed-zesty |
| Launchpad Janitor (janitor) wrote : | #20 |
This bug was fixed in the package nplan - 0.32~16.04.3
---------------
nplan (0.32~16.04.3) xenial; urgency=medium
* tests/integrati
backend.
nplan (0.32~16.04.2) xenial; urgency=medium
* tests/integrati
the skip rules for 16.04 after merging in 0.32.
nplan (0.32~16.04.1) xenial; urgency=medium
* Backport netplan 0.32 to 16.04. (LP: #1713142)
* debian/control: Depend on systemd (>= 229-4ubuntu20) for the PrimarySlave
feature backported in that revision.
* tests/integrati
nplan (0.32) bionic; urgency=medium
* src/nm.c: better handle the UUID generation; the order of iterating
through interaces may affect things here. Also make sure the tests catch
a null UUID.
nplan (0.31) bionic; urgency=medium
[ Mathieu Trudel-Lapierre ]
* src/nm.c: generate a UUID for a connection only as needed; when we're
dealing with NM VLANs. (LP: #1712921)
* debian/
failing right from the start when systemd-networkd is disabled.
(LP: #1699371)
* tests/integrati
120 seconds, autopkgtest infrastructure tends to be a little slow for the
network device configuration to be applied and noticed by NM.
(LP: #1699371)
[ Dimitri John Ledkov ]
* Reload udevd to invalidate configuration cache of .rules/.link files
as generate step may have changed them. LP: #1669564
[ Dan Streetman ]
* Add another interface driver exception to netplan replug to prevent unbind
of the Xen VIF interfaces. (LP: #1729573)
nplan (0.30) artful; urgency=medium
* Add an "optional" syntax node for now to all devices. This is unimplemented
for now, but intended to allow users to mark some devices as optional: to
make sure they do not delay boot when configured. (LP: #1664844)
nplan (0.29) artful; urgency=medium
* Fix autopkgtests in a world where /run/NetworkMan
exists. nplan is enabled by default, so it might well have the directory
already created on the filesystem.
nplan (0.28) artful; urgency=medium
* Revert 56cd3eec which disabled IPv6 Router Advertisements by default. It
broke default network config in LXD and was contrary to the defaults used
by the kernel. Reopens LP: 1655440. (LP: #1717404)
* Add "accept-ra:" key for all device types; this will default to OFF but
allow users to disable processing Router Advertisements when required by
their network setup. (LP: #1655440)
nplan (0.27) artful; urgency=medium
[ Mathieu Trudel-Lapierre ]
* Fix crash in systemd generator if called by an user on the command-line
* coverage: fix exclusions to properly not cover our "never reached defaults"
[ Dimitri John Ledkov ]
* tests/integrati
* src/networkd.c: Set UseMTU=true by default, whenever DHCP is in use.
(LP: #1717471)
* tests/integrati
nplan (0.26) artful; urgency=medium
...
| Changed in nplan (Ubuntu Xenial): | |
| status: | Fix Committed → Fix Released |
The verification of the Stable Release Update for nplan has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
| Launchpad Janitor (janitor) wrote : | #22 |
This bug was fixed in the package nplan - 0.32~17.04.1
---------------
nplan (0.32~17.04.1) zesty; urgency=medium
* Backport 0.32 to 17.04. (LP: #1713142)
nplan (0.32) bionic; urgency=medium
* src/nm.c: better handle the UUID generation; the order of iterating
through interaces may affect things here. Also make sure the tests catch
a null UUID.
nplan (0.31) bionic; urgency=medium
[ Mathieu Trudel-Lapierre ]
* src/nm.c: generate a UUID for a connection only as needed; when we're
dealing with NM VLANs. (LP: #1712921)
* debian/
failing right from the start when systemd-networkd is disabled.
(LP: #1699371)
* tests/integrati
120 seconds, autopkgtest infrastructure tends to be a little slow for the
network device configuration to be applied and noticed by NM.
(LP: #1699371)
[ Dimitri John Ledkov ]
* Reload udevd to invalidate configuration cache of .rules/.link files
as generate step may have changed them. LP: #1669564
[ Dan Streetman ]
* Add another interface driver exception to netplan replug to prevent unbind
of the Xen VIF interfaces. (LP: #1729573)
nplan (0.30) artful; urgency=medium
* Add an "optional" syntax node for now to all devices. This is unimplemented
for now, but intended to allow users to mark some devices as optional: to
make sure they do not delay boot when configured. (LP: #1664844)
nplan (0.29) artful; urgency=medium
* Fix autopkgtests in a world where /run/NetworkMan
exists. nplan is enabled by default, so it might well have the directory
already created on the filesystem.
nplan (0.28) artful; urgency=medium
* Revert 56cd3eec which disabled IPv6 Router Advertisements by default. It
broke default network config in LXD and was contrary to the defaults used
by the kernel. Reopens LP: 1655440. (LP: #1717404)
* Add "accept-ra:" key for all device types; this will default to OFF but
allow users to disable processing Router Advertisements when required by
their network setup. (LP: #1655440)
nplan (0.27) artful; urgency=medium
[ Mathieu Trudel-Lapierre ]
* Fix crash in systemd generator if called by an user on the command-line
* coverage: fix exclusions to properly not cover our "never reached defaults"
[ Dimitri John Ledkov ]
* tests/integrati
* src/networkd.c: Set UseMTU=true by default, whenever DHCP is in use.
(LP: #1717471)
* tests/integrati
nplan (0.26) artful; urgency=medium
* Bonding:
- Add support for specifying a primary slave. (LP: #1709135)
* Rebind:
- Fix brcmfmac harder. Treat any 'brcmfmac' driver as not supporting
rebind. (LP: #1712224)
* Autopkgtests:
- Add allow-stderr. Systemd now bleats about a the networkd socket still
being around and enabled when we restart the service; but we don't need
to care since we're /restarting/ the service to load the new config.
- Fix the autostart package to be more sensible: we don't really care if
...
| Changed in nplan (Ubuntu Zesty): | |
| status: | Fix Committed → Fix Released |
| Ryan Harper (raharper) wrote : | #23 |
Curtin will pass the MAAS provided network config to the target. In netplan format, the accept-ra configuration is present and this will be passed through to the target system and reflected in the installed system. I'm marking the curtin portion here invalid. If curtin does need to do something (for say xenial deployments/
| Changed in curtin: | |
| status: | New → Invalid |
| Adam Collard (adam-collard) wrote : | #24 |
This bug has not seen any activity in the last 6 months, so it is being automatically closed.
If you are still experiencing this issue, please feel free to re-open.
MAAS Team
| Changed in maas: | |
| status: | Triaged → Invalid |
This is an Ubuntu default setting, and MAAS does not currently change operating-
In order for us to disable the acceptance of IPv6 router advertisements, we would either need to disable IPv6 completely, such as by modifying this sysctl:
net.ipv6.
... or disable just the acceptance of IPv6 router advertisements using this sysctl:
net.ipv6.
I think it seems reasonable that MAAS should be able to configure these settings. However, this is a decision that goes beyond just MAAS. (I'll add curtin to this bug.)