Zerotier IPv6 latency and packet loss

Hi,

I have a VM on Vultr running VyOS which is advertising some of my IPv6 subnets. I have these then exposed over zerotier to other “sites”.

IPv4 connectivity is very stable and no issues noticed there, however IPv6 seems to have some odd packet loss.
Quite frequently packets seem to drop, regardless of protocol used (ping for example) and devices never receive a response, consequently requiring a retransmission. This can happen for a few seconds, and then suddenly it will start working, all this happens yet only IPv6 is affected, IPv4 is unaffected and works fine.

ZT tunnel has its own interface called “eth3”.
WAN interface is on “eth0”

interface counters:

Kernel Interface table
Iface             MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
dum0             1500        0      0      0 0         57296      0      0      0 BORU
eth0             1500 188044536      0      0 0      284981982      0      0      0 BMRU
eth1             1500        4      0      0 0         35329      0      0      0 BMRU
eth3             2800 80983093      0      0 0      135884858      0  55178      0 BMRU
lo              65536  1719572      0      0 0       1719572      0      0      0 LRU

Packet capture:

16:18:17.789961 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13489, length 8
16:18:17.789981 IP6 2a13:df80:800::1 > 2a13:df80:800::2: ICMP6, echo reply, id 8053, seq 13489, length 8
16:18:18.742042 IP6 2a13:df80:801:a500:e0d3:39a7:93f0:9042 > 2a13:df80:800::1: ICMP6, echo request, id 1, seq 714, length 40
16:18:18.742093 IP6 2a13:df80:800::1 > 2a13:df80:801:a500:e0d3:39a7:93f0:9042: ICMP6, echo reply, id 1, seq 714, length 40
16:18:18.797891 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13490, length 8
16:18:18.797935 IP6 2a13:df80:800::1 > 2a13:df80:800::2: ICMP6, echo reply, id 8053, seq 13490, length 8
16:18:19.751929 IP6 2a13:df80:801:a500:e0d3:39a7:93f0:9042 > 2a13:df80:800::1: ICMP6, echo request, id 1, seq 715, length 40
16:18:19.751988 IP6 2a13:df80:800::1 > 2a13:df80:801:a500:e0d3:39a7:93f0:9042: ICMP6, echo reply, id 1, seq 715, length 40
16:18:19.814033 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13491, length 8
16:18:19.814072 IP6 2a13:df80:800::1 > 2a13:df80:800::2: ICMP6, echo reply, id 8053, seq 13491, length 8
16:18:20.757917 IP6 2a13:df80:801:a500:e0d3:39a7:93f0:9042 > 2a13:df80:800::1: ICMP6, echo request, id 1, seq 716, length 40
16:18:20.831871 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13492, length 8
16:18:21.873872 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13493, length 8
16:18:22.887869 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13494, length 8
16:18:23.893834 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13495, length 8
16:18:24.904191 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13496, length 8
16:18:25.611938 IP6 2a13:df80:801:a500:e0d3:39a7:93f0:9042 > 2a13:df80:800::1: ICMP6, echo request, id 1, seq 717, length 40
16:18:25.924294 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13497, length 8
16:18:26.933908 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13498, length 8
16:18:27.946272 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13499, length 8
16:18:28.949970 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13500, length 8
16:18:29.997829 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13501, length 8
16:18:30.443588 IP6 2a13:df80:800::1 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2a13:df80:800::2, length 32
16:18:30.450107 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, neighbor advertisement, tgt is 2a13:df80:800::2, length 32
16:18:30.450169 IP6 2a13:df80:800::1 > 2a13:df80:800::2: ICMP6, echo reply, id 8053, seq 13501, length 8
16:18:30.612037 IP6 2a13:df80:801:a500:e0d3:39a7:93f0:9042 > 2a13:df80:800::1: ICMP6, echo request, id 1, seq 718, length 40
16:18:30.612092 IP6 2a13:df80:800::1 > 2a13:df80:801:a500:e0d3:39a7:93f0:9042: ICMP6, echo reply, id 1, seq 718, length 40
16:18:31.011857 IP6 2a13:df80:800::2 > 2a13:df80:800::1: ICMP6, echo request, id 8053, seq 13502, length 8
16:18:31.011900 IP6 2a13:df80:800::1 > 2a13:df80:800::2: ICMP6, echo reply, id 8053, seq 13502, length 8
16:18:31.621983 IP6 2a13:df80:801:a500:e0d3:39a7:93f0:9042 > 2a13:df80:800::1: ICMP6, echo request, id 1, seq 719, length 40
16:18:31.622039 IP6 2a13:df80:800::1 > 2a13:df80:801:a500:e0d3:39a7:93f0:9042: ICMP6, echo reply, id 1, seq 719, length 40

You can see in the packet capture that the interface is still receiving echo requests but VyOS never seems to send a response during this period.

I’m wondering if the MTU is causing some issues and I need to change the MTU on the interfaces.

Anyone with zerotier had any similar issues?