settingsLogin | Registersettings

[openstack-dev] [neutron][nova] Config drive claims ipv6_dhcp, neutron api says slaac

0 votes

Hello,

The infra team ran into glean not being able to correctly configure host
interfaces on boot. The trigger for this appears to be this change to
nova which enabled ipv6 in metadata/config drive [0]. I don't think
there is anything wrong with this but it exposed another interesting
behavior.

The config drive networkdata.json is:
{
"links": [
{
"ethernet
macaddress": "fa:16:3e:9e:84:5c",
"id": "tap14b906ba-8c",
"mtu": 1450,
"type": "ovs",
"vif
id": "14b906ba-8c2c-4829-852e-2987d25ceabc"
}
],
"networks": [
{
"id": "network0",
"link": "tap14b906ba-8c",
"networkid": "7ee08c00-7323-4f18-94bb-67e081520e70",
"type": "ipv4
dhcp"
},
{
"id": "network1",
"link": "tap14b906ba-8c",
"networkid": "7ee08c00-7323-4f18-94bb-67e081520e70",
"type": "ipv6
dhcp"
}
],
"services": []
}

You'll notice that the network1 entry has a type of ipv6dhcp; however,
if you ask the neutron api it tells slaac is the ipv6
addressmode and
ipv6
ramode. But enabledhcp is also set to True. So which is it? Is
there a bug here or am I missing something obvious? At the very least it
appears that the config drive info is incomplete and does not include
the slaac info.

clarkb@ubuntu-xenial-internap-mtl01-8040461:~$ openstack --os-cloud
devstack network show 7ee08c00-7323-4f18-94bb-67e081520e70
+---------------------------+----------------------------------------------------------------------------+
| Field | Value
|
+---------------------------+----------------------------------------------------------------------------+
| adminstateup | UP
|
| availabilityzonehints |
|
| availabilityzones | nova
|
| created
at | 2017-03-23T14:35:33Z
|
| description |
|
| dnsdomain | None
|
| id | 7ee08c00-7323-4f18-94bb-67e081520e70
|
| ipv4
addressscope | None
|
| ipv6
addressscope | None
|
| is
default | None
|
| mtu | 1450
|
| name | private
|
| portsecurityenabled | True
|
| projectid | 46dd6a74cf244079a4f97ba1fc493793
|
| provider:network
type | None
|
| provider:physicalnetwork | None
|
| provider:segmentation
id | None
|
| qospolicyid | None
|
| revisionnumber | 7
|
| router:external | Internal
|
| segments | None
|
| shared | False
|
| status | ACTIVE
|
| subnets | 2cbae31d-27be-42aa-b543-b2baa5e52130,
92664772-b719-4b2d-9d47-e657be990c0b |
| updated
at | 2017-03-23T14:35:40Z
|
+---------------------------+----------------------------------------------------------------------------+
clarkb@ubuntu-xenial-internap-mtl01-8040461:~$ openstack --os-cloud
devstack subnet show 2cbae31d-27be-42aa-b543-b2baa5e52130
+-------------------+--------------------------------------------------------+
| Field | Value
|
+-------------------+--------------------------------------------------------+
| allocationpools |
fd5a:a41c:fe7a::2-fd5a:a41c:fe7a:0:ffff:ffff:ffff:ffff |
| cidr | fd5a:a41c:fe7a::/64
|
| created
at | 2017-03-23T14:35:40Z
|
| description |
|
| dnsnameservers |
|
| enable
dhcp | True
|
| gatewayip | fd5a:a41c:fe7a::1
|
| host
routes |
|
| id | 2cbae31d-27be-42aa-b543-b2baa5e52130
|
| ipversion | 6
|
| ipv6
addressmode | slaac
|
| ipv6
ramode | slaac
|
| name | ipv6-private-subnet
|
| network
id | 7ee08c00-7323-4f18-94bb-67e081520e70
|
| projectid | 46dd6a74cf244079a4f97ba1fc493793
|
| revision
number | 2
|
| segmentid | None
|
| service
types |
|
| subnetpoolid | eba9b529-80ce-4906-a895-ca333731afeb
|
| updated
at | 2017-03-23T14:35:40Z
|
+-------------------+--------------------------------------------------------+

This job is set up using a default devstack + neutron provided network
setup, then we run neutron alongside that so I don't think we are doing
anything here to affect this.

[0] https://review.openstack.org/#/c/430910/

Thanks,
Clark


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Mar 27, 2017 in openstack-dev by Clark_Boylan (8,800 points)   1 2 4

5 Responses

0 votes

Clark Boylan writes:
[...]

    {
        "id": "network1",
        "link": "tap14b906ba-8c",
        "network_id": "7ee08c00-7323-4f18-94bb-67e081520e70",
        "type": "ipv6_dhcp"
    }
],
"services": []

}

You'll notice that the network1 entry has a type of ipv6dhcp; however,
if you ask the neutron api it tells slaac is the ipv6
addressmode and
ipv6
ramode. But enabledhcp is also set to True. So which is it? Is
there a bug here or am I missing something obvious? At the very least it
appears that the config drive info is incomplete and does not include
the slaac info.

Here's my hypothesis... "type ipvX_dhcp" really means "Neutron will
manage ipvX addresses", not necessarily that it will use the DHCP
protocol. For IPv4 it will always imply DHCP, but for IPv6 the method
to tell the port user (instance) the address might be SLAAC (for the
"slaac" and "dhcpv6-stateless" modes) or Stateful DHCPv6 (for the
"dhcpv6-stateful" mode).

I think it would indeed be useful to convey the ipv6addressmode (and
maybe also ipv6ramode) in the metadata; but in principle a system
should be able to infer the supported mode by looking at the flags in
the RAs (Router Advertisements). It's just that most GNU/Linux
distributions ignore what the RAs say :-( so you need to configure
/etc/network/interfaces explicitly for either "auto" (SLAAC) or "dhcp"
(DHCPv6).)
--
Simon.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 24, 2017 by Simon_Leinen (620 points)   1
0 votes

2017-03-24 9:30 GMT+00:00 Simon Leinen simon.leinen@switch.ch:

Clark Boylan writes:
[...]

    {
        "id": "network1",
        "link": "tap14b906ba-8c",
        "network_id": "7ee08c00-7323-4f18-94bb-67e081520e70",
        "type": "ipv6_dhcp"
    }
],
"services": []

}

You'll notice that the network1 entry has a type of ipv6dhcp; however,
if you ask the neutron api it tells slaac is the ipv6
addressmode and
ipv6
ramode. But enabledhcp is also set to True. So which is it? Is
there a bug here or am I missing something obvious? At the very least it
appears that the config drive info is incomplete and does not include
the slaac info.

Two small notes:

  1. The enable_dhcp must be true also for slaac, its real meaning
    is not "dhcp is enabled", but "neutron will take care of address assignments".

  2. The situation is not specific to the config drive being used, the identical
    information is presented at
    http://169.254.169.254/openstack/latest/network_data.json

Here's my hypothesis... "type ipvX_dhcp" really means "Neutron will
manage ipvX addresses", not necessarily that it will use the DHCP
protocol.

Right, this is the code part that produces the info:
http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/netutils.py#n267

For IPv4 it will always imply DHCP, but for IPv6 the method
to tell the port user (instance) the address might be SLAAC (for the
"slaac" and "dhcpv6-stateless" modes) or Stateful DHCPv6 (for the
"dhcpv6-stateful" mode).

I think it would indeed be useful to convey the ipv6addressmode (and
maybe also ipv6ramode) in the metadata; but in principle a system
should be able to infer the supported mode by looking at the flags in
the RAs (Router Advertisements). It's just that most GNU/Linux
distributions ignore what the RAs say :-(

Which is sad but true indeed, but IMO would be the correct solution in
the long run,
that's we the flags are there in the first place. FWIW there is a beta
version of cirros
that tries to implement this, but it has not been released yet.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 24, 2017 by Dr._Jens_Rosenboom (1,680 points)   3
0 votes

2017-03-24 9:48 GMT+00:00 Jens Rosenboom j.rosenboom@x-ion.de:

2017-03-24 9:30 GMT+00:00 Simon Leinen simon.leinen@switch.ch:

Clark Boylan writes:
[...]

    {
        "id": "network1",
        "link": "tap14b906ba-8c",
        "network_id": "7ee08c00-7323-4f18-94bb-67e081520e70",
        "type": "ipv6_dhcp"
    }
],
"services": []

}

