-
Notifications
You must be signed in to change notification settings - Fork 908
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPv6-enabled EC2 subnets always have dhcp enabled #3980
Comments
Launchpad user mhayden(mhayden-redhat-bugs) wrote on 2022-06-01T15:28:42+00:00 A Fedora user opened an issue[0] about an issue with cloud-init on EC2. When they launch an instance on a IPv6-enabled subnet, cloud-init sets the However, AWS uses router advertisements to let instances know about the nearest router. Using the A workaround is to run NetworkManager commands to fix the issue:
The instance immediately routes IPv6 traffic after making that change. The dhcp setting appears to be applied automatically for EC2 subnets with IPv6 addresses assigned[1]. I would expect Thank you! [0] https://pagure.io/cloud-sig/issue/382 cloud-init/cloudinit/sources/DataSourceEc2.py Lines 861 to 863 in 53a995e
|
When cloud-init finds any ipv6 information in the instance metadata, it automatically enables dhcp6 for the network interface. However, this brings up the instance with a broken IPv6 configuration because SLAAC should be used for almost all situations on EC2. Red Hat BZ: https://bugzilla.redhat.com/show_bug.cgi?id=2092459 Fedora Pagure: https://pagure.io/cloud-sig/issue/382 Upstream: https://bugs.launchpad.net/cloud-init/+bug/1976526 Fixes: canonical#3980 Signed-off-by: Major Hayden <major@redhat.com>
When cloud-init finds any ipv6 information in the instance metadata, it automatically enables dhcp6 for the network interface. However, this brings up the instance with a broken IPv6 configuration because SLAAC should be used for almost all situations on EC2. Red Hat BZ: https://bugzilla.redhat.com/show_bug.cgi?id=2092459 Fedora Pagure: https://pagure.io/cloud-sig/issue/382 Upstream: https://bugs.launchpad.net/cloud-init/+bug/1976526 Fixes: canonical#3980 Signed-off-by: Major Hayden <major@redhat.com>
After [0, 1], dhcp6 is going to be always false after upgrading cloud-init. Correct this in the integration test. Refs: [0] canonical#3980 [1] https://bugs.launchpad.net/cloud-init/+bug/1976526
On systems without NetworkManager (directly used, or as a Netplan backend), the switch to As shown in #5131, Ubuntu systems upgrading cloud-init to 24.1.x in bionic, focal, jammy and mantic. Do we want to patch this fix out for b, f, j and m? @holmanb. |
After [0, 1], dhcp6 is going to be always false after upgrading cloud-init. Correct this in the integration test. Refs: [0] #3980 [1] https://bugs.launchpad.net/cloud-init/+bug/1976526
When cloud-init finds any ipv6 information in the instance metadata, it automatically enables dhcp6 for the network interface. However, this brings up the instance with a broken IPv6 configuration because SLAAC should be used for almost all situations on EC2. Red Hat BZ: https://bugzilla.redhat.com/show_bug.cgi?id=2092459 Fedora Pagure: https://pagure.io/cloud-sig/issue/382 Upstream: https://bugs.launchpad.net/cloud-init/+bug/1976526 Fixes GH-3980 Signed-off-by: Major Hayden <major@redhat.com>
After [0, 1], dhcp6 is going to be always false after upgrading cloud-init. Correct this in the integration test. Refs: [0] #3980 [1] https://bugs.launchpad.net/cloud-init/+bug/1976526
When cloud-init finds any ipv6 information in the instance metadata, it automatically enables dhcp6 for the network interface. However, this brings up the instance with a broken IPv6 configuration because SLAAC should be used for almost all situations on EC2. Red Hat BZ: https://bugzilla.redhat.com/show_bug.cgi?id=2092459 Fedora Pagure: https://pagure.io/cloud-sig/issue/382 Upstream: https://bugs.launchpad.net/cloud-init/+bug/1976526 Fixes GH-3980 Signed-off-by: Major Hayden <major@redhat.com>
After [0, 1], dhcp6 is going to be always false after upgrading cloud-init. Correct this in the integration test. Refs: [0] #3980 [1] https://bugs.launchpad.net/cloud-init/+bug/1976526
When cloud-init finds any ipv6 information in the instance metadata, it automatically enables dhcp6 for the network interface. However, this brings up the instance with a broken IPv6 configuration because SLAAC should be used for almost all situations on EC2. Red Hat BZ: https://bugzilla.redhat.com/show_bug.cgi?id=2092459 Fedora Pagure: https://pagure.io/cloud-sig/issue/382 Upstream: https://bugs.launchpad.net/cloud-init/+bug/1976526 Fixes GH-3980 Signed-off-by: Major Hayden <major@redhat.com>
After [0, 1], dhcp6 is going to be always false after upgrading cloud-init. Correct this in the integration test. Refs: [0] #3980 [1] https://bugs.launchpad.net/cloud-init/+bug/1976526
This bug was originally filed in Launchpad as LP: #1976526
Launchpad details
Launchpad user Major Hayden(rackerhacker) wrote on 2022-06-01T15:26:26.024707+00:00
A Fedora user opened an issue[0] about an issue with cloud-init on EC2. When they launch an instance on a IPv6-enabled subnet, cloud-init sets the
ipv6.method
todhcp
in NetworkManager.However, AWS uses router advertisements to let instances know about the nearest router. Using the
ipv6.method: dhcp
setting prevents router advertisements from working. The instance ends up with an IPv6 address assigned, but it cannot route traffic.A workaround is to run NetworkManager commands to fix the issue:
The instance immediately routes IPv6 traffic after making that change. The dhcp setting appears to be applied automatically for EC2 subnets with IPv6 addresses assigned[1].
I would expect
ipv6.method
to beauto
in these situations.Thank you!
[0] https://pagure.io/cloud-sig/issue/382
[1]
cloud-init/cloudinit/sources/DataSourceEc2.py
Lines 861 to 863 in 53a995e
The text was updated successfully, but these errors were encountered: