BGP Graceful Restart : RFC 4724, LLGR RFC 9478 et résilience Anycast VPN

Le protocole de passerelle frontière (BGP-4, RFC 4271) constitue l’ossature du routage sur l’Internet mondial, coordonnant la joignabilité des préfixes entre des dizaines de milliers de systèmes autonomes (AS). Au sein des architectures réseau de classe opérateur, les routeurs maintiennent une séparation fondamentale entre le Plan de contrôle (Control Plane — le démon logiciel qui gère la base d’informations de routage RIB) et le Plan de transfert de données (Data Forwarding Plane — les composants matériels ASIC et les tables FIB du noyau qui assurent la commutation des paquets à la vitesse physique des liaisons).

Historiquement, toute interruption du démon de contrôle—qu’elle résulte d’une mise à jour logicielle, d’un plantage imprévu ou d’une bascule administrative—rompait instantanément la session TCP sous-jacente. Selon les règles BGP traditionnelles, les routeurs pairs voisins retiraient aussitôt tous les préfixes appris du routeur en redémarrage, propageant des vagues massives de messages de retrait et déclenchant des pénalités d’amortissement d’oscillations de route (Route Flap Damping). Pour éliminer ces tempêtes d’instabilité, l’IETF a normalisé le mécanisme BGP Graceful Restart (RFC 4724), avant de le compléter par le Long-Lived Graceful Restart (LLGR, RFC 9478). Maîtriser ces protocoles de transfert ininterrompu est indispensable pour bâtir une infrastructure Anycast VPN hautement disponible.

La crise de l’instabilité du routage : pourquoi les redémarrages perturbent le trafic

Dans le fonctionnement classique de BGP, la perte d’une session de peering est traitée comme un incident critique. Dès que le processus de routage redémarre, la connexion TCP sur le port 179 s’interrompt, incitant les pairs adjacents à déclarer la session inactive. Conformément à la RFC 4271, le pair voisin purge sans délai toutes les routes apprises de sa table Adj-RIB-In, recalcule ses chemins optimaux vers les fournisseurs alternatifs et expédie des messages BGP WITHDRAW à l’ensemble de ses voisins en aval.

Ce retrait brutal entraîne des perturbations d’envergure :

1. Délais de convergence globale : Des centaines de milliers de routeurs de bordure doivent recalculer leurs vecteurs de chemin, engendrant des boucles transitoires et des pertes de paquets pendant plusieurs minutes.
2. Pénalités d’amortissement sur les dorsales : Un retrait de route précipité suivi quelques minutes plus tard d’une réannonce du même préfixe est sanctionné par les opérateurs de transit via l’algorithme RFC 2439 Route Flap Damping, provoquant des heures d’isolement forcé.
3. Interruption matérielle injustifiée : Dans l’écrasante majorité des cas de maintenance ou de redémarrage logiciel, les cartes de ligne, les modules optiques et les puces ASIC demeurent totalement opérationnels. Vider la table FIB matérielle alors que le plan de données est sain crée une indisponibilité artificielle.

En établissant un protocole de synchronisation qui découple la relance du logiciel de contrôle de la commutation matérielle, Graceful Restart préserve un flux continu de trafic. Les utilisateurs vérifiant la stabilité de leur acheminement via /what-is-my-ip ne subissent aucune déconnexion pendant ces opérations.

Anatomie de la RFC 4724 : les mécanismes de BGP Graceful Restart

Publiée en janvier 2007, la RFC 4724 formalise le mécanisme de redémarrage sans heurt pour BGP. Elle définit deux rôles complémentaires : le Routeur en redémarrage (Restarting Speaker — le nœud qui relance son démon BGP tout en conservant intact son plan de transfert matériel) et le Routeur récepteur (Receiving Speaker — le pair voisin qui continue d’acheminer les flux via les routes conservées).

Négociation des capacités et préservation de l’état de transfert

Lors de l’établissement initial de la session BGP, les deux équipements négocient la capacité Graceful Restart (Capability Code 64) au moyen des messages OPEN :

+-------------------------------------------------------------+
| Capability Code (64) | Capability Length (variable)         |
+-------------------------------------------------------------+
| Restart Flags (4 bits: R-bit) | Restart Time (12 bits)      |
+-------------------------------------------------------------+
| Address Family Identifier (AFI - 16 bits)                   |
| Subsequent Address Family Identifier (SAFI - 8 bits)        |
| Flags for Address Family (8 bits: F-bit Forwarding State)   |
+-------------------------------------------------------------+

Le paramètre Restart Time indique la durée maximale (en secondes) pendant laquelle le routeur en redémarrage sollicite l’attente de son pair avant de rétablir la session (typiquement de 120 à 300 secondes). Élément déterminant, le bit d’état de transfert (F-bit) atteste formellement que le routeur a su maintenir son plan matériel durant le redémarrage. Lorsque le F-bit est actif, le routeur récepteur sait que la table FIB matérielle est vivante et marque les routes comme périmées (stale) sans les détruire.

