Re: [openstack-dev] [neutron][nova] Config drive claims ipv6_dhcp, neutron api says slaac
2017-03-24 17:17 GMT+00:00 Clark Boylan :
> On Fri, Mar 24, 2017, at 05:24 AM, Jens Rosenboom wrote:
>> 2017-03-24 9:48 GMT+00:00 Jens Rosenboom :
>> > 2017-03-24 9:30 GMT+00:00 Simon Leinen :
>> >> 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.
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] Config drive claims ipv6_dhcp, neutron api says slaac
On Fri, Mar 24, 2017, at 05:24 AM, Jens Rosenboom wrote:
> 2017-03-24 9:48 GMT+00:00 Jens Rosenboom :
> > 2017-03-24 9:30 GMT+00:00 Simon Leinen :
> >> 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] Config drive claims ipv6_dhcp, neutron api says slaac
2017-03-24 9:48 GMT+00:00 Jens Rosenboom :
> 2017-03-24 9:30 GMT+00:00 Simon Leinen :
>> 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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] Config drive claims ipv6_dhcp, neutron api says slaac
2017-03-24 9:30 GMT+00:00 Simon Leinen :
> 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.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][nova] Config drive claims ipv6_dhcp, neutron api says slaac
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.
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 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 :-( 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
