BGP Large Communities RFC 8195 : Marquage 12 octets et ingénierie Anycast

La table de routage globale BGP-4 constitue le système nerveux central d'Internet. Pendant des décennies, les ingénieurs réseau ont orchestré l'ingénierie de trafic au moyen des BGP Communities standard (RFC 1997), adjoignant des étiquettes numériques aux annonces de préfixes pour contrôler le filtrage de transit, affiner les préférences locales et orienter les politiques de peering. Toutefois, l'épuisement des numéros de systèmes autonomes (ASN) sur 2 octets et le déploiement généralisé des ASN sur 4 octets (RFC 6793) ont brisé cette mécanique historique. Les attributs standard ne pouvant accueillir des identifiants 32 bits, les opérateurs ont dû recourir à des expédients fragiles. Standardisé par les RFC 8092 et RFC 8195, le protocole BGP Large Communities résout cette impasse par une structure d'attribut claire de 12 octets. Pour les réseaux Anycast VPN distribués, les Large Communities fournissent le plan de contrôle déterministe requis pour aiguiller les flux utilisateurs, isoler les attaques et équilibrer les charges de transit à l'échelle mondiale.

La crise des ASN 4 octets et les limites des BGP Communities standard

Publiées en 1996, les BGP Communities standard (RFC 1997) ont introduit un attribut de chemin optionnel transitif de 4 octets (32 bits). Traditionnellement représenté sous la forme AA:NN, ses 16 premiers bits désignaient l'ASN émetteur de la règle, tandis que les 16 bits suivants encodaient l'action administrative locale :

Structure d'une BGP Community standard (RFC 1997) - 4 octets :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       ASN sur 2 octets (AA)   |     Valeur sur 2 octets (NN)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Cette architecture concise a convenu aux besoins du réseau jusqu'à la fin des années 2000, période où le stock d'ASN 16 bits s'est tari. L'IANA a alors introduit les ASN sur 4 octets (RFC 6793), portant le volume d'identifiants à plus de 4,29 milliards.

Alors que le protocole BGP a facilement intégré ces ASN 32 bits au sein de l'attribut AS-Path, les communautés de la RFC 1997 se sont retrouvées dans l'impasse :

1. Impossibilité de tronquer : Un opérateur titulaire d'un ASN 4 octets (comme AS13335, AS16509 ou AS396982) ne peut loger son numéro dans le champ AA restreint à 16 bits.
2. Collisions d'espaces de nommage : Les réseaux ont dû emprunter des ASN privés 16 bits (64512–65534). Dès lors que plusieurs transitaires utilisaient les mêmes valeurs privées pour des actions contradictoires, les politiques de routage devenaient imprévisibles.
3. Limites des Extended Communities : Les communautés étendues (RFC 4360) fournissent 8 octets, mais leur structure morcelée par des drapeaux de type et sous-type ne laisse que 4 octets aux données réelles. Conçue pour les Route Targets en environnement MPLS VPN, cette extension s'est avérée complexe et mal adaptée à l'ingénierie de trafic public.

La RFC 8195 a ainsi été conçue pour offrir un schéma moderne, dégagé de tout héritage contraignant et parfaitement adapté aux systèmes autonomes 32 bits.

Structure de données à 12 octets de BGP Large Communities (RFC 8195)

Définies structurellement par la RFC 8092 et opérationnellement par la RFC 8195, les BGP Large Communities portent la taille de l'attribut à exactement 12 octets (96 bits). Elles utilisent le code d'attribut (Type Code) 32 en tant qu'attribut de chemin optionnel transitif :

Encodage d'une BGP Large Community (RFC 8092 / RFC 8195) - 12 octets :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Global Administrator (4 octets)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Local Data Part 1 (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Local Data Part 2 (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Analyse des trois champs de 4 octets : Admin, Function et Parameter

La représentation canonique s'écrit Global Administrator:Local Data 1:Local Data 2. Chacun des champs occupe une largeur uniforme de 32 bits :

1. Administrateur global (Global Administrator — 4 octets) : ASN de l'entité émettrice (ex. 64496). Prenant nativement en charge les ASN 32 bits, il supprime tout risque de collision de politiques entre réseaux distincts.
2. Données locales partie 1 / Fonction (Local Data Part 1 — 4 octets) : Définit la nature de l'action opératoire, telle que le filtrage, l'ajout d'étapes AS-Path, la modulation de préférence ou la portée géographique.
3. Données locales partie 2 / Paramètre (Local Data Part 2 — 4 octets) : Contient les arguments spécifiques associés à la fonction, comme l'ASN de l'opérateur visé, un code de localisation UN/LOCODE ou une métrique.

Exemple d'une politique appliquée par l'ASN 64496 vis-à-vis d'un transitaire amont :

Exemple de Large Community : 64496:1:174
- 64496 : ASN de l'opérateur émetteur (Global Administrator)
- 1     : Action opérationnelle (ex. Ne pas exporter ce préfixe)
- 174   : ASN du transitaire ciblé (Cogent Communications)

Cette structure tripartite offre une lisibilité optimale pour les équipes réseau et se prête parfaitement à l'automatisation logicielle.