Cycle de vie de la reconvergence : temporisateurs et synchronisation End-of-RIB

Lorsque la session TCP s’interrompt, le routeur récepteur attribue le statut stale aux routes issues de ce pair. Il maintient ces entrées dans sa table FIB et continue de transférer les paquets sur les interfaces physiques.

Après son rechargement, le routeur en redémarrage rétablit la session BGP et transmet sa table initiale. Pour signifier la fin de l’envoi, il expédie un marqueur de fin de table (End-of-RIB — EoR), matérialisé par un message BGP UPDATE vide pour la famille d’adresses concernée. À la réception de ce marqueur EoR, le routeur récepteur applique la mise à jour : les routes réannoncées remplacent les anciennes, et les routes non reconduites sont supprimées gracieusement, évitant tout à-coup d’instabilité.

Le dilemme des routes zombies : pièges de Graceful Restart et trous noirs de trafic

Bien que la RFC 4724 accroisse considérablement la fluidité des opérations planifiées, elle présente un risque opérationnel notoire nommé piège des routes zombies (Zombie Route Trap).

Si un routeur subit une défaillance matérielle irréversible—coupure d’alimentation électrique, avarie de carte mère ou rupture physique de fibre optique—le pair récepteur ne peut faire la distinction entre cette panne totale et un simple redémarrage logiciel. Le temporisateur de Graceful Restart étant enclenché, le pair récepteur continue d’injecter le trafic utilisateur vers l’équipement hors service pendant toute la durée du Restart Time (par exemple 180 secondes). Durant ce laps de temps, les paquets sont engloutis dans un trou noir réseau complet.

De plus, si le routeur redémarre avec une table FIB vide ou corrompue, les routes périmées demeurent bloquées. La RFC 8538 a par la suite pallié ce risque en autorisant l’envoi d’un message BGP NOTIFICATION portant le sous-code Hard Reset pour forcer la purge immédiate des routes en cas de panne matérielle avérée.

Couplage de BFD avec Graceful Restart : discrimination des pannes en moins d’une seconde

Pour désamorcer le piège des routes zombies, les réseaux résilients associent systématiquement BGP Graceful Restart au protocole de détection de transfert bidirectionnel (BFD, RFC 5880). BFD opère comme un signal de battement de cœur matériel cadencé à haute fréquence sur les liaisons physiques directes, décelant les coupures en quelques dizaines de millisecondes.

Lorsqu’un câble optique est sectionné, BFD identifie immédiatement la panne ($3 \times 100,\text{ms} = 300,\text{ms}$). Le routeur interrompt immédiatement le processus de Graceful Restart, invalide les routes périmées et bascule le trafic sur ses liaisons de secours. À l’inverse, si seul le processus logiciel redémarre alors que le lien physique et la session BFD restent opérationnels, Graceful Restart s’active sereinement. Cette synergie garantit une réaction sous la seconde en cas de panne physique tout en maintenant la continuité de service lors des mises à jour applicatives.

Architecture de la RFC 9478 : Long-Lived Graceful Restart et rétention de secours

La RFC 4724 est limitée par des temporisateurs courts : conserver des routes périmées au-delà de quelques minutes est risqué en raison des mutations de la topologie globale. Toutefois, sur des réseaux d’extrémité, des sites distants ou des liaisons à attachement unique, supprimer les routes après 300 secondes en l’absence de chemin alternatif provoque une rupture totale de service.

En 2023, l’IETF a ratifié la RFC 9478, définissant le protocole Long-Lived Graceful Restart (LLGR). Ce dernier étend la période de conservation des routes périmées de quelques minutes à plusieurs heures voire plusieurs jours ($T_{\text{llgr}}$ jusqu’à 16 777 215 secondes, soit environ 194 jours).

Sous LLGR, à l’échéance du délai initial de la RFC 4724, au lieu d’effacer la route, le routeur la fait basculer dans un état de conservation prolongée (long-lived stale) :

$$T_{\text{retention}} = T_{\text{graceful}} + T_{\text{llgr}}$$

Les échanges continuent ainsi d’être assurés tant que cette route constitue l’unique issue physique disponible pour atteindre la destination isolée.

Propagation des communautés de routes obsolètes : dépriorisation sans oscillation

L’ingéniosité de la RFC 9478 réside dans sa capacité à prolonger la rétention des routes sans perturber le routage mondial. Dès qu’une route entre dans l’état LLGR stale, le routeur lui associe automatiquement la communauté BGP réservée LLGR_STALE (0xFFFF0006).

+-------------------------------------------------------------+
| BGP Route Attribute: Communities (RFC 1997 / RFC 9478)       |
+-------------------------------------------------------------+
| Community Value: 0xFFFF0006 (LLGR_STALE)                    |
| Optional Community: 0xFFFF0007 (NO_LLGR)                    |
+-------------------------------------------------------------+

Les règles de traitement sont strictement déterministes :

