The Curious Case of the BGP Connect State

I got this question from Paul:

Have you ever seen a BGP peer in the “Connect” state? In 20 years, I have never been able to see or reproduce this state, nor any mention in a debug/log. I am starting to believe that all the documentation is BS, and this does not exist.

The BGP Finite State Machine (FSM) (at least the one defined in RFC 4271 and amended in RFC 9687) is “a bit” hard to grasp but the basics haven’t changed from the ancient days of RFC 1771:

  • When a router decides to connect to a BGP neighbor, it sends a TCP SYN and transitions from the Idle to the Connect state.
  • Once the TCP session is established1, the router sends the BGP OPEN message and moves to the OpenSent state
  • If the TCP session cannot be established, the router transitions to the Active state, where it waits for an incoming TCP session (transitioning to OpenSent) or for the ConnectRetry timer (transitioning to Connect)

You will never see the Connect state on Cisco IOS. Cisco implemented BGP in the days of the (original) RFC 1105 when the state machine did not have Connect state. The Connect state was added in RFC 1163, but Cisco never changed the printouts.

To see the states of the recent BGP FSMs, use FRR or Arista EOS (the easiest ones to get started in a virtual lab).

Based on the above, how could we keep a BGP speaker in the Connect state long enough to observe it? Not configuring a BGP neighbor on one side of the BGP session doesn’t help – most routers getting an incoming TCP SYN packet would immediately respond with an RST (with a notable depressing exception). Configuring an EBGP neighbor with an invalid IP address also doesn’t bring us much – the ARP/ND processing would fail pretty quickly, bringing down the TCP session.

To get stuck in the Connect state for an observable amount of time, we need the TCP SYN packet to disappear without a trace. Here are some ideas on how to get that done:

  • Configure GTSM on one end of the EBGP session (does not work on some platforms)
  • Configure an IBGP neighbor (or a multi-hop EBGP neighbor) with a bogus IP address.
  • Break the end-to-end path between IBGP neighbors (for example, mess up an MPLS LSP)
  • Drop BGP packets with an ACL that does not generate ICMP unreachables.
  • Configure a discard static route for the BGP session’s source IP address on the remote router.

Next, sit back and enjoy watching the BGP Connect state ;)

Revision History

2026-07-06
  • RFC 1105 has BGP_Active state but no BGP_Connect state.
  • Yet another mechanism to get the Connect state is a discard static route.

  1. The router receives SYN/ACK confirmation for an outgoing TCP session or an ACK confirmation for an incoming TCP session. ↩︎

Recent posts in the same categories

