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.

The new firewall niw has no such restrictions on port definitions, going to close this as resolved.

This is now implemented in 1.4

Should be fixed now with https://github.com/vyos/vyos-1x/pull/1193

Above fixed in PR: https://github.com/vyos/vyos-1x/pull/1193

With nftables, this should in principle be possible with nested variables, and the firewall groups are based on these now.

We confirmed the problem - some serial consoles continue to work well, some are not initialized properly with the --keep-baud option. For example, this can be reproduced in the SOS console in Equinix Metal.
Originally, the problem comes from a systemd service template.
Since it is not completely clear if the option is necessary in one case or another, it seems that the best solution would be to provide the ability to set/remove it from the CLI, so everyone may configure what works best for his hardware.

Incorrect behavior with multiple commits
Configuration:

set policy local-route rule 10 set table '101'
set policy local-route rule 10 source '192.0.2.1'
set policy local-route rule 10 source '192.0.2.2'
commit
set policy local-route rule 10 destination '203.0.113.25'
commit

Expected rules:

10:	from 192.0.2.1 to 203.0.113.25 lookup 101
10:	from 192.0.2.2 to 203.0.113.25 lookup 101

Getting rules:

10:	from 192.0.2.2 lookup 101
10:	from 192.0.2.1 to 203.0.113.25 lookup 101
10:	from 192.0.2.2 to 203.0.113.25 lookup 101

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

As reproducing the exact issue seems to be difficult, I'm going to instead change the install function so it catches errors and outputs the set pki ... syntax so it behaves like generate pki ... install <name> is run from op-mode anyway.

Actually.. re-testing now I'm also unable to reproduce this. I would guess it was some sort of environmental bug. This time I have ensured that I am using the exact input parameters I was using before and am also in conf mode but it just works. I would say let's close this issue for now and if I run into this again I'll double check the reproducability and ask to reopen this issue.

@sdev You are spot on. I did run it with "run" in conf mode (sorry for editing that out :). But it does bungle it in conf mode on VyOS 1.4-rolling-202201240317 with a non 'vyos' user. Maybe that (the non-vyos user) is what is tripping it up.

This issue is due to negated source/destination port not being handled properly in code, not validation.

It looks like it’s trying to directly install the certificate into the config from op-mode, that is only supposed to happen while you're in configure mode calling the command using run generate pki ... install <name>.

Important to note that simply running the failing set command (pki certificate v.my.domain certificate <base64-cert-here>) in config mode works fine.

Is it the same task T4138 ?

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

I had forgotten about the recent syntax and it was merged in a broken state (https://github.com/vyos/vyos-1x/blob/current/python/vyos/firewall.py#L164). We should try and find a remedy, or remove it from CLI.

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

set policy prefix-list TST_PRF_LST rule 10 action 'permit'
set policy prefix-list TST_PRF_LST rule 10 prefix '10.5.5.0/24'
set policy prefix-list TST_PRF_LST rule 20 action 'permit'
set policy prefix-list TST_PRF_LST rule 20 prefix '10.6.6.0/24'
set policy prefix-list TST_PRF_LST rule 30 action 'permit'
set policy prefix-list TST_PRF_LST rule 30 prefix '10.6.6.0/24'

Try to dump traffic from the required interface

For first do these changes as in commit
Try policy local route, for example:

set policy local-route rule 10 set table 111
set policy local-route rule 10 source 192.0.2.0/24

The main reason:

@Rhongomiant Am I understanding correctly that you don't see the default route in table 111?

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

@sdev Thanks