2017-03-24 9:48 GMT+00:00 Jens Rosenboom <[email protected]>: > 2017-03-24 9:30 GMT+00:00 Simon Leinen <[email protected]>: >> 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
