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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 28 2023
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?
Oct 27 2023
@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".
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?
Oct 26 2023
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
Do you have any idea for CLI?