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

Jens Rosenboom j.rosenboom at x-ion.de
Fri Mar 24 09:48:29 UTC 2017


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

> 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 ipv6_address_mode (and
> maybe also ipv6_ra_mode) 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.



More information about the OpenStack-dev mailing list