[15:46] Hello, I have another IPv6 question around the new version of our DataSource. It looks like the network-manager renderer forces a /64 subnet when defining the default gateway (as seen in this example : https://paste.ubuntu.com/p/tMYZr8Mh5r/) [15:48] on at least CentOS stream 8 it doesn't work. My current workaround is to use the deprecated gateway6 keywork which adds `gateway={IPv6 addr}` [15:48] you are talking about "::/64"? [15:49] yes. In the yaml config (and also what is passed by our DataSourceScaleway.py), the input is ::/0 [15:49] this is not "a /64 subnet" [15:49] and which version? [15:51] Jammy's 22.4-1 (sorry network hickup) [15:52] I have to problem with the netplan & ENI renderers on Ubuntu & Debian [15:53] If I manually add a ip -6 route add default via fe80::dc00:00ff:fe01:6552 dev eth0 everything works fine [15:53] ubuntu jammy contains cloud-init 22.4.2-0ubuntu0~22.04.1 as of now [15:54] yeah, I now, but this is network-manager rendering on CentOS, not on Jammy [15:54] irrelevant. i want to know which code you are using [15:56] When I started working on the DS, 22.4-1 was the most recent. Now COPR has 22.4-1 for the RH based and I need a minimum of 22.4 to get EphemeralIPv6Network [16:03] i can reproduce it on a debian 22.4.2-1. reason is cloudinit.net.network_state._normalize_route is called to times. in the first iteration /0 is split away, in the second this info is not used and prefix is overwiriten with 64. not sure why [16:05] ok, thanks for testing. So looks like this is not to be expected then [16:06] not at all [16:08] Want me to create a bug on this ? [16:15] please do [16:16] on my way [16:16] do you want the bug on Launchpad or GH ? [16:16] launchpad, see topic [16:17] that's what I thought [16:18] caribou: I'm currently looking into issues with the eni renderer and network config v2 "routes:" versus gateway4/gateway6 [16:18] minimal: ENI seems to work fine, I tested my DS on bullseye [16:19] caribou: eni sort of works - the eni created *should* use "gateway" for the default route, however it uses pre-up/post-up entries instead [16:20] yep, saw that while trying to figure out why it didn't work on CentOS [16:22] whilst this sort-of-works it means that for providers giving either a /32 IPv4 address or a /128 IPv6 address (i.e. where the gateway is NOT in the same subnet) then ifupdown/ifupdown-ng's workaround of always specifying the "onlink" option to "ip route add" does NOT happen for the default route (whereas if eni uses "gateway" it does [16:22] I'm in the process of investigating/working on a fix for this and some other eni-related issues [16:24] A few weeks back we had a discussion on a similar topic for IPv4 where I had to use the on-link option as the default gw is not in the same subnet. Turned out we went back to DHCPv4 so it was not needed anymore [16:25] right, but using "routes:" for IPv4 has the same issue with eni of "onlink" not being used [16:28] since it was early testing, I was using Jammy and the netplan renderer is a passthrough so I was able ot use on-link [16:29] I fixed Alpine's ifupdown-ng package to act the same as Debian's ifupdown in adding "onlink" for the default route, now there is this need for default routes specified via "routes" in cloud-init's v2 to use "gateway" rather than "pre-up/post-up" for eni for the rest of the fix [16:31] FYI : https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2003562 [16:31] -ubottu:#cloud-init- Launchpad bug 2003562 in cloud-init (Ubuntu) "network-manager renderer does not honour IPv6 default route subnet" [Undecided, New] [16:42] Thanks for the attention : I'm heading out & will be checking the backlog & bug on monday !