BGP Communities: standard, large ed extended

Cosa sono le BGP community?

Le BGP community sono tag a 32 bit allegati agli annunci di rotta. Trasportano informazioni di segnalazione tra AS senza modificare la rotta stessa. Una community dice "tratta questo prefisso in modo diverso": abbassa la sua preferenza, effettua prepend sul path, scartalo del tutto, oppure annuncialo solo a peer specifici. Le community sono transitive: si propagano tra le sessioni BGP a meno che non vengano esplicitamente rimosse. Esistono tre tipi: standard (RFC 1997), extended (RFC 4360) e large (RFC 8092).

Le community risolvono un problema di coordinamento. Senza di esse, ogni decisione di routing policy richiede configurazione bilaterale su entrambi i lati di una sessione. Con le community, il tuo upstream o il route server dell'IX legge i tuoi tag e applica la policy richiesta. Tagghi una volta, la rete agisce.

Se ti serve prima il setup di una sessione BGP, vedi BIRD2 BGP Configuration on Linux o FRR BGP Configuration on Linux.

Quali sono i tre tipi di BGP community?

Differiscono per dimensione, codifica e problemi che risolvono. Le community standard gestiscono la maggior parte dei casi d'uso ma non funzionano con ASN a 4 byte. Le large community risolvono questa limitazione. Le extended community servono applicazioni specializzate del control plane.

Proprietà	Standard (RFC 1997)	Large (RFC 8092)	Extended (RFC 4360)
Dimensione	32 bit	96 bit (3 x 32 bit)	64 bit
Formato	ASN:value	ASN:value1:value2	type:subtype:value
Supporto ASN	Solo 2 byte	4 byte nativo	2 byte o 4 byte (dipende dal tipo)
Attributo BGP	COMMUNITIES (8)	LARGE_COMMUNITIES (32)	EXTENDED COMMUNITIES (16)
Uso primario	Segnalazione upstream, traffic engineering	Come standard, compatibile con ASN a 4 byte	MPLS VPN, EVPN, route target
Adozione	Universale	Diffusa dal ~2018	Specifica per protocollo

Community standard (RFC 1997)

Le community standard sono valori a 32 bit scritti come due interi a 16 bit separati da due punti: ASN:value. I 16 bit di ordine superiore identificano l'AS che definisce il significato della community. I 16 bit di ordine inferiore contengono l'azione o l'informazione.

Esempio: 174:70 significa "Cogent: imposta la local preference a 70". Solo Cogent definisce il significato del valore 70 nel namespace 174. Ogni provider pubblica le proprie definizioni di community.

Il campo ASN a 16 bit limita le community standard ad ASN a 2 byte (0-65535). Con oltre 120.000 ASN assegnati nel 2026, la maggior parte delle nuove assegnazioni sono numeri a 4 byte. Le community standard non possono rappresentarli.

IANA riserva l'intervallo da 65535:0 a 65535:65535 per le community well-known.

Large community (RFC 8092)

Le large community usano tre interi a 32 bit: Global Administrator : Local Data 1 : Local Data 2. Il global administrator è l'ASN della rete che definisce la community. Entrambi i campi local data sono definiti dall'operatore.

Questo formato risolve il problema degli ASN a 4 byte. Un AS con numero 398465 può definire 398465:100:0 come large community valida. Le community standard non possono codificarlo.

La struttura a tre campi consente anche semantiche più ricche. Un pattern comune è ASN:funzione:parametro. Ad esempio, 35661:1010:174 potrebbe significare "effettua prepend una volta a Francoforte verso Cogent (AS174)".

Il supporto per le large community è disponibile in BIRD 1.6.3+, BIRD2, FRR 3.0+, OpenBGPD 6.1+, GoBGP, Cisco IOS-XR 6.2.1+ e Junos 17.3+. Se il tuo BGP daemon è stato rilasciato dopo il 2018, quasi certamente le supporta.

Extended community (RFC 4360)

Le extended community sono valori a 64 bit con un campo type, un campo subtype e un valore. A differenza delle community standard e large, le extended community hanno semantiche strutturate: type e subtype definiscono come il valore deve essere interpretato.

Le extended community si incontrano principalmente in:

