08-22-2021 12:05 AM - edited 08-22-2021 12:07 AM
Hello Friends,
I have some doubt about in which state TCP initiation happened in BGP. According to the BGP Fundamental book following can be observed.
But according to the following table of CCIE V5 OCG TCP session initiate in Active state.
So what is the correct state of the TCP initiation ? Thank you very much for your valuable time
08-22-2021 01:49 AM - edited 08-22-2021 01:51 AM
This is the first stage of the BGP FSM. BGP detects a start event, tries to initiate a TCP connection to the BGP peer, and also listens for a new connect from a peer router.
If an error causes BGP to go back to the Idle state for a second time, the ConnectRetryTimer is set to 60 seconds and must decrement to zero before the connection is initiated again. Further failures to leave the Idle state result in the ConnectRetryTimer doubling in length from the previous time.
In this state, BGP initiates the TCP connection. If the 3-way TCP handshake completes, the established BGP Session BGP process resets the ConnectRetryTimer and sends the Open message to the neighbor, and then changes to the OpenSent State.
If the ConnectRetry timer depletes before this stage is complete, a new TCP connection is attempted, the ConnectRetry timer is reset, and the state is moved to Active. If any other input is received, the state is changed to Idle.
according to RFC 4271:
https://datatracker.ietf.org/doc/html/rfc4271
Idle state:
Initially, the BGP peer FSM is in the Idle state. Hereafter, the
BGP peer FSM will be shortened to BGP FSM.
In this state, BGP FSM refuses all incoming BGP connections for
this peer. No resources are allocated to the peer. In response
to a ManualStart event (Event 1) or an AutomaticStart event (Event
3), the local system:
- initializes all BGP resources for the peer connection,
- sets ConnectRetryCounter to zero,
- starts the ConnectRetryTimer with the initial value,
- initiates a TCP connection to the other BGP peer,
- listens for a connection that may be initiated by the remote
BGP peer, and
- changes its state to Connect.
The ManualStop event (Event 2) and AutomaticStop (Event
are ignored in the Idle state.
Connect State:
In this state, BGP FSM is waiting for the TCP connection to be
completed.
The start events (Events 1, 3-7) are ignored in the Connect state.
In response to a ManualStop event (Event 2), the local system:
- drops the TCP connection,
- releases all BGP resources,
Rekhter, et al. Standards Track [Page 54]
RFC 4271 BGP-4 January 2006
- sets ConnectRetryCounter to zero,
- stops the ConnectRetryTimer and sets ConnectRetryTimer to
zero, and
- changes its state to Idle.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide