Réseautage : BGP pour petits réseaux — Configuration minimale et sûre

Ce dont vous avez réellement besoin (et de ce dont vous n’avez pas besoin)

Les petits réseaux n’ont pas besoin d’un « BGP avancé ». Ils ont besoin d’un BGP prévisible. Si vous êtes multihomé avec deux upstreams,
votre objectif est : garder vos préfixes atteignables, maintenir la cohérence des routes des autres, et basculer sans devenir la une d’un article sur une fuite de routes.

Voici la définition minimale et sûre :

• Un ASN (le vôtre, ou un ASN assigné par le fournisseur si vous ne pouvez vraiment pas en obtenir un).
• Une ou plusieurs sessions fournisseurs (eBGP), idéalement sur des routeurs séparés.
• N’annoncez que ce que vous possédez (préfixes exacts, AS d’origine correct).
• N’acceptez que ce que vous voulez (table complète si nécessaire, uniquement le default si possible).
• Filtres stricts à la fois en entrant et en sortant.
• Limites (max-prefix, limites de débit, et protections de session).
• Observabilité montrant l’état des sessions, le nombre de routes et les chemins de trafic réels.
• Rollback documenté qui fonctionne à 3h du matin.

Ce dont vous n’avez pas besoin au premier jour :

• Ingénierie du trafic via dix couches de communities que vous ne comprenez pas.
• Chasse aux chemins exotiques avec des prepends AS-path à cinq endroits « pour la redondance ».
• Graceful restart partout parce que quelqu’un a dit que c’est « plus propre ».
• Reflecteurs de route et gymnastique d’iBGP dans un réseau qui tient sur un seul tableau blanc.

Un petit réseau peut faire tourner BGP comme une ceinture de sécurité : simple, ennuyeux et rarement remarqué. C’est le but.

Bref contexte historique et faits intéressants

Un peu de contexte aide, car le comportement de BGP semble souvent « étrange » tant que vous n’avez pas en tête pour quoi il a été conçu : la politique, pas
la perfection du plus court chemin.

1. BGP a remplacé EGP lorsque l’Internet est passé d’une topologie en arbre à un maillage désordonné d’autonomous systems.
2. BGP est un protocole de type path-vector : il transporte un AS-path pour éviter les boucles, pas un graphe topo complet comme les protocoles link-state.
3. CIDR et BGP ont grandi ensemble au début des années 1990 pour ralentir l’explosion des tables de routage en permettant l’agrégation.
4. La « zone sans default » est devenue une réalité quand de nombreux routeurs cœur transportaient des routes complètes sans route par défaut.
5. Les fuites de routes continuent parce que le modèle de confiance de BGP suppose que les pairs se comportent bien, et les humains souvent ne le font pas.
6. Les communities ont été ajoutées pour permettre aux réseaux d’étiqueter les routes pour la politique sans réécrire le protocole de base à chaque fois.
7. Multiprotocol BGP (MP-BGP) a permis les VPNs (comme L3VPN) et l’IPv6 à grande échelle sans réinventer un protocole totalement neuf.
8. RPKI est relativement récent et encore déployé de façon inégale, mais c’est l’un des premiers mécanismes largement utilisés pour réduire les détournements d’origine.

La morale : BGP est assez vieux pour voter, et certaines de ses hypothèses sont plus anciennes que votre supervision.

Modèle de menace pour petits réseaux : ce qui peut mal tourner

Pour les petits réseaux, la « sécurité BGP » ne concerne pas les adversaires étatiques. Il s’agit des modes de défaillance quotidiens :
fautes de frappe, mauvaise communication et valeurs par défaut des équipements qui semblent inoffensives jusqu’à preuve du contraire.

Mode de défaillance : vous annoncez ce que vous ne possédez pas

Classique. Une faute de frappe dans une prefix-list, un agrégat trop large, ou un « test temporaire » qui n’a jamais été reverté.
Les upstreams peuvent filtrer, mais vous ne devriez pas externaliser votre sécurité à leur bonne volonté.

Mode de défaillance : vous acceptez des ordures et vous vous mettez en blackhole

Prendre une table complète et l’installer sur un petit routeur sans mémoire suffisante est une façon fiable d’inventer de nouveaux
schémas de perte de paquets. Prendre uniquement le default mais oublier de fixer les next-hops ou le local-pref peut provoquer des flaps bizarres.

Mode de défaillance : fuite de routes via des politiques de transit

Une fuite de route survient quand vous fournissez accidentellement du transit entre deux réseaux qui n’étaient pas d’accord. Votre réseau devient
un couloir involontaire. Le trafic suit le couloir jusqu’à son effondrement.

Mode de défaillance : le plan de contrôle dit « up » alors que le plan de données est en feu

Les sessions BGP peuvent être Established et heureuses pendant que MTU, ACLs ou asymétrie tuent silencieusement le débit.
BGP est un protocole du plan de contrôle. Ce n’est pas un thérapeute.

Une citation à garder en tête : « L’espoir n’est pas une stratégie. » — Gene Kranz.

Blague n°1 : BGP est le seul endroit où « confiance » est une option de configuration, pas un statut relationnel.

Conception minimale sûre : décisions à prendre

1) Choisissez votre modèle de routage : default-only ou table complète

Si votre réseau est petit, vous n’avez probablement pas besoin de la table Internet complète. Le mode default-only (0.0.0.0/0 and ::/0) réduit
la pression mémoire et le risque opérationnel. La table complète vous offre un contrôle plus fin et parfois de meilleures performances, mais elle vous donne aussi
900k+ façons de vous faire mal.

Ma règle d’opinion :

• Si vous avez un seul routeur de bord : default-only est généralement la bonne option.
• Si vous avez deux routeurs de bord et de réels besoins d’ingénierie du trafic : envisagez la table complète, mais seulement avec du matériel qui peut la supporter.
• Si vous faites du scrubbing DDoS, multi-exit complexe, ou beaucoup de trafic CDN : la table complète devient plus défendable.

2) Deux routeurs si vous le pouvez

Un routeur est un point de défaillance unique. Deux routeurs, c’est beaucoup de paperasserie. Pourtant : si vous pouvez aligner deux boîtiers modestes,
faites-le. Placez-les sur des alimentations séparées, des uplinks séparés, et de préférence des points de raccordement upstream séparés.

3) Gardez iBGP petit et évident

Si vous faites tourner deux routeurs de bord, vous aurez probablement un iBGP entre eux. Restez simple :
une session dans chaque sens, des politiques de route claires, et un IGP (ou des routes statiques) unique pour porter les next-hops.
Vous ne construisez pas un backbone tier-1. Agissez en conséquence.

4) Séparez la politique de la plomberie

Votre démon BGP peut être FRR, BIRD, Junos, IOS, EOS — ce n’est pas tant le logiciel que votre discipline.
Créez une structure de politique que vous pouvez auditer :

• Filtre entrant : ce que vous acceptez, ce que vous rejetez, et ce que vous tagguez.
• Filtre sortant : ce que vous originez, ce que vous exportez, et comment vous le marquez.
• Garde-fous de session : max-prefix, sécurité TTL (le cas échéant), MD5/TCP-AO si supporté, et timers raisonnables.

5) Décidez de votre stratégie d’annonce : priorisez les exacts

Commencez par les préfixes exacts. N’annoncez que les blocs spécifiques que vous possédez et que vous comptez originer. Les agrégats peuvent venir plus tard,
et seulement quand vous êtes sûr de ne pas avaler par erreur de l’espace d’adresses que vous ne contrôlez pas.

Filtres : votre vrai pare-feu, c’est la politique

En BGP, le filtrage fait la différence entre « un réseau » et « un accident ».
Vous avez besoin de politiques sortantes pour éviter les fuites et de politiques entrantes pour empêcher les absurdités d’être installées.

Filtrage sortant : n’annoncez que vos préfixes

Pour un petit réseau, la politique sortante est généralement :

• Permettre vos préfixes possédés (et seulement ceux-là).
• Définir vos propres communities si vous les utilisez.
• Rejeter tout le reste.

Si vous êtes client (pas fournisseur de transit), vous ne devriez pas exporter la table complète apprise de l’ISP A vers l’ISP B.
C’est l’archétype de fuite de routes.

Filtrage entrant : acceptez ce que vous pouvez gérer

Votre politique entrante dépend si vous prenez uniquement le default ou la table complète :

• Default-only : acceptez 0.0.0.0/0 and ::/0 de chaque upstream, plus éventuellement un petit ensemble de routes spécifiques au fournisseur si nécessaire.
• Table complète : acceptez tout après avoir éliminé les bogons, martiens, préfixes trop longs et origines RPKI invalides.

Idées de bogons/martiens de base

Au minimum, supprimez les routes pour RFC1918, l’espace carrier-grade NAT, les loopbacks, link-local, multicast et autres plages non-globales évidentes.
Vous pouvez aussi rejeter les préfixes trop spécifiques (par ex. IPv4 plus longs que /24 et IPv6 plus longs que /48) sauf si vous en avez explicitement besoin.

Votre upstream peut déjà filtrer ces éléments. Bien. Filtrez-les quand même. La redondance n’est pas réservée aux blocs d’alimentation.

RPKI : sécurité peu coûteuse, ROI élevé

La validation RPKI vérifie si l’AS d’origine est autorisé à annoncer un préfixe (sur base des ROA).
Ce n’est pas la solution à tous les problèmes de sécurité BGP. Cela réduit cependant le rayon d’explosion des erreurs d’origine et certains détournements.

Position RPKI minimale pour les petits réseaux :

