Score:2

systemd network ipv6 gateway is not set up

mv flag

Cross posted on github

I don't understand why my systemd network config doesn't set up ipv6 gateway route, XXX.XXX.XXX.XXX and YYYY:YYYY:YYYY:YYYY:: are always the same ip. My server is hosted by OVH:

[Match]
Name=eth0
 
[Network]
DHCP=false
 
DNS=91.121.161.184
DNS=91.121.164.227
 
Address=XXX.XXX.XXX.XXX/24
Gateway=XXX.XXX.XXX.254
 
DNS=2001:41d0:1:e2b8::1
DNS=2001:41d0:1:e5e3::1
 
Address=YYYY:YYYY:YYYY:YYYY::/64
Gateway=YYYY:YYYY:YYYY:YYFF:FF:FF:FF:FF

This correctly work for ivp4:

networkctl status eth0
● 2: eth0
                     Link File: n/a
                  Network File: /etc/systemd/network/eth0.network
                          Type: ether
                         State: routable (configuring)
                  Online state: online
                        Vendor: Intel Corporation
                         Model: Ethernet Controller 10G X550T
                    HW Address: xx:xx:xx:xx:xx:xx (ASRock Incorporation)
                           MTU: 1500 (min: 68, max: 9710)
                         QDisc: mq
  IPv6 Address Generation Mode: eui64
          Queue Length (Tx/Rx): 64/64
              Auto negotiation: yes
                         Speed: 10Gbps
                        Duplex: full
                          Port: tp
                       Address: XXX.XXX.XXX.XXX
                                YYYY:YYYY:YYYY:YYYY::
                                fe80::d250:99ff:fed9:a09d
                       Gateway: XXX.XXX.XXX.254
                           DNS: 91.121.161.184
                                91.121.164.227
                                2001:41d0:1:e2b8::1
                                2001:41d0:1:e5e3::1
             Activation Policy: up
           Required For Online: yes
             DHCP6 Client DUID: DUID-EN/Vendor:0000000000000000000000000000
 
Jul 13 23:21:15 optomata systemd-networkd[557]: eth0: NDISC: Sent Router Solicitation, next solicitation in 4s
Jul 13 23:21:19 optomata systemd-networkd[557]: eth0: NDISC: Sent Router Solicitation, next solicitation in 8s
Jul 13 23:21:25 optomata systemd-networkd[557]: eth0: NDISC: No RA received before link confirmation timeout
Jul 13 23:21:25 optomata systemd-networkd[557]: eth0: NDISC: Invoking callback for 'timeout' event.
Jul 13 23:21:25 optomata systemd-networkd[557]: eth0: NDisc handler get timeout event
Jul 13 23:21:25 optomata systemd-networkd[557]: eth0: link_check_ready(): static routes are not configured.
Jul 13 23:21:27 optomata systemd-networkd[557]: eth0: NDISC: Sent Router Solicitation, next solicitation in 17s
Jul 13 23:21:45 optomata systemd-networkd[557]: eth0: NDISC: Sent Router Solicitation, next solicitation in 33s
Jul 13 23:22:19 optomata systemd-networkd[557]: eth0: NDISC: Sent Router Solicitation, next solicitation in 1min 10s
Jul 13 23:23:29 optomata systemd-networkd[557]: eth0: NDISC: Sent Router Solicitation, next solicitation in 2min 21s
ping google.fr
PING google.fr (142.250.201.195) 56(84) bytes of data.
64 bytes from bud02s35-in-f3.1e100.net (142.250.201.195): icmp_seq=1 ttl=111 time=15.5 ms
64 bytes from bud02s35-in-f3.1e100.net (142.250.201.195): icmp_seq=2 ttl=111 time=15.5 ms
64 bytes from bud02s35-in-f3.1e100.net (142.250.201.195): icmp_seq=3 ttl=111 time=15.5 ms
64 bytes from bud02s35-in-f3.1e100.net (142.250.201.195): icmp_seq=4 ttl=111 time=15.5 ms
64 bytes from bud02s35-in-f3.1e100.net (142.250.201.195): icmp_seq=5 ttl=111 time=15.5 ms
^C
--- google.fr ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 15.461/15.471/15.488/0.009 ms

but ipv6 doesn't work:

