- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Aug 6 2026
Aug 5 2026
Thanks for reproducing this independently — matches what we found on our own multi-device-unnumbered topology (loopback address duplicated across lo + 3 P2P bond interfaces per router, full-mesh OSPF core). We proved the same underlying inconsistency with a logging-only rule (no notrack, just log+counter, run in parallel with live traffic, zero production impact):
I tested with 2 interfaces when testing BGP over OSPF, but with 8 for BGP only ip unnumbered:
You're right that device binding implicitly selects the VRF — bindacqdevice/binddevice on an interface that belongs to a VRF scopes that socket to it, no separate VRF
option needed for that to work at the chrony level.
Again, VRF is selected through both bindacqdevice and binddevice so having "asymmetric incoming/outgoing VRF binding" works perfectly fine.
binddevice/bindacqdevice are already separately configurable — binddevice maps to the existing interface option (incoming/listen), bindacqdevice to this PR's new
ource-interface (outgoing/client). So incoming vs. outgoing device binding is already independent.
Thanks for testing this — appreciate the data. To reconcile with what we saw: our issue wasn't IP-unnumbered per se, but specifically that our own address appears on
multiple devices simultaneously in the local route table (ip route show table local showed our loopback duplicated across lo + 3 P2P bond interfaces used for OSPF, since
our full-mesh core reuses the loopback address on each P2P link). We proved with a logging-only rule (fib daddr . iif type unicast log) that real traffic to our own
address was classified unicast, never local, even though ip route get reported local for the same case.
OSPF and BGP is for input, so they should be there.
@L0crian: When you did that test did you try to reboot in between?
Its worsen the situation since selecting source-address wont work if thats in a different vrf so that smoketest will fail where it shouldnt.
Can you provide your config you tested with. I just tested and it works as expected even with using ip unnumbered. This is with forwarding traffic going across the router:
Using ip unnumbered BGP over OSPF:
vyos@vyos# run show conntrack table ipv4 Original src Original dst Original packets Original bytes Reply src Reply dst Reply packets Reply bytes Protocol State Timeout Mark Zone -------------- -------------- ------------------ ---------------- ------------ -------------- --------------- ------------- ---------- ----------- --------- ------ ------ 10.0.0.1 224.0.0.5 0 0 224.0.0.5 10.0.0.1 0 0 unknown 596 0 10.0.0.2 224.0.0.5 0 0 224.0.0.5 10.0.0.2 0 0 unknown 598 0 10.0.0.1:43585 10.0.0.2:179 0 0 10.0.0.2:179 10.0.0.1:43585 0 0 tcp ESTABLISHED 431985 0
And if I then delete the disable-conntrack, you can see forward traffic now enters conntrack:
vyos@vyos# delete firewall ipv4 forward filter disable-conntrack vyos@vyos# commit vyos@vyos# run show conntrack table ipv4 Original src Original dst Original packets Original bytes Reply src Reply dst Reply packets Reply bytes Protocol State Timeout Mark Zone -------------- -------------- ------------------ ---------------- ------------ -------------- --------------- ------------- ---------- ----------- --------- ------ ------ 10.0.10.10 10.0.11.10 0 0 10.0.11.10 10.0.10.10 0 0 icmp 27 0 10.0.0.1 224.0.0.5 0 0 224.0.0.5 10.0.0.1 0 0 unknown 596 0 10.0.0.2 224.0.0.5 0 0 224.0.0.5 10.0.0.2 0 0 unknown 597 0 10.0.0.1:43585 10.0.0.2:179 0 0 10.0.0.2:179 10.0.0.1:43585 0 0 tcp ESTABLISHED 431979 0
Using ip unnumbered only BGP:
vyos@vyos# run show conntrack table ipv4 Entries not found
vyos@vyos# run show conntrack table ipv6 Original src Original dst Original packets Original bytes Reply src Reply dst Reply packets Reply bytes Protocol State Timeout Mark Zone ------------------------- --------------------------- ------------------ ---------------- --------------------------- ------------------------- --------------- ------------- ---------- ----------- --------- ------ ------ fe80::ecd:a4ff:fec2:0:179 fe80::eda:29ff:fe4e:0:39492 0 0 fe80::eda:29ff:fe4e:0:39492 fe80::ecd:a4ff:fec2:0:179 0 0 tcp ESTABLISHED 431999 0 fe80::ecd:a4ff:fec2:0:179 fe80::eda:29ff:fe4e:0:39496 0 0 fe80::eda:29ff:fe4e:0:39496 fe80::ecd:a4ff:fec2:0:179 0 0 tcp ESTABLISHED 431999 0
Thanks both for the input.
@Apachez: Thanks for the feedback — you're right that a source IP alone doesn't fully solve this for multi-VRF setups with overlapping address ranges.
Is this the same (exists in Stream 2026.03)?
Also currently missing in Stream 2026.03:
It seems that this change occurs behind the scenes as in not a configurable option. Being dealt with by adjusting buffers so jumboframes are still properly supported (even if DPDK documentation claims this is NOT compatible with jumbo frames!?).
How will it work if I got 2 different VRFs?
Aug 4 2026
Correct, if you want to test it you'd have to test on rolling. If the feature works for you, you could then request the feature get backported to 1.5. The commit was on the 1.5 board, so I'm not sure why it wasn't backported before the GA was released.
@L0crian the command :
Aug 3 2026
@L0crian thx for this information, this could help with my current setup. I will try it in the lab. But I also see that my patched could be usefull
I can create a patch for this if wanted
Your addition is still useful because it lets you match only on specific interfaces or traffic, but have you seen that you can already do this?:
Aug 2 2026
Aug 1 2026
Jul 31 2026
This includes but not limited to:
- Updating the CI workflows
- Troubleshooting the upstream provider changes
- Fixing failing tests
- Assisting contributors with their PRs, reviewing their PRs
- Updating branches
Jul 30 2026
It was available in 1.4 but with different variable name WLB_SCRIPT_IFACE-