Description

One of the bgp neighbor went down and stuck in a close-wait state, not coming up again. 
From the logs line with timestamp "Jun 17 17:18:07.541", it says that Connection Rejected as Reason: no group for 194.35.38.23+54547 (proto) from AS 64789 found (peer unconfigured) in master(em1.0), dropping him

Symptoms

>> The user is seeing below logs on Juniper device. 
Jun 17 17:18:07.541 rpd[18774]: bgp_pp_recv:5066: NOTIFICATION sent to 194.35.38.23+54547 (proto): code 6 (Cease) subcode 5 (Connection Rejected), Reason: no group for 194.35.38.23+54547 (proto) from AS 64789 found (peer unconfigured) in master(em1.0), dropping him
Jun 17 17:18:07.616 rpd[18774]: BGP_IO_ERROR_CLOSE_SESSION: BGP peer 194.35.38.23 (Internal AS 64789): Error event Connection reset by peer(54) for I/O session - closing it (instance master)
Jun 17 17:18:07.616 rpd[18774]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 194.35.38.23 (Internal AS 64789) changed state from Established to Idle (event TransportError) (instance master)

Solution

>> As per the configuration in RSI, VRR is acting as a passive server that is dynamically waiting for the remote client to initiate a TCP session. 
protocols {
  bgp {
    group RR-XXX {
      type internal;
      multihop {
        no-nexthop-change;
      }
      local-address 194.35.38.243;
      passive;
      import no_import;
      family l2vpn {
        signaling;
      }
      family evpn {
        signaling;
      }
      export XXX-EXPORT;
      graceful-restart;
      dynamic-neighbor abrs {
        allow [ 194.35.x.x/26 ];
      }
    }

 

>> The neighborship with 194.35.38.23 was UP and went down at the below timestamp.

Jun 17 17:18:07.541 rpd[18774]: bgp_pp_recv:5066: NOTIFICATION sent to 194.35.38.23+54547 (proto): code 6 (Cease) subcode 5 (Connection Rejected), Reason: no group for 194.35.38.23+54547 (proto) from AS 64789 found (peer unconfigured) in master(em1.0), dropping him

>> But the catch here is that we do not see any further attempt to initiate tcp from a remote with VRR. So our thought is that the remote device has stopped sending TCP packets to VRR just after these logs and is bringing the neighborship down.
 
>> The explanation in the above logs is: VRR is sending a notification message to 194.35.38.23 (non-Juniper) stating they are not receiving any packets from this neighbor. All of a sudden, this peer is acting as if there is no neighbor-ship configuration present.
 
>> BGP is the payload for TCP. BGP, being an application, sends a finish request from the non-Juniper device to VRR and later, after the finish request, there is no new session initiated from Non-Juniper device. Hence, VRR has generated above logs stating it is not able to find the configuration of the neighbor.

>> You need to investigate on non-Juniper router.

 

Modification History

2024-08-13 : Article Created