Dépannage BGP : état des sessions, MTU, debug, looking glass

Introduction

90% des problèmes BGP que tu rencontreras avec un Remote Transit IP tombent dans 5 catégories :

1. Tunnel down → la session ne s'établit jamais
2. TCP/179 bloqué → session reste en Active/Connect
3. MD5 mismatch → session en OpenSent qui retombe
4. Filtre trop strict → session Established mais 0 routes
5. MTU / PMTU broken → session flap périodique, ou tout l'Internet "lent"

Ce tuto te donne la méthode systématique pour identifier rapidement où ça pèche.

Prérequis

• Une session BGP qui ne fonctionne pas (sinon ferme l'onglet)
• Accès au démon BGP (BIRD, FRR, Cisco, Arista)
• Le mail technique VeryCloud à portée de main

Étape 1 : Comprendre la machine à états BGP

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

   Active : tentative de connexion entrante (passif)

Diagnostic par état :

Étape 2 : Vérifier le tunnel d'abord

Avant tout BGP, vérifie que ton tunnel marche. Sans tunnel, BGP ne peut pas démarrer.

# Linux
ip link show gre-vc        # ou vxlan-vc, ou wg-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

Si le ping échoue → ton problème n'est PAS BGP, c'est le tunnel. Va voir le tuto transports.

Étape 3 : Vérifier TCP/179

Une fois le tunnel up, BGP utilise TCP/179. Si firewall ou ACL bloque, la session reste en Connect ou Active.

Linux :

# Voir si quelque chose ecoute sur 179 cote toi
sudo ss -tlnp | grep :179

# Tester la connexion vers le peer
nc -zv 169.254.X.1 179

# Capture pour voir les SYN
sudo tcpdump -i any "host 169.254.X.1 and port 179" -nn

Cisco :

show tcp brief | include :179
debug ip tcp transactions

Arista :

show tcp connections detail | include 179

Si SYN sort mais SYN-ACK ne revient pas → côté VeryCloud port pas ouvert, contact support. Si SYN n'arrive jamais → ton firewall local drope.

Étape 4 : Authentification MD5

Symptôme classique : session monte jusqu'à OpenSent ou OpenConfirm puis retombe en boucle, avec logs du type :

BGP: 169.254.X.1 active open failed - tcp md5sig invalid

ou

%TCP-6-BADAUTH: Invalid MD5 digest from 169.254.X.1

Vérifier le MD5 :

# Linux BIRD
sudo birdc show protocols all verycloud_v4 | grep -i pass

# FRR
sudo vtysh -c "show bgp neighbor 169.254.X.1" | grep -i pass

Solution :

• Recopie le password depuis le mail VeryCloud (CTRL-A CTRL-C, attention aux espaces invisibles)
• Pas de caractère non-ASCII
• Identique des deux côtés au bit près

Étape 5 : ASN mismatch

Symptôme : OpenSent qui retombe sans MD5 dans les logs, mais notification BGP Bad Peer AS.

neighbor 169.254.X.1 remote-as 198825   ! Pas 198824 ou autre

Vérifie côté VeryCloud que ton AS est aussi correctement configuré chez eux. C'est ASN local qu'ils attendent qui doit correspondre.

Étape 6 : Session Established mais pas de routes

C'est le cas le plus frustrant : tout est vert, mais rien ne passe.

Vérifier ce qui est reçu :

BIRD :

sudo birdc show route protocol verycloud_v4 count
# Si 0 routes : c'est cote VeryCloud
sudo birdc show route protocol verycloud_v4

FRR :

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

Cisco :

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

Si 0 routes reçues :

• Côté VeryCloud, la session n'a pas activé l'envoi (cas rare, contact support)
• soft-reconfiguration inbound pas activé : clear bgp 169.254.X.1 soft in pour forcer

Vérifier ce qui est annoncé :

# BIRD
sudo birdc show route export verycloud_v4

# FRR
sudo vtysh -c "show bgp ipv4 unicast neighbors 169.254.X.1 advertised-routes"

# Cisco
show ip bgp neighbors 169.254.X.1 advertised-routes

Si 0 routes annoncées :

• Les routes correspondantes n'existent pas dans la RIB
• Filtre export ou route-map out trop restrictif

Vérification RIB :

# Linux
ip route show

# Cisco/Arista
show ip route

Étape 7 : Problèmes de MTU / PMTU

Symptômes :

• La session BGP s'établit, mais flap après quelques minutes
• Tout l'Internet est "lent" depuis derrière le tunnel
• traceroute marche, wget plante en milieu de fichier

Le BGP utilise des paquets de 4096 octets parfois (table dump). Si MTU mal réglé, le segment se fragmente, et si la fragmentation ne marche pas (filtrage ICMP type 3 code 4), c'est broken.

Tests MTU :

# Test paquet de 1400 (devrait passer)
ping -M do -s 1400 169.254.X.1

# Test paquet 1450 (devrait passer si MTU 1476)
ping -M do -s 1450 169.254.X.1

# Test paquet 1476 (limite GRE)
ping -M do -s 1476 169.254.X.1

# Test 1500 (devrait FAIL sur GRE)
ping -M do -s 1500 169.254.X.1

Si le 1450 fail mais le 1400 passe → MTU à baisser.

Solutions :

• Linux : ip link set gre-vc mtu 1400
• Cisco : ip mtu 1400 sur l'interface tunnel
• TCP MSS clamping : voir tutos transports

💡 ICMP Path MTU Discovery doit fonctionner pour que tout marche bien. Si ton firewall bloque ICMP type 3 code 4 (Fragmentation Needed), tu es dans la merde. Autorise-le.

Étape 8 : Looking Glass VeryCloud

Quand tout marche côté toi mais que tes préfixes ne sont pas visibles sur Internet :

1. Va sur le Looking Glass VeryCloud (cf doc commerciale pour l'URL exacte, généralement lg.verycloud.fr)
2. Tape un show ip bgp <ton_prefixe> ou équivalent
3. Tu dois voir tes préfixes annoncés avec ton AS dans l'AS-path

Si tu ne vois pas tes préfixes côté VeryCloud → tes annonces ne montent pas correctement, vérifie filtre out + routes existantes.

Si tu vois tes préfixes côté VeryCloud mais pas sur Internet en général :

• ROA RPKI manquant → tes annonces sont droppées par les autres opérateurs
• route-object IRR manquant → idem
• AS-path préprend trop agressif

Test depuis l'extérieur :

# Depuis un VPS externe
mtr -n4 192.0.2.1
mtr -n6 2001:db8::1

# Verifier RPKI public
curl -s "https://stat.ripe.net/data/looking-glass/data.json?resource=192.0.2.0/24"

Étape 9 : Debugging actif

Quand tu es vraiment perdu, debug bavard :

BIRD :

# Logs en live
sudo journalctl -u bird -f

# Activer trace
sudo birdc> debug protocols verycloud_v4 events states

FRR / Cisco / Arista :

debug ip bgp 169.254.X.1
debug ip bgp events
debug ip bgp updates
! ATTENTION : ça spamme énormément
undebug all   ! pour stop

⚠️ Ne laisse jamais debug all en prod. Ça peut crasher un routeur.

Étape 10 : Cas concrets fréquents

Cas 1 — Session flap toutes les 3 minutes → Hold-time expire car keepalives ne passent pas. Souvent MTU. Solution : baisser MTU + activer MSS clamping.

Cas 2 — bad BGP identifier → Ton router-id est 0.0.0.0 ou non-unique. Configure un router-id explicite avec une IPv4 réelle.

Cas 3 — Session Established mais default route absente du kernel → BGP a la route en table BGP mais pas installée en FIB. Vérifie la cohérence next-hop, ou next-hop self côté VeryCloud.

Cas 4 — Préfixes annoncés mais reçus avec un préfixe trop spécifique de l'autre côté → ROA max-length mal configuré. Si tu annonces /24 et que ROA a max-length=24, OK. Mais si tu déagregges en /25 ailleurs, et ROA dit max-length=24, les /25 sont RPKI-invalid.

Cas 5 — Cease/Out of Resources → Tu as dépassé maximum-prefix. Augmente la valeur ou passe en default-route only.

Commandes utiles — récap

# 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

Quand BGP ne marche pas, suis l'ordre : tunnel → TCP/179 → MD5 → ASN → filtres → MTU → looking glass. 9 fois sur 10, le problème est dans les 4 premières étapes. Ne pars pas en debugging des subtilités RFC tant que tu n'as pas validé que le ping sur le peer fonctionne. Garde le mail technique VeryCloud à portée — toutes les valeurs critiques (IPs, MD5, ASN) y sont.

Pour aller plus loin : monitoring proactif (Prometheus exporter BGP, alertmanager sur session DOWN), automatisation des tests post-déploiement (Ansible/Nornir), Path Validation avec ASPA.

Ressources

• RFC 4271 — BGP-4 Finite State Machine
• VeryCloud — Looking Glass
• Cisco — Troubleshoot BGP
• Arista — BGP Troubleshooting
• Team Cymru — Path MTU Discovery