Not only affects, smoketest.. nat66 got broken
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Aug 9 2023
Aug 8 2023
PR https://github.com/vyos/vyos-1x/pull/2140
set service monitoring zabbix-agent directory '/config/zabbix/' set service monitoring zabbix-agent limits buffer-send '8' set service monitoring zabbix-agent limits buffer-size '120' set service monitoring zabbix-agent log debug-level 'warning' set service monitoring zabbix-agent log size '1' set service monitoring zabbix-agent server '192.0.2.5' set service monitoring zabbix-agent server-active 192.0.2.5 port '10051' set service monitoring zabbix-agent server-active 2001:db8::123
Aug 7 2023
Nope, now i had to do
@aalmenar could you test this patch?
information that can be useful for this feature request :
If that was pppoe i'd have thought of arp, but here with fixed number of l2tp tunnels (22 tunnels from LACs) i don't think arp cache oversizes the table.
Some more information which i can't think of as a failure reason yet, but it looks strange, - just before the issue we see that LAC drops l2tp tunnel for some reason and starts to send SCCRQ with tid=0 as if it just started working. After a while accel-ppp daemon drops the old tunnels and starts the new ones for few LACs. This definitely cause massive (thousands) route updates between zebra and kernel i guess. Sometimes the system can stand this, sometimes it cant.
I tried digging through google if somebody else have encountered the same but I couldnt find any obvious hints (except for the zebra nexthop-group keep 1 already mentioned).
I checked the FRR version in the recent rolling release - it is release candidate still. Does it worth upgrading from 8.5.2? As for the possibility - yes, sure we can build latest image.