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

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

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

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.

The intended upgrade to debian trixie will provide nginx version 1.26.3.

Changing this counter value from 100 (25seconds) to 200 (50 seconds) works for me:
https://github.com/vyos/vyos-1x/blob/f6a1ff94f02282bd018b9b49ae1a9812619ec7ba/src/conf_mode/interfaces_wwan.py#L143

Made a crack at a PR in my own fork. Not sure If its correct, but happy to get feedback 😀

Adding the raw command outputs as a comment — the code blocks in the description lost their monospace formatting and I don't have edit rights to fix them inline. All addresses are anonymised (RFC 1918 / RFC 5737 documentation ranges).

In T7736#274164, @MattK wrote:

This change seems to have broken the container smoketests due to a dual-stack issue: https://github.com/vyos/vyos-1x/actions/runs/30939432127/job/92574815074

This change seems to have broken the container smoketests due to a dual-stack issue: https://github.com/vyos/vyos-1x/actions/runs/30939432127/job/92574815074

hi please try:

One thing not covered above — this isn't rolling-only. Same box migrated to Stream 2026.03 (circinus), reproduces identically:

Root cause found: ask_yes_no() in python/vyos/utils/io.py:57 catches EOFError from input() but loops right back to the top of while True with no backoff or exit condition:

Also reproduces on VyOS Stream 2026.03 (circinus), not only rolling.

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

PR: https://github.com/vyos/vyos-1x/pull/5389
PR: https://github.com/vyos/vyos-documentation/pull/2193

@Apachez default powerdns: https://doc.powerdns.com/recursor/security.html it seems it was taken over from the debiab powerdns package.

I think most implementations in VyOS regarding source-interface is referencing physical or logical interfaces and not VRF's even if VRF's is an "interface" in Linux (which can be seen if you do ip a in bash mode).

Why does it phone home like this?

Ad.1/2 It's there

PR:
https://github.com/vyos/vyos1x-config/pull/91

Hi, thanks for the detailed report.

https://github.com/vyos/vyos-build/pull/1262