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:

To verify that it isnt something in your 5G modem that triggers this behaviour try to put a L2-switch in between and then simulate a link failure between VyOS and this L2-switch and see how things behaves?

I've tested this issues in our lasted rolling-realese , after last commit , it seems works without problems :

vyos@vyos# load test.conf
Loading configuration from 'test.conf'
Load complete. Use 'commit' to make changes effective.
[edit]
vyos@vyos# compare
[policy]
+ route-map TEST {
+     rule 10 {
+         action "permit"
+         set {
+             community {
+                 add "65001:1"
+             }
+             large-community {
+                 add "4200000000:100:1"
+             }
+         }
+     }
+ }