Uno degli attributi BGP più utili nelle applicazioni è l'attributo Community. Curiosamente, la definizione di BGP Community non è presente nel documento originale di definizione del BGP versione 4, la versione oggi in uso (RFC 1771 - A Border Gateway Protocol 4 (BGP-4) del Marzo 1995, poi aggiornata nella RFC 4271 con lo stesso titolo nel Gennaio 2006). L'attributo BGP Community è stato introdotto infatti con la RFC 1997 - BGP Communities Attribute, dell'Agosto 1996.
Tecnicamente parlando, una BGP Community è un attributo Optional Transitive di tipo "opaco", utilizzato per classificare annunci BGP secondo le proprie esigenze amministrative, ed eventualmente eseguire azioni sulla base del valore dell’attributo. Il fatto che sia un valore "opaco" sta a significare che a differenza di altri attributi BGP come ad esempio Local Preference, AS-Path, MED, ecc., non trasporta informazioni che poi vengono utilizzate dal BGP in modo ben definito (ad esempio, come arcinoto, il Local Preference viene utilizzato come metrica nel processo di selezione BGP), ma trasporta una informazione che poi può venir utilizzata dal BGP nei modi più svariati, in funzione dei desiderata dell'amministratore dell'Autonomous System (vedi sezione successiva "Utilizzo delle BGP Community").
Il formato dell'attributo BGP Community è riportato nella figura seguente.
Come si può notare, il valore dell’attributo ha lunghezza Nx4 byte. Questo perché ciascun valore di Community ha lunghezza 4 byte ed è possibile associare un qualsivoglia numero di Community a ciascun messaggio BGP UPDATE, con il numero che dipende dall'utilizzo che si fa dell'attributo .
I valori di Community vengono tipicamente espressi nel formato AS:NN, dove AS è un numero di Autonomous System (2 byte) e NN un valore arbitrario (2 byte). Negli standard, i valori di Community vengono espressi nel formato esadecimale, mentre nei router i costruttori preferiscono utilizzare una notazione decimale. Ad esempio, il valore decimale 3269:90 è espresso nella notazione esadecimale come 0x0CC5005A (3269 = 0x0CC5, 90 = 0x005A).
I valori dell’attributo Community vengono assegnati su base configurazione sia agli annunci in uscita che in ingresso. La strategia di propagazione degli attributi Community dipende dalla particolare implementazione dei costruttori. Ad esempio, nell’implementazione Cisco, di default un BGP speaker che riceve un annuncio con determinati valori di Community, non propaga questi valori sulle altre sessioni BGP (siano esse iBGP o eBGP). Questa regola può essere però variata su base configurazione. Nell’implementazione Juniper invece, gli attributi Community vengono propagati automaticamente.
Nella RFC 1997 sono definiti tre valori di COMMUNITY con un significato particolare (well-known Community):
- NO_EXPORT (0xFFFFFF01): tutti gli annunci che hanno associato questo valore di Community, non devono essere propagati al di fuori di un AS, ossia, non devono essere propagati su sessioni eBGP.
- NO_ADVERTISE (0xFFFFFF02): tutti i prefissi che hanno associato questo valore di Community, non devono essere propagati su alcuna sessione BGP (iBGP o eBGP).
- NO_EXPORT_SUBCONFED (0xFFFFFF03): utilizzata nelle Confederazioni BGP per evitare la propagazione degli annunci BGP su sessioni eBGP sia verso AS esterni alla Confederazione BGP che verso sub-AS intra-confederazione .
La figura seguente riporta un esempio di applicazione delle well-known Community NO_EXPORT e NO_ADVERTISE.
Gli annunci dei prefissi X e Y vengono inviati da AS 3 verso AS 2 e hanno rispettivamente attributi Community NO_ADVERTISE e NO_EXPORT, mentre l’annuncio del prefisso Z non ha associata alcuna Community. Il BGP speaker RD, dopo l’esecuzione del processo di selezione, ammesso che gli annunci risultino best-path, propaga il solo annuncio del prefisso Z verso AS 1, mentre propaga gli annunci dei prefissi Y e Z sulla sessione iBGP verso RA. La propagazione avviene di default senza associare alcun valore di Community agli annunci. Qualora, eventualmente tramite una configurazione, si consenta la propagazione dei valori di Community sulla sessione iBGP tra RD e RA, il prefisso Y non verrebbe propagato verso AS 1 a causa della well-known Community NO_EXPORT.
In generale, i valori negli intervalli 0x00000000–0x0000FFFF e 0xFFFF0000–0xFFFFFFFF sono riservati alle well-known Community, il cui registro è mantenuto dallo IANA, che è anche responsabile dell'assegnazione. Il registro è consultabile a questo link. Un esempio di assegnazione recente si trova in questo post, dove ho parlato della definizione della well-known Community GRACEFUL_SHUTDOWN (valore 0xFFFF0000 = 65535:0).
DALLE COMMUNITY ALLE EXTENDED COMMUNITY
Lo spazio riservato al valore di Community, pari a 4 byte, si è rivelato ben presto non sufficiente per le nuove applicazioni del BGP, in particolare per l'utilizzo nei servizi BGP/MPLS. Per sopperire a questo problema, è stato definito con la RFC 4360 - BGP Extended Communities Attribute del Febbraio 2006, l'attributo Community esteso (Extended Community). Oltre a raddoppiare lo spazio dedicato all'attributo Community, la RFC 4360 ne ha anche definito una struttura generale, riportata nella figura seguente (tratta direttamente dalla RFC 4360):
Il nuovo attributo Extended Community ha Type code = 16. Per i dettagli potete consultare direttamente la RFC 4360, qui voglio solo illustrare il caso di una particolare Extended Community utilizzata in molti servizi BGP/MPLS, il Route Target.
Facendo riferimento a quello che forse è il servizio BGP/MPLS più noto (sicuramente il più diffuso), il servizio L3VPN, il Route Target (RT) è un parametro associato ad ogni prefisso VPN-IPv4 esportato da un PE, che viene trasportato come attributo BGP Extended Community. Gli attributi BGP Extended Community di tipo Route Target hanno il campo Type low sempre pari a 0x02, mentre il campo Type high può assumere i valori 0x00, 0x01 e 0x02, in funzione del formato del campo Value (che è di 6 byte). Sono previsti tre formati del campo Value:
NOTA: nell'ultimo formato ho espresso il numero di AS (4 byte) nella notazione "asdot", che consiste nel dividere i 4 byte in due blocchi di 2 byte ciascuno, e rappresentarli in notazione decimale separati da un punto.
Il nuovo attributo Extended Community ha Type code = 16. Per i dettagli potete consultare direttamente la RFC 4360, qui voglio solo illustrare il caso di una particolare Extended Community utilizzata in molti servizi BGP/MPLS, il Route Target.
Facendo riferimento a quello che forse è il servizio BGP/MPLS più noto (sicuramente il più diffuso), il servizio L3VPN, il Route Target (RT) è un parametro associato ad ogni prefisso VPN-IPv4 esportato da un PE, che viene trasportato come attributo BGP Extended Community. Gli attributi BGP Extended Community di tipo Route Target hanno il campo Type low sempre pari a 0x02, mentre il campo Type high può assumere i valori 0x00, 0x01 e 0x02, in funzione del formato del campo Value (che è di 6 byte). Sono previsti tre formati del campo Value:
- Type = 0x00-02 : formato AS-2byte:NN (esempio 12345:6789).
- Type = 0x01-02 : formato Indirizzo-IP:NN (esempio 192.168.0.1:6789).
- Type = 0x02-02 : formato AS-4byte:NN (esempio 1.1:6789).
NOTA: nell'ultimo formato ho espresso il numero di AS (4 byte) nella notazione "asdot", che consiste nel dividere i 4 byte in due blocchi di 2 byte ciascuno, e rappresentarli in notazione decimale separati da un punto.
DALLE EXTENDED COMMUNITY ALLE LARGE COMMUNITY
L'introduzione dei numeri di AS a 4 byte, necessaria poiché i numeri di AS a 2 byte sono in via di esaurimento (a fine 2016 ne erano disponibili solo 3.172, con l'ARIN che li aveva già esauriti), ha creato problemi all'utilizzo sia delle Community classiche che alle Extended Community.
Le Community classiche, avendo a disposizione uno spazio utile di 4 byte, non possono proprio essere utilizzate con numeri di AS a 4 byte. O meglio, possono essere utilizzate, ma non è possibile utilizzare, per ovvie ragioni, il formato AS:NN, il che ne limita di molto l'utilizzo pratico.
Per le Extended Community il problema è simile. Possono essere utilizzate, ma il campo gestito dall'amministratore della rete si riduce a 2 byte, uno spazio ritenuto insufficiente nelle applicazioni pratiche.
E' quindi sorta l'esigenza tra gli ISP di risolvere in modo possibilmente definitivo il problema dell'ampiezza delle Community, introducendo Community ancora più grandi, in modo da dare agli amministratori di rete uno strumento duraturo su cui basare le loro policy BGP.
Il primo tentativo verso questa direzione in realtà non ha aumentato lo spazio disponibile per gli amministratori, ma si è limitato a proporre un cambio di formato delle Extended Community. Il tentativo si è concretizzato nella già citata RFC 5668 - 4-Octet AS Specific BGP Extended Community, dell’Ottobre 2009. Ma come detto sopra, non è una soluzione al problema, ma solo un palliativo. Lo spazio disponibile agli amministratori di rete, secondo questa RFC è di soli 2 byte, che come detto non sono ritenuti sufficienti.
Altri tentativi si sono arenati strada facendo. Vedi ad esempio i draft IETF (mai divenuti RFC) draft-lange-flexible-bgp-communities - Flexible BGP Communities , scaduto nel Febbraio 2011, e draft-ietf-idr-wide-bgp-communities - BGP Community Container Attribute, scaduto nel Settembre 2017.
La soluzione che invece è diventata uno standard IETF è descritta nella RFC 8092 - BGP Large Communities Attribute, del Febbraio 2017, che introduce il concetto di Large Community.
La proposta espande il campo a disposizione dell'amministratore di rete da 6 a 12 byte, eliminando nel contempo i due byte Type high e Type low. Il formato di una Large Community è il seguente (figura tratta dalla RFC 8092).
dove il campo di Global Administrator è un numero di AS a 4 byte (in realtà la RFC 8092 dice che dovrebbe essere), mentre gli altri due campi sono lasciati alla discrezione dell'amministratore di rete. Tipicamente il valore di Global Administrator coincide con il valore di AS che attribuisce il significato alla Community.
La RFC 8092 stabilisce inoltre una rappresentazione canonica di una Large Community come:
Global Administrator:Local Data Part 1:Local Data Part 2
Ad esempio, l'amministratore dell'AS 12345 può definire e utilizzare le Large Community 12345:1:2 , 12345:0:1, 12345:0:0, ecc. attribuendo a ciascuna di queste un significato.
Lo IANA ha inoltre stabilito per l'attributo BGP Large Community il Type Code 32 (NOTA: durante la stesura e progressione del draft, IANA aveva stabilito il Type Code 30, ma questo era già utilizzato da Huawei in modo improprio per usi interni. Per evitare conflitti IANA nella RFC ufficiale, ha cambiato il valore da 30 a 32).
Come si può notare, la struttura di una Large Community definita nella RFC 8092 assomiglia molto la definizione delle Community classiche della vecchia RFC 1997, cambia solo l'ampiezza, che è stata triplicata.
Molte delle implementazioni correnti del BGP già supportano o hanno in progetto di supportare le Large Community. Una lista completa e continuamente aggiornata del supporto della RFC 8092 da parte dei vendor e delle implementazioni open del BGP, è consultabile a questo link.
Tra i costruttori più noti, ad esempio Juniper supporta le Large Community a partire dalla versione Junos 17.3R1. Per chi di voi è familiare con la CLI del Junos, la definizione di una Large Community avviene anteponendo al valore la parola chiave "large" (in modo analogo ad esempio a quanto avviene per i Route Target, dove si antepone al valore la parola chiave "target"). Di seguito un esempio di configurazione:
tt@PE1# show policy-options {
community LG-12 members large:12345:14:10;
}
Cisco al momento supporta le Large Community nella versione beta dell'IOS XR e sta pianificando l'introduzione nell'IOS XE. Per chi di voi è familiare con la CLI dell'IOS XR, per definire un valore di Community si utilizzano le route policy. Di seguito un esempio di configurazione:
route-policy SET-LARGE-COMM
set large-community (12345:14:10)
end-policy
Oltre ai soliti comandi di tipo show dei router, è possibile utilizzare wireshark per verificare la presenza di Large Community nei messaggi BGP UPDATE. Di seguito lo snapshot parziale di una cattura di un messaggio BGP UPDATE contenente una Large Community. La figura è tratta da questo link.
Bene, arrivato a questo punto non mi resta che dare alcuni cenni sull'utilizzo delle BGP Community, cercando di mettere in evidenza i vantaggi e la maggiore flessibilità delle Large Community rispetto alle Community tradizionali.
Le Community classiche, avendo a disposizione uno spazio utile di 4 byte, non possono proprio essere utilizzate con numeri di AS a 4 byte. O meglio, possono essere utilizzate, ma non è possibile utilizzare, per ovvie ragioni, il formato AS:NN, il che ne limita di molto l'utilizzo pratico.
Per le Extended Community il problema è simile. Possono essere utilizzate, ma il campo gestito dall'amministratore della rete si riduce a 2 byte, uno spazio ritenuto insufficiente nelle applicazioni pratiche.
E' quindi sorta l'esigenza tra gli ISP di risolvere in modo possibilmente definitivo il problema dell'ampiezza delle Community, introducendo Community ancora più grandi, in modo da dare agli amministratori di rete uno strumento duraturo su cui basare le loro policy BGP.
Il primo tentativo verso questa direzione in realtà non ha aumentato lo spazio disponibile per gli amministratori, ma si è limitato a proporre un cambio di formato delle Extended Community. Il tentativo si è concretizzato nella già citata RFC 5668 - 4-Octet AS Specific BGP Extended Community, dell’Ottobre 2009. Ma come detto sopra, non è una soluzione al problema, ma solo un palliativo. Lo spazio disponibile agli amministratori di rete, secondo questa RFC è di soli 2 byte, che come detto non sono ritenuti sufficienti.
Altri tentativi si sono arenati strada facendo. Vedi ad esempio i draft IETF (mai divenuti RFC) draft-lange-flexible-bgp-communities - Flexible BGP Communities , scaduto nel Febbraio 2011, e draft-ietf-idr-wide-bgp-communities - BGP Community Container Attribute, scaduto nel Settembre 2017.
La soluzione che invece è diventata uno standard IETF è descritta nella RFC 8092 - BGP Large Communities Attribute, del Febbraio 2017, che introduce il concetto di Large Community.
La proposta espande il campo a disposizione dell'amministratore di rete da 6 a 12 byte, eliminando nel contempo i due byte Type high e Type low. Il formato di una Large Community è il seguente (figura tratta dalla RFC 8092).
dove il campo di Global Administrator è un numero di AS a 4 byte (in realtà la RFC 8092 dice che dovrebbe essere), mentre gli altri due campi sono lasciati alla discrezione dell'amministratore di rete. Tipicamente il valore di Global Administrator coincide con il valore di AS che attribuisce il significato alla Community.
La RFC 8092 stabilisce inoltre una rappresentazione canonica di una Large Community come:
Global Administrator:Local Data Part 1:Local Data Part 2
Ad esempio, l'amministratore dell'AS 12345 può definire e utilizzare le Large Community 12345:1:2 , 12345:0:1, 12345:0:0, ecc. attribuendo a ciascuna di queste un significato.
Lo IANA ha inoltre stabilito per l'attributo BGP Large Community il Type Code 32 (NOTA: durante la stesura e progressione del draft, IANA aveva stabilito il Type Code 30, ma questo era già utilizzato da Huawei in modo improprio per usi interni. Per evitare conflitti IANA nella RFC ufficiale, ha cambiato il valore da 30 a 32).
Come si può notare, la struttura di una Large Community definita nella RFC 8092 assomiglia molto la definizione delle Community classiche della vecchia RFC 1997, cambia solo l'ampiezza, che è stata triplicata.
Molte delle implementazioni correnti del BGP già supportano o hanno in progetto di supportare le Large Community. Una lista completa e continuamente aggiornata del supporto della RFC 8092 da parte dei vendor e delle implementazioni open del BGP, è consultabile a questo link.
Tra i costruttori più noti, ad esempio Juniper supporta le Large Community a partire dalla versione Junos 17.3R1. Per chi di voi è familiare con la CLI del Junos, la definizione di una Large Community avviene anteponendo al valore la parola chiave "large" (in modo analogo ad esempio a quanto avviene per i Route Target, dove si antepone al valore la parola chiave "target"). Di seguito un esempio di configurazione:
tt@PE1# show policy-options {
community LG-12 members large:12345:14:10;
}
Cisco al momento supporta le Large Community nella versione beta dell'IOS XR e sta pianificando l'introduzione nell'IOS XE. Per chi di voi è familiare con la CLI dell'IOS XR, per definire un valore di Community si utilizzano le route policy. Di seguito un esempio di configurazione:
route-policy SET-LARGE-COMM
set large-community (12345:14:10)
end-policy
Oltre ai soliti comandi di tipo show dei router, è possibile utilizzare wireshark per verificare la presenza di Large Community nei messaggi BGP UPDATE. Di seguito lo snapshot parziale di una cattura di un messaggio BGP UPDATE contenente una Large Community. La figura è tratta da questo link.
Bene, arrivato a questo punto non mi resta che dare alcuni cenni sull'utilizzo delle BGP Community, cercando di mettere in evidenza i vantaggi e la maggiore flessibilità delle Large Community rispetto alle Community tradizionali.
UTILIZZO PRATICO DELLE BGP COMMUNITY
L'attributo Community (di qualsiasi tipo) è utilizzato per classificare annunci BGP secondo le proprie esigenze amministrative ed eventualmente eseguire azioni sulla base del valore dell’attributo. Ad esempio, l’attributo Community può essere utilizzato per definire:
Infine, come ultimo esempio di applicazione di tipo informativo delle Community, l'AS 12345 potrebbe utilizzare lo schema seguente per definire la relazione con l'ISP che gli invia gli annunci:
APPLICAZIONI A CUI CONSEGUONO DELLE AZIONI
Supponiamo che l’Upstream ISP AS 12345 adotti la seguente politica di assegnazione del Local Preference:
Configurazione del router CE1 (Juniper):
[edit policy-options]
tt@CE1# show
policy-statement SET-COMM-LP {
from {
route-filter 100.24.0.0/24 exact;
}
then {
community add COMM-LP;
}
}
community COMM-LP members large:12345:9:150;
- Politiche di routing per gruppi di prefissi omogenei, come ad esempio, assegnare un valore di Local Preference sulla base di un valore di Community.
- Politiche di Qualità del Servizio sulla base di Service Level Agreement definiti tra Clienti e ISP, come ad esempio, differenziare i livelli di Qualità del Servizio offerti ai Clienti (vedi ad esempio la funzionalità QPPB Cisco).
- Politiche di filtraggio dei prefissi, come ad esempio, non annunciare i prefissi che hanno un determinato valore di Community.
- L'origine del traffico.
- La natura della relazione con un altro ISP (peering, transito).
e molto altro. Il fatto poi che si abbia a disposizione uno spazio maggiore e più strutturato rispetto al passato, lascia molto spazio alla fantasia, un po' come accade nei piani di numerazione IPv6, dove essendo i bit a disposizione moltissimi (forse troppi), si possono definire piani di numerazione più sofisticati rispetto ai classici piani di numerazione IPv4.
Facendo una classificazione a grandi linee, le applicazioni delle Community di possono dividere in due categorie:
- Applicazioni di tipo informativo, dove le Community sono utilizzate come una sorta di etichetta da associare agli annunci ricevuti.
- Applicazioni a cui conseguono delle azioni, dove le Community sono utilizzate come condizioni di tipo "match", a cui conseguono determinate azioni.
Illustrerò ora alcune applicazioni delle Large Community di entrambe le categorie. Le applicazioni che illustrerò sono in parte tratte dalla recente RFC 8195 - Use of BGP Large Communities, del Giugno 2017.
APPLICAZIONI DI TIPO INFORMATIVO
Le applicazioni di tipo informativo delle Community sono utilizzate ad esempio per definire la provenienza di un annuncio, la natura della relazione con l'ISP da cui si riceve un annuncio, l'ambito di propagazione dell'annuncio. In queste applicazioni, il campo Global Administrator contiene di norma il numero di AS che assegna il valore di Community.
Le applicazioni di tipo informativo delle Community sono utilizzate ad esempio per definire la provenienza di un annuncio, la natura della relazione con l'ISP da cui si riceve un annuncio, l'ambito di propagazione dell'annuncio. In queste applicazioni, il campo Global Administrator contiene di norma il numero di AS che assegna il valore di Community.
Tipicamente a beneficiare di queste Community sono i downstream ISP, anche se qualsiasi AS può trarre beneficio dal loro valore.
La RFC 8195 illustra alcuni esempi esempi di assegnazione di Large Community per queste applicazioni. Per informare altri ISP sulla regione geografica da dove l'AS che assegna il valore di Community importa gli annunci BGP, un ISP può assegnare a ciascun annuncio ad esempio una Large Community che contenga l'informazione sulla provenienza geografica degli annunci. Ad esempio, l'AS 12345 potrebbe utilizzare il primo campo a disposizione (Local part 1) per definire il formato e il secondo (Local part 2) per definire un codice associato alla provenienza.
Due soluzioni proposte nella RFC 8195, che possono essere utilizzate contemporaneamente, sono basate sugli standard ISO 3166-1 e UN M.49. Il primo standard assegna un codice a ciascuna nazione del mondo. I codici li potete trovare a questo link. Ad esempio, per l'Italia il codice è 380, per gli Stati Uniti 840, ecc. . Assegnando un valore pari a 1 al campo Local part 1, l'AS 12345 potrebbe ad esempio utilizzare uno schema seguente:
Lo standard UN M.49 definisce inoltre le regioni geografiche. I codici utilizzati si trovano a questo link. Ad esempio l'Europa ha il codice 150, a sua volta suddiviso in 4 sotto-aree: Europa dell'Est - codice 151, Europa del nord - codice 154, Europa occidentale - codice 155, Europa del Sud - codice 039. Anche qui, assegnando un valore pari a 2 al campo Local part 1 (che ad esempio indica l'utilizzo dello standard UN M.49), l'AS 12345 potrebbe utilizzare uno schema seguente:
Naturalmente questi valori di Community possono essere combinati tra loro. Ad esempio, ad un annuncio possono essere associati i due valori di Community: 12345:1:380 + 12345:3:3 per indicare che l'annuncio è stato ricevuto da un ISP localizzato in Italia con cui è stata stabilita una relazione di peering.
Giusto per capire l'importanza di definire la provenienza geografica di un annuncio, consideriamo lo scenario della figura seguente.
Se ISP-X ricevesse un annuncio dello stesso prefisso IP da ISP-A e ISP-B, allora sarebbe bene far transitare il traffico attraverso l’AS geograficamente più vicino (routing ottimo). Ad esempio, supponendo che ISP-X e ISP-B siano in Europa e ISP-A negli Stati Uniti, potrebbe accadere che il prefisso di un AS Z più "vicino" a ISP-A che a ISP-B secondo l’AS_PATH ma localizzato in Europa (come nella figura), venga raggiunto attraverso ISP-A, geograficamente più distante, piuttosto che attraverso ISP-B, che è geograficamente più vicino. Purtroppo negli annunci BGP, il concetto di vicinanza geografica non esiste, e quindi per risolvere il problema di routing ottimo, è necessario adottare un qualche stratagemma. Una idea molto semplice è proprio quella che gli Upstream Provider, ISP-A e ISP-B nella figura, associno agli annunci BGP degli attributi Community sulla base della localizzazione geografica.
Ad esempio, ritornando all'esempio della figura, supponiamo che ISP-A e ISP-B associno, agli annunci dei prefissi originati da AS localizzati in Europa, rispettivamente i valori di Large Community AS_ISP-A:2:150 e AS_ISP-B:2:150. Per fare in modo che il traffico originato nell’AS dell’ISP-X raggiunga i prefissi di AS localizzati in Europa attraverso l’ISP-B, è sufficiente applicare sul router di ISP-X interconnesso con ISP-B, una politica del tipo: per tutti gli annunci provenienti da ISP-B che contengono il valore di Large Community AS_ISP-B:2:150, poni Local Preference = 200, per tutti gli annunci provenienti da ISP-A che contengono il valore di Large Community AS_ISP-A:2:150 lascia il valore di Local Preference al valore di default 100. Con questa politica, ciascun router dell’ISP-X preferirà raggiungere, grazie al valore di Local Preference più elevato, i prefissi locali di AS Europei attraverso ISP-B.
APPLICAZIONI A CUI CONSEGUONO DELLE AZIONI
Vi sono vari esempi di applicazioni di Community a cui conseguono delle azioni. Secondo il sottoscritto, il più elegante e utile nelle applicazioni pratiche è quello descritto nella vecchia RFC 1998 - An Application of the BGP Community Attribute in Multi-home Routing, dell'Agosto 1996, che consente una gestione molto semplice del traffico inbound. L'idea di fondo è molto semplice: un ISP pubblica una lista di azioni che esegue a fronte della ricezione di annuncio BGP con un determinato valore di Community. Sulla base della lista pubblicata, un downstream ISP o un semplice Cliente, sulla base di determinati desiderata, inviano all'Upstream ISP annunci con il valore di Community appropriato. Di norma i valori di Community utilizzati hanno nel campo Global Administrator il numero di AS dell'ISP che esegue le azioni. Giusto per curiosità, a questo link potete trovare le Community e relative azioni utilizzate da NTT America (AS 2914).
Per illustrare meglio il funzionamento, mi farò aiutare da un semplice esempio, in cui utilizzerò delle Large Community. Consideriamo lo scenario della figura seguente, in cui un Cliente dual-homed a due router dello stesso AS 12345, voglia gestire il traffico inbound secondo propri desiderata, senza però che il suo Upstream ISP 12345 debba personalizzargli le configurazioni.
Supponiamo che l’Upstream ISP AS 12345 adotti la seguente politica di assegnazione del Local Preference:
- Se un annuncio eBGP ricevuto contiene il valore di Community = 12345:9:150, allora assegna all’annuncio il valore Local Preference = 150.
- Altrimenti, assegna il valore di Local Preference di default (= 100).
- Tutto il traffico verso il prefisso 100.24.0.0/24 deve entrare nell’AS 65501, attraverso il router CE1.
- Tutto il traffico verso il prefisso 100.25.0.0/24 deve entrare nell’AS 65501, attraverso il router CE2.
- Sulla sessione eBGP tra CE1 e PE1, il prefisso 100.24.0.0/24 venga annunciato con Large Community = 12345:9:150, e il prefisso 100.25.0.0/24 non abbia la Large Community = 12345:9:150.
- Viceversa, sulla sessione eBGP tra CE2 e PE2, il prefisso 100.25.0.0/24 venga annunciato con Large Community = 12345:9:150, e il prefisso 100.24.0.0/24 non abbia la Large Community = 12345:9:150.
Configurazione del router CE1 (Juniper):
[edit policy-options]
tt@CE1# show
policy-statement SET-COMM-LP {
from {
route-filter 100.24.0.0/24 exact;
}
then {
community add COMM-LP;
}
}
community COMM-LP members large:12345:9:150;
}
[edit protocols bgp group EBGP]
tt@CE1# show
type external;
export SET-COMM-LP;
neighbor 172.16.1.1 {
peer-as 12345;
}
Configurazione del router PE1 (Cisco IOS XR):
[edit protocols bgp group EBGP]
tt@CE1# show
type external;
export SET-COMM-LP;
neighbor 172.16.1.1 {
peer-as 12345;
}
Configurazione del router PE1 (Cisco IOS XR):
route-policy SET-LP
if large-community matches-any (12345:9:150) then
set local-preference 150
endif
end-policy
!
router bgp 12345
address-family ipv4 unicast
neighbor 172.16.1.2
remote-as 65001
address-family ipv4 unicast
route-policy SET-LP in
CONCLUSIONI
Le Community BGP sono uno strumento molto utilizzato dagli amministratori degli AS. Solo che la versione originale dello standard (RFC 1977) ha mostrato nel tempo alcune limitazioni che hanno richiesto un po' di "manutenzione". Recentemente è stata introdotta una novità che ha risolto in modo abbastanza semplice e per il momento definitivo il problema dell'utilizzo delle Community, soprattutto ora che si stanno diffondendo sempre di più i numeri di AS a 4 byte. La novità è stata l'introduzione delle Large Community, con le quali lo spazio disponibile per i valori di Community è stato triplicato, da 4 a 12 byte, e che amplia notevolmente l'ambito di applicazione.
Al momento le Large Community non sono supportate da tutti i vendor, nel post ho messo un link che potete consultare per gli aggiornamenti. Pertanto invito tutti gli interessati a premere sui vostri vendor preferiti affinché implementino il supporto alla RFC 8092, con la minaccia di passare alla concorrenza.
RINGRAZIAMENTI
Vorrei ringraziare il fantasmagorico e spumeggiante Job Snijders di NTT Communications (unTier-1, AS 2914) per avermi stimolato a scrivere questo post e per lo scambio di interessanti considerazioni sulle novità introdotte di recente nel BGP.
Nessun commento:
Posta un commento