ping -6 google.fr
ping: connect: Network is unreachable
ip -6 route show dev eth0
YYYY:YYYY:YYYY:YYYY::/64 proto kernel metric 256 pref medium
fe80::/64 proto kernel metric 256 pref medium

but if I manually add the route:

ip -6 route add YYYY:YYYY:YYYY:YYFF:FF:FF:FF:FF dev eth0
networkctl status eth0
● 2: eth0
                     Link File: n/a
                  Network File: /etc/systemd/network/eth0.network
                          Type: ether
                         State: routable (configured)
                  Online state: online
                        Vendor: Intel Corporation
                         Model: Ethernet Controller 10G X550T
                    HW Address: xx:xx:xx:xx:xx:xx (ASRock Incorporation)
                           MTU: 1500 (min: 68, max: 9710)
                         QDisc: mq
  IPv6 Address Generation Mode: eui64
          Queue Length (Tx/Rx): 64/64
              Auto negotiation: yes
                         Speed: 10Gbps
                        Duplex: full
                          Port: tp
                       Address: XXX.XXX.XXX.XXX
                                YYYY:YYYY:YYYY:YYYY::
                                fe80::d250:99ff:fed9:a09d
                       Gateway: XXX.XXX.XXX.254
                                YYYY:YYYY:YYYY:YYFF:FF:FF:FF:FF
                           DNS: 91.121.161.184
                                91.121.164.227
                                2001:41d0:1:e2b8::1
                                2001:41d0:1:e5e3::1
             Activation Policy: up
           Required For Online: yes
             DHCP6 Client DUID: DUID-EN/Vendor:0000000000000000000000000000

Jul 13 23:23:29 optomata systemd-networkd[557]: eth0: NDISC: Sent Router Solicitation, next solicitation in 2min 21s
Jul 13 23:25:51 optomata systemd-networkd[557]: eth0: NDISC: Sent Router Solicitation, next solicitation in 4min 38s
Jul 13 23:30:30 optomata systemd-networkd[557]: eth0: NDISC: Sent Router Solicitation, next solicitation in 9min 18s
Jul 13 23:39:49 optomata systemd-networkd[557]: eth0: NDISC: Sent Router Solicitation, next solicitation in 18min 42s
Jul 13 23:47:49 optomata systemd-networkd[557]: eth0: Remembering foreign route: dst: YYYY:YYYY:YYYY:YYff:ff:ff:ff:ff/128, src: n/a, gw: n/a, prefsrc: n/a, scope: global, table: main(254), proto: boot, type: unicast, nexthop: 0, priority: 1024
Jul 13 23:47:49 optomata systemd-networkd[557]: eth0: Configuring route: dst: n/a, src: n/a, gw: YYYY:YYYY:YYYY:YYff:ff:ff:ff:ff, prefsrc: n/a, scope: global, table: main(254), proto: static, type: unicast, nexthop: 0, priority: 1024
Jul 13 23:47:49 optomata systemd-networkd[557]: eth0: Received remembered route: dst: n/a, src: n/a, gw: YYYY:YYYY:YYYY:YYff:ff:ff:ff:ff, prefsrc: n/a, scope: global, table: main(254), proto: static, type: unicast, nexthop: 0, priority: 1024
Jul 13 23:47:49 optomata systemd-networkd[557]: eth0: Routes set
Jul 13 23:47:49 optomata systemd-networkd[557]: eth0: link_check_ready(): dhcp4:no ipv4ll:no dhcp6_addresses:no dhcp6_routes:no dhcp6_pd_addresses:no dhcp6_pd_routes:no ndisc_addresses:yes ndisc_routes:yes
Jul 13 23:47:49 optomata systemd-networkd[557]: eth0: State changed: configuring -> configured
ping -6 google.com
PING google.com(fra24s08-in-x0e.1e100.net (2a00:1450:4001:82b::200e)) 56 data bytes
64 bytes from fra24s08-in-x0e.1e100.net (2a00:1450:4001:82b::200e): icmp_seq=1 ttl=113 time=1.39 ms
64 bytes from fra24s08-in-x0e.1e100.net (2a00:1450:4001:82b::200e): icmp_seq=2 ttl=113 time=1.41 ms
64 bytes from fra24s08-in-x0e.1e100.net (2a00:1450:4001:82b::200e): icmp_seq=3 ttl=113 time=1.39 ms
64 bytes from fra24s08-in-x0e.1e100.net (2a00:1450:4001:82b::200e): icmp_seq=4 ttl=113 time=1.40 ms
64 bytes from fra24s08-in-x0e.1e100.net (2a00:1450:4001:82b::200e): icmp_seq=5 ttl=113 time=1.42 ms
64 bytes from fra24s08-in-x0e.1e100.net (2a00:1450:4001:82b::200e): icmp_seq=6 ttl=113 time=1.40 ms
ip -6 route show dev eth0
YYYY:YYYY:YYYY:YYYY::/64 proto kernel metric 256 pref medium
YYYY:YYYY:YYYY:YYff:ff:ff:ff:ff metric 1024 pref medium
fe80::/64 proto kernel metric 256 pref medium
default via YYYY:YYYY:YYYY:YYff:ff:ff:ff:ff proto static metric 1024 pref medium

