@Viacheslav it happened yesterday again but the stack trace was different. This time it was complaining that BGPD did not respond and the frr watch process tried to restart it, which of course did not help the situation.
I will continue to monitor but i think we can close this issue and wait for more details when it happens again.

Just to confirm, increasing the route,max_size fixed this issue completely. I think it can be closed. But maybe we should set these settings by default before closing this.

Some statistics from ipv6 bgp summary

@thomas-mangin the sessions are still stable, for 7 days now. The only thing changed was that max_size limit. Also no packetloss on the IPv6 connections has been observed during this time.

@syncer Re-opening this. Had the first exact same incident on a different router with an IPv6 BGP session on a RJ45 connection, so that would rule out any issues with the Intel X710 card in relation to this issue.

We ave no RPKI filtering active yet, so https://github.com/FRRouting/frr/issues/5458 seems not related.

This issue exists in firmware 6.8 and 7.1.
Starting with 7.1 i can see that the disable command 'sudo ethtool --set-priv-flags <interface name> disable-fw-lldp on' also works.

Found that in drivers 2.3.6 and newer this should also work:

Upgraded the firmware of the X710 adapters from 6.0 to 6.8, waiting for Dell to get 7.0 and 7.2 ready. But for now the sessions are 18 hours stable so little optimistic that it was a firmware issue and not BGPd causing issues

Trying to find more information with debugging settings of zebra process.
Apr 12 23:52:18 router zebra[1472]: 0:2404:5780:3::/48: Route install failed
Apr 12 23:52:18 router zebra[1472]: 0:2404:5780:3::/48 Stale dplane result for old_re 0x555f6166b300
Apr 12 23:52:18 router zebra[1472]: 0:2404:5780:3::/48 Processing dplane ctx 0x555f765ff7a0, op ROUTE_UPDATE result FAILURE

My main question is why is this message displayed and do we need to worry.

I have had the maximum-paths setting for years since Vyos 1.1.x and I have a lot of routes ipv4 and ipv6 installed in the routing table with 2 or 3 routes even if they are not the same. I am not specifically using ecmp I just have multiple routes for fast failover.

I have the following:
set protocols bgp as maximum-paths ebgp '3'
set protocols bgp as maximum-paths ibgp '3'

After receiving
zebra[1507]: 0:2804:fa0:8000::/33: Route install failed

A router reboot last week reminded me to never to write mem in vtysh (but after looking it was automatic bij me :( )
The router booted with the configuration in FRR already loaded, and then Vyos tried to populate FRR based on the Vyos configuration and everything was broken :-)
It didn't help that the configuration i saved in FRR was a couple of months old.

@hagbard

set service snmp community dummycomm authorization 'ro'
set service snmp community dummycomm client '8.8.8.8'
set service snmp community dummycomm client '8.8.4.4'
set service snmp contact '[email protected]'
set service snmp location 'Datacenter, City, Country'

@hagbard i tried testing by installing the package.
The service is running but not working correctly.
The following is shown:
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 10: Warning: Unknown token: smuxpeer.
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 11: Warning: Unknown token: smuxpeer.
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 12: Warning: Unknown token: smuxsocket.
Jan 07 10:25:54 server snmpd[9979]: notificationEvent OID: linkUp
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 21: Error: unknown notification OID
Jan 07 10:25:54 server snmpd[9979]: notificationEvent OID: linkDown
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 22: Error: unknown notification OID
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 23: Warning: Unknown token: monitor.
Jan 07 10:25:54 server snmpd[9979]: /etc/snmp/snmpd.conf: line 24: Warning: Unknown token: monitor.
Jan 07 10:25:54 server snmpd[9979]: net-snmp: 2 error(s) in config file(s)

I have built the current branch this evening, version is 1.3.0-rolling because i named it that way.

Tested by installing the new package
https://packages.debian.org/bullseye/amd64/iperf

Most of the times when i try a second time it just works.

@jestabro i am not able to build the vyos-1x package because of dependencies on other packages.
Can we include them in rolling so i can test tomorrow?

@jestabro i have encountered the first situation in my networks where i really need RFC-Complaint VRRP
(Some devices do not learn the MAC-address on the VRRP gateway, it works for some time and then stops).

Ok so that would mean the BGP4 info is exposed to the SNMP server and someone has to check it on a client.

@cpo the SNMP server has to support the MIB to export the OID. And afterwards the client has to have an up2data MIB to map it again. If the server does not export it the client can update the MIB but the OID won’t be there.

I was reading old documentation. It does work once I set it with the configuration instead of editing the file directly.

@dmbaturin did you find time to check the pull requests? Checked with latest crux build and the issue still exists.
I can test this if needed.

In 1.2.3 build this error does not appear and it seems to work correctly

You have to add a sync-group.
set high-availability vrrp sync-group intgroup member int1
set service conntrack-sync failover-mechanism vrrp sync-group intgroup