Running into this as well on: 1.4-rolling-202307260317
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 6 2023
Lets keep this one open for some more time and see if the issue is resolved or not.
Aug 5 2023
There is a bugzilla opened for this issue: https://bugzilla.netfilter.org/show_bug.cgi?id=1697
I can confirm that updating blacklist now is vrf aware and functional:
PR created: https://github.com/vyos/vyos-1x/pull/2135
PR created: https://github.com/vyos/vyos-1x/pull/2135
Added task https://vyos.dev/T5440 to fix the issue of preconfig-script doesnt show up in /config/scripts after system upgrade (add system image).
The reason *I* use chrony with my linux qemu guests, is that it supports using the kvm_ptp to get the kvm hypervisor's time as sync source, and I then don't need the VM to chat with NTP servers.
PR for 1.3 https://github.com/vyos/vyos-1x/pull/2134
PR for 1.3 https://github.com/vyos/vyos-1x/pull/2134
Fixed in the latest rolling release
I need some help with this one.
It seems happy for now:
[email protected]:~$ systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Sat 2023-08-05 21:00:00 CEST 38min left Sat 2023-08-05 20:00:01 CEST 21min ago logrotate.timer logrotate.service
Bug present in 1.3.3 as well
Also watchfrr was disabled some time ago as FRR process handling was moved to systemd.
FRR mgmtd can not be disabled.
Aug 4 2023
The VRF error applies to DHCPv6, too
Note, if mgmtd is of no use in VyOS then the preferred is to have it disabled all together (after updating daemons.tmpl in case it gets enabled in future).
PR created: https://github.com/vyos/vyos-1x/pull/2132
Could be added the same way https://github.com/vyos/vyos-1x/blob/8f161eaae78769e5a1d573e43f00a0f439aadc28/debian/vyos-1x.postinst#L126-L139
Aug 3 2023
Note also that 1.4 rolling as of today (3rd aug) uses FRR 9.0 (previously I think 8.5.4 were used or something like that).
Yes, i did that as option A yesterday. And rebooted. Then removed "zebra nexthop-group keep 1" and play a bit with interfaces up/down until kernel routes vanished. Then i put "zebra nexthop-group keep 1" back and rebooted again.
Will try option B then.
Meanwhile it appeared possible to fix "Route install failed" errors. I turned on debug zebra kernel, found the nhg_id which caused route install error and created it manually using nh1/nh2 provided by vtysh -c "show nexthop-group rib <nhg_id>". Just as it is described in the original thread regarding ipv6 routes.
Note that you had an "s" too much in your command.
Found that the defaults in daemons-file are set by VyOS in /usr/share/vyos/templates/frr/daemons.frr.tmpl
There is still some problem with the workaround proposed. It seems not fully working when applied on the running system with active BGP sessions. At least i still see the next hop groups in the kernel which has only one next hop after our last tests:
Hi
I would like to see last delay sessions be minimum allowed integer be 0 not 1 to 999999