Tri canonique et prévention du battement de routes BGP

Dans les cœurs de réseaux, un même préfixe IP peut agréger plusieurs dizaines de communautés. Si les routeurs sérialisent ces données dans un ordre variable lors de l'émission des annonces, les équipements voisins interprètent cela comme une modification d'attribut. Ce phénomène produit des salves de messages BGP UPDATE redondants et risque d'enclencher l'amortissement du battement de routes (Route Flap Damping, RFC 2439), interrompant indûment le trafic.

Les RFC 8092 et 8195 imposent un tri canonique (Canonical Sorting) rigoureux :

• L'ensemble des Large Communities d'un message BGP UPDATE doit être classé par ordre croissant sur la totalité de leurs 12 octets.
• L'évaluation compare d'abord le champ Global Administrator, puis Local Data Part 1, et enfin Local Data Part 2.
• Les doublons sont considérés comme des anomalies syntaxiques et sont automatiquement éliminés lors du décodage.

Ce tri homogène sur les plateformes de routage (BIRD, FRRouting, Junos, Cisco IOS-XR) garantit la stabilité des annonces et préserve la mémoire des processeurs de routage.

Ingénierie de trafic au sein des dorsales Anycast VPN

L'architecture Anycast est la clé de voûte des réseaux VPN modernes à faible latence. En annonçant un même préfixe IP depuis des dizaines de centres de données périphériques, le réseau Internet oriente naturellement chaque internaute vers le point d'accès le plus proche topologiquement. Néanmoins, les routes BGP mondiales sont soumises à de fortes asymétries : incidents sur des câbles sous-marins ou saturations locales de peering peuvent dévier le trafic asiatique vers l'Europe.

Les BGP Large Communities procurent les leviers de contrôle indispensables pour corriger ces dérives d'acheminement.

Régulation Anycast via Large Communities :
+-------------------+      Annonce BGP avec étiquette    +--------------------+
| Passerelle Anycast|   Large Community: 64496:100:10   | Transitaire Tier-1 |
| (Nœud de Tokyo)   |---------------------------------->| (Dorsale mondiale) |
+-------------------+                                   +---------+----------+
                                                                  |
                      Maintien du trafic asiatique en local       |
                      Suppression de l'export vers US/Europe      v
                                                        +--------------------+
                                                        | Internautes locaux |
                                                        | et peerings locaux |
                                                        +--------------------+

Contrôle de portée : propagation locale, régionale et planétaire

Sans contrôle d'exposition, un nœud périphérique de taille modeste risque d'être submergé par des flux intercontinentaux. Les Large Communities permettent d'instaurer des paliers hiérarchiques de diffusion :

Exemple de hiérarchisation des portées :
- 64496:100:10  -> Portée locale (Local) : diffusion cantonnée aux nœuds IXP locaux
- 64496:100:20  -> Portée régionale (Regional) : diffusion à l'échelle du continent (APAC)
- 64496:100:30  -> Portée planétaire (Global) : diffusion intégrale sur les réseaux Tier-1

Lors de l'activation d'un nouveau nœud Anycast ou d'une opération de maintenance, le routeur diffuse ses préfixes avec une portée locale ou régionale, empêchant les flux de traverser inutilement les océans.

Politiques d'exportation sélective et prepend AS-Path maîtrisé

L'allongement artificiel du chemin AS-Path (prepending) s'appliquait jadis globalement, dégradant la priorité sur l'ensemble des transitaires. Les Large Communities permettent d'appliquer un prepending chirurgical ciblé par opérateur :

Politiques de ciblage sélectif :
- 64496:200:1299 -> Ajouter 1 saut AS-Path pour Telia Carrier (AS1299)
- 64496:201:3356 -> Ajouter 2 sauts AS-Path pour Lumen (AS3356)
- 64496:0:6939   -> Bloquer l'exportation vers Hurricane Electric (AS6939)

En cas de rupture d'une dorsale fibre chez un prestataire, le routeur périphérique injecte la communauté 64496:0:<ASN_Prestataire> dans sa session eBGP. Ce dernier cesse aussitôt de propager le préfixe, basculant les flux vers des chemins préservés.

Comparaison architecturale : Standard vs Extended vs Large Communities

Les communautés standard sont obsolètes pour les ASN 32 bits, tandis que les communautés étendues sont grevées par leur complexité interne. Les Large Communities apportent un équilibre remarquable entre simplicité et puissance fonctionnelle.

Atténuation des congestions et optimisation Anycast avec RiceGuard

Dans un système Anycast, l'instabilité temporaire des routes BGP peut faire osciller les flux entre différents centres de données, entraînant des coupures de sessions TCP (phénomène d'Anycast jitter). VPNRice intègre RiceGuard pour stabiliser en continu la connectivité :