• Faites tourner un validateur (comme Routinator) en interne.
• Configurez vos routeurs/démons pour effectuer la validation d’origine.
• Rejetez les routes RPKI-invalides en entrée depuis les transits (ou au moins dépréférez-les fortement).
• Publiez correctement les ROA pour vos propres préfixes (et gardez-les à jour).

Si vous ne faites qu’une seule modernisation, faites celle-ci. C’est l’équivalent du port du casque pour BGP.

Limites et timers : éviter la saturation surprise

Les limites ne servent pas à être prudents seulement. Elles servent à faire échouer les pannes rapidement, bruyamment et de manière contenue.

Limites max-prefix

Si vous prenez default-only, votre max-prefix devrait être minuscule (comme 10–100, selon les extras de votre upstream).
Si vous prenez la table complète, dimensionnez-la par rapport à votre table attendue plus une marge, mais pas une marge infinie.

Votre décision est philosophique : voulez-vous que la session se coupe quand quelque chose d’étrange arrive (fail-closed),
ou préférez-vous la garder active en espérant que votre boîtier survive (fail-open) ? Pour les petits réseaux, fail-closed est généralement plus indulgent.

Keepalives et hold timers

Les valeurs par défaut conviennent généralement. Ajuster les timers pour « basculer plus vite » vous fera souvent juste flapper plus vite.
Si vous avez besoin d’une convergence sub-seconde, vous n’êtes plus en configuration « minimale et sûre » ; vous êtes dans le domaine « concevez toute la pile ».

Graceful restart : utile, mais facile à mal utiliser

Le graceful restart peut masquer des redémarrages du plan de contrôle, mais peut aussi préserver un forwarding obsolète et rendre le diagnostic des pannes étrange.
Si vous l’activez, testez-le. Puis testez-le encore avec des pannes partielles.

Blague n°2 : Le graceful restart, c’est comme mettre votre routeur en « Ne pas déranger ». C’est calme jusqu’au moment où vous réalisez qu’il a manqué l’alarme incendie.

Contrôles du plan de données : ne faites pas confiance au plan de contrôle

BGP échangera volontiers des routes sur une session TCP pendant que votre trafic réel meurt à cause d’un MTU, d’ACL, d’asymétrie de routage
ou d’un upstream qui noie silencieusement le trafic pendant une atténuation.

Position opérationnelle minimale :

• Validez toujours l’atteignabilité de vos préfixes depuis l’extérieur (pas seulement depuis l’intérieur).
• Conservez un hôte de test connu et sain dans un autre réseau (une VM bon marché ailleurs suffit).
• Mesurez la perte de paquets et la latence par lien uplink, pas seulement « BGP Established ».

Tâches pratiques : commandes, sorties et décisions (12+)

Ce sont des tâches réelles que vous pouvez exécuter sur un routeur basé Linux, un serveur de routes ou une machine de dépannage.
J’utiliserai le style FRR avec vtysh et des outils Linux courants parce qu’ils sont largement disponibles.
L’essentiel est le flux de travail : commande → interpréter la sortie → prendre une décision.

Task 1: Verify BGP sessions are Established (FRR)

cr0x@server:~$ vtysh -c "show ip bgp summary"
BGP router identifier 203.0.113.2, local AS number 64512
BGP table version is 128, main routing table version 128
Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
198.51.100.1    4      65001    9132    9050      128    0    0 2d03h        1
203.0.113.1     4      65002    8321    8204      128    0    0 2d03h        1

Ce que cela signifie : Les deux voisins sont up depuis ~2 jours et chacun envoie 1 préfixe (probablement default-only).
Décision : Si vous attendiez des routes complètes et que vous voyez « 1 », votre politique entrante est en default-only (ou cassée).
Si vous attendiez default-only et que vous voyez « 900000 », vos filtres sont erronés ou votre upstream vous envoie la table complète.

Task 2: Check received routes from an upstream and confirm filtering

cr0x@server:~$ vtysh -c "show ip bgp neighbor 198.51.100.1 received-routes" | head
BGP table version is 128, local router ID is 203.0.113.2
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0/0        198.51.100.1             0    100      0 65001 i

Ce que cela signifie : Vous ne recevez que le default. C’est cohérent avec le design default-only.
Décision : Si vous voyez des RFC1918 ou d’autres saletés ici, resserrez immédiatement les filtres entrants.

Task 3: Confirm you only advertise your intended prefixes

cr0x@server:~$ vtysh -c "show ip bgp neighbor 198.51.100.1 advertised-routes"
BGP table version is 128, local router ID is 203.0.113.2

   Network          Next Hop            Metric LocPrf Weight Path
*> 203.0.113.0/24   0.0.0.0                  0         32768 i

Ce que cela signifie : Vous n’annoncez que 203.0.113.0/24. Bien.
Décision : Si vous voyez 0.0.0.0/0 ou une table complète ici en tant que réseau client, vous faites une fuite. Coupez : désactivez l’export, puis corrigez la politique.

