Confirm
VyOS 1.4-rolling-202201291849

My hunch would be that this is the breaking commit, given the context:

Thanks!😀

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

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

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

I already have a fix for this from your comment on T4213. Will have it included in a PR shortly.

I don't know what I'm building. How can I be sure I'm actually building 1.3.0 rather than 1.4? I ask because when I boot off the build I compiled I get the following message at the start of the boot process. Is it 1.3.0 or sagitta (1.4)?

The same situation if you set the number or special symbol.

I've checked the same scenario on the cisco router.

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

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

Failover is handled by my firewall which is upstream of VyOS which I am using more as a router than anything. The commit you listed I believe is actually the fix for T4206, not for this, but I can certainly try that to see if I'm up and running and to see if the issue I'm reporting here is resolved, since I have only tried this setup in 1.3.0 RC6. I'm not sure why you'd think I'd need " failover with custom hook-scripts" for this issue. All I'm trying to do is have a PBR for traffic with the destination IP of local VyOS interfaces to use the main table rather than the vrf table. I also have an issue where if I ping the IP on the FIOS WAN interface from upstream, the reply traffic from the VyOS is sent downstream to the FiOS gateway, so this fails. However, the VyOS isn't doing that for the WOW! WAN interface, and I get the replies as expected. So it seems there are strange things happening. Either things not being cleaned up and/or not being set up right.

Good question. I missed this moment.
So, if you want to reload in some minutes, VYOS offered you two variants:

1. To choose between 1 and 99
2. To set time when you want to reload VYOS if 99 minutes too short for you (for example 10:00, 12:45, 23:59, and so on)

But descriptions of thees command doesn't have enough information about it.

I've actually found a way to define this properly, resulting rule now looks like below:

tcp dport { 22 } add @FOO_30 { ip saddr limit rate over 4/minute burst 4 packets } counter packets 3 bytes 156 reject comment "FOO-30"
ct state { new } tcp dport { 22 } counter packets 5 bytes 260 return comment "FOO-40"

@adestis https://github.com/vyos/vyatta-config-mgmt/tree/equuleus

I could commit a merge request but I have not figured out in which repo the file is located.

@Viacheslav steps to reproduce:

I'm not completely sure that behavior in 1.4 is the correct one.
If I add these two routes:

vyos@vyos# set protocols static route 8.8.8.8/32 dhcp-interface eth0
vyos@vyos# set protocols static route 8.8.8.8/32 dhcp-interface eth1

I would expect to see both in main routing table, as it is in 1.3 version. I would expect that latest command doesn't overwrite previous command, as user may want/need redundancy for that particular route.
So I think that adding routes to main routing table and not overwriting previous entry is the correct behavior.
IMO in 1.3:

• Second route is added and not overwriten in main routing table -- OK
• But in vyos cli, second route overwrites the first one, when both routes should remain present in config --- Not OK

I agree with @johannrichard, having recent "change" behavior is probably going to cause some confusion.

I‘m no expert here nor extremely strong opiniated. My thoughts though: if theres no exact equivalent, why try to re-implement the recent functionality with nftables at „all“ cost?

Why is it 1-99?
If I want to reboot the router in 1500 min?

Hi again, I found another bug, if I have two policy routes with the same table it tries to create the table twice, and it doesn't work because the table is already created:

It's good to know that it works as expected on 1.4-rolling. Is it possible to get a fix for 1.3?

We didn't receive the customer's request.
The timers work without problems.
I'll open a design request to see the range 1-99.

I have emulated the same scenario in to vyos VyOS 1.4-rolling-202201041316
And it works well.
{

vyos@vyos:~$ show dhcp client leases
interface  : eth0
ip address : 172.168.32.146     [Active]
subnet mask: 255.255.255.0
domain name: localdomain        [overridden by domain-name set using CLI]
router     : 172.168.32.2
name server: 172.168.32.2
dhcp server: 172.168.32.254
lease time : 1800
last update: Fri Jan 28 01:09:31 UTC 2022
expiry     : Fri Jan 28 01:39:30 UTC 2022
reason     : RENEW

Good to hear, going to mark this as resolved.

Hi,
I applied your new policy-route.py manually, and now my ipv6 pbr works again!! Thanks a lot!

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

In T4209#117579, @thomasjsn wrote:

In T4209#117429, @sdev wrote:

Would changing the guide to use limit rate 4/minute achieve the same target functionality?

What is the practical difference between limit rate and recent? Is it just two different ways of accomplishing the same?

In T4209#117429, @sdev wrote:

Would changing the guide to use limit rate 4/minute achieve the same target functionality?

I've come up with a working idea how to implement but would like feedback before submitting a PR.

Thanks for the report, I believe I know what's caused it to break. Hopefully will have a fix in for the build tomorrow.

I'm looking into it. I'm going to add a test with multiple commits. Good catch, I didn't test this. :)

@johannrichard Hey sorry I didn't see your comment, I suggest we move the discussion to the dedicated task: https://phabricator.vyos.net/T4209

This was included with the new firewall, going to mark as resolved.