I have added a Pull Request under https://github.com/vyos/vyos.vyos/pull/494

Closed in https://vyos.dev/T9122

I checked the current public vyos-cloud-init branches and the issue still appears to be present: cloudinit/stages.py calls util.del_file(self.paths.instance_link), while util.del_file() uses os.unlink(), so a stale real directory at that path still raises IsADirectoryError.

I would like to work on this task.

PR submitted and ready for review:
https://github.com/vyos/vyos-cloud-init/pull/116

I would like to work on this task.

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

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

Running Commit again after the modem 0 is exist does work.

Update: the "Low fit" verdict above for policy as-path-list/community-list/extcommunity-list/large-community-list ("no natural derivation source") needs a caveat.

@Viacheslav thx for cleanup the task,. Did you see that I ask for an decision from the team about the implementation?

In T9172#273881, @Viacheslav wrote:

@hybridops Would you like to claim this task?

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

@bradkollmyer Would you like to claim this task?
At first glance all related changes here https://github.com/vyos/vyos-1x/blob/278fba204200f02bb461f786f889b40dc38a26f6/python/vyos/template.py#L907

@hybridops Would you like to claim this task?

File is present int rolling release. Please use any rolling release published AFTER this post.

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

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

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

@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?

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

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

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

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 :

https://github.com/vyos/vyos-documentation/pull/2187

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

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

https://github.com/vyos/vyos-documentation/pull/2186

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

https://github.com/vyos/vyos-documentation/pull/2185

See https://github.com/vyos/vyos-1x/pull/5371

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