another bug

[Radu Anghel]

Another one:

Since killing bird is now safe-ish, I added one more bird3 to the party.

Then I tried killing the first bird again.

This caused the new bird3 to get stuck with BGP into Flush:

BGP_IPv4   BGP        ---        flush  2024-12-19 16:35:08  Flush 
   Socket: Connection reset by peer
BGP_IPv6   BGP        ---        flush  2024-12-19 16:35:06  Flush 
   Socket: Connection reset by peer

No errors are logged on this second bird after the "Connection reset by 
peer" stuff, the first bird is retrying to connect, I see that with tcpdump.

birdc restart BGP_IPvx does nothing
birdc [dis|en]able BGP_IPvx also changes nothing

Some more info about this new bird:
- it is a RR so iBGP
- has MD5 enabled for the sessions
- import/export tables on
- extended messages on
- add paths on

Tried it with killing multiple bird2s instead of bird3-bird3:
- the ones with low number of routes (in my case <10k) do not get stuck 
Flushing
- the ones with one (or more) full tables get stuck Flushing on the RR

Killing birds looks like a theme since I have to kill the Flushing bird3 
to get it to reconnect those sessions.

The template from the Flushing bird RR (looks the same for v6):

template bgp BGP_v4_t {
     debug { events };
     disabled off;

     local as ASN;

     enable extended messages on;

     igp metric off;
     prefer older on;

     rr client;
     rr cluster id 0.0.0.1;

     ipv4 {
         add paths on;

         import limit 3000000 action warn;

         import filter BGP_IN4;
         export filter BGP_OUT4;
         import table on;
         export table on;
     };
}

Cheers,

Radu