1

I have a cloud instance on OVH which is accessible over IPv4 but not IPv6. It's running Ubuntu 18.04. I've found conflicting advice about using netplan vs configuring systemd-networkd directly, but all of the things I've tried don't seem to have any effect.

In OVH's web interface I have these addresses defined for me:

IPv6: 2607:5300:201:2100::5d4

Gateway: 2607:5300:201:2100::1

According to the guides I've read, I've configured netplan like this:

/etc/netplan/90-ipv6.yml

network:
    ethernets:
        ens3:
            match:
                macaddress: fa:16:3e:53:64:ce
            set-name: ens3
            addresses:
                - 2607:5300:201:2100::5d4/64
            gateway6: 2607:5300:201:2100::1
            nameservers:
                addresses:
                    - 2001:41d0:3:163::1

    version: 2

And systemd-networkd like this:

/etc/systemd/network/10-ens3.network

[Match]
Name=ens3

[Network]
DHCP=ipv4
Gateway=2607:5300:201:2100::1
DNS=2001:41d0:3:163::1
Destination=2607:5300:201:2100::1

[Address]
Address=2607:5300:201:2100::5d4/64

[Route]
Destination=2607:5300:201:2100::1
Scope=link

My ip addr output looks like this:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:16:3e:53:64:ce brd ff:ff:ff:ff:ff:ff
    inet 54.39.191.97/32 scope global dynamic ens3
       valid_lft 85848sec preferred_lft 85848sec
    inet6 2607:5300:201:2100::5d4/0 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe53:64ce/64 scope link
       valid_lft forever preferred_lft forever

I can ping the gateway and get a response. However I cannot get a response from the server from any other location over IPv6, and a ping6 google.com from this server results in:

PING google.com(yul02s05-in-x0e.1e100.net (2607:f8b0:4020:805::200e)) 56 data bytes
From [hostname] (2607:5300:201:2100::5d4) icmp_seq=1 Destination unreachable: Address unreachable
...
--- google.com ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4085ms

The only thing I haven't tried is rebooting the server, as it's live and I'd really rather not.

What am I missing? I don't really know what I'm doing, so it might be something very obvious.

Thanks!

EDIT: Updated the prefix to /64. This configuration also doesn't work.

7
  • Are you sure that prefix and gateway address are correct? Check in your control panel and confirm it. Aug 6, 2020 at 12:23
  • The control panel doesn't have an explicit prefix, so I'm not sure, no. Gateway is definitely correct though.
    – joshsharp
    Aug 7, 2020 at 0:28
  • Oh you're right, they don't give an explicit prefix. The correct prefix is /64. Aug 7, 2020 at 1:25
  • Thanks, this is what I started with but it also didn't work. I've changed it back so it's correct but it doesn't fix the problem unfortunately.
    – joshsharp
    Aug 7, 2020 at 1:28
  • Unsure if this is relevant, but I still get /0 in inet6 2607:5300:201:2100::5d4/0 scope global after changing the prefix and restarting networkd.
    – joshsharp
    Aug 7, 2020 at 1:31

2 Answers 2

0

The correct IPv6 prefix for OVHcloud VPS is /64, not /128 or /0.

0

I actually fixed this issue by changing something I didn't outline in my question, unfortunately.

In following a guide to setting up IPv6 with netplan, I had edited my netplan config to also include IPv4 address config in a separate, existing file 50-cloud-init.yaml. Although the addresses matched the provided IPs for my instance, they must have conflicted with some other config elsewhere, and this was the root of my problem (where I believe seeing /0 in the output of ip addr indeed indicated an issue).

Removing the IPv4 address and gateway values from my netplan config, so that the only thing I was setting were IPv6 address and gateway, and applying the new configuration, fixed the issue.

For anyone else who ends up getting into this situation, this blog post I found describes exactly what needs to be changed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.