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

@Viacheslav yes, I already did last month, but there were lots of errors when veryfing the fix.
I figured it came due to the changes performed by task https://vyos.dev/T5048.

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

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.

One way however to make the variable more robust in case there are for whatever reason more than one squashfs mounted object available is to select the one who is "loop0".

Looking through https://vyos.dev/T5457 I now get what you meant by "re-broke it".

But before the revert by T5690 today T5440 worked perfectly fine so what was "re-broken"?

Nope, it works fine, now; your revision to the change re-broke it.

https://github.com/vyos/vyos-build/pull/441 PR has been created

Does your 5G-modem do any NAT on its own or does it just forward the DHCP to the ISP?

So in short https://vyos.dev/T5440 will be broken again?

It was fixed in a keepalived project.
https://github.com/acassen/keepalived/commit/9ca8688c7fe591e1face259f19ee6169e20a3438

Should be fixed in https://vyos.dev/T5232
needs to re-check

Does your 5G-modem do any NAT on its own or does it just forward the DHCP to the ISP?

Could also be if legacy spanning-tree is being used that it will take approx 25 seconds before packets are being forwarded after a linkdown - workaround here is to enable "spanning-tree portfast" or disable spanning-tree.

For the record.

Oops, wrong task.

I would just expose these 3 options as-is.

Yes, it does. thank you

@SrividyaA Can you confirm this is working as you expect?

@a.apostoliuk Can you confirm this is working as expected?

This error was already fixed in https://github.com/vyos/vyos-1x/pull/2406

@jvoss thanks to confirm !

PR for op-mode command that fits new cli: https://github.com/vyos/vyos-1x/pull/2408

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

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

Do you have any idea for CLI?

Hi @fernando. I can confirm this behavior is still working correctly after this was merged: