IPv6 default route NOT being set netplan Ubuntu 18.04.2 LTS

networking 18.04 netplan routing ipv6

8,459

Solution 1

Your configuration shows you have a local network of 2001:0db8:0004:4a1a::/64 but you are trying to configure a gateway of 2001:0db8:0004::0001 which is not part of that network. So networkd refuses to add a default route via a router that you to not have a route to.

Your manual configuration with ip route also reflects this: you are first adding a route for the router's address, declaring that it is locally connected to your Ethernet, and afterwards setting the default route.

So you must do the equivalent with netplan, which is to declare two entries in routes:, one that is scope: link and one that sets on-link: true:

  addresses:
    - "2001:0db8:0004:4a1a::dead:dead/64"
  routes:
    - to: "2001:0db8:0004::0001/128"
      scope: link
    - to: "::/0"
      via: "2001:0db8:0004::0001"
      on-link: true

Solution 2

I just ran into this issue. The actual cause is written right in /etc/sysctl.conf

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1

When IPv6 forwarding is disabled, the host will not listen to router advertisements, which is how the default route is usually determined. Therefore, you have to manually add the default route (and DNS servers and anything else you were getting out of the RA) or, set the accept_ra kernel option to 2, which overrides the behaviour.

See this blog article for some more info.

Solution 3

network:
  version: 2
  renderer: networkd
  ethernets:
    ens19:
      dhcp6: no
      accept-ra: no
      addresses: ["2001:0db8:0004:4a1a::dead:dead/64"]
      gateway6: "2001:0db8:0004::0001"
      routes:
         - to: "2001:0db8:0004::0001/128"
           scope: link

This works for me as of this writing on Ubuntu 18.04.4 LTS (using different netblocks but tested)

8,459

Sachin Garg

Updated on September 18, 2022

Comments

Sachin Garg over 1 year

Am unable to configure the default route using netplan on an Ubuntu 18.04.2 system. The route works when explicit ip -6 route add ... commands are issued.

Privacy extensions have been disabled: /etc/sysctl.d/10-ipv6-privacy.conf

net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0
net.ipv6.conf.ens192.use_tempaddr = 0

SLACC and RA have been disabled, IPv4/IPv6 forwarding are one (machine serves as an OpenVPN server)

/etc/sysctl.d/10-ipv6-router.conf

net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.all.accept_ra = 0

net.ipv6.conf.all.proxy_ndp = 1

/etc/sysctl.conf

net.ipv4.ip_forward=1
...
net.ipv6.conf.all.forwarding=1

/etc/netplan/01-netcfg.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      dhcp4: no
      addresses:
        - a.b.c.d/24
      gateway4: a.b.c.e

      dhcp6: no
      accept-ra: no
      addresses:
        - "2001:0db8:0004:4a1a::dead:beef/64"
      gateway6: "2001:0db8:0004::0001"

    ens19:
      dhcp6: no
      accept-ra: no
      addresses:
        - "2001:0db8:0004:4a1a::dead:dead/64"
      gateway6: "2001:0db8:0004::0001"

This assigns the addresses to the interface as shown below:

$ ip -6 addr show

2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:0db8:0004:4a1a::dead:beef/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::abcd:efff:fea3:2a03/64 scope link 
       valid_lft forever preferred_lft forever
3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:0db8:0004:4a1a::dead:dead/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::defc:deff:fe98:7c74/64 scope link 
       valid_lft forever preferred_lft forever

The routes using ip -6 route show

2001:0db8:0004:4a1a::/64 dev ens19 proto kernel metric 256 pref medium
2001:0db8:0004:4a1a::/64 dev ens18 proto kernel metric 256 pref medium

fe80::/64 dev ens19 proto kernel metric 256 pref medium
fe80::/64 dev ens18 proto kernel metric 256 pref medium

There is no default route configured and pinging external sites does NOT work:

$ ping -6 -c3 ipv6.google.com
connect: Network is unreachable

Running the following two commands:

$ sudo ip -6 route add 2001:0db8:0004::0001 dev ens18 metric 1
$ sudo ip -6 route add default via 2001:0db8:0004::0001 dev ens18 metric 1