System information:

cat /etc/os-release
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux
uname -a
Linux optomata 5.12.15-arch1-1 #1 SMP PREEMPT Wed, 07 Jul 2021 23:35:29 +0000 x86_64 GNU/Linux
systemctl --version
systemd 249 (249-2-arch)
+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +XKBCOMMON +UTMP -SYSVINIT default-hierarchy=unified

journalctl -u systemd-networkd.service

John Mahowald avatar
cn flag
Please edit your question to not obfuscate IP addresses. Easier to help you when we can verify what your ISP is, if you are using ULA or your public prefix. https://meta.serverfault.com/questions/963/what-information-should-i-include-or-obfuscate-in-my-posts
Ron Maupin avatar
us flag
Unlike IPv4, IPv6 gets its information from the RAs (Router Advertisements), which tell the host whether or not it can use stateful or stateless address configuration, and the link-local gateway address for all the addresses configured on the link about which the router knows. The gateway (router) address is a link-local address, not an address in the same network as the interface address, which is quite different than IPv4. You have not included the addresses (real or the equivalent), so we really cannot tell what you are doing or where you may have gone wrong.
Stargateur avatar
mv flag
@JohnMahowald your link say the contrary and whatever no I will try to improve the obfuscation but I don't want to attract attention on static ip there is all information needed to know I didn't misspell the IP
Stargateur avatar
mv flag
@RonMaupin improved, as I state it's work if I add the route by hand thus I didn't misspell the ip tell me if there still not enough information
Ron Maupin avatar
us flag
IANA gives you an example prefix (`2001:db8::/32`) that you can use the replace the first 32 bits of an address to obfuscate it. Also, there is no reason to obfuscate a link-local address (your gateway address) because _every_ link in the world uses the same link-local addressing. It is nearly impossible to help without something realistic.
Michael Hampton avatar
cz flag
I have a suspicion of what might be going on, given your new log entries, but since you have obfuscated so much, I cannot be sure of it. You should share as much real information as possible.
Stargateur avatar
mv flag
@RonMaupin I don't understand mask ip enough to make a perfect transision between my /64 ip and the /32 you propose
Ron Maupin avatar
us flag
Simply replace the first 32 bits of your global addresses with `2001:db8:`. Nobody could guess what your addresses really are from that.
Stargateur avatar
mv flag
@RonMaupin I don't see how that would improve the post in anyway right now but I will try next time in fact no if I do that the ip is easy to guess since my host is ovh so your idea is totally bad
Ron Maupin avatar
us flag
It would give us realistic addressing that can give us a clue what you are doing and where you may have gone wrong. In any case, you are still obfuscating the gateway address, but that is a link-local address, just like the other link-local addresses you display.
Score:1
cz flag

You have a server on OVH, which has its IPv6 gateway in a different subnet than the /64 assigned to you, despite it being on the same layer 2 physical link.

This means you need to tell systemd-networkd that it needs to create the static route you have been creating manually.

Instead of having the IPv6 Gateway= shortcut in the [Network] section, you'll need to remove it from there and create a [Route] section to hold the IPv6 gateway and the necessary parameter GatewayOnLink=yes. This tells the kernel that the gateway is directly reachable on the LAN and it will create the necessary static route itself.

[Route]
Gateway=2001:41d0:whatever
GatewayOnLink=yes
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.