ipv6 ospfv3 redistribute
Closed, InvalidPublicBUG
Actions

Assigned To

None

Authored By

	drixter
	Aug 8 2026, 3:15 PM

Description

Just checked VyOS 1.5.1 and looks like that static routes are not redistributed to OSPFv3.

System was upgraded from 1.4.4.

I'm happy to debug/support.

vyos@r0-sto.e-utp.net:~$ show ipv6 ospfv3 redistribute
Redistributing External Routes from:

5: connected
0: static

Total 5 routes
C 2001:67c:21ec::1/128 0.0.0.12 type-2 0 :: (ifindex 1)
C 2001:67c:21ec:42b0::/64 0.0.0.13 type-2 0 :: (ifindex 7)
C 2001:67c:21ec:9999::8/128 0.0.0.14 type-2 0 :: (ifindex 1)
C 2a0f:5707:ba00::1/128 0.0.0.15 type-2 0 :: (ifindex 1)
C 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128 0.0.0.16 type-2 0 :: (ifindex 2)

vyos@r0-sto.e-utp.net:~$ show configuration commands | grep ospf | grep redi
set protocols ospfv3 redistribute connected
set protocols ospfv3 redistribute static

vyos@r0-sto.e-utp.net:~$ show configuration commands | grep static
set protocols ospfv3 redistribute static
set protocols static route6 2a0f:5707:ba0e:100::/64 interface eth0
set protocols static route6 2001:67c:21ec:4500::/64 interface tun60

Am I doing something wrong? Was working on 1.4.4. Just upgraded.

Thanks,

Details

Version: 1.5.1
Is it a breaking change?: Behavior change
Issue type: Bug (incorrect behavior)

Related Objects

Mentioned Here: T7531: Add FRR no-ipv6-auto-ra option

Event Timeline

drixter created this task.Aug 8 2026, 3:15 PM

Hi, thanks for the detailed report.

I took a look at the vyos-1x conf-mode code that generates the OSPFv3 FRR config (XML definition, config_dict merging, and the FRR jinja2 template), and the
"redistribute static" path looks correct there — it's even covered by an existing smoketest that commits redistribute static with metric/metric-type/route-map and
asserts the resulting line shows up in the generated ospf6d config. So this doesn't look like a straightforward conf-mode regression on the VyOS side.

To help narrow this down, could you provide a bit more detail:

Right after committing, can you check whether redistribute static actually made it into FRR's own config? In vtysh: show running-config

and look under router ospf6 for the redistribute static ... line. If it's present there but still not showing up in show ipv6 ospfv3 redistribute, that points to an FRR-side issue (ospf6d/zebra) rather than a VyOS config-generation bug.

Can you try triggering a change on one of the static routes after the redistribute config is already committed (e.g. delete and re-add it, or add a new one), and see if that one then appears? FRR's redistribution into OSPF is somewhat event-driven — routes that already existed in the RIB before redistribution was enabled aren't always retroactively pushed on some FRR versions, only routes added/changed afterwards. If that's what's happening here, it would point to a behavior change in the FRR version shipped with 1.5.1 rather than something in vyos-1x.

What FRR version is 1.5.1 actually running (show version should include it)? 1.5 moved to a notably newer FRR release than 1.4.4, so it's worth confirming whether this is reproducible against a plain FRR config (outside of VyOS) with the same FRR version — that would confirm/rule out an upstream FRR regression.

This will help decide whether this needs a fix in vyos-1x or should be reported upstream to FRR.

pasik subscribed.Aug 9 2026, 6:38 AM

Ad.1/2 It's there

router ospf6
 ospf6 router-id 51.21.99.1
 log-adjacency-changes detail
 auto-cost reference-bandwidth 100
 redistribute connected
 redistribute static
exit

Ad.3

I've tried, doesn't help.

Ad.4

FRRouting 10.5.2 (r0-sto.e-utp.net) on Linux(6.6.144-vyos).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--sbindir=/usr/lib/frr' '--with-vtysh-pager=/usr/bin/pager' '--libdir=/usr/lib/x86_64-linux-gnu/frr' '--with-moduledir=/usr/lib/x86_64-linux-gnu/frr/modules' '--disable-dependency-tracking' '--enable-rpki' '--enable-scripting' '--enable-pim6d' '--disable-grpc' '--disable-address-sanitizer' '--with-libpam' '--enable-doc' '--enable-doc-html' '--enable-snmp' '--enable-fpm' '--disable-protobuf' '--disable-zeromq' '--enable-ospfapi' '--enable-bgp-vnc' '--enable-multipath=256' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' '--enable-pcre2posix' 'build_alias=x86_64-linux-gnu' 'PYTHON=python3'

Looks like problem in FRR, let me closer look.

Thanks,

Thanks for the detailed follow-up, this is helpful.