Task 4: Validate your router’s RIB vs BGP RIB (Linux)

cr0x@server:~$ ip route show default
default via 198.51.100.1 dev eth1 proto bgp metric 20

Ce que cela signifie : La route par défaut du kernel est installée via BGP sur eth1.
Décision : Si votre uplink préféré devrait être ISP2 mais que ceci pointe vers ISP1, ajustez le local-pref (préférence) ou le weight (spécifique au vendeur).

Task 5: Check route counts at a glance (BIRD)

cr0x@server:~$ birdc show protocols all | sed -n '1,14p'
BIRD 2.0.12 ready.
Name       Proto      Table      State  Since         Info
up_isp1    BGP        master4    up     2026-02-04    Established
  BGP state:          Established
  Neighbor address:   198.51.100.1
  Neighbor AS:        65001
  Routes:             1 imported, 1 exported, 1 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:         2          0          0          0          2
    Export updates:         2          0          0          0          2

Ce que cela signifie : BIRD confirme votre forme attendue « default-only ».
Décision : Si les « rejected » augmentent brusquement, votre filtre bloque quelque chose ; déterminez si c’est un filtrage voulu ou un blocage accidentel.

Task 6: Check that your prefix is visible externally (from a remote probe)

cr0x@server:~$ whois -h whois.radb.net 203.0.113.0/24 | head
route:          203.0.113.0/24
origin:         AS64512
descr:          Example Network
mnt-by:         EXAMPLENET-MNT
changed:        noc@example.net 20250101
source:         RADB

Ce que cela signifie : Il existe un objet route (registry) indiquant votre intention d’originer ce préfixe.
Décision : Si votre upstream utilise un filtrage basé IRR et que ceci manque/est incorrect, vos annonces peuvent être filtrées. Corrigez l’objet de registre ou l’autorisation upstream.

Task 7: Verify ROA status for your prefix (Routinator)

cr0x@server:~$ routinator validate 203.0.113.0/24 | head
203.0.113.0/24 AS64512 valid (maxLength 24)

Ce que cela signifie : Votre préfixe a un ROA valide pour votre ASN.
Décision : Si c’est « invalid » ou « notfound », corrigez les ROA. Si votre upstream rejette les invalides, vous disparaitrez d’une manière où « BGP est up mais personne ne peut nous joindre ».

Task 8: Check RPKI validation state on the router (FRR example)

cr0x@server:~$ vtysh -c "show bgp rpki summary"
RPKI cache servers:
1) 127.0.0.1:3323  pref 1  state Established  uptime 2d03h  serial 12981
Prefix records: 214532

Ce que cela signifie : Votre routeur parle au validateur local, et il a des données RPKI.
Décision : Si l’état n’est pas Established, votre politique « reject invalids » peut ne plus fonctionner silencieusement. Réparez d’abord la connectivité RTR.

Task 9: Confirm you’re not melting your router (memory/CPU quick check)

cr0x@server:~$ top -b -n1 | head -n 8
top - 10:12:54 up 32 days,  4:19,  1 user,  load average: 0.22, 0.18, 0.15
Tasks: 134 total,   1 running, 133 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.4 us,  0.5 sy,  0.0 ni, 97.8 id,  0.2 wa,  0.0 hi,  0.1 si,  0.0 st
MiB Mem :   7984.2 total,   4231.7 free,    912.4 used,   2840.1 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   6589.4 avail Mem

Ce que cela signifie : Beaucoup de marge. Bien pour la table complète ? Peut-être. Bien pour default-only ? Définitivement.
Décision : Si vous swappez ou que le CPU est saturé pendant des mises à jour, réduisez l’entrée de routes (default-only), augmentez le matériel, ou déplacez BGP vers une boîte plan de contrôle séparée avec une approche propre de programmation FIB.

Task 10: Check for packet loss on the uplink interface

cr0x@server:~$ ip -s link show dev eth1
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:11:22:33 brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  9123456  0       12       0       0
    TX:  bytes  packets  errors  dropped  carrier collsns
    1234567890  7345678  0       0        0       0

Ce que cela signifie : Quelques drops RX existent. Cela peut être de la policing, de la pression sur les buffers, ou un problème de pilote.
Décision : Si les drops augmentent pendant les pics, vous avez probablement de la congestion ou un mismatch de shaping. Ne « corrigez » pas ça avec BGP. Réparez avec de la capacité, du QoS, ou du tuning d’interface.

Task 11: Validate MTU with do-not-fragment ping

cr0x@server:~$ ping -M do -s 1472 -c 3 198.51.100.1
PING 198.51.100.1 (198.51.100.1) 1472(1500) bytes of data.
1472 bytes from 198.51.100.1: icmp_seq=1 ttl=64 time=0.61 ms
1472 bytes from 198.51.100.1: icmp_seq=2 ttl=64 time=0.58 ms
1472 bytes from 198.51.100.1: icmp_seq=3 ttl=64 time=0.60 ms

