# Exploring the BGP Neighbor CONNECT State

DevFeed: [Exploring the BGP Neighbor CONNECT State](<https://devfeed.tech/articles/exploring-the-bgp-neighbor-connect-state-11422.md>)

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

Published: 2026-08-18T05:16: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>), [networking](<https://devfeed.tech/topics/networking.md>), [Finite-state machine](<https://devfeed.tech/topics/finite-state-machine.md>), [Routing (disambiguation)](<https://devfeed.tech/topics/routing.md>)

Tags: [bgp](<https://devfeed.tech/tags/bgp.md>), [blog-post](<https://devfeed.tech/tags/blog-post.md>), [debug](<https://devfeed.tech/tags/debug.md>), [routing](<https://devfeed.tech/tags/routing.md>)

## AI overview

An exploration of how Cisco IOS/XE presents the BGP neighbor CONNECT state during an incoming TCP session. The article tests several lab scenarios involving passive neighbors, static discard routes, ACLs, and suppressed ICMP unreachable messages, finding that CONNECT appears in BGP debugging output while the neighbor remains Idle in the displayed operational state.

## Source excerpt

Sakar left an interesting comment on my The Curious Case of the BGP Connect State blog post, claiming that Cisco IOS/XE goes through a CONNECT state when opening an incoming BGP session. I wanted to double-check this behavior, so I needed a scenario where one router would keep sending TCP SYN requests, the other would not (or we wouldn't learn anything), and the two routers could not communicate (or they'd quickly go into the OPEN state). Here's my first attempt at meeting those requirements: Read more ...