Now running ip -6 route shows:

2001:0db8:4::1 dev ens18 metric 1 pref medium

2001:0db8:4:4a1a::/64 dev ens19 proto kernel metric 256 pref medium
2001:0db8:4:4a1a::/64 dev ens18 proto kernel metric 256 pref medium

fe80::/64 dev ens19 proto kernel metric 256 pref medium
fe80::/64 dev ens18 proto kernel metric 256 pref medium

default via 2001:0db8:4::1 dev ens18 metric 1 pref medium

A default route is now configured and pinging external sites works:

$ ping -6 -c3 ipv6.google.com
PING ipv6.google.com(ord38s18-in-x0e.1e100.net (2607:f8b0:4009:804::200e)) 56 data bytes
64 bytes from ord38s18-in-x0e.1e100.net (2607:f8b0:4009:804::200e): icmp_seq=1 ttl=56 time=23.2 ms
64 bytes from ord38s18-in-x0e.1e100.net (2607:f8b0:4009:804::200e): icmp_seq=2 ttl=56 time=23.2 ms
64 bytes from ord38s18-in-x0e.1e100.net (2607:f8b0:4009:804::200e): icmp_seq=3 ttl=56 time=23.2 ms

--- ipv6.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 23.274/23.283/23.293/0.176 ms

So, what is wrong with the netplan configuration? Why are the default IPv6 routes not being configured?

Edited after making changes suggested by @slangasek:

 ethernets:
    ens18:
     ...

      dhcp6: no
      accept-ra: no
      addresses:
        - "2001:0db8:0004:4a1a::dead:beef/64"

      routes:
        - to: "::/0"
          via: "2001:0db8:0004::1"
          metric: 1
          on-link: true

However, this does not work. I get messages like ens18: Could not set route: No route to host in the journal logs.

From the answer at https://askubuntu.com/a/1014683, I added the additional route to the router using scope: link:

  routes:
    - to: "2001:0db8:0004::1/128"
      via: "2001:0db8:0004::1"
      metric: 1
      scope: link
    - to: "::/0"
      via: "2001:0db8:0004::1"
      metric: 1
      on-link: true

But, still not working!

chili555 almost 5 years

Please add DNS nameservers as outlined here: cat /usr/share/doc/netplan/examples/static.yaml and then try again.
Sachin Garg almost 5 years

Pray what has DNS servers got to do with default routing. DNS and routing works at very-very different levels in the IP hierarchy. Is netplan so terribly broken?

slangasek almost 5 years

As an aside, I don't understand why you would have a network like this. This contradicts all the basic principles of routed networks to have your gateway not have a local network address.
Sachin Garg almost 5 years

not my decision to make. It is the service provider who have made that decision. However, my network is part of the /48 routed by the router - so this should not be considered way off!
Sachin Garg almost 5 years

Still does not work. I am not getting the route configured. In the journalctl output, I get: Jun 03 11:32:34 jwaala systemd-networkd[5917]: ens19: Could not set route: No route to host Jun 03 11:32:34 jwaala systemd-networkd[5917]: ens19: Configured Jun 03 11:32:34 jwaala systemd-networkd[5917]: ens18: Could not set route: No route to host Jun 03 11:32:34 jwaala systemd-networkd[5917]: ens18: Configured
Sachin Garg almost 5 years

@slagasek: Please see edited question above and let me know what you think? Any idea where to get the fikle generated by netplan generate?
Sachin Garg almost 5 years

Have given up on this netplan thing and moved to ifup as given in (askubuntu.com/a/1052023)
slangasek almost 5 years

are you sure that /64 is even the correct netmask for your local network, and that it shouldn't be /48?
Sachin Garg almost 5 years

Yes. Everything works with ifupdown. Either netplan is broken or poorly documented, especially for IPv6.
slangasek almost 5 years

I have reproduced this locally; the issue is that you have an invalid 'via' in your first route. I have updated my answer to show the correct syntax, which works for me here.
slangasek almost 5 years

Also my question about the correct netmask for your network was not because I believed the configuration could not be made to work as described, but because it's bad network design on the part of your provider if you must configure your network this way, and it's possible /48 is the correct netmask for the provider's network.