Connect and Active: no TCP session
Connect and Active both mean there is no working TCP connection yet, so the question is what happened to the SYN. A packet capture on TCP port 179 answers it in seconds, and the two answers lead to completely different fixes.
The peer isn't configured for you
Here r2 has no neighbor 192.0.2.0 at all, so it has never heard of r1. You might expect r2 to ignore r1 completely, but the capture shows something more interesting. r2's TCP stack completes the handshake, because bgpd listens on port 179 for everyone. Then bgpd sees a connection from an address it has no neighbour for, and hangs up.
r1 lands in Active, with one connection established and one dropped. The signature is the FIN or RST arriving right after the handshake, from the peer itself. That means the path is fine, the peer is reachable, and the problem is the peer's configuration: wrong neighbour address, missing neighbour, or a session you're not supposed to have.
A firewall drops TCP 179
Now r2 is configured, but a firewall in front of it drops BGP. (In the lab it's iptables on r2 itself, which behaves the same as a firewall on the path.) This time r1 sits in Connect. The capture shows its SYN being sent again and again, with no answer of any kind, and the firewall's drop counters climbing.
Silence means a firewall or a routing problem; a reset means the peer itself refused you. If nothing at all comes back, check every firewall and access list on the path (including the peer's own control-plane filter) and that the peer has a route back to you. The router's own ping to the peer address proves only that ICMP gets through.
Timers you'll notice
FRR waits 120 seconds between connection attempts by default (the ConnectRetry timer, shown as Next connect timer due in…). After you fix the cause, clear bgp <address> retries straight away instead of waiting.
- SYN. r1 opens a TCP connection to port 179.
- SYN-ACK. r2's kernel answers: bgpd is listening on port 179 for everyone, so the handshake completes.
- ACK. The connection is up. r1's FSM moves towards OpenSent.
- FIN. r2's bgpd sees a connection from an address it has no neighbour for, and hangs up straight away.
- OPEN, then RST. r1's OPEN was already on its way. It arrives on a closed socket, so r2 answers with a reset. r1 goes back to Active and waits for its connect-retry timer.
r1:~# timeout 8 tcpdump -lnni eth0 tcp port 179
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
03:29:36.015609 IP 192.0.2.0.37920 > 192.0.2.1.179: Flags [S], seq 2828726788, win 64240, options [mss 1460,sackOK,TS val 3302550658 ecr 0,nop,wscale 10], length 0
03:29:36.015682 IP 192.0.2.1.179 > 192.0.2.0.37920: Flags [S.], seq 2373249985, ack 2828726789, win 65160, options [mss 1460,sackOK,TS val 1957022853 ecr 3302550658,nop,wscale 10], length 0
03:29:36.015696 IP 192.0.2.0.37920 > 192.0.2.1.179: Flags [.], ack 1, win 63, options [nop,nop,TS val 3302550658 ecr 1957022853], length 0
03:29:36.015850 IP 192.0.2.1.179 > 192.0.2.0.37920: Flags [F.], seq 1, ack 1, win 64, options [nop,nop,TS val 1957022853 ecr 3302550658], length 0
03:29:36.015972 IP 192.0.2.0.37920 > 192.0.2.1.179: Flags [P.], seq 1:100, ack 2, win 63, options [nop,nop,TS val 3302550659 ecr 1957022853], length 99: BGP
03:29:36.016007 IP 192.0.2.1.179 > 192.0.2.0.37920: Flags [R], seq 2373249987, win 0, length 0
6 packets captured
6 packets received by filter
0 packets dropped by kernel
r1# show bgp summary
IPv4 Unicast Summary:
BGP router identifier 198.51.100.241, local AS number 64500 VRF default vrf-id 0
BGP table version 9
RIB entries 3, using 384 bytes of memory
Peers 1, using 17 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.0.2.1 4 64501 9 7 0 0 0 00:00:13 Active 0 r2
Total number of neighbors 1
r1:~# vtysh -c "show bgp neighbors 192.0.2.1" | grep -E "BGP state|Last reset|Connections|Next connect"
BGP state = Active
Connections established 1; dropped 1
Last reset 00:00:13, Waiting for peer OPEN (n/a)
Next connect timer due in 111 seconds
r2:~# grep -iE "not configured|192.0.2.0" /var/log/frr/frr.log | tail -3
2026/10/18 03:29:14 BGP: [M59KS-A3ZXZ] bgp_update_receive: rcvd End-of-RIB for IPv4 Unicast from 192.0.2.0 in vrf default
2026/10/18 03:29:31 BGP: [HZN6M-XRM1G] %NOTIFICATION(Hard Reset): sent to neighbor 192.0.2.0 6/3 (Cease/Peer De-configured) 0 bytes
2026/10/18 03:29:31 BGP: [PXVXG-TFNNT] %ADJCHANGE: neighbor 192.0.2.0(r1) in vrf default Down Neighbor deleted- Lines 4–6: The TCP handshake succeeds: r2's kernel accepts connections to port 179 from anyone.
- Line 7: r2's bgpd hangs up immediately (FIN): it has no neighbour 192.0.2.0.
- Lines 8–9: r1's 99-byte OPEN arrives on a closed socket, so r2 resets the connection.
- Line 24: r1 lands in Active, waiting for its next attempt.
- Lines 30–31: One connection made, one dropped, while waiting for an OPEN that never came.
- Lines 36–37: r2's log: the neighbour was deleted (that was us, making the change).
r2:~# iptables -L INPUT -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP 6 -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:179
0 0 DROP 6 -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:179
r1# show bgp summary
IPv4 Unicast Summary:
BGP router identifier 198.51.100.241, local AS number 64500 VRF default vrf-id 0
BGP table version 9
RIB entries 1, using 128 bytes of memory
Peers 1, using 17 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
192.0.2.1 4 64501 10 9 0 0 0 00:00:10 Connect 0 r2
Total number of neighbors 1
r1:~# vtysh -c "show bgp neighbors 192.0.2.1" | grep -E "BGP state|Last reset|Connections|Next connect|Connect Retry"
BGP state = Connect
Connections established 1; dropped 1
Last reset 00:00:10, Waiting for peer OPEN (n/a)
BGP Connect Retry Timer in Seconds: 120
Next connect timer due in 111 seconds
r2:~# iptables -L INPUT -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
7 420 DROP 6 -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:179
8 554 DROP 6 -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:179- Lines 4–5: Drop BGP in both directions: to port 179 (r1 calling r2) and from port 179 (r2 calling r1).
- Line 16: Stuck in Connect: a SYN is out and nothing has come back.
- Lines 22–23: These counters remember the healthy session from before the firewall rule; they don't describe the current attempt.
- Line 25: FRR will give up on this attempt and try again when the ConnectRetry timer expires.
- Lines 30–31: Proof: the drop counters have gone from 0 to 7 and 8.
r1:~# timeout 6 tcpdump -lnni eth0 "tcp port 179 and tcp[tcpflags] & tcp-syn != 0"
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
03:33:20.667643 IP 192.0.2.0.55148 > 192.0.2.1.179: Flags [S], seq 2834635123, win 64240, options [mss 1460,sackOK,TS val 825580283 ecr 0,nop,wscale 10], length 0
03:33:21.692096 IP 192.0.2.0.55148 > 192.0.2.1.179: Flags [S], seq 2834635123, win 64240, options [mss 1460,sackOK,TS val 825581307 ecr 0,nop,wscale 10], length 0
03:33:22.715862 IP 192.0.2.0.55148 > 192.0.2.1.179: Flags [S], seq 2834635123, win 64240, options [mss 1460,sackOK,TS val 825582331 ecr 0,nop,wscale 10], length 0
03:33:24.763889 IP 192.0.2.0.55148 > 192.0.2.1.179: Flags [S], seq 2834635123, win 64240, options [mss 1460,sackOK,TS val 825584379 ecr 0,nop,wscale 10], length 0
4 packets captured
4 packets received by filter
0 packets dropped by kernel- Line 1: Only packets with the SYN flag set, to keep it short.
- Lines 4–7: The same SYN (same sequence number) sent again and again, with no SYN-ACK and no reset. Silence means something on the path is dropping it.
Check your understanding
A new peering sits in Connect. On your router, tcpdump shows your SYNs to port 179 repeating with no reply. What's the most likely cause?
- A firewall or ACL on the path (or on the peer) is dropping TCP 179, or the peer has no route back to you.
- The peer has the wrong remote-as configured for you.
- The peer isn't configured with your address.
- Your max-prefix limit is too low.