Description

Setting only set interfaces pppoe pppoe0 ipv6 adjust-mss <n> creates the ipv6 node under the PPPoE interface. The static route template (data/templates/frr/staticd.frr.j2) renders ipv6 route ::/0 pppoe0 tag 210 <distance> as soon as that node is defined, whether or not the PPPoE link has any IPv6 connectivity ({% if interface_config.ipv6 is vyos_defined %}). The pppd peer file gets +ipv6 for the same reason.

If the router has another IPv6 default route with the same distance, for example a static ::/0 over a 6in4 tunnel, both are installed as equal-cost nexthops. The kernel spreads IPv6 flows over both paths, and every flow that hashes to the PPPoE interface goes into a path without IPv6 uplink. Symptoms are intermittent: some connections work, others do not.

A user reported this on 1.5 with a home router: IPv6 via a tunnelbroker 6in4 tunnel (tun0) had problems since the migration, and the IPv6 default route had two nexthops, tun0 and pppoe0:

default nhid 79 proto static metric 20 pref medium
    nexthop dev tun0 weight 1
    nexthop dev pppoe0 weight 1

The only IPv6 setting under pppoe0 was ipv6 adjust-mss '1452'. FRR had ipv6 route ::/0 pppoe0 tag 210 next to the static ::/0 over the tunnel. Removing the route with vtysh (no ipv6 route ::/0 pppoe0 tag 210) fixed the problem.

How to reproduce (rolling 2026.10.16-0024, a PPPoE client against a PPPoE server, a dummy interface in place of the tunnel)

set interfaces dummy dum0 address 2001:db8:1::2/64
set protocols static route6 ::/0 interface dum0
set interfaces pppoe pppoe0 source-interface eth0
set interfaces pppoe pppoe0 authentication username <user>
set interfaces pppoe pppoe0 authentication password <password>
commit

vtysh -c "show running-config" has ipv6 route ::/0 dum0 and the IPv4 default route via pppoe0, no IPv6 route via pppoe0. Then:

set interfaces pppoe pppoe0 ipv6 adjust-mss 1452
commit

Result after the session came up again:

ipv6 route ::/0 dum0
ipv6 route ::/0 pppoe0 tag 210

show ipv6 route ::/0:
  Known via "static", distance 1, metric 0, tag 210, best
  * directly connected, dum0, weight 1
  * directly connected, pppoe0, weight 1

ip -6 route show default:
  default nhid 3472 proto static metric 20 pref medium
        nexthop dev dum0 weight 1
        nexthop dev pppoe0 weight 1

pppoe0 had no global IPv6 address, there is nothing that could carry the traffic there.

Expected behaviour

An option that only changes the MSS clamping should not add a default route. Possible ways: render the IPv6 default route only when IPv6 is really enabled on the interface (an address such as autoconf or dhcpv6, or a prefix delegation), not by the presence of the ipv6 node, or give the route a distance that cannot tie with the usual static default route. I have not tried a patch.

Not reproduced

On the user's 1.5 system the route stayed in FRR after delete interfaces pppoe pppoe0 ipv6 and a commit, while the peer file already said noipv6. On the rolling VM above the route is removed right at the commit (the static configuration is rendered again). So the part where the route stays behind is not reproduced, it may be specific to 1.5, where I do not know how the route is created. I only checked the code of rolling.