In T1185#133944, @sdev wrote:

A similar syntax change is in progress as part of a larger firewall refactor. It should reach the 1.4 branch in a week or so. It should allow for any valid existing interface name.

In T1185#133941, @roedie wrote:

Just a suggestion, would it be a weird idea to move the firewall config from the interface section to the firewall section? A bit like the zone config. So something like:

set firewall local interface eth0 name <firewall-filter>
set firewall in interface eth0 name <firewall-filter>
set firewall out interface eth0 name <firewall-filter>
set firewall local interface bond0.10v22v6 ipv6-name <firewall-filter>

The problem is that using zone-policy firewall is a bit overkill for a pure router or even a router with async routing. In which scenario I guess only the local variant would be useful.

Or, come to think, some free from of set interfaces unknown <typeyourownname> firewall local name <ruleset> where you can only config stuff that doesn't really depend on an interface.

Just a suggestion, would it be a weird idea to move the firewall config from the interface section to the firewall section? A bit like the zone config. So something like:

First we need to include the "google-authenticator" in our build

/usr/libexec/vyos/op_mode/route.py already exists but without an execution flag
PR https://github.com/vyos/vyos-1x/pull/1531

I am suggesting marking this task as "Resolved" because the driver works by himself and NIC can be used with a proper configuration.

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

The real check without IPv4 local/remote:

vyos@r14# commit
[ interfaces openvpn vtun2 ]

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

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

Created pull request with fix. https://github.com/vyos/vyos-1x/pull/1527

I've tested this and it seems to work correctly.

The interface naming is incorrect after this change for the second interface with the same VRID. It breaks show int.

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

@aserkin Could you create a PR?

As @zsdc says, it's not enough to just have the driver, the problem is that it doesn't work with MTUs over 1460, and VyOS now tries to force it to 1500 if it's not specified. We need to adjust that logic so that MTU setting error doesn't cause a commit error.

I'd suggest adding

**Restart=always
RestartSec=10**

to /usr/share/vyos/templates/telegraf/override.conf.j2 as it is done for ntp.service.
Otherwise the telegraf service do not start - it does 5 start attempts very quickly during boot with error:

Sep 07 11:43:59 vyos-lns-1 systemd[1]: telegraf.service: Failed with result 'exit-code'.
Sep 07 11:43:59 vyos-lns-1 systemd[1]: telegraf.service: Scheduled restart job, restart counter is at 5.
Sep 07 11:43:59 vyos-lns-1 systemd[1]: telegraf.service: Start request repeated too quickly.
Sep 07 11:43:59 vyos-lns-1 systemd[1]: telegraf.service: Failed with result 'exit-code'.

and stays in a failed state.
see boot log attached.

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

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

Changes for the inversion operator (--not-range instead of !) have been made. Generalizing exit codes, as suggested in PR comments will be handled in a separate task.

The PR:

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

The [email protected] seems to work well after the fix. We should backport this to the equuleus as well.

As we have threshold it seems require migration threshold => threshold general

vyos@r14# set service ids ddos-protection threshold 
Possible completions:
   fps                  Flows per second
   mbps                 Megabits per second
   pps                  Packets per second

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

set system update-check auto-check
set system update-check url 'http://192.168.122.14:8080/download/image-version.json'

PR for VyOS 1.3

• https://github.com/vyos/vyos-1x/pull/1520
• https://github.com/vyos/vyos-build/pull/261

When the interface of the bridge registers VLANs, the bridge itself must register the same VLANs at the same time, otherwise the bridge will not forward VLANs