--- 198.51.100.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Ce que cela signifie : Le Path MTU semble correct pour Ethernet 1500 bytes.
Décision : Si ceci échoue et que des tailles plus petites fonctionnent, vous avez un risque de blackhole MTU. Corrigez MTU/MSS clamping avant d’accuser BGP de lenteurs « aléatoires ».

Task 12: Check actual egress path selection with traceroute

cr0x@server:~$ traceroute -n -w 1 -q 1 1.1.1.1 | head
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  198.51.100.1  0.530 ms
 2  198.51.100.254  1.212 ms
 3  203.0.113.254  2.891 ms

Ce que cela signifie : Vous sortez via ISP1.
Décision : Si vous vouliez ISP2 comme primaire, changez le local-pref/weight ou la préférence de route par défaut. Ne faites pas que prépender et espérer ; contrôlez inbound/outbound séparément.

Task 13: Confirm kernel sees the expected BGP-learned routes (size sanity)

cr0x@server:~$ ip route | grep -c "proto bgp"
1

Ce que cela signifie : Vous avez installé exactement une route BGP (probablement le default). C’est votre intention déclarée en mode default-only.
Décision : Si ce compteur explose de façon inattendue, votre démon peut installer la table complète. Confirmez les politiques et si vous devriez utiliser un VRF/table séparée.

Task 14: Spot a route leak pattern by checking AS-path on unexpected routes

