# Understanding and Observing the BGP Connect State

DevFeed: [Understanding and Observing the BGP Connect State](<https://devfeed.tech/articles/the-curious-case-of-the-bgp-connect-state-11112.md>)

Original publisher: [Read original article](<https://blog.ipspace.net/2025/01/bgp-connect-state/>)

Published: 2025-01-30T06:55:00Z

Content type: article

Language: en

Sources: [ipSpace.net blog](<https://devfeed.tech/sources/ipspace-net-blog.md>)

Topics: [BGP](<https://devfeed.tech/topics/bgp.md>), [Finite-state machine](<https://devfeed.tech/topics/finite-state-machine.md>), [Cisco](<https://devfeed.tech/topics/cisco.md>)

Tags: [arp](<https://devfeed.tech/tags/arp.md>), [bgp](<https://devfeed.tech/tags/bgp.md>), [cisco](<https://devfeed.tech/tags/cisco.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [machine](<https://devfeed.tech/tags/machine.md>), [mpls](<https://devfeed.tech/tags/mpls.md>), [state](<https://devfeed.tech/tags/state.md>), [tcp](<https://devfeed.tech/tags/tcp.md>)

## AI overview

The article explains why the BGP Connect state is difficult to observe, especially on Cisco IOS, whose implementation predates the state and does not display it. It describes the BGP state transitions and conditions that can cause a peer to remain in Connect long enough to observe, including dropped TCP SYN packets and certain routing or filtering configurations.

## Source excerpt

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: Read more ...