• MPLS L3VPN: route target (rt 65000:100) e route distinguisher controllano l'import/export delle VRF
• EVPN: MAC mobility, ESI label e tipi di rotta
• BGP Flowspec: limitazione del traffico e azioni di redirect

Per il traffic engineering tra AS, le community standard e large sono gli strumenti giusti. Le extended community servono quando si gestiscono servizi overlay. Questo articolo si concentra sulle community standard e large nelle sezioni successive.

Cosa sono le BGP community well-known?

IANA definisce diversi valori di community well-known nell'intervallo riservato 65535:*. Ogni implementazione BGP conforme deve comprenderli.

Community	Valore	Hex	Comportamento	RFC
NO_EXPORT	65535:65281	0xFFFFFF01	Non annunciare al di fuori della confederazione AS locale	1997
NO_ADVERTISE	65535:65282	0xFFFFFF02	Non annunciare a nessun peer BGP	1997
NO_EXPORT_SUBCONFED	65535:65283	0xFFFFFF03	Non annunciare al di fuori dell'AS locale	1997
NOPEER	65535:65284	0xFFFFFF04	Non annunciare ai peer bilaterali	3765
BLACKHOLE	65535:666	0xFFFF029A	Richiedere il blackhole del prefisso taggato	7999
GRACEFUL_SHUTDOWN	65535:0	0xFFFF0000	Segnalare lo shutdown pianificato della sessione, impostare local-pref a 0	8326

NO_EXPORT è la più usata. Tagga un prefisso con essa e il tuo peer non lo riannuncerà oltre il confine del proprio AS. È così che si controllano i route leak verso terzi.

BLACKHOLE e GRACEFUL_SHUTDOWN sono trattate in dettaglio nelle sezioni sul traffic engineering qui sotto.

Come le BGP community abilitano il traffic engineering?

Le community ti permettono di influenzare le decisioni di routing in reti che non controlli. Non puoi accedere ai router del tuo upstream e modificarne la configurazione. Ma puoi taggare i tuoi annunci con community che hanno accettato di onorare. Questo è il BGP traffic engineering tramite community.

Come funziona la segnalazione di local preference con le community?

La maggior parte dei transit provider offre community che impostano la local preference del tuo prefisso all'interno della loro rete. Una local preference più alta significa "preferisci questo path". Un valore più basso significa "usa questo solo come backup".

Ad esempio, un provider con AS 64500 potrebbe definire:

Community	Effetto
64500:100	Preferenza normale (default)
64500:90	Preferenza inferiore (path di backup)
64500:150	Preferenza superiore (path preferito)

Taggando il tuo annuncio con 64500:90 quando lo invii a un upstream e lasciando il default sull'altro, indirizzi il traffico in ingresso verso l'upstream senza la community di backup. Questo funziona perché la local preference viene valutata prima della lunghezza dell'AS path nel processo decisionale BGP.

Controlla la documentazione delle community del tuo provider. I valori sopra sono illustrativi. Ogni provider definisce il proprio schema.

Come funziona il BGP prepending con le community?

L'AS-path prepending gonfia artificialmente la lunghezza del path per rendere una rotta meno preferita dalle reti remote. Invece di fare prepending sul tuo router (che influisce su tutti i peer allo stesso modo), le community ti permettono di richiedere il prepending selettivamente.

Uno schema tipico di un provider:

Community	Effetto
64500:1001	Prepend 1x verso tutti i peer
64500:1002	Prepend 2x verso tutti i peer
64500:1003	Prepend 3x verso tutti i peer

Con le large community, il target può essere più specifico:

Large community	Effetto
64500:1:174	Prepend 1x verso Cogent (AS174)
64500:2:174	Prepend 2x verso Cogent (AS174)
64500:3:0	Prepend 3x verso tutti i peer

Questa granularità è il motivo per cui le large community stanno sostituendo le community standard per il traffic engineering. Il terzo campo codifica l'ASN target o il gruppo di peer.

Come funziona il BGP blackholing con la community BLACKHOLE?

Il blackholing dice alle reti upstream di scartare tutto il traffico destinato a un prefisso taggato. È uno strumento di mitigazione DDoS: quando un IP è sotto attacco, lo annunci con la community BLACKHOLE e i tuoi upstream null-routano il traffico prima che raggiunga la tua rete.

L'RFC 7999 standardizza la community well-known 65535:666 per questo scopo.

Requisiti perché il blackholing funzioni:

1. Specificità del prefisso. Annuncia un /32 (IPv4) o /128 (IPv6) per l'IP target. Non fare mai blackhole di un intero /24.
2. Accordo bilaterale. Il tuo upstream deve essere configurato per onorare la community BLACKHOLE. Non è automatico. Verifica con il tuo provider.
3. Tagging NO_EXPORT. Aggiungi sempre NO_EXPORT insieme a BLACKHOLE per evitare che il blackhole si propaghi oltre il tuo upstream immediato.
4. Monitoraggio. Il blackholing scarta tutto il traffico, legittimo e malevolo. Monitora e ritira l'annuncio non appena l'attacco termina.

La maggior parte dei route server degli IXP supporta il blackholing tramite 65535:666. Il route server imposta il next-hop a un indirizzo blackhole e aggiunge NO_EXPORT prima della redistribuzione.

Come si usano le community per l'annuncio selettivo?

L'annuncio selettivo ti permette di controllare quali peer o IXP vedono il tuo prefisso. È il pattern "non annunciare a" o "annuncia solo a".

Le implementazioni comuni usano un modello deny/allow:

Community	Effetto
64500:0:0	Non annunciare a nessuno (deny globale)
64500:0:174	Non annunciare a Cogent
64500:8:174	Annuncia solo a Cogent (override del deny)

Con Virtua (AS35661), questo utilizza lo schema di community location-aware descritto nella tabella di riferimento qui sotto.

Come funziona il graceful shutdown con la community GRACEFUL_SHUTDOWN?

L'RFC 8326 definisce la community GRACEFUL_SHUTDOWN (65535:0) per la manutenzione pianificata. Quando devi abbattere una sessione BGP, taggare le tue rotte con questa community dice ai router riceventi di abbassare la local preference a 0 e iniziare a preferire path alternativi prima della disconnessione.

La sequenza:

1. Aggiungi la community GRACEFUL_SHUTDOWN a tutte le rotte inviate al peer in manutenzione
2. Attendi la convergenza (le rotte si spostano su path alternativi)
3. Abbatti la sessione BGP
4. Esegui la manutenzione
5. Riattiva la sessione
6. Rimuovi la community

Senza graceful shutdown, l'abbattimento di una sessione causa il ritiro immediato della rotta. Il traffico cade fino a quando BGP converge sul path alternativo. Con il graceful shutdown, il traffico si sposta gradualmente prima che la sessione vada giù.

Questo si collega direttamente alle strategie di failover in multi-homing.

Come configuro le BGP community in BIRD2?

BIRD2 usa attributi community tipizzati sugli oggetti rotta. I tre attributi rilevanti sono:

Attributo	Tipo	Tipo di community
bgp_community	clist (pair list)	Standard
bgp_large_community	lclist (triplet list)	Large
bgp_ext_community	eclist (extended list)	Extended

Aggiungere community in BIRD2

Usa il metodo .add() nei blocchi 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;
}

Matching delle community in BIRD2

Verifica l'appartenenza con l'operatore ~:

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'operatore ~ restituisce true se l'operando sinistro è membro dell'operando destro. Per il matching con set, usa pattern a coppia/tripletta con * come wildcard.

Eliminare community in BIRD2

Rimuovi le community in ingresso per prevenire segnalazioni non autorizzate:

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;
}

Ricevitore graceful shutdown in 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;
}

Applica ebgp_inbound come filtro di import su tutte le sessioni EBGP. Quando un peer invia la community GRACEFUL_SHUTDOWN, la local preference viene impostata a 0, facendo sì che il tuo router preferisca qualsiasi path alternativo.

Trigger blackhole in 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;
}

Come configuro le BGP community in FRR?

FRR usa definizioni community-list in stile IOS e azioni route-map. Le community vengono matchate con clausole match e impostate con clausole set.

Definire community list in 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 supporta sia community list numerate (1-99 per standard, 100-500 per expanded) che denominate. Le liste denominate sono più facili da mantenere.

Impostare community nelle route-map 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

La keyword additive aggiunge community invece di sostituire l'insieme esistente. Senza di essa, set community sovrascrive tutte le community esistenti.

Matching delle community nelle route-map 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

Rimuovere community in 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:.*:.*

Questo rimuove qualsiasi community nel namespace del tuo ASN che un peer potrebbe iniettare. Applica questa route-map come neighbor <peer> route-map SCRUB-INBOUND in.

Graceful shutdown in FRR

FRR fornisce un comando integrato:

router bgp 35661
 bgp graceful-shutdown

Questo aggiunge automaticamente la community GRACEFUL_SHUTDOWN (65535:0) a tutte le rotte inviate a tutti i peer EBGP. Usalo prima della manutenzione pianificata.

Sul lato ricevente, applica una route-map che matcha la community e abbassa 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

Confronto configurazione community tra BIRD2 e FRR

Operazione	BIRD2	FRR
Aggiungere community standard	bgp_community.add((ASN, val))	set community ASN:val additive
Aggiungere large community	bgp_large_community.add((ASN, v1, v2))	set large-community ASN:v1:v2 additive
Match community standard	if (ASN, val) ~ bgp_community	match community LIST_NAME
Match large community	if (ASN, v1, v2) ~ bgp_large_community	match large-community LIST_NAME
Eliminare per pattern	bgp_community.delete([(ASN, *)])	set comm-list LIST_NAME delete
Match con wildcard	[(ASN, *)] in espressione set	Community-list expanded con regex
Applicare filtro	import filter name; nel protocollo	neighbor X route-map NAME in

BIRD2 gestisce le operazioni sulle community inline nelle funzioni filter. FRR separa la definizione (community-list) dall'azione (route-map). Entrambi gli approcci funzionano. La sintassi inline di BIRD2 è più concisa per logiche complesse con condizionali. Il modello separato di FRR è più leggibile per policy semplici di match-and-set.

Quali sono i valori delle BGP community di Virtua?

Virtua (AS35661) supporta sia community BGP standard che large. Le large community seguono il formato 35661:AZIONE_LOCATION:TARGET. Lo schema è location-aware, permettendo di controllare gli annunci per POP, per tipo di peer o per ASN specifico del peer.

Codici di localizzazione

Codice	Città	Paese	POP ID
000	Parigi	Francia	PAR01FR
001	Lille	Francia	LIL01FR
010	Francoforte	Germania	FRA01DE
020	Amsterdam	Paesi Bassi	AMS01NL
999	Tutte le localizzazioni	--	ALL

Community di azione

Azione	Formato large community	Effetto
Origine della rotta	35661:0[LOC]:TARGET	Informativo: identifica dove la rotta è stata appresa
Prepend 1x	35661:1[LOC]:TARGET	Prepend AS35661 una volta verso il target
Prepend 2x	35661:2[LOC]:TARGET	Prepend AS35661 due volte verso il target
Prepend 3x	35661:3[LOC]:TARGET	Prepend AS35661 tre volte verso il target
Export only	35661:8[LOC]:TARGET	Override del deny: annuncia solo al target
No export	35661:9[LOC]:TARGET	Non annunciare al target

Selettori target

Valore target	Significato
0	Tutti i peer nella localizzazione specificata
1	Solo peer di transito
2	Solo peer IX
ASN specifico	Un singolo peer (es. 174 per Cogent)

Regole di precedenza

Quando più community sono in conflitto, Virtua le valuta in questo ordine (priorità più alta per prima):

1. 35661:8[LOC]:ASN -- allow esplicito per un peer specifico
2. 35661:9[LOC]:ASN -- deny per un peer specifico
3. 35661:9[LOC]:1 o 35661:9[LOC]:2 -- deny per gruppo di peer (transito o IX)
4. 35661:9[LOC]:0 -- deny per tutti i peer in una localizzazione
5. 35661:9999:0 -- deny globale (non annunciare da nessuna parte)

Esempi con le community Virtua

Annuncia ovunque tranne che a Cogent a Francoforte:

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

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

Annuncia solo ai peer IX in tutte le localizzazioni:

# 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 verso tutti i peer a Parigi:

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

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

Per maggiori informazioni sulla configurazione BGP con Virtua, vedi BGP Bring Your Own IP on a VPS.

Come verifico le BGP community su una rotta?

Verifica in BIRD2

birdc show route for 203.0.113.0/24 all

Cerca gli attributi BGP.community e BGP.large_community nell'output:

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

Verifica in FRR

vtysh -c "show ip bgp 203.0.113.0/24"

L'output include una riga Community::

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

Verifica con strumenti esterni

Non è possibile vedere le community solo dall'interno della propria rete. Usa looking glass esterni per verificare cosa vede il resto di internet:

• bgp.tools: cerca il tuo prefisso e controlla la tab "Communities". Mostra le community viste da più collector in tutto il mondo.
• RIPE Stat: il widget "BGP Looking Glass" mostra gli attributi community dai collector RIPE RIS.
• NLNOG Looking Glass: interroga dai nodi NLNOG RING attraverso più AS.

Verifica sempre dall'esterno. Una community potrebbe essere impostata correttamente sul tuo router ma rimossa da una rete intermedia.

Come gestire la sicurezza delle community?

Le community sono transitive per default. Qualsiasi rete nel path può leggerle, aggiungerle o rimuoverle. Questo crea rischi di sicurezza se non si filtra correttamente.

Rimuovere le community in ingresso nel proprio namespace ASN

Se un peer ti invia una rotta taggata con le tue community (es. 35661:9999:0), e non le rimuovi, i tuoi filtri di export potrebbero onorarle. Questo potrebbe farti smettere di annunciare il prefisso del tutto.

Pulisci sempre il tuo namespace community in 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

Validare le richieste di blackhole

Non onorare mai ciecamente 65535:666 da qualsiasi peer. Un peer malevolo o mal configurato potrebbe fare blackhole dei prefissi dei tuoi clienti.

Regole per l'accettazione del blackhole:

• Accetta rotte taggate blackhole solo per prefissi che il peer è autorizzato a originare
• Verifica la validità RPKI/ROA prima di onorare il blackhole (vedi RPKI ROA Setup for BGP)
• Limita la lunghezza del prefisso accettato a /32 (IPv4) e /128 (IPv6) per i blackhole
• Aggiungi sempre NO_EXPORT alle rotte blackhole prima della redistribuzione

# 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;
}

Rimuovere community in export quando appropriato

Prima di annunciare rotte ai peer, rimuovi le community che non dovrebbero vedere o su cui non dovrebbero agire:

# 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 sicurezza delle community fa parte di una strategia di filtraggio delle rotte più ampia. Vedi BGP Route Filtering and Security per il quadro completo.

Qualcosa non funziona?

Le community non appaiono sui looking glass remoti. Il tuo upstream potrebbe rimuoverle. Verifica se la community è in un namespace che onorano. Alcuni provider rimuovono tutte le community di terze parti per default.

Il blackhole non funziona. Verifica la lunghezza del prefisso (/32 o /128 richiesto). Conferma che il tuo upstream supporta RFC 7999. Controlla se NO_EXPORT viene aggiunto: senza di esso, il blackhole potrebbe propagarsi oltre il previsto e venire rimosso.

Le large community non si propagano. Implementazioni BGP più vecchie scartano silenziosamente gli attributi sconosciuti. Se un AS intermedio usa software che precede il supporto RFC 8092, le large community andranno perse. Controlla l'AS path e identifica la rete che le scarta.

Errori di sintassi nei filtri BIRD2. Le coppie community usano parentesi, non due punti: (35661, 100) non 35661:100. Le large community sono triplette: (35661, 100, 200). La notazione con i due punti è solo per la visualizzazione e la CLI.

La community-list FRR non matcha. Le community list denominate devono essere referenziate esattamente come definite. Controlla eventuali errori di battitura. Usa show bgp community-list per verificare il contenuto della lista.

Community sovrascritte invece che aggiunte in FRR. Manca la keyword additive in set community o set large-community. Senza di essa, tutte le community esistenti vengono sostituite. Usa sempre additive a meno che tu non voglia intenzionalmente sovrascrivere.

Controlla i log per problemi con le sessioni BGP:

# BIRD2
journalctl -u bird -f

# FRR
journalctl -u frr -f

Copyright 2026 Virtua.Cloud. Tutti i diritti riservati. Questo contenuto è un'opera originale del team Virtua.Cloud. La riproduzione, ripubblicazione o redistribuzione senza autorizzazione scritta è vietata.