Executive summary: I expected this test to go much differently. This bug
should probably be "cloud-init does not wait for IPv6 config in dual-
stack network"
--
One of my initial tests was in my primary dual-stack network, and it
also worked similar to your example.
Excerpt from my deploy script:
iid="iid-$(printf "%x" $(date +%s))"
virt-install --name ${vm_name} --memory ${mem_size} \
--sysinfo
system_serial="ds=nocloud-net;h=${vm_name};i=${iid};s=http://gemini.home.nivex.net/cidata/";
\
--controller=scsi,model=virtio-scsi \
--disk "path=${vdisk},bus=scsi,discard=unmap" \
--import \
--os-variant ubuntu18.04 \
--machine q35 \
--network network=ovs-net,target=ve0-${vm_name} \
--graphics none \
--noautoconsole
cloud-init[321]: Cloud-init v. 20.1-10-g71af48df-0ubuntu5 running 'init' at
Tue, 19 May 2020 23:03:21 +0000. Up 6.19 seconds.
cloud-init[321]: ci-info: ++++++++++++++++++++++++++++++++++++++Net device
info+++++++++++++++++++++++++++++++++++++++
cloud-init[321]: ci-info:
+--------+-------+----------------------------+---------------+--------+-------------------+
cloud-init[321]: ci-info: | Device | Up | Address |
Mask | Scope | Hw-Address |
cloud-init[321]: ci-info:
+--------+-------+----------------------------+---------------+--------+-------------------+
cloud-init[321]: ci-info: | enp1s0 | True | 172.31.3.134 |
255.255.255.0 | global | 52:54:00:4d:27:e9 |
cloud-init[321]: ci-info: | enp1s0 | True | fe80::5054:ff:fe4d:27e9/64 |
. | link | 52:54:00:4d:27:e9 |
cloud-init[321]: ci-info: | lo | True | 127.0.0.1 |
255.0.0.0 | host | . |
cloud-init[321]: ci-info: | lo | True | ::1/128 |
. | host | . |
cloud-init[321]: ci-info: | sit0 | False | . |
. | . | . |
cloud-init[321]: ci-info: | tunl0 | False | . |
. | . | . |
cloud-init[321]: ci-info:
+--------+-------+----------------------------+---------------+--------+-------------------+
cloud-init[321]: ci-info: +++++++++++++++++++++++++++++Route IPv4
info++++++++++++++++++++++++++++++
cloud-init[321]: ci-info:
+-------+-------------+------------+-----------------+-----------+-------+
cloud-init[321]: ci-info: | Route | Destination | Gateway | Genmask
| Interface | Flags |
cloud-init[321]: ci-info:
+-------+-------------+------------+-----------------+-----------+-------+
cloud-init[321]: ci-info: | 0 | 0.0.0.0 | 172.31.3.1 | 0.0.0.0
| enp1s0 | UG |
cloud-init[321]: ci-info: | 1 | 172.31.3.0 | 0.0.0.0 | 255.255.255.0
| enp1s0 | U |
cloud-init[321]: ci-info: | 2 | 172.31.3.1 | 0.0.0.0 | 255.255.255.255
| enp1s0 | UH |
cloud-init[321]: ci-info:
+-------+-------------+------------+-----------------+-----------+-------+
cloud-init[321]: ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++
cloud-init[321]: ci-info: +-------+-------------+---------+-----------+-------+
cloud-init[321]: ci-info: | Route | Destination | Gateway | Interface | Flags |
cloud-init[321]: ci-info: +-------+-------------+---------+-----------+-------+
cloud-init[321]: ci-info: | 1 | fe80::/64 | :: | enp1s0 | U |
cloud-init[321]: ci-info: | 3 | local | :: | enp1s0 | U |
cloud-init[321]: ci-info: | 4 | ff00::/8 | :: | enp1s0 | U |
cloud-init[321]: ci-info: +-------+-------------+---------+-----------+-------+
Note the absence of an IPv6 global address or default route. We end up
resolving the HTTP server via IPv4 DNS.
We also see in the access log on the webserver that the link-local address was
used:
fe80::5054:ff:fe4d:27e9 - - [19/May/2020:19:03:23 -0400] "GET /cidata/meta-data
HTTP/1.1" 200 256 "-" "Cloud-Init/20.1-10-g71af48df-0ubuntu5"
fe80::5054:ff:fe4d:27e9 - - [19/May/2020:19:03:23 -0400] "GET /cidata/user-data
HTTP/1.1" 200 2059 "-" "Cloud-Init/20.1-10-g71af48df-0ubuntu5"
Let's try out this example:
http -------- router --------- cloud
server vlan1 | vlan101 device
|
| vlan121
|
dns server
vlan101 has an IPv6 router that announces a prefix and RDNSS
information. It has no IPv4 available.
We run an almost identical command to above, but putting the test VM in the new
VLAN with a portgroup parameter:
virt-install --name ${vm_name} --memory ${mem_size} \
--sysinfo
system_serial="ds=nocloud-net;h=${vm_name};i=${iid};s=http://gemini.home.nivex.net/cidata/";
\
--controller=scsi,model=virtio-scsi \
--disk "path=${vdisk},bus=scsi,discard=unmap" \
--import \
--os-variant ubuntu18.04 \
--machine q35 \
--network network=ovs-net,portgroup=v6only-slaac,target=ve0-${vm_name} \
--graphics none \
--noautoconsole
And here's where it got interesting. In the spirit of being a good
scientist:
my hypothesis: I expected this to fail straight away
actual result: It worked after a lengthy wait in "Waiting for network to be
configured".
cloud-init[320]: Cloud-init v. 20.1-10-g71af48df-0ubuntu5 running 'init' at
Tue, 19 May 2020 23:12:38 +0000. Up 124.72 seconds.
cloud-init[320]: ci-info: +++++++++++++++++++++++++++++++++++++++++++Net device
info++++++++++++++++++++++++++++++++++++++++++++
cloud-init[320]: ci-info:
+--------+-------+------------------------------------------+-----------+--------+-------------------+
cloud-init[320]: ci-info: | Device | Up | Address
| Mask | Scope | Hw-Address |
cloud-init[320]: ci-info:
+--------+-------+------------------------------------------+-----------+--------+-------------------+
cloud-init[320]: ci-info: | enp1s0 | True |
2606:a000:a442:9801:5054:ff:fe01:af45/64 | . | global |
52:54:00:01:af:45 |
cloud-init[320]: ci-info: | enp1s0 | True | fe80::5054:ff:fe01:af45/64
| . | link | 52:54:00:01:af:45 |
cloud-init[320]: ci-info: | lo | True | 127.0.0.1
| 255.0.0.0 | host | . |
cloud-init[320]: ci-info: | lo | True | ::1/128
| . | host | . |
cloud-init[320]: ci-info: | sit0 | False | .
| . | . | . |
cloud-init[320]: ci-info: | tunl0 | False | .
| . | . | . |
cloud-init[320]: ci-info:
+--------+-------+------------------------------------------+-----------+--------+-------------------+
cloud-init[320]: ci-info: ++++++++++++++++++++++++++++++++++Route IPv6
info++++++++++++++++++++++++++++++++++
cloud-init[320]: ci-info:
+-------+--------------------------+--------------------------+-----------+-------+
cloud-init[320]: ci-info: | Route | Destination | Gateway
| Interface | Flags |
cloud-init[320]: ci-info:
+-------+--------------------------+--------------------------+-----------+-------+
cloud-init[320]: ci-info: | 1 | 2606:a000:a442:9801::/64 | ::
| enp1s0 | Ue |
cloud-init[320]: ci-info: | 2 | fe80::/64 | ::
| enp1s0 | U |
cloud-init[320]: ci-info: | 3 | ::/0 |
fe80::7444:1ff:fe96:504e | enp1s0 | UGe |
cloud-init[320]: ci-info: | 5 | local | ::
| enp1s0 | U |
cloud-init[320]: ci-info: | 6 | local | ::
| enp1s0 | U |
cloud-init[320]: ci-info: | 7 | ff00::/8 | ::
| enp1s0 | U |
cloud-init[320]: ci-info:
+-------+--------------------------+--------------------------+-----------+-------+
So it looks like cloud-init is proceeding forward on a dual-stack network as
soon as it gets an IPv4 config.
My suggestions:
- Wait an extra tick if you've got IPv4 to see if it's going to pick up IPv6
configuration as well.
- Shorten the timeout waiting for IPv4 if you get an IPv6 configuration.
I do still have some concerns about the lack of a "dhcp6: true" in
/etc/netplan/50-cloud-init.yaml inside the resulting VM.
It makes me wonder if we're getting some of this IPv6 configuration by luck
rather than deliberate action.
Per https://netplan.io/reference:
dhcp4 (bool)
Enable DHCP for IPv4. Off by default.
dhcp6 (bool)
Enable DHCP for IPv6. Off by default. ...
This tells me that someone enabled dhcp4 but not dhcp6 for cloud-init.
We need to make sure we have feature parity across the protocols.
** Changed in: cloud-init (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1878682
Title:
IPv6 not enabled by default
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1878682/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