cr0x@server:~$ vtysh -c "show ip bgp 8.8.8.0/24"
BGP routing table entry for 8.8.8.0/24
Paths: (1 available, best #1, table default)
  65001 15169
    198.51.100.1 from 198.51.100.1 (198.51.100.1)
      Origin IGP, localpref 100, valid, external, best

Ce que cela signifie : Vous avez appris cette route via ISP1. Normal si vous prenez la table complète.
Décision : Si vous êtes en default-only mais que vous voyez des spécifiques comme celle-ci installés, votre filtre entrant ne fonctionne pas comme vous le pensez.

Task 15: Check BGP flap history to detect intermittent transport issues

cr0x@server:~$ vtysh -c "show ip bgp neighbor 198.51.100.1"
BGP neighbor is 198.51.100.1, remote AS 65001, local AS 64512, external link
  BGP version 4, remote router ID 198.51.100.1
  BGP state = Established, up for 2d03h
  Last read 00:00:19, Last write 00:00:21
  Connections established 3; dropped 2
  Last reset 1d01h, due to Hold Timer Expired

Ce que cela signifie : La session est tombée deux fois, la dernière due à un Hold Timer Expired. C’est souvent une perte de transport ou une famine CPU.
Décision : Si les expirations du hold se corrèlent avec de la congestion ou un DDoS, améliorez d’abord la fiabilité du transport (QoS, coordination de policing, protection du plan de contrôle).

Trois mini-récits d’entreprise du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne s’est multihomée pour la première fois. Deux upstreams, un routeur, FRR. Ils avaient une fenêtre de changement,
un runbook et un canal Slack au nom confiant comme #bgp-cutover.

La mauvaise hypothèse : « Notre upstream filtrera tout ce que nous ne devons pas annoncer. » L’ingénieur a écrit une politique sortante
destinée à n’annoncer que leur /24, mais il a aussi redistribué les routes connected. Un sous-réseau de management était par hasard un espace public issu
d’une acquisition précédente et était encore sur une interface. Il a été annoncé.

Rien n’avait l’air cassé en interne. BGP était Established. Leurs IPs de service restaient joignables. Le seul signe était un étrange pic
de trafic entrant sur l’interface de management et quelques alertes de supervision sur l’élévation de la CPU.

Puis l’upstream a remarqué. L’upstream a coupé la session BGP—brutalement. La connectivité sortante est passée sur le second ISP,
mais le trafic entrant ne s’est pas rétabli proprement. Certains clients ont encore suivi le chemin retiré pendant des minutes, car la mise en cache et la propagation
ne sont pas obligées de respecter votre fenêtre de maintenance.

La correction fut simple et humiliante : prefix-lists sortantes explicites, plus aucune redistribution dans eBGP, et une vérification pré-changement qui
affiche les routes annoncées et exige une approbation humaine. La meilleure phrase du postmortem fut : « Nous avons externalisé la correction à quelqu’un
avec des incitations différentes. »

Mini-récit 2 : L’optimisation qui a échoué

Une entreprise de retail voulait « basculer plus vite ». Ils ont lu sur BFD et des timers agressifs. Leur bord avait deux routeurs, chacun avec deux sessions.
L’équipe a activé des keepalives BGP plus courts et hold timers réduits, et a aussi activé BFD partout.

Pendant une semaine, tout semblait parfait. Une coupure de lien basculait rapidement. Tout le monde se sentait malin. Puis une maintenance upstream bénigne
a introduit des micro-burst de perte de paquets intermittents sur un circuit. Pas assez pour nuire beaucoup aux flux TCP. Assez pour irriter BFD.

Le résultat fut un mode de défaillance difficile à expliquer : les sessions ont flappé à répétition, les routes ont oscillé,
la CPU a grimpé, et la perte de paquets a empiré parce que le plan de contrôle s’est mis à ronger des ressources pour la reconvergence. L’« optimisation »
a créé une instabilité auto-infligée. Le réseau était rapide à tomber, lent à guérir.

Ils ont rétabli des timers plus conservateurs et n’ont activé BFD que là où le transport était propre et bien compris. La leçon durable :
la convergence est une propriété système. Si vous serrez trop fort une partie, une autre gonfle.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Un petit fournisseur d’hébergement exploitait une configuration BGP minimale depuis des années : prefix-lists strictes, limites max-prefix, validation RPKI,
et un job nocturne qui diffait « les routes annoncées par voisin » par rapport à un fichier attendu. Ce n’était pas glamour. C’était aussi la raison pour laquelle ils dormaient.

Un après-midi, ils ont reçu un appel d’un upstream : « Nous voyons un nombre inhabituel de préfixes depuis votre session. » En interne,
leur monitoring avait déjà alerté. Le job de diff avait détecté que leur routeur était sur le point d’exporter plus que les deux préfixes attendus.
Le max-prefix sur l’export n’est pas universel, mais leur politique était stricte : refuser tout sauf une liste explicite.

La cause racine était une erreur de gestion de configuration : une expansion de variable de template a produit une prefix-list plus large sur un seul routeur.
La politique stricte « refuser tout le reste » a empêché d’exporter quoi que ce soit d’inattendu, donc le rayon d’impact s’est limité à « nous n’avons pas annoncé un
de nos préfixes prévus pendant quelques minutes » au lieu de « nous avons fuité la table ».

Ils ont corrigé le template, redéployé, et fermé l’incident avec à peine d’impact client. Le salut n’était pas le génie.
C’était l’ennui : allowlists explicites, attentes diffables, et refuser de compter sur la clémence des upstreams.

Mode opératoire pour diagnostic rapide

Quand quelque chose cloche, votre travail est de trouver rapidement le goulot d’étranglement, pas d’admirer l’épave. Voici l’ordre qui
tend à produire des réponses vite.

Première étape : est-ce le plan de contrôle, le plan de données, ou la politique ?

• Vérification du plan de contrôle : Les sessions sont-elles Established ? Les préfixes reçus/émis sont-ils en nombre attendu ?
• Vérification du plan de données : Pouvez-vous pinguer/traceroute ? D’autres peuvent-ils atteindre vos préfixes ? Y a-t-il des drops/erreurs ?
• Vérification de la politique : Le local-pref/weight a-t-il changé ? Des filtres nouveaux, des changements RPKI, ou des max-prefix ont-ils déclenché ?

Deuxième étape : validez vos propres annonces

• Sur le routeur : vérifiez que les routes annoncées par voisin correspondent à votre allowlist.
• Externe : vérifiez que les ROA sont valides et que les registres correspondent à ce que l’upstream attend.
• Vérifiez que l’AS d’origine est correct et stable.

Troisième étape : vérifiez la symétrie du routage entrant et les next-hops

• Recevez-vous un default depuis les deux ? Lequel gagne en préférence ?
• Le trafic de retour revient-il par l’ISP attendu ? Sinon, avez-vous des firewalls stateful qui vont détester ça ?
• Votre IGP/static est-il cohérent avec les next-hops BGP ?

Quatrième étape : recherchez l’épuisement des ressources et l’instabilité

• Des pics CPU lors des mises à jour de route peuvent provoquer des expirations de hold timer.
• La pression mémoire peut causer des retards de traitement des routes et des décalages de programmation FIB étranges.
• Logs : resets de session, événements max-prefix, déconnexions du cache RPKI.

Cinquième étape : isolez en forçant un basculement propre (avec prudence)

Si vous avez deux upstreams, coupez temporairement une session BGP (ou ajustez local-pref) et observez. Si le problème disparaît,
la cause est probablement spécifique à l’upstream ou à la politique. S’il persiste, c’est probablement votre bord ou votre réseau aval.

Erreurs courantes : symptôme → cause racine → correction

1) Symptôme : Internet « fonctionne » mais certains sites time-out

Cause racine : Blackhole MTU ou PMTUD cassé, souvent à travers des tunnels ou des points de transit fournisseur.

Correction : Validez le MTU avec des pings DF ; implémentez le MSS clamping sur le bord pour TCP ; alignez les MTU sur les handoffs.

2) Symptôme : BGP Established, mais personne ne peut atteindre vos IPs

