7 min read Advanced 14.0k

BGP troubleshooting: session state, MTU, debug, looking glass

Published on May 18, 2026 at 04:01 PM

Toolbox to diagnose a transit BGP session that's not working: FSM states (Idle/Active/OpenSent/Established), MTU issues, debugging, using VeryCloud Looking Glass, and concrete failure cases.

Introduction

90% of BGP problems you'll hit with a Remote Transit IP fall into 5 categories:

Tunnel down → session never establishes
TCP/179 blocked → session stuck in Active/Connect
MD5 mismatch → session in OpenSent that drops
Filter too strict → session Established but 0 routes
MTU / PMTU broken → periodic session flap, or "slow" Internet

This tutorial gives you the systematic method to quickly identify where it's failing.

Prerequisites

A non-working BGP session (otherwise close this tab)
Access to the BGP daemon (BIRD, FRR, Cisco, Arista)
VeryCloud's technical email at hand

Step 1: Understand the BGP state machine

   Idle ──────► Connect ──────► OpenSent ──────► OpenConfirm ──────► Established
    ▲             │                │                 │                    │
    │             │                │                 │                    │
    └─────────────┴────────────────┴─────────────────┴────────────────────┘
                                   (errors → back to Idle)

   Active: attempting incoming connection (passive)

Diagnosis by state:

State	Likely cause
Idle	You did `disable`, or config error
Connect	Trying to connect, not receiving SYN-ACK → TCP blocked
Active	Waiting for incoming connection, none → TCP reverse blocked
OpenSent	TCP OK, but Open message problem — wrong ASN, BGP version
OpenConfirm	Open exchanged, but KeepAlive or MD5 fail
Established	OK! No routes: filter too strict

Step 2: Check the tunnel first

Before BGP, verify your tunnel works. No tunnel, no BGP.

# Linux
ip link show gre-vc
ip addr show gre-vc
ping 169.254.X.1
ping6 2a0e:XXXX:XXXX::0

! Cisco/Arista
show interface Tunnel0
ping 169.254.X.1

If ping fails → your problem is NOT BGP, it's the tunnel. See transport tutorials.

Step 3: Check TCP/179

Once tunnel up, BGP uses TCP/179. Firewall or ACL blocking → session stuck in Connect or Active.

sudo ss -tlnp | grep :179
nc -zv 169.254.X.1 179
sudo tcpdump -i any "host 169.254.X.1 and port 179" -nn

show tcp brief | include :179
debug ip tcp transactions

! Arista
show tcp connections detail | include 179

SYN out but no SYN-ACK → VeryCloud side port not open, contact support. SYN never arrives → your local firewall drops.

Step 4: MD5 authentication

Classic symptom: session climbs to OpenSent or OpenConfirm then loops back, with logs:

BGP: 169.254.X.1 active open failed - tcp md5sig invalid
%TCP-6-BADAUTH: Invalid MD5 digest from 169.254.X.1

sudo birdc show protocols all verycloud_v4 | grep -i pass
sudo vtysh -c "show bgp neighbor 169.254.X.1" | grep -i pass

Solution: re-paste from VeryCloud email, no invisible whitespace, no non-ASCII.

Step 5: ASN mismatch

Symptom: OpenSent dropping with Bad Peer AS notification.

neighbor 169.254.X.1 remote-as 198825   ! Not 198824 or other

Check VeryCloud side has your AS correctly too.

Step 6: Session Established but no routes

The most frustrating case: all green, nothing passing.

Check received:

sudo birdc show route protocol verycloud_v4 count

show bgp ipv4 unicast neighbors 169.254.X.1 received-routes
show ip bgp neighbors 169.254.X.1 received-routes

If 0 routes received:

VeryCloud session not activated to send (rare, contact support)
soft-reconfiguration inbound not enabled: clear bgp 169.254.X.1 soft in

Check announced:

sudo birdc show route export verycloud_v4

show bgp ipv4 unicast neighbors 169.254.X.1 advertised-routes
show ip bgp neighbors 169.254.X.1 advertised-routes

If 0 announced:

Routes don't exist in RIB
export filter or route-map out too restrictive

ip route show

show ip route

Step 7: MTU / PMTU issues

Symptoms:

BGP session establishes but flaps after minutes
Internet "slow" through the tunnel
traceroute works, wget fails mid-file

BGP sometimes uses 4096-byte packets (table dump). With wrong MTU, segments fragment, and if fragmentation breaks (ICMP type 3 code 4 filtered), it's broken.

