| 2017-01-10 19:45:16 |
Andreas Hasenack |
bug |
|
|
added bug |
| 2017-01-14 00:08:19 |
Mike Pontillo |
bug task added |
|
curtin |
|
| 2017-01-14 00:08:24 |
Mike Pontillo |
maas: status |
New |
Triaged |
|
| 2017-01-14 00:08:26 |
Mike Pontillo |
maas: importance |
Undecided |
Wishlist |
|
| 2017-01-14 00:08:59 |
Mike Pontillo |
bug task added |
|
netplan |
|
| 2017-01-16 06:31:54 |
Andrew McDermott |
bug |
|
|
added subscriber Andrew McDermott |
| 2017-01-25 12:59:34 |
Andreas Hasenack |
bug |
|
|
added subscriber Landscape |
| 2017-02-16 07:50:21 |
Andrew McDermott |
removed subscriber Andrew McDermott |
|
|
|
| 2017-02-20 21:34:08 |
Mathieu Trudel-Lapierre |
netplan: status |
New |
Triaged |
|
| 2017-02-20 21:34:10 |
Mathieu Trudel-Lapierre |
netplan: importance |
Undecided |
High |
|
| 2017-02-20 21:34:12 |
Mathieu Trudel-Lapierre |
netplan: assignee |
|
Mathieu Trudel-Lapierre (cyphermox) |
|
| 2017-07-13 00:45:07 |
Mathieu Trudel-Lapierre |
bug task added |
|
nplan (Ubuntu) |
|
| 2017-07-13 00:45:13 |
Mathieu Trudel-Lapierre |
nplan (Ubuntu): status |
New |
Triaged |
|
| 2017-07-13 00:45:15 |
Mathieu Trudel-Lapierre |
nplan (Ubuntu): importance |
Undecided |
High |
|
| 2017-07-13 00:45:18 |
Mathieu Trudel-Lapierre |
nplan (Ubuntu): assignee |
|
Mathieu Trudel-Lapierre (cyphermox) |
|
| 2017-07-17 17:34:57 |
Launchpad Janitor |
nplan (Ubuntu): status |
Triaged |
Fix Released |
|
| 2017-08-01 13:48:13 |
Mathieu Trudel-Lapierre |
netplan: status |
Triaged |
Fix Released |
|
| 2017-08-25 19:44:12 |
Mathieu Trudel-Lapierre |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-08-25 19:44:12 |
Mathieu Trudel-Lapierre |
bug task added |
|
nplan (Ubuntu Xenial) |
|
| 2017-08-25 19:45:28 |
Mathieu Trudel-Lapierre |
nplan (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2017-08-25 19:45:29 |
Mathieu Trudel-Lapierre |
nplan (Ubuntu Xenial): status |
New |
In Progress |
|
| 2017-08-25 19:45:33 |
Mathieu Trudel-Lapierre |
nplan (Ubuntu Xenial): assignee |
|
Mathieu Trudel-Lapierre (cyphermox) |
|
| 2017-08-25 19:51:13 |
Mathieu Trudel-Lapierre |
description |
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. |
[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 there is no nplan configuration for the device on the network
3) Verify that there is no IPv6 address set; using 'ip -6 addr'.
[Regression potential]
Any network setup that relies on the existing "omitted" configuration to implicitly allow IPv6 would fail to configure correctly. 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. |
|
| 2017-09-26 17:36:15 |
Mathieu Trudel-Lapierre |
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 there is no nplan configuration for the device on the network
3) Verify that there is no IPv6 address set; using 'ip -6 addr'.
[Regression potential]
Any network setup that relies on the existing "omitted" configuration to implicitly allow IPv6 would fail to configure correctly. 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. |
[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. |
|
| 2017-09-29 17:44:13 |
Francis Ginther |
tags |
landscape |
id-5966b7c8f96a052f6904d7cb landscape |
|
| 2017-10-06 22:06:55 |
Brian Murray |
nplan (Ubuntu Zesty): status |
New |
Fix Committed |
|
| 2017-10-06 22:06:58 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-10-06 22:07:00 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2017-10-06 22:07:04 |
Brian Murray |
tags |
id-5966b7c8f96a052f6904d7cb landscape |
id-5966b7c8f96a052f6904d7cb landscape verification-needed verification-needed-zesty |
|
| 2017-10-06 22:15:20 |
Brian Murray |
nplan (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2017-10-06 22:15:26 |
Brian Murray |
tags |
id-5966b7c8f96a052f6904d7cb landscape verification-needed verification-needed-zesty |
id-5966b7c8f96a052f6904d7cb landscape verification-needed verification-needed-xenial verification-needed-zesty |
|
| 2017-10-20 18:03:13 |
Mathieu Trudel-Lapierre |
tags |
id-5966b7c8f96a052f6904d7cb landscape verification-needed verification-needed-xenial verification-needed-zesty |
id-5966b7c8f96a052f6904d7cb landscape verification-done-xenial verification-needed verification-needed-zesty |
|
| 2017-11-06 16:57:05 |
Mathieu Trudel-Lapierre |
tags |
id-5966b7c8f96a052f6904d7cb landscape verification-done-xenial verification-needed verification-needed-zesty |
id-5966b7c8f96a052f6904d7cb landscape verification-done-xenial verification-done-zesty |
|
| 2017-11-23 16:10:16 |
Łukasz Zemczak |
tags |
id-5966b7c8f96a052f6904d7cb landscape verification-done-xenial verification-done-zesty |
id-5966b7c8f96a052f6904d7cb landscape verification-done-xenial verification-needed verification-needed-zesty |
|
| 2017-11-23 16:59:59 |
Łukasz Zemczak |
tags |
id-5966b7c8f96a052f6904d7cb landscape verification-done-xenial verification-needed verification-needed-zesty |
id-5966b7c8f96a052f6904d7cb landscape verification-needed verification-needed-xenial verification-needed-zesty |
|
| 2017-11-28 21:10:14 |
Mathieu Trudel-Lapierre |
tags |
id-5966b7c8f96a052f6904d7cb landscape verification-needed verification-needed-xenial verification-needed-zesty |
id-5966b7c8f96a052f6904d7cb landscape verification-failed-xenial verification-needed verification-needed-zesty |
|
| 2017-11-29 21:26:30 |
Brian Murray |
tags |
id-5966b7c8f96a052f6904d7cb landscape verification-failed-xenial verification-needed verification-needed-zesty |
id-5966b7c8f96a052f6904d7cb landscape verification-needed verification-needed-xenial verification-needed-zesty |
|
| 2017-12-04 14:02:36 |
Mathieu Trudel-Lapierre |
tags |
id-5966b7c8f96a052f6904d7cb landscape verification-needed verification-needed-xenial verification-needed-zesty |
id-5966b7c8f96a052f6904d7cb landscape verification-failed-xenial verification-needed verification-needed-zesty |
|
| 2017-12-05 09:14:11 |
Łukasz Zemczak |
tags |
id-5966b7c8f96a052f6904d7cb landscape verification-failed-xenial verification-needed verification-needed-zesty |
id-5966b7c8f96a052f6904d7cb landscape verification-needed verification-needed-xenial verification-needed-zesty |
|
| 2017-12-13 20:10:22 |
Mathieu Trudel-Lapierre |
tags |
id-5966b7c8f96a052f6904d7cb landscape verification-needed verification-needed-xenial verification-needed-zesty |
id-5966b7c8f96a052f6904d7cb landscape verification-done-xenial verification-done-zesty |
|
| 2018-01-10 02:34:58 |
Launchpad Janitor |
nplan (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2018-01-10 02:35:49 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-01-10 02:37:12 |
Launchpad Janitor |
nplan (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2019-03-06 01:17:29 |
Ryan Harper |
curtin: status |
New |
Invalid |
|
| 2019-09-19 14:53:06 |
Adam Collard |
maas: status |
Triaged |
Invalid |
|
