Open Stack

On Fri, Mar 24, 2017, at 05:24 AM, Jens Rosenboom wrote:
> 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.

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