Given that redistribute static is present in the FRR config but adding/removing static routes never triggers redistribution (not even for newly-added routes), this does look like an FRR-side issue in ospf6d rather than something VyOS's config generation is doing wrong.

A couple of things that would help narrow this down further:

1. Do you have summary-address configured under router ospf6? There's a known FRR bug (fixed via PR #19733 (https://github.com/FRRouting/frr/pull/19733), backported to the 10.5 branch) where redistributed routes get dropped and never re-added as LSAs if a summary-address is removed while an aggregation timer is running. If you have
summary-address configured, please confirm your exact FRR patch level (10.5.2 alone doesn't tell us if that backport is included) and whether removing it changes anything.
2. Does IPv4 redistribute static work correctly on the same router (router ospf)? If IPv4 OSPF redistribution works fine while IPv6 OSPFv3 does not, that would confirm this is specific to ospf6d and not a general FRR/zebra redistribution problem.
3. Could you connect directly via vtysh (bypassing the VyOS CLI) and run show ipv6 route static followed by show ipv6 ospf6 database to confirm zebra actually holds the static routes and that ospf6d's database has no corresponding external LSA for them? That would tell us whether the routes never reach ospf6d, or reach it but aren't
advertised.

If this turns out to be a genuine FRR regression, the next step would be to reproduce it in a minimal vtysh-only setup (no VyOS) and report it upstream at https://github.com/FRRouting/frr/issues.

Viacheslav assigned this task to hedrok.Aug 10 2026, 2:27 PM

Viacheslav triaged this task as Normal priority.

Some input, I can't test it with IPv4.

I need to do some lab box, because right now due the missing working static route I'm announce it on different box which still use VyOS 1.4.x (RTR: 70.34.220.105)
Give me some time to build it.

But for now:

r0-sto.e-utp.net# show ipv6 ospf6 database

        Area Scoped Link State Database (Area 0.0.0.0)

Type LSId           AdvRouter       Age   SeqNum                        Payload
[...]
        I/F Scoped Link State Database (I/F lo in Area 0.0.0.0)

Type LSId           AdvRouter       Age   SeqNum                        Payload
Lnk  0.0.0.1        51.21.99.1      308 8000006d            fe80::200:ff:fe00:0
Lnk  0.0.0.1        51.21.99.1      308 8000006d          2001:67c:21ec:9999::8
Lnk  0.0.0.1        51.21.99.1      308 8000006d              2a0f:5707:ba00::1

        I/F Scoped Link State Database (I/F tun7 in Area 0.0.0.0)

Type LSId           AdvRouter       Age   SeqNum                        Payload
Lnk  0.0.0.7        51.21.99.1      308 8000006d      fe80::f803:cfff:fe6b:db0a
Lnk  0.0.0.7        51.21.99.1      308 8000006d          2001:67c:21ec:42b0::1
Lnk  0.0.0.11       70.34.220.105  1656 80000299       fe80::f8af:32ff:fe4f:b56

        AS Scoped Link State Database

Type LSId           AdvRouter       Age   SeqNum                        Payload
[..]
ASE  0.0.0.12       70.34.220.105  1232 8000006c        2a0f:5707:ba0e:100::/64
[..]

r0-sto.e-utp.net# show ipv6 route static
Codes: K - kernel route, C - connected, L - local, S - static,
       R - RIPng, O - OSPFv3, I - IS-IS, B - BGP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
       f - OpenFabric, t - Table-Direct,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

IPv6 unicast VRF default:
S   2a0f:5707:ba0e:100::/64 [1/0] is directly connected, eth0, weight 1, 1d13h57m

r0-sto.e-utp.net# show ipv6 ospf6 redistribute
Redistributing External Routes from:
    5: connected
    0: static
Total 5 routes
C 2001:67c:21ec::1/128             0.0.0.22        type-2     0 :: (ifindex 1)
C 2001:67c:21ec:42b0::/64          0.0.0.23        type-2     0 :: (ifindex 7)
C 2001:67c:21ec:9999::8/128        0.0.0.24        type-2     0 :: (ifindex 1)
C 2a0f:5707:ba00::1/128            0.0.0.25        type-2     0 :: (ifindex 1)
C 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128 0.0.0.26        type-2     0 :: (ifindex 2)
r0-sto.e-utp.net#

Looking at your last output more closely - I think this might not be an FRR-side redistribution bug at all, but a route-selection conflict on your box.

In show ipv6 route static, your entry is:
S 2a0f:5707:ba0e:100::/64 [1/0] is directly connected, eth0, weight 1, 1d13h57m
Note there's no > or * marker - per the legend, that means this route is neither selected as best nor installed in the FIB. Zebra only redistributes the *selected*
route for a given prefix to other protocols, so if this static route isn't selected, ospf6d never sees it via ZEBRA_REDISTRIBUTE_ROUTE_ADD - which matches your
redistribute output showing 0: static.

At the same time, your show ipv6 ospf6 redistribute output lists a connected route 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128 - an address on eth0 that falls inside
the same 2a0f:5707:ba0e:100::/64 your static route covers. If that address came from SLAAC/DHCPv6-PD, Linux will auto-install a kernel on-link route for the whole /64 on
eth0. A connected route (distance 0) always beats a static route (distance 1) for an overlapping/same prefix, so the static route would stay in the RIB but never become
the selected/installed path - explaining both the missing >/* and the "0: static" in redistribute, without needing any FRR bug.

Could you check:

show ipv6 route 2a0f:5707:ba0e:100::/64 longer-prefixes (or just show ipv6 route table all filtered to that prefix) - is there a competing C (connected) entry for

this exact or a covering prefix?

show ipv6 route static json - the selected/installed/fib flags on this route entry should say explicitly whether it's inactive and why.

If that confirms it, this would be a config issue (delegated-prefix static route overlapping an on-link SLAAC/PD route on the same interface), not something to file
upstream against FRR - and it would also mean this isn't really a 1.4.4 vs 1.5.1 regression, just whatever changed in the address assignment on eth0.

vyos@r0-sto.e-utp.net:~$ vtysh

Hello, this is FRRouting (version 10.5.2).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

r0-sto.e-utp.net# show ipv6 route 2a0f:5707:ba0e:100::/64 longer-prefixes
Codes: K - kernel route, C - connected, L - local, S - static,
       R - RIPng, O - OSPFv3, I - IS-IS, B - BGP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
       f - OpenFabric, t - Table-Direct,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

IPv6 unicast VRF default:
O   2a0f:5707:ba0e:100::/64 [110/20] via fe80::f8af:32ff:fe4f:b56, tun7, weight 1, 05:58:09
S   2a0f:5707:ba0e:100::/64 [1/0] is directly connected, eth0, weight 1, 2d03h44m
K>* 2a0f:5707:ba0e:100::/64 [0/256] is directly connected, eth0, weight 1, 2d19h53m
L * 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128 is directly connected, eth0, weight 1, 2d19h50m
C>* 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128 is directly connected, eth0, weight 1, 2d19h50m
K * 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128 [0/256] is directly connected, eth0, weight 1, 2d19h53m
r0-sto.e-utp.net# show ipv6 route static json
{"2a0f:5707:ba0e:100::/64":[{"prefix":"2a0f:5707:ba0e:100::/64","prefixLen":64,"protocol":"static","vrfId":0,"vrfName":"default","distance":1,"metric":0,"table":254,"internalStatus":0,"internalFlags":65,"internalNextHopNum":1,"internalNextHopActiveNum":1,"nexthopGroupId":15,"receivedNexthopGroupId":15,"uptime":"2d03h44m","nexthops":[{"flags":3,"fib":true,"directlyConnected":true,"interfaceIndex":2,"interfaceName":"eth0","active":true,"weight":1}]}]
}
r0-sto.e-utp.net#

I'll compare on the evening how this looks llike with 1.4.x

How this looks like on 1.4.4, same config, for clearnes: 51.21.99.1 is this Router ID.

vyos@r0-sto.e-utp.net:~$ vtysh

Hello, this is FRRouting (version 9.1.3).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

r0-sto.e-utp.net# show ipv6 route 2a0f:5707:ba0e:100::/64 longer-prefixes
Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, F - PBR,
       f - OpenFabric, t - Table-Direct,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

O   2a0f:5707:ba0e:100::/64 [110/20] via fe80::f8af:32ff:fe4f:b56, tun7, weight 1, 00:00:26
S>* 2a0f:5707:ba0e:100::/64 [1/0] is directly connected, eth0, weight 1, 00:00:30
C>* 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128 is directly connected, eth0, 00:00:29
r0-sto.e-utp.net# show ipv6 route static json
{"2a0f:5707:ba0e:100::/64":[{"prefix":"2a0f:5707:ba0e:100::/64","prefixLen":64,"protocol":"static","vrfId":0,"vrfName":"default","selected":true,"destSelected":true,"distance":1,"metric":0,"installed":true,"table":254,"internalStatus":16,"internalFlags":73,"internalNextHopNum":1,"internalNextHopActiveNum":1,"nexthopGroupId":16,"installedNexthopGroupId":16,"uptime":"00:00:45","nexthops":[{"flags":3,"fib":true,"directlyConnected":true,"interfaceIndex":2,"interfaceName":"eth0","active":true,"weight":1}]}]}
r0-sto.e-utp.net# show ipv6 ospf6 redistribute
Redistributing External Routes from:
    5: connected
    1: static
Total 6 routes
C 2001:67c:21ec::1/128             0.0.0.1         type-2     0 :: (ifindex 1)
C 2001:67c:21ec:42b0::/64          0.0.0.2         type-2     0 :: (ifindex 7)
C 2001:67c:21ec:9999::8/128        0.0.0.3         type-2     0 :: (ifindex 1)
C 2a0f:5707:ba00::1/128            0.0.0.4         type-2     0 :: (ifindex 1)
S 2a0f:5707:ba0e:100::/64          0.0.0.6         type-2     0 :: (ifindex 2)
C 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128 0.0.0.7         type-2     0 :: (ifindex 2)
r0-sto.e-utp.net# show ipv6 ospf6 database

        Area Scoped Link State Database (Area 0.0.0.0)

Type LSId           AdvRouter       Age   SeqNum                        Payload
[..]

        I/F Scoped Link State Database (I/F lo in Area 0.0.0.0)

Type LSId           AdvRouter       Age   SeqNum                        Payload
Lnk  0.0.0.1        51.21.99.1       79 80000001            fe80::200:ff:fe00:0
Lnk  0.0.0.1        51.21.99.1       79 80000001               2001:67c:21ec::1
Lnk  0.0.0.1        51.21.99.1       79 80000001          2001:67c:21ec:9999::8
Lnk  0.0.0.1        51.21.99.1       79 80000001              2a0f:5707:ba00::1

        I/F Scoped Link State Database (I/F tun7 in Area 0.0.0.0)

Type LSId           AdvRouter       Age   SeqNum                        Payload
Lnk  0.0.0.7        51.21.99.1       79 80000001      fe80::f803:cfff:fe6b:db0a
Lnk  0.0.0.7        51.21.99.1       79 80000001           2001:67c:21ec:42b0::
Lnk  0.0.0.11       70.34.220.105  1256 800002c8       fe80::f8af:32ff:fe4f:b56
Lnk  0.0.0.11       70.34.220.105  1256 800002c8           2001:67c:21ec:42b0::

        AS Scoped Link State Database

Type LSId           AdvRouter       Age   SeqNum                        Payload
[...]
ASE  0.0.0.6        51.21.99.1       79 80000001        2a0f:5707:ba0e:100::/64
[...]

r0-sto.e-utp.net#

---Thanks for the detailed comparison, that confirms the route-selection theory: on 1.5.1 there's now a third competing entry for this prefix that doesn't exist on

1.4.4:

K>* 2a0f:5707:ba0e:100::/64 [0/256] is directly connected, eth0
Metric 256 is the Linux kernel's default metric for an automatically-created on-link/prefix route when an address is added to an interface (unless the noprefixroute
flag is set on that address). Since your static route is for that exact /64 via the same interface (eth0), the kernel's own K route now wins the distance-0 tiebreak
and the static route never gets selected/installed - which is why zebra never redistributes it into OSPFv3.

The open question is why that kernel route exists on 1.5.1 but not on 1.4.4 for what you say is the same config. I checked vyos-1x's address-adding code
(Interface.add_addr()) and it doesn't set noprefixroute in either version, so that's not an obvious explanation on its own. To pin down whether this is a VyOS-side
regression (e.g. how the eth0 address itself is assigned) or just an environment difference between your two test setups, could you post, for both versions:

show configuration commands | match eth0 (how is the eth0 address configured - static /64, DHCPv6-PD, SLAAC?)
ip -6 addr show dev eth0 (does the address have the noprefixroute flag set on one version and not the other?)

If the eth0 address configuration is identical on both and the kernel still only installs the on-link route on 1.5.1, that would point to a kernel- or netifd-level
behavior change rather than anything in vyos-1x itself.

Hi.

Doesn't see difference:

1.5.1:

vyos@r0-sto.e-utp.net:~$ show configuration commands | match eth0
set interfaces ethernet eth0 address 'dhcp'
set interfaces ethernet eth0 address 'dhcpv6'
set interfaces ethernet eth0 hw-id '06:a4:76:a9:5d:ab'
set interfaces ethernet eth0 ipv6 address autoconf
set interfaces ethernet eth0 ipv6 adjust-mss '1360'
set interfaces ethernet eth0 mtu '1500'
set nat destination rule 10 inbound-interface name 'eth0'
set nat source rule 10 outbound-interface name 'eth0'
set protocols static route6 2a0f:5707:ba0e:100::/64 interface eth0
set system name-server 'eth0'
vyos@r0-sto.e-utp.net:~$

vyos@r0-sto.e-utp.net:~$ ip -6 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    altname enp0s5
    altname ens5
    inet6 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::4a4:76ff:fea9:5dab/64 scope link
       valid_lft forever preferred_lft forever
vyos@r0-sto.e-utp.net:~$

1.4.4:

vyos@r0-sto.e-utp.net:~$ show configuration commands | match eth0
set interfaces ethernet eth0 address 'dhcp'
set interfaces ethernet eth0 address 'dhcpv6'
set interfaces ethernet eth0 hw-id '06:a4:76:a9:5d:ab'
set interfaces ethernet eth0 ipv6 address autoconf
set interfaces ethernet eth0 ipv6 adjust-mss '1360'
set interfaces ethernet eth0 mtu '1500'
set nat destination rule 10 inbound-interface name 'eth0'
set nat source rule 10 outbound-interface name 'eth0'
set protocols static route6 2a0f:5707:ba0e:100::/64 interface eth0
set system name-server 'eth0'
vyos@r0-sto.e-utp.net:~$ ip -6 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    altname enp0s5
    altname ens5
    inet6 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::4a4:76ff:fea9:5dab/64 scope link
       valid_lft forever preferred_lft forever
vyos@r0-sto.e-utp.net:~$

Thanks, that rules out a config difference - the eth0 setup (DHCP/DHCPv6/autoconf) and the resulting address are identical between the two versions.

Since the actual assigned address is a /128, the /64 K route on 1.5.1 can't come from the address itself - it has to be coming from RA processing: with autoconf
enabled, the kernel can install an on-link route straight from a Router Advertisement's Prefix Information Option (PIO), independently of the address it also
autoconfigures. That's controlled by sysctls, not by anything in the vyos-1x config layer, so if this only happens on 1.5.1 with identical config, it's most likely a
kernel/sysctl-default difference between the two VyOS releases' underlying images rather than a vyos-1x bug.

Could you post, for both versions:

uname -r (kernel version)
sysctl net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_pinfo net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding

If those sysctls differ between versions, that's almost certainly the cause, and this would need to be raised against whatever changed the kernel/sysctl defaults
between releases rather than against vyos-1x directly. If they're identical too, then it really is a kernel-version PIO-handling behavior change and we'd need to
check the actual kernel changelog between the two VyOS releases' kernel packages.

Hi,

1.5.1:

vyos@r0-sto.e-utp.net:~$ uname -r
6.6.144-vyos

vyos@r0-sto.e-utp.net:~$ sysctl net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_pinfo net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.accept_ra_pinfo = 1
net.ipv6.conf.eth0.forwarding = 1
net.ipv6.conf.all.forwarding = 1
vyos@r0-sto.e-utp.net:~$

1.4.4:

vyos@r0-sto.e-utp.net:~$ uname -r
6.6.117-amd64-vyos

vyos@r0-sto.e-utp.net:~$ sysctl net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_pinfo net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.accept_ra_pinfo = 1
net.ipv6.conf.eth0.forwarding = 1
net.ipv6.conf.all.forwarding = 1
vyos@r0-sto.e-utp.net:~$

Both the config and the relevant sysctls (accept_ra/accept_ra_pinfo/
forwarding) being identical on 1.4.4 and 1.5.1 rules out an interface-
config or sysctl-default explanation. I initially suspected a kernel
patch-level difference (6.6.117 vs 6.6.144), but I don't think that's
it either: the likely real candidate is T7531 (bgpd's automatic IPv6
RA sending, the bgp ipv6-auto-ra behavior, disabled via
set protocols bgp parameters disable-ipv6-auto-ra).

I checked upstream FRR history: the underlying auto-RA-sending
behavior (bgpd asking zebra to send RAs on an interface when
extended-nexthop or unnumbered peers are configured) is not new, and
the explicit disable knob (no bgp ipv6-auto-ra, added upstream Sep

was backported into both branches you're running - it's in the

9.1.3 changelog (VyOS 1.4.4) and obviously present in 10.5.2 (VyOS
1.5.1). So the FRR *feature* itself isn't the version-specific part.

What hasn't been checked yet is whether your BGP config (specifically
extended-nexthop / unnumbered peers on or near eth0) is actually the
same on both boxes - only the interface config has been compared so
far, not BGP. If bgpd on the 1.5.1 box has extended-nexthop/unnumbered
enabled (or was set up slightly differently there) and is sending its
own RA out eth0 with a PIO for that /64, that alone would explain the
K route appearing only there - independent of the kernel or FRR
defaults.

Could you check, on the 1.5.1 box:

show configuration commands | match bgp (extended-nexthop / unnumbered peers configured? is disable-ipv6-auto-ra set?)
In vtysh: show interface eth0 (does zebra report RA sending as active on this interface?)
sudo tcpdump -c 5 -i eth0 'icmp6 && ip6[40] == 134' (are RA packets actually arriving on eth0, and what's their source link-local/MAC - the upstream router's, or this box's own?)

And the same show configuration commands | match bgp on the 1.4.4
box, so we can actually compare BGP config between the two rather than
just interface config.

Hi,

There is no BGP on that box.
This box is IPv6 client, RA are send from upstream router, in that case is AWS.

1.4.4/1.5.1:

vyos@r0-sto.e-utp.net:~$ show configuration commands | match bgp
vyos@r0-sto.e-utp.net:~$

1.5.1:
vyos@r0-sto.e-utp.net:~$ sudo tcpdump -c 5 -i eth0 'icmp6 && ip6[40] == 134'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:24:59.796107 IP6 fe80::4f7:44ff:fe8f:a860 > ip6-allnodes: ICMP6, router advertisement, length 56
21:25:10.195912 IP6 fe80::4f7:44ff:fe8f:a860 > ip6-allnodes: ICMP6, router advertisement, length 56
21:25:20.595733 IP6 fe80::4f7:44ff:fe8f:a860 > ip6-allnodes: ICMP6, router advertisement, length 56
21:25:30.995684 IP6 fe80::4f7:44ff:fe8f:a860 > ip6-allnodes: ICMP6, router advertisement, length 56
21:25:41.395387 IP6 fe80::4f7:44ff:fe8f:a860 > ip6-allnodes: ICMP6, router advertisement, length 56
5 packets captured
5 packets received by filter
0 packets dropped by kernel
vyos@r0-sto.e-utp.net:~$

vyos@r0-sto.e-utp.net:~$ ip -6 r s 2a0f:5707:ba0e:100::/64
2a0f:5707:ba0e:100::/64 dev eth0 proto kernel metric 256 pref medium
vyos@r0-sto.e-utp.net:~$

vyos@r0-sto.e-utp.net:~$ ip -6 r g 2a0f:5707:ba0e:100::/64
Warning: /64 as prefix is invalid, only /128 (or none) is supported.
2a0f:5707:ba0e:100:: from :: dev eth0 proto kernel src 2a0f:5707:ba0e:100:14ab:ba50:9291:6963 metric 256 pref medium
vyos@r0-sto.e-utp.net:~$

r0-sto.e-utp.net# show interface eth0
Interface eth0 is up, line protocol is up
  Link ups:       3    last: 2026/08/11 21:21:08.55
  Link downs:     3    last: 2026/08/11 21:20:43.95
  vrf: default
  index 2 metric 0 mtu 1500 speed 0 txqlen 1000
  flags: <UP,LOWER_UP,BROADCAST,RUNNING,MULTICAST>
  MPLS  Not specified by CLI
  Ignore all v4 routes with linkdown
  Ignore all v6 routes with linkdown
  Multicast config is Not specified by CLI
  Shutdown config is Not specified by CLI
  Type: Ethernet
  HWaddr: 06:a4:76:a9:5d:ab
  inet 172.31.24.243/20
  inet6 fe80::4a4:76ff:fea9:5dab/64
  inet6 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128
  Interface Type Other
  Interface Slave Type None
  protodown: off
r0-sto.e-utp.net#

1.4.4:

vyos@r0-sto.e-utp.net:~$ ip -6 r s 2a0f:5707:ba0e:100::/64
2a0f:5707:ba0e:100::/64 nhid 16 dev eth0 proto static metric 20 pref medium
2a0f:5707:ba0e:100::/64 dev eth0 proto kernel metric 256 pref medium
vyos@r0-sto.e-utp.net:~$

vyos@r0-sto.e-utp.net:~$ ip -6 r g 2a0f:5707:ba0e:100::/64
Warning: /64 as prefix is invalid, only /128 (or none) is supported.
2a0f:5707:ba0e:100:: from :: dev eth0 proto static src 2a0f:5707:ba0e:100:14ab:ba50:9291:6963 metric 20 pref medium
vyos@r0-sto.e-utp.net:~$

Thanks,

Thanks - that rules out BGP/extended-nexthop entirely then, good to know it's a legitimate RA from your upstream (AWS) gateway, not a self-sent one.

The ip -6 route show snippets are the most interesting thing yet, though - that's the actual Linux kernel FIB, not zebra's RIB view. On 1.4.4 the static route shows
up there directly with metric 20 (lower than the kernel/RA route's 256), which would explain it winning for real forwarding even independent of zebra's own
distance-based selection.

Could you post the FULL, unfiltered output of this on both versions (all lines, not a snippet - if there's more than one route for the prefix I need to see every one
of them with their exact proto/metric):

ip -6 route show 2a0f:5707:ba0e:100::/64
I want to see whether the static route (proto static, interface-only nexthop) is present at all in the 1.5.1 kernel table, and if so with what metric - or whether
it's missing there entirely (which would mean zebra isn't pushing it into the kernel table at all on 1.5.1, unlike 1.4.4).

1.5.1:

vyos@r0-sto.e-utp.net:~$ ip -6 r s  | grep -v tun7
2001:67c:21ec::1 dev lo proto kernel metric 256 pref medium
2001:67c:21ec:9999::8 dev lo proto kernel metric 256 pref medium
2a0f:5707:ba00::1 dev lo proto kernel metric 256 pref medium
2a0f:5707:ba0e:100:14ab:ba50:9291:6963 dev eth0 proto kernel metric 256 pref medium
2a0f:5707:ba0e:100::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev lo proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::4f7:44ff:fe8f:a860 dev eth0 proto ra metric 1024 expires 1790sec hoplimit 255 pref medium
vyos@r0-sto.e-utp.net:~$

vyos@r0-sto.e-utp.net:~$ ip -6 route show 2a0f:5707:ba0e:100::/64
2a0f:5707:ba0e:100::/64 dev eth0 proto kernel metric 256 pref medium
vyos@r0-sto.e-utp.net:~$

1.4.4:

vyos@r0-sto.e-utp.net:~$ ip -6 r s  | grep -v tun7
2001:67c:21ec::1 dev lo proto kernel metric 256 pref medium
2001:67c:21ec:9999::8 dev lo proto kernel metric 256 pref medium
2a0f:5707:ba00::1 dev lo proto kernel metric 256 pref medium
2a0f:5707:ba0e:100:14ab:ba50:9291:6963 dev eth0 proto kernel metric 256 pref medium
2a0f:5707:ba0e:100::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev lo proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::4f7:44ff:fe8f:a860 dev eth0 proto ra metric 1024 expires 1793sec hoplimit 255 pref medium
vyos@r0-sto.e-utp.net:~$

vyos@r0-sto.e-utp.net:~$ ip -6 route show 2a0f:5707:ba0e:100::/64
2a0f:5707:ba0e:100::/64 dev eth0 proto kernel metric 256 pref medium
vyos@r0-sto.e-utp.net:~$

Thanks for the full dump — that actually complicates things rather than confirming the kernel-FIB-metric theory. Your new output shows the static route absent from the

kernel FIB on both 1.4.4 and 1.5.1 (only proto kernel metric 256 present in each), which contradicts the earlier 1.4.4 snippet showing proto static metric 20 there. So
either that earlier capture was momentary/stale, or the kernel-installed route is not stable over time (e.g. it disappears/reappears around RA refresh or a DHCPv6 lease
event).

That means the kernel-FIB-installation angle probably isn't the real differentiator after all — if 1.4.4 never had the static route in the kernel table either, but still
redistributed it into OSPFv3, then zebra/ospf6d on 1.4.4 must be redistributing from the RIB regardless of FIB-installation state, while 1.5.1 doesn't. That would point to
a redistribution-logic change between FRR 9.1.3 and 10.5.2, not a kernel/routing difference at all.

To pin this down, could you capture all three of the following in a single shot (so timing can't shift between them), on both versions:

vtysh -c "show ipv6 route static json" ; vtysh -c "show ipv6 ospf6 redistribute" ; ip -6 route show 2a0f:5707:ba0e:100::/64

That gives us the RIB state, the actual redistribute count, and the kernel FIB all from the same instant, so we can tell whether the discrepancy is really 1.4.4-vs-1.5.1,
or whether it's time-dependent (e.g. right after commit vs. some minutes later) on both versions.

If 1.4.4 still shows the static route being redistributed (5→6 routes) at that same moment its kernel FIB shows only proto kernel, that would confirm the FIB-installation
state doesn't matter for redistribution on 1.4.4 — which is the key fact we need to compare against 1.5.1's behavior.

Hi,

Data below, but looks like different approach of FRR, could be issue there, but now I thinking how we can workaround it, just to somehow inject route into OSPFv3

1.5.1:

vyos@r0-sto.e-utp.net:~$ date
Wed Aug 12 08:35:53 AM UTC 2026
vyos@r0-sto.e-utp.net:~$ vtysh -c "show ipv6 route static json" ; vtysh -c "show ipv6 ospf6 redistribute" ; ip -6 route show 2a0f:5707:ba0e:100::/64
{"2a0f:5707:ba0e:100::/64":[{"prefix":"2a0f:5707:ba0e:100::/64","prefixLen":64,"protocol":"static","vrfId":0,"vrfName":"default","distance":1,"metric":0,"table":254,"internalStatus":0,"internalFlags":65,"internalNextHopNum":1,"internalNextHopActiveNum":1,"nexthopGroupId":13,"receivedNexthopGroupId":13,"uptime":"02:07:29","nexthops":[{"flags":3,"fib":true,"directlyConnected":true,"interfaceIndex":2,"interfaceName":"eth0","active":true,"weight":1}]}]
}
Redistributing External Routes from:
    5: connected
    0: static
Total 5 routes
C 2001:67c:21ec::1/128             0.0.0.1         type-2     0 :: (ifindex 1)
C 2001:67c:21ec:42b0::/64          0.0.0.2         type-2     0 :: (ifindex 7)
C 2001:67c:21ec:9999::8/128        0.0.0.3         type-2     0 :: (ifindex 1)
C 2a0f:5707:ba00::1/128            0.0.0.4         type-2     0 :: (ifindex 1)
C 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128 0.0.0.6         type-2     0 :: (ifindex 2)
2a0f:5707:ba0e:100::/64 dev eth0 proto kernel metric 256 pref medium
vyos@r0-sto.e-utp.net:~$ date
Wed Aug 12 08:35:58 AM UTC 2026
vyos@r0-sto.e-utp.net:~$

1.4.4:

vyos@r0-sto.e-utp.net:~$ date
Wed Aug 12 08:44:32 AM UTC 2026
vyos@r0-sto.e-utp.net:~$ vtysh -c "show ipv6 route static json" ; vtysh -c "show ipv6 ospf6 redistribute" ; ip -6 route show 2a0f:5707:ba0e:100::/64
{"2a0f:5707:ba0e:100::/64":[{"prefix":"2a0f:5707:ba0e:100::/64","prefixLen":64,"protocol":"static","vrfId":0,"vrfName":"default","selected":true,"destSelected":true,"distance":1,"metric":0,"installed":true,"table":254,"internalStatus":16,"internalFlags":73,"internalNextHopNum":1,"internalNextHopActiveNum":1,"nexthopGroupId":16,"installedNexthopGroupId":16,"uptime":"00:06:48","nexthops":[{"flags":3,"fib":true,"directlyConnected":true,"interfaceIndex":2,"interfaceName":"eth0","active":true,"weight":1}]}]}
Redistributing External Routes from:
    5: connected
    1: static
Total 6 routes
C 2001:67c:21ec::1/128             0.0.0.1         type-2     0 :: (ifindex 1)
C 2001:67c:21ec:42b0::/64          0.0.0.2         type-2     0 :: (ifindex 7)
C 2001:67c:21ec:9999::8/128        0.0.0.3         type-2     0 :: (ifindex 1)
C 2a0f:5707:ba00::1/128            0.0.0.4         type-2     0 :: (ifindex 1)
S 2a0f:5707:ba0e:100::/64          0.0.0.6         type-2     0 :: (ifindex 2)
C 2a0f:5707:ba0e:100:14ab:ba50:9291:6963/128 0.0.0.7         type-2     0 :: (ifindex 2)
2a0f:5707:ba0e:100::/64 nhid 16 dev eth0 proto static metric 20 pref medium
2a0f:5707:ba0e:100::/64 dev eth0 proto kernel metric 256 pref medium
vyos@r0-sto.e-utp.net:~$ date
Wed Aug 12 08:44:37 AM UTC 2026
vyos@r0-sto.e-utp.net:~$

Root cause confirmed — this is an upstream FRR behavior change, not a VyOS bug.

FRR commit d528c02a204086da0d542d5655b8724de681a65c ("zebra: Handle kernel routes appropriately", merged via FRRouting/frr#16300
(https://github.com/FRRouting/frr/pull/16300)) removed a filter in zebra/rt_netlink.c that used to make zebra unconditionally discard any netlink route notification with
rtm_protocol == RTPROT_KERNEL (i.e. proto kernel — exactly what the Linux kernel auto-installs for an RA Prefix Information Option's on-link flag). That filter is present
in FRR 9.1.3 (your 1.4.4) and absent starting with FRR 10.2, including your 10.5.2 (1.5.1).

- Before (9.1.3): the kernel-installed on-link route for your /64 never entered zebra's RIB at all, so your static route was uncontested — selected, installed, and
redistributed into OSPFv3.
- After (10.2+/10.5.2): zebra now imports that kernel route as ZEBRA_ROUTE_KERNEL with the conventional distance 0, which legitimately beats your static route's distance 1
for the same prefix under normal best-path rules — so it wins, and your static route is no longer selected/installed/redistributed.

So functionally this now behaves "correctly" by zebra's own distance rules — it just didn't used to, because the competing kernel route wasn't visible to zebra before. PR
#16300's own description says it was aimed at fixing NOPREFIXROUTE handling for connected addresses; there's nothing in the changelog about RA-derived on-link routes or
static-route interaction, so this specific side effect looks unintended and undocumented. I couldn't find an existing FRRouting issue describing this exact interaction, so
it's likely worth reporting upstream (referencing PR #16300 directly) if you want it addressed at the FRR level rather than worked around here.

For a workaround on your end: since any static route that fully overlaps an RA-advertised on-link prefix will now always lose to the kernel route on FRR ≥10.2, the more
robust fix is avoiding that overlap (e.g. reconsidering whether you need this static route to cover the exact same /64 the upstream router is advertising as on-link)
rather than trying to force redistribution via a workaround — happy to help work through options if useful once you've had a look.

Hi,

So this mean we can close the bug, because it's looks like that I need to redistrubute KERNEL ones with some filtering or you see some other option?

Thanks,

Use the forum if you want to discuss your issue and find solutions
Phorge is the wrong place for it.

ipv6 ospfv3 redistributeClosed, InvalidPublicBUGActions

Description

Details

Related Objects

Event Timeline

ipv6 ospfv3 redistribute
Closed, InvalidPublicBUG
Actions