Cause racine : Vous n’annoncez pas réellement votre préfixe (erreur de politique), ou l’upstream le filtre (mismatch IRR/RPKI).

Correction : Vérifiez advertised-routes ; confirmez l’AS d’origine ; validez les ROA ; assurez-vous que les objets de registre correspondent aux exigences de filtrage upstream.

3) Symptôme : CPU du routeur monte et les sessions flappent lors des pics

Cause racine : Surcharge du plan de contrôle due aux mises à jour de la table complète, timers trop agressifs, ou churn de routes.

Correction : Rétablissez des timers raisonnables ; réduisez les routes (default-only) ; protégez le plan de contrôle ; envisagez du matériel séparé de routage.

4) Symptôme : Réception soudaine de beaucoup plus de routes que d’habitude

Cause racine : Un upstream a fuité la table complète vers votre session default-only, ou votre filtre entrant a changé.

Correction : Appliquez des filtres entrants stricts ; définissez un max-prefix strict ; coordonnez avec l’upstream ; envisagez de rejeter tout sauf le default si c’est votre conception.

5) Symptôme : Votre upstream menace de déconnexion pour « fuite de routes »

Cause racine : Vous avez exporté des routes apprises vers un autre voisin, ou vous avez redistribué connected/IGP dans eBGP.

Correction : Supprimez la redistribution dans eBGP ; implémentez une allowlist sortante explicite ; validez les routes annoncées avant d’activer les sessions.

6) Symptôme : Le basculement fonctionne en sortie, mais le trafic entrant reste collé à l’ISP mort

Cause racine : Le trafic entrant dépend de la sélection de chemin des réseaux distants ; vos changements d’annonce ne sont pas immédiats ni préférés.

Correction : Utilisez les communities fournies par les providers ; assurez-vous que les deux upstreams voient vos annonces ; envisagez des annonces plus spécifiques pour un basculement contrôlé (avec prudence).

7) Symptôme : RPKI « a cassé Internet » après activation

Cause racine : Vous rejetiez les invalides alors que vos propres ROA étaient incorrects, ou la connectivité du validateur a échoué et la politique a basculé de manière inattendue.

Correction : Validez d’abord vos propres préfixes ; assurez une connexion RTR stable ; implémentez une politique graduée (préférer les valides, dé-préférer les inconnus, rejeter les invalides) si nécessaire.

8) Symptôme : Routage asymétrique casse les sessions des firewalls stateful

Cause racine : Utilisation d’uplinks différents pour inbound vs outbound, plus un firewall qui attend de la symétrie.

Correction : Soit concevez pour la symétrie (politique/local-pref), soit déployez de la synchronisation d’état / firewall aware du routage ; évitez l’ECMP « aléatoire » à travers des dispositifs stateful.

Listes de contrôle / plan pas à pas

Phase 0 : Avant de toucher à BGP

• Clarifiez l’espace d’adresses et l’ASN : qui possède quoi, qui origne quoi.
• Décidez default-only vs table complète ; dimensionnez le matériel en conséquence.
• Construisez un chemin de management hors bande qui ne dépende pas du nouveau design BGP.
• Rédigez une allowlist des préfixes que vous annoncerez (préfixes exacts, longueurs de masque correctes).
• Décidez vos valeurs max-prefix par voisin et documentez-les.

Phase 1 : Mettre en service les sessions en sécurité (une à la fois)

1. Configurez le voisin avec un deny-all sortant temporaire.
2. Établissez la session BGP et confirmez qu’elle reste Established pendant au moins 15–30 minutes.
3. Activez la politique entrante (default-only ou table complète) et confirmez que le nombre de préfixes reçus correspond à l’attendu.
4. Activez l’allowlist sortante et confirmez que la liste de préfixes annoncés correspond à votre fichier attendu.
5. Validez l’atteignabilité externe de vos préfixes depuis une sonde distante.

Phase 2 : Ajouter des garde-fous

• Définissez max-prefix et le comportement en cas de dépassement (alerte vs shutdown ; je préfère shutdown pour petits réseaux).
• Activez la validation RPKI et choisissez la politique (rejeter les invalides est courant ; soyez délibéré sur le traitement des « notfound »).
• Filtrez bogons/martiens en entrée ; empêchez les préfixes trop spécifiques sauf si requis.
• Assurez-vous de ne pas redistribuer connected/IGP dans eBGP sauf si explicitement prévu et filtré selon la même allowlist.

Phase 3 : Redondance et basculement contrôlé

• Mettez en service le second upstream avec la même discipline : deny-all puis allowlist.
• Décidez de la préférence sortante (local-pref/weight) et testez le basculement en coupant une session.
• Pour la préférence entrante, utilisez les communities supportées par les providers ou des annonces plus spécifiques contrôlées.
• Testez pendant une fenêtre à faible risque ; mesurez la convergence et l’impact applicatif.

