I added a comment to https://github.com/FRRouting/frr/issues/12239 so hopefully there might be some other commands or stuff to do other than the debug-commands to hunt this thing down.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Aug 7 2023
Adding what was available this time. Will try to turn on debugs next time if we have another chance. Yes, the behavior was identical to previous.
And the logs looks the same as in your original post?
After 19 hours of production run since yesterday the failure occurred again despite the workaround applied. Routes are cleared from kernel for some reason. During the run we observed few l2tp tunnels drops followed by 600 to 6000 sessions drop. The reason is not clear for now but i'm not sure this should kill zebra functionality this way.
Fixed
set qos interface eth1 egress 'VyOS-HTB' set qos policy shaper VyOS-HTB bandwidth '100mbit' set qos policy shaper VyOS-HTB class 10 bandwidth '40%' set qos policy shaper VyOS-HTB class 10 description 'dscp_EF_ipprec_5_GETS' set qos policy shaper VyOS-HTB class 10 match AF11 ip dscp 'AF11' set qos policy shaper VyOS-HTB class 10 priority '1' set qos policy shaper VyOS-HTB class 10 queue-type 'fair-queue' set qos policy shaper VyOS-HTB class 20 bandwidth '30%' set qos policy shaper VyOS-HTB class 20 description 'dscp_AF4x_ipprec_4' set qos policy shaper VyOS-HTB class 20 match ef ip dscp 'EF' set qos policy shaper VyOS-HTB class 20 priority '2' set qos policy shaper VyOS-HTB class 20 queue-type 'fair-queue' set qos policy shaper VyOS-HTB default bandwidth '20%' set qos policy shaper VyOS-HTB default queue-type 'fq-codel'
Dont count on it - the way things works on internet is that there are alot of people complaining at stuff but very few who does something about it :-)
The way I use it is a bit weird. I have ESXi installed on the host and since it has no driver for it, i pass it through to vyos and then bridge it with a vmxnet interface so that hosts in the same virtual switch can use that interface instead of the usb one I use for ESXi remote access.
@c-po Tried with latest rolling 1.4-rolling-202308060317, rpki doesn't start automatically, one must do:
Latest rolling uses FRR 9.0. - could you re-test it please?
Aug 6 2023
Running into this as well on: 1.4-rolling-202307260317
Lets keep this one open for some more time and see if the issue is resolved or not.
If it crashes it should be reported upstream to kernel.org (and the maintainer for the r8169 driver) since VyOS is using the latest Linux Kernel LTS (current version 6.1.43 as of writing):
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