MTU tests:

ping -M do -s 1400 169.254.X.1
ping -M do -s 1450 169.254.X.1
ping -M do -s 1476 169.254.X.1
ping -M do -s 1500 169.254.X.1

If 1450 fails but 1400 passes → lower MTU.

Solutions:

Linux: ip link set gre-vc mtu 1400
Cisco: ip mtu 1400 on tunnel
TCP MSS clamping (see transport tutorials)

💡 ICMP Path MTU Discovery must work for everything to be fine. If your firewall blocks ICMP type 3 code 4 (Fragmentation Needed), you're in trouble. Authorize it.

Step 8: VeryCloud Looking Glass

When everything works your side but your prefixes aren't visible on the Internet:

Go to VeryCloud Looking Glass (cf commercial doc for exact URL, usually lg.verycloud.fr)
Type show ip bgp <your_prefix> or equivalent
You should see your prefixes announced with your AS in the AS-path

If you don't see your prefixes VeryCloud side → your announcements don't reach properly, check outbound filter + existing routes.

If you see them VeryCloud-side but not on Internet generally:

Missing RPKI ROA → your announcements dropped by other operators
Missing IRR route-object → same
Too aggressive AS-path prepend

External tests:

mtr -n4 192.0.2.1
mtr -n6 2001:db8::1
curl -s "https://stat.ripe.net/data/looking-glass/data.json?resource=192.0.2.0/24"

Step 9: Active debugging

When truly lost, verbose debug:

sudo journalctl -u bird -f
sudo birdc> debug protocols verycloud_v4 events states

debug ip bgp 169.254.X.1
debug ip bgp events
debug ip bgp updates
! ATTENTION: spams massively
undebug all

⚠️ Never leave debug all in prod. Can crash a router.

Step 10: Common cases

Case 1 — Session flap every 3 minutes → Hold-time expires because keepalives don't pass. Often MTU. Solution: lower MTU + enable MSS clamping.

Case 2 — bad BGP identifier → router-id is 0.0.0.0 or non-unique. Configure explicit router-id with a real IPv4.

Case 3 — Session Established but default route absent from kernel → BGP has the route in BGP table but not in FIB. Check next-hop consistency, or next-hop self VeryCloud side.

Case 4 — Prefixes announced but received as more specific on the other side → ROA max-length misconfigured. If you announce /24 and ROA has max-length=24, OK. If you de-aggregate to /25 elsewhere and ROA says max-length=24, /25 are RPKI-invalid.

Case 5 — Cease/Out of Resources → Exceeded maximum-prefix. Increase value or go default-route only.

Useful commands — recap

# BIRD
sudo birdc show protocols
sudo birdc show protocols all verycloud_v4
sudo birdc show route protocol verycloud_v4
sudo birdc show route export verycloud_v4
sudo birdc configure
sudo birdc restart verycloud_v4
sudo journalctl -u bird -f

# FRR
sudo vtysh -c "show bgp summary"
sudo vtysh -c "show bgp ipv4 unicast neighbors 169.254.X.1"
sudo vtysh -c "show bgp ipv4 unicast neighbors 169.254.X.1 received-routes"
sudo vtysh -c "clear bgp 169.254.X.1 soft in"
sudo journalctl -u frr -f

! Cisco
show ip bgp summary
show ip bgp neighbors 169.254.X.1
show ip bgp neighbors 169.254.X.1 received-routes
show ip bgp neighbors 169.254.X.1 advertised-routes
show ip route bgp
clear ip bgp 169.254.X.1 soft in
clear ip bgp 169.254.X.1
debug ip bgp 169.254.X.1
undebug all

! Arista
show ip bgp summary
show ip bgp neighbors 169.254.X.1
show ip bgp neighbors 169.254.X.1 received-routes
clear ip bgp 169.254.X.1 soft in
show log | grep BGP

Conclusion

When BGP doesn't work, follow the order: tunnel → TCP/179 → MD5 → ASN → filters → MTU → looking glass. 9 times out of 10, the problem is in the first 4 steps. Don't go debugging RFC subtleties until you've validated ping on the peer works. Keep VeryCloud's technical email at hand — all critical values (IPs, MD5, ASN) are there.

Going further: proactive monitoring (BGP Prometheus exporter, alertmanager on session DOWN), automated post-deployment tests (Ansible/Nornir), Path Validation with ASPA.