Description

The Remote device (non-Juniper) was sending BGP open requests too quickly to Juniper device and very frequently. The user want to understand the Min and Max time interval one should wait for again when trying for a BGP connection. What does Juniper recommend?

Symptoms

>> User shared Wireshark file and we could see multiple connect_retry from non-Juniper device towards Juniper VRR.

Solution

>> BGP is the payload for TCP.
>> The Routers do not hold any state information, like firewall. So they never come to know if the same peer is sending a continuous burst of open messages.
>> Any device with BGP configuration will continuously keep sending if there is any mismatch in the open message. There is no hard limit for this retry or any exponential back-off.
>> Everytime it will clear the BGP resource and send TCP initialization, and later it will close it due to a notification error.
>> In the case of a firewall, it will keep the record or session information which is continuously flooding open message and may block this session.

>> ConnectRetryCounter is also set locally.

>> Below is a snippet from RFC. 
RFC 4271             BGP-4           January 2006
   In response to a ManualStart_with_PassiveTcpEstablishment event
   (Event 4) or AutomaticStart_with_PassiveTcpEstablishment event
   (Event 5), the local system:
    - initializes all BGP resources,
    - sets the ConnectRetryCounter to zero,
    - starts the ConnectRetryTimer with the initial value,
    - listens for a connection that may be initiated by the remote
     peer, and
    - changes its state to Active.
   The exact value of the ConnectRetryTimer is a local matter, but it
   SHOULD be sufficiently large to allow TCP initialization.
 
>> The standard does not define any timer/limit on attempts or time between subsequent attempts.
>> To confirm on Juniper side, I have just reserved a R1<---->R2 lab and will share how often we see open message along with notification message exchange.
>> I will share this information in sometime.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I created a below setup.
 
R1 <-----> R2
 
R1 is passive.
R2 is initiating the session. I ran it for 20 minutes.
 
R2 kept on sending the TCP Sync initiation continuously. It would send initiation message initially for every ConnectTimer: 2 seconds and keep on increasing the ConnectTimer exponentially after every retry but it won't stop.
 
In my example, I saw it increasing from 2 seconds to 8 then 32 then 64.

 

Modification History

2024-08-13 : Article Created