• Priorité locale minimale (Local Preference) : Les routeurs prenant en charge LLGR attribuent la priorité la plus basse aux routes étiquetées LLGR_STALE (LOCAL_PREF = 0). Dès qu’un chemin valide réapparaît, le trafic bascule instantanément vers ce dernier.
• Filtrage des annonces en sortie : Les routes LLGR_STALE ne sont pas réémises vers les opérateurs de transit amont, sauf accord explicite pour du secours d’urgence, ce qui prévient la propagation de boucles au niveau mondial.

Cœur de réseau Anycast RiceGuard : transfert ininterrompu lors des pannes de peering

Les réseaux VPN exploitant des architectures Anycast font face à des contraintes de stabilité exigeantes. Lorsqu’un point de présence (PoP) Anycast doit redémarrer son service de routage, l’interruption brutale de ses annonces forcerait des millions de sessions utilisateurs à migrer vers des nœuds géographiquement lointains, dégradant fortement la latence.

L’architecture RiceGuard déploie le protocole BGP Graceful Restart multi-homé associé à une surveillance BFD sur l’ensemble de ses nœuds Anycast :

+---------------------------------------------------------------+
| Terminal utilisateur (Session de tunnel Layer 3 WireGuard)    |
+---------------------------------------------------------------+
| Point d’entrée Anycast (Table FIB ASIC : commutation active)  |
| [Démon BGP : En rechargement] <--- Session BFD OK ---> [FIB OK]|
+---------------------------------------------------------------+
| Cœur maillé RiceGuard (Routage dynamique multichemin ECMP)    |
| Redirection fluide à l’écart des liens de transit dégradés    |
+---------------------------------------------------------------+

Comme les tunnels chiffrés de couche 3 de RiceGuard aboutissent sur l’appareil client, le maintien du plan matériel FIB durant la réinitialisation de BGP garantit que les flux WireGuard ne subissent aucune perte de paquets. Combinée aux protections contre l’amortissement décrites dans /news/bgp-route-flap-damping-rfc-2439-suppression-resiliency et aux technologies de filtrage rapide de /news/bgp-flowspec-vs-rtbh-ddos-mitigation-vpn-resiliency, la dorsale assure une imperméabilité totale face aux pannes.

Les utilisateurs peuvent obtenir les applications RiceGuard depuis /download pour tous leurs équipements de bureau et mobiles.

Tests de résilience empiriques : latence de convergence, perte de paquets et gigue

Pour valider l’apport concret des RFC 4724 et RFC 9478 en environnement intensif, des tests ont été réalisés sur un banc Anycast 100 Gbps lors de redémarrages logiciels et de ruptures physiques :

Les mesures démontrent que Graceful Restart élimine totalement les pertes lors des maintenances courantes, tandis que l’adjonction de BFD réduit la reprise sous les 300 millisecondes lors de destructions physiques.

Déploiement en production : configuration de GR et LLGR sous Bird 2 et FRRouting

La mise en service de Graceful Restart en production requiert une paramétrisation harmonisée des routeurs frontaliers.

Ajustement des temporisateurs et paramètres de peering dans les grappes Bird 2

Sous Linux avec BIRD 2, les fonctionnalités Graceful Restart et LLGR sont activées dans /etc/bird/bird.conf :

# Configuration de BGP Graceful Restart sous BIRD 2
protocol bgp upstream_transit_a {
    local as 64512;
    neighbor 198.51.100.1 as 64500;

    # Activer Graceful Restart standard (RFC 4724)
    graceful restart on;
    graceful restart time 120;
    graceful restart wait 300;

    # Activer Long-Lived Graceful Restart (RFC 9478)
    long lived graceful restart on;
    long lived stale time 3600;

    # Associer BFD pour la détection immédiate des pannes physiques
    bfd on;

    ipv4 {
        import filter {
            # Déprioriser les routes périmées à longue durée
            if (65535, 6) ~ bgp_community then {
                bgp_local_pref = 0;
            }
            accept;
        };
        export all;
    };
}

Inspection de l’état de peering et des routes obsolètes via les diagnostics BGP

Les équipes réseau doivent valider les échanges de capacités et surveiller les temporisateurs grâce aux commandes d’administration :

# Vérifier la négociation de la capacité Graceful Restart sous BIRD 2
birdc show protocols all upstream_transit_a

# Afficher les routes actuellement marquées stale ou pénalisées
birdc show route protocol upstream_transit_a all

# Contrôler le statut des sessions BFD et les intervalles de détection
birdc show bfd sessions

# Sous FRRouting, consulter les temporisateurs de Graceful Restart
vtysh -c "show ip bgp neighbors 198.51.100.1" | grep -A 10 "Graceful Restart"

L’harmonisation des RFC 4724, RFC 9478 LLGR et du contrôle BFD procure aux concepteurs réseau une continuité absolue de commutation de couche 3, immunisant l’infrastructure VPN tant contre les maintenances de routine que contre les avaries matérielles imprévues.