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 established¹, 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)

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.

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