1 comments:

  1. Sakar 06 July 2026 01:21

    >"You will never see the Connect state on Cisco IOS. Cisco implemented BGP in the days of the (original) RFC 1105 when the state machine did not have Connect and Active states."

    I think there is a typo here. I checked RFC 1105 and did find Active state but did not find Connect state.

    And if I recall correctly, I did see Connect state in Cisco IOL L3 17.16.1a, with "debug ip bgp events". I am not sure about the BGP topology setup but it was quite a simple topology.

    Replies
    1. Ivan Pepelnjak 06 July 2026 06:15

      > I checked RFC 1105 and did find Active state but did not find Connect state.

      You're right. Fixing...

      > And if I recall correctly, I did see Connect state in Cisco IOL L3 17.16.1a, with "debug ip bgp events".

      Checked on 17.18.2 and the "debug ip bgp event" printout still shows the neighbor state yo-yo-ing between Idle and Active. Will publish a blog post with a simple topology to recreate it.

    2. Sakar 07 July 2026 04:55

      So, the debug command was "debug ip bgp" and you would see connect state in only one of the peer, depending upon who initiated the TCP connection. If the local router was the one who initiated the TCP connection, it would move from Idle->Active->OpenSent->OpenConfirm->Established and if remote router was the one who initiated the TCP connection, it would move from Idle->Connect->OpenSent->OpenConfirm->Established.

      I think RFC 4271 defines Active state as where BGP FSM is trying to acquire a peer by listening for, and accepting, a TCP connection. Either my understanding is wrong or Cisco has assigned their own definition to Active/Connect state.

      Log from 10.10.10.1: *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive open to 10.10.10.1 *Jul 7 02:00:56.353: BGP: Fetched peer 10.10.10.2 from tcb *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive went from Idle to Connect *Jul 7 02:00:56.353: BGP: ses global 10.10.10.2 (0x7F1EF1A8B8A8:0) pas Setting open delay timer to 60 seconds. *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive rcv message type 1, length (excl. header) 38 *Jul 7 02:00:56.353: BGP: ses global 10.10.10.2 (0x7F1EF1A8B8A8:0) pas Receive OPEN *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive rcv OPEN, version 4, holdtime 180 seconds *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive rcv OPEN w/ OPTION parameter len: 28 *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6 *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive OPEN has CAPABILITY code: 1, length 4 *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive OPEN has MP_EXT CAP for afi/safi: 1/1 *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2 *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive OPEN has CAPABILITY code: 128, length 0 *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive OPEN has ROUTE-REFRESH capability(old) for all address-families *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2 *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive OPEN has CAPABILITY code: 2, length 0 *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive OPEN has ROUTE-REFRESH capability(new) for all address-families *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 2 *Jul 7 02:00:56.353: BGP: 10.10.10.2 passive OPEN has CAPABILITY code: 70, length 0 *Jul 7 02:00:56.353: BGP: ses global 10.10.10.2 (0x7F1EF1A8B8A8:0) pas Enhanced Refresh cap received in open message *Jul 7 02:00:56.354: BGP: 10.10.10.2 passive rcvd OPEN w/ optional parameter type 2 (Capability) len 6 *Jul 7 02:00:56.354: BGP: 10.10.10.2 passive OPEN has CAPABILITY code: 65, length 4 *Jul 7 02:00:56.354: BGP: 10.10.10.2 passive OPEN has 4-byte ASN CAP for: 200 *Jul 7 02:00:56.354: BGP: 10.10.10.2 passive rcvd OPEN w/ remote AS 200, 4-byte remote AS 200 *Jul 7 02:00:56.354: BGP: ses global 10.10.10.2 (0x7F1EF1A8B8A8:0) pas Adding topology IPv4 Unicast:base *Jul 7 02:00:56.354: BGP: ses global 10.10.10.2 (0x7F1EF1A8B8A8:0) pas Send OPEN *Jul 7 02:00:56.354: BGP: ses global 10.10.10.2 (0x7F1EF1A8B8A8:0) pas Building Enhanced Refresh capability *Jul 7 02:00:56.354: BGP: 10.10.10.2 passive went from Connect to OpenSent *Jul 7 02:00:56.354: BGP: 10.10.10.2 passive sending OPEN, version 4, my as: 100, holdtime 180 seconds, ID 1010101 *Jul 7 02:00:56.354: BGP: 10.10.10.2 passive went from OpenSent to OpenConfirm *Jul 7 02:00:56.355: BGP: 10.10.10.2 passive went from OpenConfirm to Established *Jul 7 02:00:56.355: BGP: ses global 10.10.10.2 (0x7F1EF1A8B8A8:1) pas Assigned ID *Jul 7 02:00:56.355: BGP: nbr global 10.10.10.2 Stop Active Open timer as all topologies are allocated *Jul 7 02:00:56.355: BGP: ses global 10.10.10.2 (0x7F1EF1A8B8A8:1) Up *Jul 7 02:00:56.355: %BGP-5-ADJCHANGE: neighbor 10.10.10.2 Up

      Log from 10.10.10.2: *Jul 7 02:00:56.352: BGP: 10.10.10.1 active went from Idle to Active *Jul 7 02:00:56.352: BGP: 10.10.10.1 open active, local address 10.10.10.2 *Jul 7 02:00:56.353: BGP: ses global 10.10.10.1 (0x7F10BA1F62A0:0) act Adding topology IPv4 Unicast:base *Jul 7 02:00:56.353: BGP: ses global 10.10.10.1 (0x7F10BA1F62A0:0) act Send OPEN *Jul 7 02:00:56.353: BGP: ses global 10.10.10.1 (0x7F10BA1F62A0:0) act Building Enhanced Refresh capability *Jul 7 02:00:56.353: BGP: 10.10.10.1 active went from Active to OpenSent *Jul 7 02:00:56.353: BGP: 10.10.10.1 active sending OPEN, version 4, my as: 200, holdtime 180 seconds, ID 2020202 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active rcv message type 1, length (excl. header) 38 *Jul 7 02:00:56.354: BGP: ses global 10.10.10.1 (0x7F10BA1F62A0:0) act Receive OPEN *Jul 7 02:00:56.354: BGP: 10.10.10.1 active rcv OPEN, version 4, holdtime 180 seconds *Jul 7 02:00:56.354: BGP: 10.10.10.1 active rcv OPEN w/ OPTION parameter len: 28 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 6 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active OPEN has CAPABILITY code: 1, length 4 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active OPEN has MP_EXT CAP for afi/safi: 1/1 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 2 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active OPEN has CAPABILITY code: 128, length 0 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active OPEN has ROUTE-REFRESH capability(old) for all address-families *Jul 7 02:00:56.354: BGP: 10.10.10.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 2 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active OPEN has CAPABILITY code: 2, length 0 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active OPEN has ROUTE-REFRESH capability(new) for all address-families *Jul 7 02:00:56.354: BGP: 10.10.10.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 2 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active OPEN has CAPABILITY code: 70, length 0 *Jul 7 02:00:56.354: BGP: ses global 10.10.10.1 (0x7F10BA1F62A0:0) act Enhanced Refresh cap received in open message *Jul 7 02:00:56.354: BGP: 10.10.10.1 active rcvd OPEN w/ optional parameter type 2 (Capability) len 6 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active OPEN has CAPABILITY code: 65, length 4 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active OPEN has 4-byte ASN CAP for: 100 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active rcvd OPEN w/ remote AS 100, 4-byte remote AS 100 *Jul 7 02:00:56.354: BGP: 10.10.10.1 active went from OpenSent to OpenConfirm *Jul 7 02:00:56.354: BGP: 10.10.10.1 active went from OpenConfirm to Established *Jul 7 02:00:56.354: BGP: ses global 10.10.10.1 (0x7F10BA1F62A0:1) act Assigned ID *Jul 7 02:00:56.354: BGP: ses global 10.10.10.1 (0x7F10BA1F62A0:1) Up *Jul 7 02:00:56.354: %BGP-5-ADJCHANGE: neighbor 10.10.10.1 Up

Add comment
Home
Sidebar