group.of.nepali.translators team mailing list archive

[Ryan Harper <1655440@xxxxxxxxxxxxxxxxxx>]

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/ifupdown) then please
re-open the task and we'll triage accordingly.

** Changed in: curtin
       Status: New => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1655440

Title:
  "unconfigured" NIC can still get IPv6 addresses via RA

Status in curtin:
  Invalid
Status in MAAS:
  Triaged
Status in netplan:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in nplan source package in Xenial:
  Fix Released
Status in nplan source package in Zesty:
  Fix Released

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1655440/+subscriptions