You'll notice that the network1 entry has a type of ipv6dhcp; however,
if you ask the neutron api it tells slaac is the ipv6
addressmode and
ipv6
ramode. But enabledhcp is also set to True. So which is it? Is
there a bug here or am I missing something obvious? At the very least it
appears that the config drive info is incomplete and does not include
the slaac info.

Two small notes:

  1. The enable_dhcp must be true also for slaac, its real meaning
    is not "dhcp is enabled", but "neutron will take care of address assignments".

  2. The situation is not specific to the config drive being used, the identical
    information is presented at
    http://169.254.169.254/openstack/latest/network_data.json

Here's my hypothesis... "type ipvX_dhcp" really means "Neutron will
manage ipvX addresses", not necessarily that it will use the DHCP
protocol.

Right, this is the code part that produces the info:
http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/netutils.py#n267

Actually, there seems to be a bug here, or maybe two.

There is a dhcpserver address set in the info for the subnet even when it
has type slaac, which cause the logic above to output type "ipv6
dhcp" instead
of "ipv6". Either that is a bug in Neutron or there is some hidden reason to
also have a DHCP server address for slaac.

It certainly is a bug in Nova to rely on that attribute in order to decide upon
the network type, as for dhcpv6-stateless we would certainly have a dhcp_server
defined additional information, but still the address configuration
type is slaac
and so the network type should be "ipv6" and the address for that subnet
be included in the metadata.

P.S.: I vaguely remember a discussion that the dhcp_server should also
send RAs in case of networks not having a router, maybe that is the reason
for the behaviour above. Though I consider that scenario broken, RAs are
"*router* advertisements" and thus should only be sent by routers. If
people decide to deploy IPv6 on an isolated subnet, they should either
be using DHCP or no auto-configuration at all.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 24, 2017 by Dr._Jens_Rosenboom (1,680 points)   3
0 votes

On Fri, Mar 24, 2017, at 05:24 AM, Jens Rosenboom wrote:
2017-03-24 9:48 GMT+00:00 Jens Rosenboom j.rosenboom@x-ion.de:

2017-03-24 9:30 GMT+00:00 Simon Leinen simon.leinen@switch.ch:

Clark Boylan writes:
[...]

    {
        "id": "network1",
        "link": "tap14b906ba-8c",
        "network_id": "7ee08c00-7323-4f18-94bb-67e081520e70",
        "type": "ipv6_dhcp"
    }
],
"services": []

}

You'll notice that the network1 entry has a type of ipv6dhcp; however,
if you ask the neutron api it tells slaac is the ipv6
addressmode and
ipv6
ramode. But enabledhcp is also set to True. So which is it? Is
there a bug here or am I missing something obvious? At the very least it
appears that the config drive info is incomplete and does not include
the slaac info.

Two small notes:

  1. The enable_dhcp must be true also for slaac, its real meaning
    is not "dhcp is enabled", but "neutron will take care of address assignments".

  2. The situation is not specific to the config drive being used, the identical
    information is presented at
    http://169.254.169.254/openstack/latest/network_data.json

Here's my hypothesis... "type ipvX_dhcp" really means "Neutron will
manage ipvX addresses", not necessarily that it will use the DHCP
protocol.

Right, this is the code part that produces the info:
http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/netutils.py#n267

Actually, there seems to be a bug here, or maybe two.

There is a dhcpserver address set in the info for the subnet even when
it
has type slaac, which cause the logic above to output type "ipv6
dhcp"
instead
of "ipv6". Either that is a bug in Neutron or there is some hidden reason
to
also have a DHCP server address for slaac.

It certainly is a bug in Nova to rely on that attribute in order to
decide upon
the network type, as for dhcpv6-stateless we would certainly have a
dhcp_server
defined additional information, but still the address configuration
type is slaac
and so the network type should be "ipv6" and the address for that subnet
be included in the metadata.

