@Viacheslav @n.fort Regarding https://github.com/vyos/vyos-1x/pull/2388: I just tested on 1.4-rolling-202311021131: ZBF config from 1.4-rolling-202304120317 loaded without a hitch.
This is a 8 zone, 959 line config.

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

I understand (and accept) the risks of running rolling.

In T5681#163634, @JeffWDH wrote:

When moving from vyos-1.5-rolling-202310090023 to vyos-1.5-rolling-202311020022 all of my inbound-interfaces got dropped from my firewall config. The NAT ones got migrated successfully.

Snippet from vyos-migrate.log:

List of executed migration scripts:
List of executed migration scripts:
List of executed migration scripts:
/opt/vyatta/etc/config-migrate/migrate/cluster/1-to-2
/opt/vyatta/etc/config-migrate/migrate/interfaces/31-to-32
/opt/vyatta/etc/config-migrate/migrate/nat/5-to-6
- op: delete path: ['nat', 'source', 'rule', '40', 'outbound-interface']
- op: set path: ['nat', 'source', 'rule', '40', 'outbound-interface', 'interface-name'] value: vtun0 replace: True
- op: delete path: ['nat', 'source', 'rule', '41', 'outbound-interface']
- op: set path: ['nat', 'source', 'rule', '41', 'outbound-interface', 'interface-name'] value: vtun1 replace: True
<omitted a bunch of NAT rules>
/opt/vyatta/etc/config-migrate/migrate/nat/6-to-7
- op: delete path: ['nat', 'source', 'rule', '40', 'outbound-interface', 'interface-name']
- op: set path: ['nat', 'source', 'rule', '40', 'outbound-interface', 'name'] value: vtun0 replace: True
- op: delete path: ['nat', 'source', 'rule', '41', 'outbound-interface', 'interface-name']
- op: set path: ['nat', 'source', 'rule', '41', 'outbound-interface', 'name'] value: vtun1 replace: True
<omitted a bunch of NAT rules>
/opt/vyatta/etc/config-migrate/migrate/nat66/1-to-2

After readding them with the new syntax all is good, but it looks like for some reason the migration script didn't run on my system.

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

When moving from vyos-1.5-rolling-202310090023 to vyos-1.5-rolling-202311020022 all of my inbound-interfaces got dropped from my firewall config. The NAT ones got migrated successfully.

Part of those is fixed with telegraf update in T5701

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

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

PR for 1.4 https://github.com/vyos/vyos-build/pull/451

Fix build PR https://github.com/vyos/vyos-build/pull/450

PR https://github.com/vyos/vyos-build/pull/448

PR https://github.com/vyos/vyos-build/pull/445

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

PR for 1.5 which will be backported to 1.4 https://github.com/vyos/vyos-1x/pull/2416

I'm building 1.4 rolling with the ixgbe out-of-tree driver if anyone cares.

Instead of "deny all" if no allow-clients are configured then localhost is always allowed. Can be handy when using containers and other if needed to sync to localhost for whatever reason (if the use of RTC isnt enough).

This has been implemented in 1.5 and 1.4.

@Apachez this request stems from this issue: https://forum.vyos.io/t/evpn-vxlan-esi-lag-duplicate-packets/12581

Both single-active and all-active should be supported when it comes to EVPN Multihoming.

I believe it's probably generating this error because modem sends an empty hostname.

Logs from just dhclient.

I didn't update it since the initial report and I don't really understand how/why it's working again.

PR for 1.5 current https://github.com/vyos/vyos-1x/pull/2413 which will then also be backported to 1.4

I would still recommend you to try to test to put a L2-switch between your 5G-router and the VyOS box and see if that resolves the situation.

This functionality has also been backported to 1.4 so it will be in the next LTS release.

Original template /usr/share/vyos/templates/chrony/chrony.conf.j2 (just the allow and listen sections):

What kind of cleanup are you talking about?

Turns out that the output of bindaddress will be broken unless put in a loop even if a single entry the only allowed entry.

This task is regarding to add localhost by default as allowed source to speak to chronyd (the current NTP daemon in VyOS).

Since the root cause for this task have been identified and fixed by the reporting user (and the task is set to invalid) I have created another task for the spinoff regarding cleaning up of the template used by chronyd:

As it seems according to https://manpages.debian.org/bookworm/chrony/chrony.conf.5.en.html both bindaddress and binddevice can only be specified once.

Ahh yes, I think there is another task in here regarding adding firewall rules by default to the firewall to avoid situations like this :-)

I added the above modifications to /usr/share/vyos/templates/chrony/chrony.conf.j2 and rebooted VyOS 1.5-rolling-202310240118.

I found the issue. I was missing a firewall input rule to allow anything from lo.

With my config chronyd still listens locally on 323:

udp        0      0 192.168.2.253:123       0.0.0.0:*                           20420/chronyd
udp        0      0 127.0.0.1:323           0.0.0.0:*                           20420/chronyd
udp6       0      0 ::1:323                 :::*                                20420/chronyd

I havent been using ninja2 scripting previously but Im guessing something like this would be needed:

Here is the output of sudo ls -la /run/chrony (just booted up so drift will probably missing for some time):

Any docs or example on how bfd interacts with pim?

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

It is not, but I do not want to make my NTP internet-facing anyways.

Is your WAN interface also in net 192.168.0.0/16?

Can you show the output of sudo ls -la /run/chrony?

My VyOS NTP config:

set allow-client address '192.168.0.0/16'
set listen-address '192.168.2.253'
set server time.aws.com pool
set server time.google.com pool

PR created: https://github.com/vyos/vyatta-op/pull/79

PR created: https://github.com/vyos/vyatta-op/pull/79

How is your current ntp configuration (as outputed by show config commands)?