EdgeRouter X PPPoE IPv6 Stalls: MTU 1492 vs Router Advertisement Prefix Overwrite Trap

1. Symptom: IPv6 access is flaky

Testing with curl -4 -I to a mirror returns 200 instantly, but curl -6 -I repeatedly times out with an SSL connection timeout, even though the NAS shows a global IPv6 address and default route.

curl -4 -I --connect-timeout 5 https://mirrors.ustc.edu.cn/
# returns 200 immediately

curl -6 -I --connect-timeout 5 https://mirrors.ustc.edu.cn/
# curl: (28) SSL connection timeout

Ping and tracepath -6 to the same host work, and tracepath shows the path MTU dropping from 1500 to 1492.

pmtu 1500
...
pmtu 1492
Resume: pmtu 1492

Running show interfaces pppoe pppoe0 on the ER‑X confirms the outbound MTU is 1492, the standard overhead for PPPoE.

2. Initial guess: PMTU black‑hole?

The first hypothesis was a PMTU black‑hole where an intermediate node fails to return an ICMPv6 "Packet Too Big" message, causing TCP to retransmit large segments. After each tracepath run, curl temporarily succeeds, and the routing cache shows an entry with mtu 1492 that expires after 540 seconds.

ip -6 route get 2001:db8:1000::1
...
expires 540sec mtu 1492

This indicated that PMTU learning works but is not reliably triggered, leading to occasional segment loss.

3. Packet capture: TLS handshake stalls

Using tcpdump and ss during a stalled curl, the TCP three‑way handshake completes and the TLS ClientHello is sent, but the server’s ServerHello and certificate chain are delayed by 8–10 seconds. The capture shows a missing TCP segment that the NAS acknowledges with SACK; the server retransmits the segment after about 8 seconds, after which the TLS handshake finishes.

The root cause is a large TCP segment being dropped on a PPPoE link with MTU 1492 because the initial MSS is based on the Ethernet default of 1500 bytes.

4. Trying to advertise MTU via RA breaks the prefix

To inform internal clients of the correct MTU, the router‑advertisement option link-mtu 1492 was set:

set interfaces switch switch0 ipv6 router-advert link-mtu 1492
commit

After applying, rdisc6 enp2s0 shows the advertised MTU, but the NAS loses its global IPv6 address, retaining only a link‑local address.

EdgeOS stores RA configuration in /etc/radvd.conf (manual or CLI generated) and the DHCPv6‑PD prefix in /run/pd-radvd-switch0.conf. When router-advert link-mtu 1492 is set, EdgeOS rewrites /etc/radvd.conf to contain only AdvLinkMTU 1492;, dropping the prefix stanza. The PD‑generated prefix file is not merged, so radvd advertises MTU without a prefix, preventing SLAAC from assigning a global address.

5. Solution: manually declare both MTU and prefix

Because EdgeOS does not automatically merge the two sources, the prefix must be added explicitly to the router-advert configuration:

configure

set interfaces switch switch0 ipv6 router-advert send-advert true
set interfaces switch switch0 ipv6 router-advert link-mtu 1492
# Manually add the /64 prefix allocated by PD
set interfaces switch switch0 ipv6 router-advert prefix ::/64 autonomous-flag true
set interfaces switch switch0 ipv6 router-advert prefix ::/64 on-link-flag true
set interfaces switch switch0 ipv6 router-advert prefix ::/64 valid-lifetime 86400
set interfaces switch switch0 ipv6 router-advert prefix ::/64 preferred-lifetime 14400

commit
save

After committing, /etc/radvd.conf contains both the MTU line and a prefix ::/64 { AdvOnLink on; AdvAutonomous on; }; stanza. The NAS regains a global IPv6 address and the route shows MTU 1492.

AdvLinkMTU 1492;

prefix ::/64 {
    AdvOnLink on;
    AdvAutonomous on;
};

ip -6 addr show dev enp2s0
    inet6 2001:db8:1:3:aaaa:bbbb:cccc:dddd/64 scope global dynamic

ip -6 route get 2001:db8:1000::1
    2001:db8:1000::1 from :: via fe80::1 dev enp2s0 proto ra src 2001:db8:1:3:aaaa:bbbb:cccc:dddd mtu 1492

Repeated 20 curl attempts no longer produce SSL time‑outs.

6. Netplan quirk on the NAS

The NAS uses netplan with systemd‑networkd. The original netplan disabled dhcp6, so accept-ra: true had to be added to receive RAs. Although /proc/sys/net/ipv6/conf/enp2s0/accept_ra remained 0, systemd‑networkd processes RAs in user space, so as long as rdisc6 shows the advertisement and ip -6 addr displays the address, the configuration works.

7. Why not just fix the NAS MTU?

Setting the NAS interface MTU to 1492 (e.g., sudo ip link set dev enp2s0 mtu 1492 or via netplan) would solve the problem for that device only, but other devices (phones, AP‑connected clients) would still suffer. The goal is to have all internal devices automatically adapt to the correct MTU via RA from the router, so the fix must be applied on the ER‑X side.