02-13-2012 04:15 PM
Look up Finite State Machine for more info
ACTIVE and CONNECT are basically TCP States
It is a little bit more complex than we are given, but that would require one of the Juniper programmers to explain this concept- but for all intent and purposes, it is waiting for the TCP handshake.BGP relies on the TCP protocol for transport. So TCP must be established first before BGP can proceed, hence these different states. I have found many different explanations and here is one, I concocted. Both states are trying to acomplish the same thing, but are a result of diffent things happening. The CONNECT state is the the result of a start event, which can be an automated event or one done by an Admin- maybe he just configured BGP on an interface and hit the commit button. Once the start even is sent, BGP kicks its resources into gear and trys to establish the TCP session, then transition to the CONNECT state. In the CONNECT state it is waiting for response from the peer to complete the 3-way handshake,TCP onnection. Among other things it starts a ConnectRetryTimer. If the connection is successful, it sends the OPEN message to the peer, then transitions to the OPENSENT state.
If there are TCP ERRORS resulting in a failure, it closes the connection and goes back to IDLE
If the connection is unsuccessful during the connect state and the retry timer has expired, transitions to ACTIVE state and tries to re-establish the TCP session again. And if successful, then OPEN message is sent and it transitions to OPENSENT...
But how it transitions to ACTIVE and what happens is far more comple
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..]