Communautés BGP : standard, large et extended

Qu'est-ce qu'une communauté BGP ?

Les communautés BGP sont des tags de 32 bits attachés aux annonces de routes. Elles transportent des informations de signalisation entre AS sans modifier la route elle-même. Une communauté dit « traite ce préfixe différemment » : baisser sa préférence, faire du prepending sur le chemin, le supprimer entièrement, ou l'annoncer uniquement à certains peers. Les communautés sont transitives : elles se propagent à travers les sessions BGP sauf si elles sont explicitement supprimées. Trois types existent : standard (RFC 1997), extended (RFC 4360), et large (RFC 8092).

Les communautés résolvent un problème de coordination. Sans elles, chaque décision de politique de routage nécessite une configuration bilatérale des deux côtés de la session. Avec les communautés, votre upstream ou le route server de l'IX lit vos tags et applique la politique demandée. Vous taguez une fois, le réseau agit.

Si vous avez d'abord besoin de mettre en place une session BGP, consultez Configuration BGP BIRD2 sous Linux ou Configuration BGP FRR sous Linux.

Quels sont les trois types de communautés BGP ?

Ils diffèrent par leur taille, leur encodage et les problèmes qu'ils résolvent. Les communautés standard couvrent la plupart des cas mais ne fonctionnent pas avec les ASN 4 octets. Les communautés large corrigent cette limitation. Les communautés extended servent des applications spécialisées du plan de contrôle.

Propriété	Standard (RFC 1997)	Large (RFC 8092)	Extended (RFC 4360)
Taille	32 bits	96 bits (3 x 32 bits)	64 bits
Format	ASN:value	ASN:value1:value2	type:subtype:value
Support ASN	2 octets uniquement	4 octets natif	2 ou 4 octets (selon le type)
Attribut BGP	COMMUNITIES (8)	LARGE_COMMUNITIES (32)	EXTENDED COMMUNITIES (16)
Usage principal	Signalisation upstream, traffic engineering	Identique au standard, compatible ASN 4 octets	MPLS VPN, EVPN, route targets
Adoption	Universelle	Largement répandu depuis ~2018	Spécifique à certains protocoles

Communautés standard (RFC 1997)

Les communautés standard sont des valeurs de 32 bits écrites sous forme de deux entiers de 16 bits séparés par deux-points : ASN:value. Les 16 bits de poids fort identifient l'AS qui définit la signification de la communauté. Les 16 bits de poids faible portent l'action ou l'information.

Exemple : 174:70 signifie « Cogent : définir la local preference à 70 ». Seul Cogent définit ce que la valeur 70 signifie dans l'espace de noms 174. Chaque fournisseur publie ses propres définitions de communautés.

Le champ ASN de 16 bits limite les communautés standard aux ASN de 2 octets (0-65535). Avec plus de 120 000 ASN alloués en 2026, la plupart des nouvelles attributions sont des numéros de 4 octets. Les communautés standard ne peuvent pas les représenter.

L'IANA réserve la plage 65535:0 à 65535:65535 pour les communautés bien connues (well-known communities).

Communautés large (RFC 8092)

Les communautés large utilisent trois entiers de 32 bits : Global Administrator : Local Data 1 : Local Data 2. L'administrateur global est l'ASN du réseau qui définit la communauté. Les deux champs de données locales sont définis par l'opérateur.

Ce format résout le problème des ASN 4 octets. Un AS avec le numéro 398465 peut définir 398465:100:0 comme communauté large valide. Les communautés standard ne peuvent pas encoder cela.

La structure à trois champs permet aussi une sémantique plus riche. Un pattern courant est ASN:function:parameter. Par exemple, 35661:1010:174 pourrait signifier « prepend une fois à Francfort vers Cogent (AS174) ».

Le support des communautés large est disponible dans BIRD 1.6.3+, BIRD2, FRR 3.0+, OpenBGPD 6.1+, GoBGP, Cisco IOS-XR 6.2.1+, et Junos 17.3+. Si votre démon BGP a été publié après 2018, il les supporte presque certainement.

Communautés extended (RFC 4360)

Les communautés extended sont des valeurs de 64 bits avec un champ type, un champ subtype et une valeur. Contrairement aux communautés standard et large, les communautés extended ont une sémantique structurée : le type et le subtype définissent comment la valeur doit être interprétée.

Vous rencontrez les communautés extended principalement dans :

• MPLS L3VPN : les route targets (rt 65000:100) et route distinguishers contrôlent l'import/export des VRF
• EVPN : mobilité MAC, labels ESI et types de routes
• BGP Flowspec : limitation de débit et actions de redirection

Pour le traffic engineering entre AS, les communautés standard et large sont les bons outils. Les communautés extended comptent quand vous opérez des services overlay. Cet article se concentre sur les communautés standard et large pour les sections suivantes.

Quelles sont les communautés BGP bien connues ?

L'IANA définit plusieurs valeurs de communautés bien connues dans la plage réservée 65535:*. Toute implémentation BGP conforme doit les comprendre.

Communauté	Valeur	Hex	Comportement	RFC
NO_EXPORT	65535:65281	0xFFFFFF01	Ne pas annoncer en dehors de la confédération AS locale	1997
NO_ADVERTISE	65535:65282	0xFFFFFF02	Ne pas annoncer à aucun peer BGP	1997
NO_EXPORT_SUBCONFED	65535:65283	0xFFFFFF03	Ne pas annoncer en dehors de l'AS local	1997
NOPEER	65535:65284	0xFFFFFF04	Ne pas annoncer aux peers bilatéraux	3765
BLACKHOLE	65535:666	0xFFFF029A	Demander le blackhole du préfixe tagué	7999
GRACEFUL_SHUTDOWN	65535:0	0xFFFF0000	Signaler un arrêt planifié de session, définir local-pref à 0	8326

NO_EXPORT est la plus utilisée. Taguez un préfixe avec et votre peer ne le re-annoncera pas au-delà de sa frontière AS. C'est ainsi que vous contrôlez les fuites de routes (route leaks) vers des tiers.

BLACKHOLE et GRACEFUL_SHUTDOWN sont détaillés dans les sections traffic engineering ci-dessous.

Comment les communautés BGP permettent-elles le traffic engineering ?

Les communautés vous permettent d'influencer les décisions de routage dans des réseaux que vous ne contrôlez pas. Vous ne pouvez pas vous connecter aux routeurs de votre upstream et modifier leur configuration. Mais vous pouvez taguer vos annonces avec des communautés qu'ils ont accepté d'honorer. C'est le traffic engineering BGP via les communautés.

Comment fonctionne la signalisation de local preference avec les communautés ?

La plupart des fournisseurs de transit offrent des communautés qui définissent la local preference de votre préfixe dans leur réseau. Une local preference plus élevée signifie « préférer ce chemin ». Une valeur plus basse signifie « utiliser uniquement en secours ».

Par exemple, un fournisseur avec l'AS 64500 pourrait définir :

Communauté	Effet
64500:100	Préférence normale (par défaut)
64500:90	Préférence réduite (chemin de secours)
64500:150	Préférence élevée (chemin préféré)

En taguant votre annonce avec 64500:90 vers un upstream et en laissant la valeur par défaut sur un autre, vous orientez le trafic entrant vers l'upstream sans la communauté de secours. Cela fonctionne parce que la local preference est évaluée avant la longueur de l'AS-path dans le processus de décision BGP.

Consultez la documentation des communautés de votre fournisseur. Les valeurs ci-dessus sont illustratives. Chaque fournisseur définit son propre schéma.

Comment fonctionne le prepending BGP avec les communautés ?

L'AS-path prepending allonge artificiellement le chemin pour rendre une route moins préférée par les réseaux distants. Au lieu de faire du prepending sur votre propre routeur (ce qui affecte tous les peers de manière égale), les communautés vous permettent de demander du prepending de manière sélective.

Un schéma typique de fournisseur :

Communauté	Effet
64500:1001	Prepend 1x vers tous les peers
64500:1002	Prepend 2x vers tous les peers
64500:1003	Prepend 3x vers tous les peers

Avec les communautés large, la cible peut être plus spécifique :

Communauté large	Effet
64500:1:174	Prepend 1x vers Cogent (AS174)
64500:2:174	Prepend 2x vers Cogent (AS174)
64500:3:0	Prepend 3x vers tous les peers

Cette granularité explique pourquoi les communautés large remplacent les communautés standard pour le traffic engineering. Le troisième champ encode l'ASN cible ou le groupe de peers.

Comment fonctionne le blackholing BGP avec la communauté BLACKHOLE ?

Le blackholing indique aux réseaux upstream de supprimer tout le trafic destiné à un préfixe tagué. C'est un outil de mitigation DDoS : quand une IP est attaquée, vous l'annoncez avec la communauté BLACKHOLE et vos upstreams null-routent le trafic avant qu'il n'atteigne votre réseau.

La RFC 7999 standardise la communauté bien connue 65535:666 à cet effet.

Prérequis pour que le blackholing fonctionne :

1. Spécificité du préfixe. Annoncez un /32 (IPv4) ou /128 (IPv6) pour l'IP cible. Ne blackholez jamais un /24 entier.
2. Accord bilatéral. Votre upstream doit être configuré pour honorer la communauté BLACKHOLE. Ce n'est pas automatique. Vérifiez avec votre fournisseur.
3. Tag NO_EXPORT. Ajoutez toujours NO_EXPORT en plus de BLACKHOLE pour empêcher le blackhole de se propager au-delà de votre upstream immédiat.
4. Supervision. Le blackholing supprime tout le trafic, légitime et malveillant. Supervisez et retirez l'annonce dès que l'attaque cesse.

La plupart des route servers d'IXP supportent aussi le blackholing via 65535:666. Le route server définit le next-hop vers une adresse blackhole et ajoute NO_EXPORT avant la redistribution.

Comment utiliser les communautés pour l'annonce sélective ?

L'annonce sélective vous permet de contrôler quels peers ou IXP voient votre préfixe. C'est le pattern « ne pas annoncer à » ou « annoncer uniquement à ».

Les implémentations courantes utilisent un modèle deny/allow :

Communauté	Effet
64500:0:0	Ne pas annoncer à personne (deny global)
64500:0:174	Ne pas annoncer à Cogent
64500:8:174	Annoncer uniquement à Cogent (override du deny)

Chez Virtua (AS35661), cela utilise le schéma de communautés géo-localisées décrit dans le tableau de référence ci-dessous.

Comment fonctionne le graceful shutdown avec la communauté GRACEFUL_SHUTDOWN ?

La RFC 8326 définit la communauté GRACEFUL_SHUTDOWN (65535:0) pour les maintenances planifiées. Quand vous devez couper une session BGP, taguer vos routes avec cette communauté indique aux routeurs récepteurs de baisser la local preference à 0 et de commencer à préférer les chemins alternatifs avant la déconnexion.

La séquence :

1. Ajouter la communauté GRACEFUL_SHUTDOWN à toutes les routes envoyées au peer en maintenance
2. Attendre la convergence (les routes basculent vers les chemins alternatifs)
3. Couper la session BGP
4. Effectuer la maintenance
5. Remonter la session
6. Retirer la communauté

Sans graceful shutdown, couper une session provoque un retrait immédiat des routes. Le trafic chute jusqu'à ce que BGP converge vers le chemin alternatif. Avec le graceful shutdown, le trafic bascule progressivement avant la coupure de session.

Cela s'intègre directement aux stratégies de failover multi-homing.

Comment configurer les communautés BGP dans BIRD2 ?

BIRD2 utilise des attributs de communautés typés sur les objets route. Les trois attributs pertinents sont :

Attribut	Type	Type de communauté
bgp_community	clist (liste de paires)	Standard
bgp_large_community	lclist (liste de triplets)	Large
bgp_ext_community	eclist (liste extended)	Extended

Ajouter des communautés dans BIRD2

Utilisez la méthode .add() dans les blocs filter :

filter export_to_upstream {
  # Add standard community
  bgp_community.add((65535, 666));

  # Add large community
  bgp_large_community.add((35661, 1010, 174));

  # Add multiple communities
  bgp_community.add((65535, 65281));  # NO_EXPORT

  accept;
}

Faire du matching de communautés dans BIRD2

Testez l'appartenance avec l'opérateur ~ :

filter import_from_peer {
  # Match a specific standard community
  if (65535, 666) ~ bgp_community then {
    dest = RTD_BLACKHOLE;
    accept;
  }

  # Match a specific large community
  if (35661, 9999, 0) ~ bgp_large_community then {
    reject;
  }

  # Match with wildcards using sets
  # Any community in the 64500:* range
  if bgp_community ~ [(64500, *)] then {
    bgp_local_pref = 50;
  }

  accept;
}

L'opérateur ~ retourne vrai si l'opérande gauche est membre de l'opérande droit. Pour le matching par ensemble, utilisez des patterns paire/triplet avec * comme joker (wildcard).

Supprimer des communautés dans BIRD2

Nettoyez les communautés en entrée pour empêcher la signalisation non autorisée :

filter scrub_inbound {
  # Remove all communities in our ASN namespace
  bgp_community.delete([(35661, *)]);
  bgp_large_community.delete([(35661, *, *)]);

  # Remove specific well-known community
  bgp_community.delete((65535, 666));

  accept;
}

Récepteur de graceful shutdown dans BIRD2

function honor_graceful_shutdown() {
  if (65535, 0) ~ bgp_community then {
    bgp_local_pref = 0;
  }
}

filter ebgp_inbound {
  honor_graceful_shutdown();
  # ... other import filters
  accept;
}

Appliquez ebgp_inbound comme filtre d'import sur toutes les sessions EBGP. Quand un peer envoie la communauté GRACEFUL_SHUTDOWN, la local preference passe à 0, ce qui force votre routeur à préférer tout chemin alternatif.

Déclencheur de blackhole dans BIRD2

protocol static blackhole_triggers {
  ipv4 {
    table master4;
  };
  # Announce 203.0.113.5/32 with BLACKHOLE + NO_EXPORT
  route 203.0.113.5/32 blackhole;
}

filter export_blackhole {
  if dest = RTD_BLACKHOLE then {
    bgp_community.add((65535, 666));    # BLACKHOLE
    bgp_community.add((65535, 65281));  # NO_EXPORT
    # Accept only /32 for blackholes
    if net.len = 32 then accept;
  }
  reject;
}

Comment configurer les communautés BGP dans FRR ?

FRR utilise des définitions community-list de style IOS et des actions route-map. Les communautés sont matchées avec des clauses match et définies avec des clauses set.

Définir des community lists dans FRR

! Standard community list - match specific community
bgp community-list standard BLACKHOLE permit 65535:666
bgp community-list standard GRACEFUL_SHUTDOWN permit 65535:0
bgp community-list standard NO_EXPORT permit no-export

! Large community list
bgp large-community-list standard PREPEND_1X permit 35661:1:0
bgp large-community-list standard NO_ANNOUNCE permit 35661:9:0

FRR supporte les community lists numérotées (1-99 pour standard, 100-500 pour expanded) et nommées. Les listes nommées sont plus faciles à maintenir.

Définir des communautés dans les route-maps FRR

route-map EXPORT-TO-UPSTREAM permit 10
 set community 65535:666 no-export additive
!
route-map EXPORT-TO-UPSTREAM permit 20
 set large-community 35661:1010:174 additive

Le mot-clé additive ajoute les communautés au lieu de remplacer l'ensemble existant. Sans lui, set community écrase toutes les communautés existantes.

Matcher des communautés dans les route-maps FRR

route-map IMPORT-FROM-PEER permit 10
 match community BLACKHOLE
 set ip next-hop 192.0.2.1
!
route-map IMPORT-FROM-PEER permit 20
 match community GRACEFUL_SHUTDOWN
 set local-preference 0
!
route-map IMPORT-FROM-PEER permit 30
 ! Default: accept everything else

Supprimer des communautés dans FRR

route-map SCRUB-INBOUND permit 10
 set comm-list OUR_COMMUNITIES delete
 set large-comm-list OUR_LARGE_COMMUNITIES delete
!
bgp community-list expanded OUR_COMMUNITIES permit 35661:.*
bgp large-community-list expanded OUR_LARGE_COMMUNITIES permit 35661:.*:.*

Cela supprime toutes les communautés dans l'espace de noms de votre ASN qu'un peer pourrait injecter. Appliquez cette route-map avec neighbor <peer> route-map SCRUB-INBOUND in.

Graceful shutdown dans FRR

FRR fournit une commande intégrée :

router bgp 35661
 bgp graceful-shutdown

Cela ajoute automatiquement la communauté GRACEFUL_SHUTDOWN (65535:0) à toutes les routes envoyées à tous les peers EBGP. Utilisez-la avant une maintenance planifiée.

Côté réception, appliquez une route-map qui matche la communauté et baisse la local preference :

route-map HONOR-GSHUT permit 10
 match community GRACEFUL_SHUTDOWN
 set local-preference 0
!
route-map HONOR-GSHUT permit 20
 ! Accept everything else at normal preference

Comparaison de la configuration des communautés BIRD2 vs FRR

Opération	BIRD2	FRR
Ajouter une communauté standard	bgp_community.add((ASN, val))	set community ASN:val additive
Ajouter une communauté large	bgp_large_community.add((ASN, v1, v2))	set large-community ASN:v1:v2 additive
Matcher une communauté standard	if (ASN, val) ~ bgp_community	match community LIST_NAME
Matcher une communauté large	if (ASN, v1, v2) ~ bgp_large_community	match large-community LIST_NAME
Supprimer par pattern	bgp_community.delete([(ASN, *)])	set comm-list LIST_NAME delete
Matching par joker	[(ASN, *)] dans une expression d'ensemble	Community-list expanded avec regex
Appliquer un filtre	import filter name; dans le protocole	neighbor X route-map NAME in

BIRD2 gère les opérations sur les communautés en ligne dans les fonctions filter. FRR sépare la définition (community-list) de l'action (route-map). Les deux approches fonctionnent. La syntaxe en ligne de BIRD2 est plus concise pour les logiques complexes avec conditions. Le modèle séparé de FRR est plus lisible pour les politiques simples de type match-and-set.

Quelles sont les valeurs de communautés BGP de Virtua ?

Virtua (AS35661) supporte les communautés BGP standard et large. Les communautés large suivent le format 35661:ACTION_LOCATION:TARGET. Le schéma est géo-localisé, ce qui permet de contrôler les annonces par POP, par type de peer, ou par ASN spécifique.

Codes de localisation

Code	Ville	Pays	ID POP
000	Paris	France	PAR01FR
001	Lille	France	LIL01FR
010	Francfort	Allemagne	FRA01DE
020	Amsterdam	Pays-Bas	AMS01NL
999	Toutes les localisations	--	ALL

Communautés d'action

Action	Format communauté large	Effet
Origine de la route	35661:0[LOC]:TARGET	Informationnel : identifie où la route a été apprise
Prepend 1x	35661:1[LOC]:TARGET	Prepend AS35661 une fois vers la cible
Prepend 2x	35661:2[LOC]:TARGET	Prepend AS35661 deux fois vers la cible
Prepend 3x	35661:3[LOC]:TARGET	Prepend AS35661 trois fois vers la cible
Export uniquement	35661:8[LOC]:TARGET	Override du deny : annoncer uniquement à la cible
Pas d'export	35661:9[LOC]:TARGET	Ne pas annoncer à la cible

Sélecteurs de cible

Valeur cible	Signification
0	Tous les peers à la localisation spécifiée
1	Peers transit uniquement
2	Peers IX uniquement
ASN spécifique	Un seul peer (ex. 174 pour Cogent)

Règles de priorité

Quand plusieurs communautés sont en conflit, Virtua les évalue dans cet ordre (priorité la plus haute en premier) :

1. 35661:8[LOC]:ASN : autorisation explicite pour un peer spécifique
2. 35661:9[LOC]:ASN : deny pour un peer spécifique
3. 35661:9[LOC]:1 ou 35661:9[LOC]:2 : deny pour un groupe de peers (transit ou IX)
4. 35661:9[LOC]:0 : deny pour tous les peers à une localisation
5. 35661:9999:0 : deny global (ne pas annoncer nulle part)

Exemples avec les communautés Virtua

Annoncer partout sauf à Cogent à Francfort :

# BIRD2
bgp_large_community.add((35661, 9010, 174));

! FRR
route-map EXPORT permit 10
 set large-community 35661:9010:174 additive

Annoncer uniquement aux peers IX sur toutes les localisations :

# BIRD2
bgp_large_community.add((35661, 9999, 1));  # deny all transit

! FRR
route-map EXPORT permit 10
 set large-community 35661:9999:1 additive

Prepend 2x vers tous les peers à Paris :

# BIRD2
bgp_large_community.add((35661, 2000, 0));

! FRR
route-map EXPORT permit 10
 set large-community 35661:2000:0 additive

Pour en savoir plus sur la configuration BGP avec Virtua, consultez BGP Bring Your Own IP sur un VPS.

Comment vérifier les communautés BGP sur une route ?

Vérifier dans BIRD2

birdc show route for 203.0.113.0/24 all

Cherchez les attributs BGP.community et BGP.large_community dans la sortie :

203.0.113.0/24   unicast [upstream1 2026-03-19] * (100) [AS64500i]
    via 198.51.100.1 on eth0
    Type: BGP univ
    BGP.community: (65535,666) (65535,65281)
    BGP.large_community: (35661,0010,174)
    BGP.as_path: 64500

Vérifier dans FRR

vtysh -c "show ip bgp 203.0.113.0/24"

La sortie inclut une ligne Community: :

BGP routing table entry for 203.0.113.0/24
  65535:666 no-export
  Large Community: 35661:0010:174

Vérifier avec des outils externes

Vous ne pouvez pas voir les communautés uniquement depuis l'intérieur de votre réseau. Utilisez des looking glasses externes pour vérifier ce que le reste d'internet voit :

• bgp.tools : recherchez votre préfixe et consultez l'onglet « Communities ». Affiche les communautés vues par plusieurs collecteurs dans le monde.
• RIPE Stat : le widget « BGP Looking Glass » affiche les attributs de communautés depuis les collecteurs RIPE RIS.
• NLNOG Looking Glass : interrogez depuis les nœuds NLNOG RING à travers plusieurs AS.

Vérifiez toujours depuis l'extérieur. Une communauté peut être correctement définie sur votre routeur mais supprimée par un réseau intermédiaire.

Comment gérer la sécurité des communautés ?

Les communautés sont transitives par défaut. Tout réseau dans le chemin peut les lire, en ajouter ou les supprimer. Cela crée des risques de sécurité si vous ne filtrez pas correctement.

Supprimer les communautés entrantes dans votre espace de noms ASN

Si un peer vous envoie une route taguée avec vos propres communautés (ex. 35661:9999:0), et que vous ne la nettoyez pas, vos propres filtres d'export pourraient l'honorer. Cela pourrait vous amener à ne plus annoncer le préfixe du tout.

Nettoyez toujours votre propre espace de noms de communautés en import :

# BIRD2 - apply on every EBGP import filter
bgp_community.delete([(35661, *)]);
bgp_large_community.delete([(35661, *, *)]);

! FRR - apply as inbound route-map on every EBGP neighbor
bgp community-list expanded OUR_COMMS permit 35661:.*
bgp large-community-list expanded OUR_LARGE_COMMS permit 35661:.*:.*

route-map SCRUB-IN permit 10
 set comm-list OUR_COMMS delete
 set large-comm-list OUR_LARGE_COMMS delete

Valider les demandes de blackhole

N'honorez jamais 65535:666 aveuglément depuis n'importe quel peer. Un peer malveillant ou mal configuré pourrait blackholer les préfixes de vos clients.

Règles pour l'acceptation des blackholes :

• Acceptez les routes taguées blackhole uniquement pour les préfixes que le peer est autorisé à originer
• Vérifiez la validité RPKI/ROA avant d'honorer le blackhole (voir RPKI ROA Setup for BGP)
• Limitez la longueur de préfixe acceptée à /32 (IPv4) et /128 (IPv6) pour les blackholes
• Ajoutez toujours NO_EXPORT aux routes blackhole avant redistribution

# BIRD2 - safe blackhole acceptance
filter import_with_blackhole {
  if (65535, 666) ~ bgp_community then {
    # Only accept /32 for blackhole
    if net.len != 32 then reject;
    dest = RTD_BLACKHOLE;
    bgp_community.add((65535, 65281));  # NO_EXPORT
    accept;
  }
  # ... normal import policy
  accept;
}

Supprimer les communautés en export si nécessaire

Avant d'annoncer des routes à vos peers, supprimez les communautés qu'ils ne devraient pas voir ou sur lesquelles ils ne devraient pas agir :

# BIRD2 - clean export to IX route server
filter export_to_ix {
  # Keep well-known communities, remove internal ones
  bgp_community.delete([(35661, *)]);
  bgp_large_community.delete([(35661, 0, *)]);  # Remove informational
  # Keep action communities the IX needs to see
  accept;
}

La sécurité des communautés fait partie d'une stratégie plus large de filtrage de routes. Consultez BGP Route Filtering and Security pour la vue d'ensemble.

Quelque chose ne fonctionne pas ?

Les communautés n'apparaissent pas sur les looking glasses distants. Votre upstream les supprime peut-être. Vérifiez si la communauté est dans un espace de noms qu'il honore. Certains fournisseurs suppriment toutes les communautés tierces par défaut.

Le blackhole ne fonctionne pas. Vérifiez la longueur du préfixe (/32 ou /128 requis). Confirmez que votre upstream supporte la RFC 7999. Vérifiez que NO_EXPORT est ajouté : sans lui, le blackhole pourrait se propager plus loin que prévu et être supprimé.

Les communautés large ne se propagent pas. Les anciennes implémentations BGP suppriment silencieusement les attributs inconnus. Si un AS intermédiaire utilise un logiciel antérieur au support de la RFC 8092, les communautés large seront perdues. Vérifiez l'AS path et identifiez le réseau qui les supprime.

Erreurs de syntaxe dans les filtres BIRD2. Les paires de communautés utilisent des parenthèses, pas des deux-points : (35661, 100) et non 35661:100. Les communautés large sont des triplets : (35661, 100, 200). La notation avec deux-points sert uniquement à l'affichage et au CLI.

La community-list FRR ne matche pas. Les community lists nommées doivent être référencées exactement comme définies. Vérifiez les fautes de frappe. Utilisez show bgp community-list pour vérifier le contenu de la liste.

Les communautés sont écrasées au lieu d'être ajoutées dans FRR. Le mot-clé additive manque dans set community ou set large-community. Sans lui, toutes les communautés existantes sont remplacées. Utilisez toujours additive sauf si vous voulez intentionnellement écraser.

Consultez les logs en cas de problèmes de session BGP :

# BIRD2
journalctl -u bird -f

# FRR
journalctl -u frr -f

Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.