BGP peer states mean on S series Switches

Active

indicates that the TCP connection is not set up for the BGP session.

No Neg

indicates that the ability to establish a BGP connection is not negotiated. Assume that one device is configured with IPv4 unicast, and the other device is configured with IPv4 unicast and IPv4 multicast. After the peer relationship is set up between the two devices, the device configured with IPv4 unicast only enters in Established state, whereas the other device configured with IPv4 unicast and IPv4 multicast enters in No Neg state. This is because one device is not configured with IPv4 multicast.

Idle (Admin)

indicates that a peer is shut down and does not attempt to set up a connection. If the peer ignore command is executed on the peer or the status of the peer is set to Down through the related MIB, the peer is in Idle (Admin) state.

i hope this would help that understand. 

Hi, BGP Peer states as follows:

• Idle:This is the first state where BGP waits for a “start event”. The start event occurs when someone configures a new BGP neighbor or when we reset an established BGP peering. After the start event, BGP will initialize some resources, resets a ConnectRetry timer and initiates a TCP connection to the remote BGP neighbor. It will also start listening for a connection in case the remote BGP neighbor tries to establish a connection. When successful, BGP moves to the Connect state. When it fails, it will remain in the Idle state.

• Connect: BGP is waiting for the TCP three-way handshake to complete. When it is successful, it will continue to the OpenSent state. In case it fails, we continue to the Active state. If the ConnectRetry timer expires then we will remain in this state. The ConnectRetry timer will be reset and BGP will try a new TCP three-way handshake. If anything else happens (for example resetting BGP) then we move back to the Idle state.

• Active: BGP will try another TCP three-way handshake to establish a connection with the remote BGP neighbor. If it is successful, it will move to the OpenSent state. If the ConnectRetry timer expires then we move back to the Connect state. BGP will also keep listening for incoming connections in case the remote BGP neighbor tries to establish a connection. Other events can cause the router to go back to the Idle state (resetting BGP for example).

• OpenSent: In this state BGP will be waiting for an Open message from the remote BGP neighbor. The Open message will be checked for errors, if something is wrong (incorrect version numbers, wrong AS number, etc.) then BGP will respond with a Notification message and jumps back to the Idle state. This is also the moment where BGP decides whether we use EBGP or IBGP (since we check the AS number). If everything is OK then BGP starts sending keepalive messages and resets its keepalive timer. At this moment, the hold time is negotiated (lowest value is picked) between the two BGP routers. In case the TCP session fails, BGP will jump back to the Active state. When any other errors occur (expiration of hold timer), BGP will send a notification message with the error code and jumps back to the Idle state. In case someone resets the BGP process, we also jump back to the Idle state.

• OpenConfirm: BGP waits for a keepalive message from the remote BGP neighbor. When we receive the keepalive, we can move to the established state and the neighbor adjacency will be completed. When this occurs, it will reset the hold timer. If we receive a notification message from the remote BGP neighbor then we fall back to the Idle state. BGP will keep sending keepalive messages.

• Established: The BGP neighbor adjacency is complete and the BGP routers will send update packets to exchange routing information. Every time we receive a keepalive or update message, the hold timer will be resetted. In case we receive a notification message we will jump back to the Idle state.

Src:
Networklessons.