Open Stack

2017-03-24 9:48 GMT+00:00 Jens Rosenboom <j.rosenboom at x-ion.de>:
> 2017-03-24 9:30 GMT+00:00 Simon Leinen <simon.leinen at 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 ipv6_dhcp; however,
>>> if you ask the neutron api it tells slaac is the ipv6_address_mode and
>>> ipv6_ra_mode. But enable_dhcp 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 dhcp_server 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.