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

I had a thought about this today, and I think a more immediate fix for this specific issue could simply be replacing these lines in the nftables.j2 templates:

"{%     if ipv4.forward is vyos_defined %}"

With these lines:

"{%     if ipv4.forward is vyos_defined and ((ipv4.forward.filter | length) > 1 or ipv4.forward.filter.default_action == 'drop') %}"

So if someone has anything other than default-action configured, like description, then it will generate that chain. Or if default-action is configured as "drop", as that differs from the <defaultValue> element. But this could maybe be a better fix for this specific issue, and be a better backport candidate if it is deemed so.

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

I tested with 2 interfaces when testing BGP over OSPF, but with 8 for BGP only ip unnumbered:

OSPF and BGP is for input, so they should be there.

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

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

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.

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

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

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

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

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

In T8316#251709, @sarthurdev wrote:

While not ideal, I don't see the built-in being used in that conf script?

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

This way, it is simple to handle native nft commands with custom tables, then use them in the VyOS CLI.
I'm not expecting this feature to be implemented in the suggested format.

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

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

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

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

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

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

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

vyos-build PR to add zerotier binary: https://github.com/vyos/vyos-build/pull/1041

PR for fix: https://github.com/vyos/vyos-1x/pull/4733

Looks like all of the calls to the script for the reset-ip-bgp.xml.in file are wrong. I originally was making a dedicated reset_bgp.py script before just incorporating it into bgp.py. I must have forgot to update those. I'll make a PR to fix it.

A quick flyby review shows the number of lines of code could be reduced by quite a bit. This isn't conclusive for a direction one way or the other. Just informational. Less code does not necessarily equal better:

Adding to this conversation. The one benefit to how things are currently being done is that changes to a single section (firewall, policy, conntrack, nat) just requires a simple delete of the entire table, then an atomic load of the updated config.

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

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

In T7144#234113, @astr0n8t wrote:

Everything seems to be working as it should on both 1.4.3 and 1.5Q2 for stream, I recently started running tailscale in a container which creates tailscale0 and while I was expecting to run into issues with this, I did not, but it got me thinking, does the interface even need to exist to be able to add it to the nftables ruleset?

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

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

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

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

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

I found a companion issue to this and created a task for it:
https://vyos.dev/T7781

@c-po

! In T7760#233813, @L0crian wrote:
Quick note on this. It'll maintain the existing AS-Path in the advertisements, but it COULD change the behavior of route rejection on received routes.

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

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

In T7769#234133, @Viacheslav wrote:

What about option priority?

set container name c1 priority 1
set container name c2 priority 2

Do you mean to manipulate the start order of the containers? If so, I don’t think it’d solve the issue. On a suitably fast system, all of the containers would start within a fraction of a second of each other. So it’d be a race condition that would almost always fail.