P.S.: I vaguely remember a discussion that the dhcp_server should also
send RAs in case of networks not having a router, maybe that is the
reason
for the behaviour above. Though I consider that scenario broken, RAs are
"*router* advertisements" and thus should only be sent by routers. If
people decide to deploy IPv6 on an isolated subnet, they should either
be using DHCP or no auto-configuration at all.

Thank you for looking into this. As mentioned earlier in the thread
glean needs to be able to configure the Linux interfaces explicitly for
auto or dhcp so ideally the metadata info would also be explicit. I
think that setting the type to "ipv6_dhcp" when using slaac has to be a
bug when considering this because it means glean and other tools like
cloud init will not be able to configure Linux interfaces properly.

Are you going to be filing the bugs against nova and/or neutron? I think
you understand the fine details better than I do, but I am happy to help
out filing and pushing things as this would affect our use case quite a
bit. Just let me know how I can help.

Thanks,
Clark


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 24, 2017 by Clark_Boylan (8,800 points)   1 2 4
0 votes

2017-03-24 17:17 GMT+00:00 Clark Boylan cboylan@sapwetik.org:

On Fri, Mar 24, 2017, at 05:24 AM, Jens Rosenboom wrote:

2017-03-24 9:48 GMT+00:00 Jens Rosenboom j.rosenboom@x-ion.de:

2017-03-24 9:30 GMT+00:00 Simon Leinen simon.leinen@switch.ch:

Clark Boylan writes:
[...]

    {
        "id": "network1",
        "link": "tap14b906ba-8c",
        "network_id": "7ee08c00-7323-4f18-94bb-67e081520e70",
        "type": "ipv6_dhcp"
    }
],
"services": []

}

You'll notice that the network1 entry has a type of ipv6dhcp; however,
if you ask the neutron api it tells slaac is the ipv6
addressmode and
ipv6
ramode. But enabledhcp is also set to True. So which is it? Is
there a bug here or am I missing something obvious? At the very least it
appears that the config drive info is incomplete and does not include
the slaac info.

Two small notes:

  1. The enable_dhcp must be true also for slaac, its real meaning
    is not "dhcp is enabled", but "neutron will take care of address assignments".

  2. The situation is not specific to the config drive being used, the identical
    information is presented at
    http://169.254.169.254/openstack/latest/network_data.json

Here's my hypothesis... "type ipvX_dhcp" really means "Neutron will
manage ipvX addresses", not necessarily that it will use the DHCP
protocol.

Right, this is the code part that produces the info:
http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/netutils.py#n267

Actually, there seems to be a bug here, or maybe two.

There is a dhcpserver address set in the info for the subnet even when
it
has type slaac, which cause the logic above to output type "ipv6
dhcp"
instead
of "ipv6". Either that is a bug in Neutron or there is some hidden reason
to
also have a DHCP server address for slaac.

It certainly is a bug in Nova to rely on that attribute in order to
decide upon
the network type, as for dhcpv6-stateless we would certainly have a
dhcp_server
defined additional information, but still the address configuration
type is slaac
and so the network type should be "ipv6" and the address for that subnet
be included in the metadata.

P.S.: I vaguely remember a discussion that the dhcp_server should also
send RAs in case of networks not having a router, maybe that is the
reason
for the behaviour above. Though I consider that scenario broken, RAs are
"*router* advertisements" and thus should only be sent by routers. If
people decide to deploy IPv6 on an isolated subnet, they should either
be using DHCP or no auto-configuration at all.

Thank you for looking into this. As mentioned earlier in the thread
glean needs to be able to configure the Linux interfaces explicitly for
auto or dhcp so ideally the metadata info would also be explicit. I
think that setting the type to "ipv6_dhcp" when using slaac has to be a
bug when considering this because it means glean and other tools like
cloud init will not be able to configure Linux interfaces properly.

Are you going to be filing the bugs against nova and/or neutron? I think
you understand the fine details better than I do, but I am happy to help
out filing and pushing things as this would affect our use case quite a
bit. Just let me know how I can help.

IMO this is a nova bug, neutron does provide all the information that
is needed, its just that nova chooses to filter some of it:

https://bugs.launchpad.net/nova/+bug/1676363


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 27, 2017 by Dr._Jens_Rosenboom (1,680 points)   3
...