1. Ajustement dynamique des routes BGP : RiceGuard surveille en continu la latence et la perte de paquets. Si un lien transitaire commence à saturer, les routeurs périphériques adjoignent sans attendre des Large Communities pour réduire la priorité de cette route avant que des pertes réelles ne surviennent.
2. Continuité des sessions inter-nœuds : RiceGuard maintient une table d'état distribuée. Si un opérateur tiers déroute momentanément des flux vers un nœud voisin, RiceGuard encapsule les paquets pour les renvoyer en interne vers la passerelle d'origine, garantissant la persistance des sessions.
3. Déviation ciblée des attaques DDoS : Lors d'attaques volumétriques, RiceGuard appose des étiquettes de nettoyage (64496:666:0), déviant les flux malveillants vers les centres d'épuration des opérateurs amont tout en préservant le trafic utilisateur sur des chemins directs.

Configuration pratique de BGP Large Communities sous BIRD et FRRouting

La mise en œuvre des spécifications de la RFC 8195 au sein des moteurs de routage open source s'avère particulièrement fluide.

Configuration sous BIRD 2 / BIRD 3

Sous BIRD, les Large Communities s'expriment sous forme de triplets (u32, u32, u32) :

# Extrait /etc/bird/bird.conf
define MY_ASN = 64496;
define ACT_PREPEND_1X = 200;
define SCOPE_REGIONAL = 20;

function apply_anycast_policy() {
    # Définition de la portée régionale
    bgp_large_community.add((MY_ASN, 100, SCOPE_REGIONAL));
    
    # Prepend sélectif d'un cran vers NTT (AS2914)
    bgp_large_community.add((MY_ASN, ACT_PREPEND_1X, 2914));
}

filter anycast_export_filter {
    apply_anycast_policy();
    accept;
}

protocol bgp transit_upstream {
    local as MY_ASN;
    neighbor 198.51.100.1 as 2914;
    ipv4 { export filter anycast_export_filter; };
}

Configuration sous FRRouting (FRR)

Sous FRRouting, le contrôle s'opère via des route-maps :

! Extrait /etc/frr/frr.conf
router bgp 64496
 neighbor 198.51.100.1 remote-as 2914
 address-family ipv4 unicast
  neighbor 198.51.100.1 route-map RM_TRANSIT_OUT out
 exit-address-family
!
route-map RM_TRANSIT_OUT permit 10
 match ip address prefix-list PL_ANYCAST_PREFIX
 set large-community 64496:100:20 additive
 set large-community 64496:200:2914 additive

Pour consulter l'état des étiquettes sous Linux :

# Vérifier les routes dotées de Large Communities sous BIRD
birdc show route all where bgp_large_community ~ [(64496, *, *)]

# Rechercher les préfixes par communauté sous FRRouting
vtysh -c "show ip bgp large-community 64496:100:20"

Filtrage d'entrée et protection contre les fuites de routes et manipulations

Puisque les Large Communities sont des attributs transitifs, leur acceptation sans contrôle depuis des partenaires non certifiés crée des vulnérabilités. Un acteur malveillant pourrait forger des étiquettes pour fausser vos choix d'acheminement.

Un déploiement rigoureux requiert des filtres d'entrée étanches :

1. Purge des étiquettes clientes entrantes : Éliminez systématiquement les communautés reprenant votre propre ASN sur les annonces reçues des clients (bgp_large_community.delete([(MY_ASN, *, *)])), n'autorisant que les étiquettes expressément validées.
2. Nettoyage des étiquettes internes en sortie eBGP : Retirez les communautés de télémétrie interne avant d'exporter des routes vers des pairs publics.
3. Application des règles par défaut de la RFC 8212 : Rejetez par défaut tout préfixe pour lequel aucune politique d'import ou d'export n'est expressément configurée, évitant ainsi les fuites de tables de routage (route leaks).

Grille d'évaluation de la résilience du trafic Anycast en production

Les architectes réseau peuvent valider leur dispositif Anycast au moyen des critères techniques suivants :

• Compatibilité ASN 4 octets avérée : Les moteurs de routage en bordure exploitent des versions prenant en charge les RFC 8092 et 8195.
• Filtrage d'entrée actif : Les règles eBGP suppriment les communautés usurpant l'ASN local.
• Tri canonique effectif : Les routeurs trient les communautés par ordre croissant avant toute émission BGP UPDATE.
• Portées de diffusion formalisées : Les plages de valeurs pour les portées Local, Regional et Global sont documentées.
• Matrice des transitaires validée : Les politiques de ciblage vers les opérateurs Tier-1 sont configurées et testées.
• Télémétrie connectée aux annonces : La surveillance de la latence ajuste dynamiquement les étiquettes de routage.

Synthèse technique et évolution du routage dynamique mondial

Les BGP Large Communities (RFC 8195) ont modernisé l'ingénierie de trafic sur Internet en fournissant un système de signalisation en phase avec les systèmes autonomes 32 bits. Leur conception claire sur 12 octets offre la souplesse et la rigueur indispensables aux réseaux contemporains.

Au sein des infrastructures Anycast VPN, où la régularité du routage détermine la stabilité des flux, les Large Communities représentent un levier de contrôle fondamental. Associées à des politiques de filtrage strictes et aux mécanismes de préservation de RiceGuard, elles garantissent un acheminement précis et une protection continue des échanges sur Internet.