@hybridops It would be great to provide both variables retaining backward compatibility. Thanks.

Thanks @sageframe for the update and the original report.

Thanks, no-prompt does the job for my case, I'll use that.

Following @rherold analysis of root cause above, cf. https://github.com/vyos/vyatta-cfg/pull/153 --- so you can simply add the no-prompt option to the script in question.

PR https://github.com/vyos/vyos-1x/pull/5340

Related PRs:
https://github.com/vyos/vyconf/pull/64
https://github.com/vyos/vyos-1x/pull/5395

https://github.com/vyos/vyos-1x/pull/5394

Thx for the Information, but I saw here also the possibility to give this to upstream finding a better solution for this.

We usually don't add docs task for the forge.
You can add PR directly to documentation repo without task number

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

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?

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

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

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).

The config in VyOS is stored in /config/config.boot as json-file.

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:~$

PR https://github.com/vyos/vyos-documentation/pull/2195

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.

Test results: rebuilt vyos-linux-firmware against the IWLMLD-enabled kernel (rolling @ 6.18.44) with the missing files included, rebuilt the ISO, and the BE200 now works end-to-end on the same hardware from the original report:

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

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).

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

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

Doesn't see difference:

---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:

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

Follow-up: I test-built an ISO from rolling with the merged fix (e14a489) to validate on the same BE200 hardware. The initial PR works... the card is now properly detected:

https://github.com/vyos/vyos-1x/pull/5393

https://github.com/vyos/vyos-1x/pull/5388

PR https://github.com/vyos/vyos-1x/pull/5249

PR https://github.com/vyos/vyos-build/pull/1265

In T9197#274465, @Viacheslav wrote:

@srnoth Would you like to claim the task and submit a PR?

@srnoth Would you like to claim the task and submit a PR?

PR https://github.com/vyos/vyos-build/pull/1263

PR https://github.com/vyos/vyos-build/pull/1264

PR https://github.com/vyos/vyos-1x/pull/5378

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

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

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.

I dropped a PR for this change, here: https://github.com/vyos/vyos-1x/pull/5392

https://github.com/vyos/vyos.vyos/pull/495

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

https://github.com/vyos/vyos-1x/pull/5391

Hi @hybridops could you add a PR and maintainers will take a look on proposed fix.
Thanks

PR https://github.com/vyos/vyos-1x/pull/5387

This is the same boot-time interface-naming race tracked by T3871, here triggered by a slow-initializing NIC (an empty-cage Intel ice E823-L, which delays bring-up with a DDP-package load plus a firmware "module not present" media check) rather than a multi-vendor probe-order difference. Related interface-ordering reports for cross-reference:

There are several places that may be affected by VPP
Though it mentioned in the VyOS documentation, it seems we should consider additonal option like warnings, needs to be discussed with maintainers

Data Path Limitations

Took a look at the current vpp-1.5 code to scope this out.