Phase 4 : Exploitez-le comme en production

• Supervisez : état des sessions, nombre de préfixes, taux d’updates, CPU/mémoire, drops/erreurs d’interface.
• Alertez sur : session down, déviation du nombre de préfixes, déconnexion du validateur RPKI, événements max-prefix.
• Contrôle des changements : les modifications de politique de pair requièrent un diff et une seconde relecture.
• Conservez un plan de rollback : désactiver l’export, couper les sessions, revenir en arrière sur la config, vérifier l’atteignabilité.

FAQ

Ai-je besoin de BGP si je suis mono-homé ?

Généralement non. Si vous avez un seul FAI et pas d’espace d’adresses portable, BGP ajoute surtout des modes de défaillance.
Utilisez du routage statique/par défaut et concentrez-vous sur la redondance ailleurs.

Default-only vs table complète : que choisir ?

Default-only si vous êtes petit et voulez de la stabilité. Table complète si vous avez de solides raisons : besoins d’ingénierie du trafic,
multiples sorties avec une politique significative, ou vous opérez à une échelle où default-only entraîne de vrais sous-optimaux.

Puis-je multihomer avec un seul routeur en toute sécurité ?

Vous pouvez, mais vous achetez une redondance partielle. Le routeur reste un point de défaillance unique. Si vous le faites, gardez le design minimal,
et assurez-vous de pouvoir accéder en remote via un chemin hors bande si vous vous verrouillez hors du réseau.

Dois-je utiliser BFD pour accélérer le basculement ?

Seulement si votre transport est propre et que vous l’avez testé sous de vraies conditions de perte. Une détection agressive peut provoquer du flapping,
et le flapping peut être pire qu’un basculement légèrement plus lent.

Que sont les communities BGP et en ai-je besoin ?

Les communities sont des tags que vous attachez aux routes pour demander un comportement upstream (comme prepend, blackholing ou modification du local-pref).
Vous n’en avez pas besoin pour la configuration minimale et sûre, mais elles sont le moyen propre d’influencer le trafic entrant une fois que vous comprenez la sémantique du provider.

RPKI est-il obligatoire ?

Pas obligatoire, mais c’est l’une des meilleures améliorations de sécurité par heure d’effort. Commencez par valider et surveiller ; puis passez à rejeter les invalides
quand vos propres ROA sont corrects.

Quelle est la façon la plus simple d’éviter une fuite de routes ?

Allowlists sortantes. Autorisez uniquement vos préfixes. Rejetez tout le reste. Ne redistribuez pas connected ou IGP dans eBGP sauf si filtré vers la même allowlist.

Pourquoi le basculement entrant prend-il parfois des minutes ?

Parce que le trafic entrant dépend de ce que le reste de l’Internet croit. La propagation des retraits, le dampening et la mise en cache distante existent.
Vous pouvez influencer avec des communities, des annonces plus spécifiques et de bons choix d’upstream, mais vous ne pouvez pas forcer une convergence globale instantanée.

Comment savoir si le problème vient de mon bord ou de mon upstream ?

Comparez plan de contrôle vs plan de données. Si les sessions sont stables et vos annonces correctes, mais que la perte de paquets ou la latence augmente,
vérifiez les stats d’interface, le MTU et la qualité du chemin upstream. Si vous pouvez basculer vers un second upstream et que le problème disparaît, c’est probablement spécifique à l’upstream.

Dois-je exécuter iBGP entre deux routeurs de bord ?

Si les deux originent les mêmes préfixes et que vous voulez une sélection de sortie coordonnée, oui—gardez-le minimal et explicite.
Si votre réseau est très petit et que vous pouvez fonctionner avec des defaults indépendants, vous pouvez éviter l’iBGP, mais comprenez les compromis.

Conclusion : prochaines étapes sans risques

La configuration BGP minimale et sûre n’est pas une question d’ingéniosité. C’est une question de retenue : allowlists explicites, filtres entrants stricts, limites sensées,
et suffisamment d’observabilité pour détecter les erreurs avant que votre upstream ne le fasse.

Prochaines étapes pratiques :

1. Notez vos annonces prévues (préfixes exacts) et traitez cette liste comme du code de production.
2. Décidez default-only vs table complète et dimensionnez votre routeur en conséquence — les contraintes matérielles sont des contraintes de politique.
3. Implémentez des allowlists sortantes et des filtres entrants (bogons, longueurs max, et max-prefix).
4. Activez la validation RPKI, validez vos propres ROA, et choisissez une politique claire pour invalid/notfound.
5. Incorporez la boucle de diagnostic rapide dans votre supervision : état des sessions, nombre de préfixes, drops d’interface, et atteignabilité externe.

Si vous voulez ensuite faire de l’ingénierie du trafic, très bien. Gagnez-le. D’abord assurez-vous que votre réseau ne peut pas accidentellement devenir un fournisseur de transit
un mardi.