Gianrico Fichera

BGP

Se stai utilizzando Firefox per vedere tutte le immagini usa IETAB

La necessita' per il BGP

Articolo beta 0.9 -revisione 16/3/03
                                 revisione 25/6/07
                                 revisione e aggiunte Dicembre 2008
                                 revisione e aggiunte Giugno 2009
                                aggiunte Agosto 2009
                                aggiunte e modifiche Febbraio 2011

L'allocazione degli indirizzi della rete Internet mondiale e' responsabilita' di cinque enti, chiamati RIR (Regional Internet Registry): RIPE, l'ARIN, APNIC, il LACNIC e l'AFRINIC. Il RIPE si occupa di Europa e Africa del Nord, l'ARIN dell'America del Nord, l'APNIC dell'Asia e del Pacifico, il LACNIC dell'America Latina, l'AFRINIC per l'Africa.

Chiunque utilizzi un indirizzo ip pubblico riconosciuto dalla rete Internet mondiale, e quindi routabile, lo ha ottenuto direttamente dal RIR che rappresenta la sua regione o da un ente, chiamato LIR (normalmente un ISP), che a sua volta lo ha ottenuto da un RIR.

I RIR assegnano gli indirizzi Internet a chiunque ne chieda in numero "sufficiente" a fronte di un canone annuale. I RIR normalmente assegnano indirizzi con almeno una mask di /21. Queste sono 8 classi C. Prima di poter ottenere le classi si dovra' dimostrare di avere effettivamente bisogno di un tale numero di indirizzi IP indicandone l'utilizzo. Il motivo di cio' e' dovuto al fatto che la risorsa "indirizzo IP" e' limitata e anzi di fronte ad un prossimo esaurimento delle risorse IPV4 i RIR adottano regole sempre piu' restrittive, invitando il passaggio a IPV6. L'assegnazione diretta di indirizzi IP dal RIPE si puo' ottenere dopo essere diventati LIR (https://www.ripe.net/membership/new-members/registration.html). Dopo l'iscrizione vi arrivera' comunicazione dal RIPE. Si dovra' effettuare il pagamento di quanto dovuto e si diventa LIR. Ogni LIR e' associato a un RIR. Il nome LIR deriva dal fatto che si diventa responsabile locale dell'assegnazione di risorse IP. Per i costi vedi anche questo link: http://www.ripe.net/membership/new-members/index.html

Normalmente dai piccoli utenti fino all'enterprise difficilmente si contatta direttamente il RIPE (in Europa). Piuttosto bisogna contattare un ISP in grado di assegnarci le classi (l'elenco e' qui: http://www.ripe.net/membership/indices/index.html ). Infatti chi ci assegna gli indirizzi IP e' normalmente il nostro fornitore di banda Internet, che dovra' comunque comunicare al RIPE l'intestatario degli stessi, a meno che non si tratti semplicemente di un singolo o di una coppia di indirizzi. Basta avere un ADSL con 8 indirizzi IP assegnati per figurare nel database del RIPE e quindi essere anche facilmente identificabili a partire dagli indirizzi ip in uso.

Normalmente avere in uso degli indirizzi assegnati dal nostro provider invece che direttamente dal RIPE non e' un problema, anzi la maggior parte degli utenti non ne e' neppure consapevole. Questo pero' implica una dipendenza dal nostro provider, che puo' diventare fastidiosa se si utilizzano gli indirizzi IP assegnati per fornire servizi Internet.
Pertanto, nel momento in cui si e' fornitori di servizi Internet, ad esempio dando anche semplicemente visibilita' di un singolo sito Web, da un certo punto in poi la questione che si puo' porre e' se restare dipendenti dal proprio provider Internet o meno. Cambiare fornitore infatti vorrebbe dire perdere i propri indirizzi IP e cambiarli con altri, assegnati dal nuovo provider. Se abbiamo parecchie macchine che forniscono servizi all'esterno, magari con certificati digitali o server DNS, un'indipendenza dal fornitore di connettivita' puo' essere preferibile. Cio' si puo' ottenere richiedendo gli indirizzi IP direttamente al RIPE, quando possibile, in quanto si ricade nelle problematiche di cui sopra, o piu' semplicemente richiedendo al proprio fornitore una classe di indirizzi IP indipendente (vedi sotto).

La tanto agognata indipendenza puo' essere fondamentale anche in contesti in cui vi sono requisiti di ridondanza e affidabilita' che trovano l'anello piu' debole della catena proprio nell'avere un unico provider fornitore di banda Internet. In questi casi cio' che va fatto e' dividere la banda tra due differenti fornitori, soluzione sicuramente piu' costosa, ma in grado di consentire alti livelli di up-time e, come vedremo, l'indipendenza dal singolo provider anche per gli indirizzi IP. Infatti per gestire una situazione del genere, chiamata di multihoming, si dovrebbero avere necessariamente degli indirizzi IP propri, e non di proprieta' di uno dei due provider in quanto, in tal caso, i pacchetti in ingresso giungerebbero sicuramente da un link solo, consentendo un bilanciamento del traffico solo in uscita.

In casi di multihoming come questo, e' necessario ottenere degli IP propri, che per l'Europa chiederemo al RIPE. Si puo' anche richiedere al RIPE solo l'autonomous system (AS), nel caso in cui il fornitore di connettivita' ci assegni delle classi indipendenti.

Ma cosa vuol dire essere Autonomous System (AS)? Il RIPE non assegna solo indirizzi IP ma fornisce anche il numero AS. Gli AS suddividono la Internet mondiale in aree, ognuna delle quali e' sotto una comune amministrazione. Il numero di AS non e' un concetto astratto e burocratico ma piuttosto un valore numerico che i router stessi utilizzano quando si scambiamo le informazioni di routing tramite il protocollo BGP. Il numero di AS inizialmente era a 16bit. Adesso si utilizzano AS a 32 bits. Ogni LIR al RIPE deve avere un numero di AS.

Chi possiede un AS puo' annunciare ai router degli AS vicini i propri indirizzi assegnati dal RIPE. Questi si propagheranno nella Internet mondiale se i router degli AS vicini lo permettono. Il protocollo di routing che agisce tra gli AS e consente la propagazione delle route a livello mondiale e' il BGP (Border Gateway Protocol).

Multihoming e classi indipendenti

Un ISP e' un LIR, ovvero e' un membro del RIPE con la responsabilita' di gestire un numero significativo di indirizzi IP, almeno una /21. Possono essere LIR anche soggetti diversi dagli ISP purche' abbiamo una necessita' di indirizzi IP pubblici sufficientemente grande (superiore alla singola classe C) o quanto meno riescono a dimostrarlo. Il LIR paga un canone annuo al RIPE avra' un AS assegnato e puo' utilizzare personalmente o assegnare a terzi i propri indirizzi IP.

RIPE assegna al LIR un address space di tipo "provider aggregable" ovvero PA.

Le classi di tipo PA consento al LIR di fare sub-addressing e assegnare indirizzi IP ai suoi clienti in modalita' "provider aggregable" (PA). Un LIR puo' far ottenere ai suoi clienti anche classi di tipo "provider indipendent" (PI).

Le classi si chiamano PA perche' il LIR e' libero di aggregarle nei suoi annunci BGP verso gli upstream provider. Se il cliente cambia provider perdera' le sue classi. Ovvero il cliente deve avere come upstream provider il LIR per poter utilizzare le sue classi.

Se il cliente ha esigenze particolari, ad esempio vuole un numero di IP superiore a quelli normalmente assegnati (che sono ad esempio 4,8,16 o 32 ip), vuole una sua autonomia amministrativa nell'uso degli indirizzi IP, vuole un AS o vuole un multihoming con BGP. Se il cliente non deve assegnare gli IP a terzi puo richiedere classi IP. Altrimenti puo' diventare lui stesso LIR.

Le classi PI possono essere assegnate da un LIR ad un utente finale sponsorizzandolo.

In questo caso il LIR richiedera' le risorse al RIPE per conto del cliente. Le classi PI assegnate non faranno parte dello spazio PA assegnato al LIR dal RIPE. Il cliente avra' un contratto siglato con il LIR e diventera' un "Direct Assignment User". In questo caso il cliente deve siglare con il LIR un contratto di tipo "Independent Assignment Request and Maintenance Agreement" e deve pagare una quota al LIR e non al RIPE. Il vantaggio per il cliente e' che deve pagare il LIR con il quale puo' trattare per un prezzo normalmente inferiore a quello che si paga direttamente al RIPE. Se il LIR e' un'azienda che termina la sua attivita' il cliente puo' chiedere di mantenere le sue classi con un nuovo LIR oppure di passare al rapporto diretto con il RIPE.

Un utente puo' chiedere un rapporto diretto con il RIPE creando un "Direct Assignment User Account". In questo caso pero' puo' utilizzare gli indirizzi IP richiesti solo per la propria infrastruttura e non per servizi a terzi (ad esempio housing, dial-up per suoi clienti). Gli IP assegnati dal RIPE saranno sempre di tipo PI e l'utente dovra' pagare un canone annuale al RIPE. In questo caso il cliente ha un contatto diretto con il RIPE e sigla con esso il documento " End User Assignment Agreement".

Se un utente ha classi PA non puo' richiedere un numero di AS. In ogni caso con classi PI il cliente non puo' cedere indirizzi IP a terzi.

Un utente PI richiedera' un suo numero di AS in parallelo alla richiesta delle classi PI.

Il protocollo BGP

I vari protocolli di routing descritti nei vari documenti di questo sito web, quali RIP, IGRP, EIGRP, OSPF, sono in grado di gestire reti di dimensione da piccola a media, se vogliamo medio/grande, come nel caso di OSPF. Ma una caratteristica comune a tutti questi protocolli e' che sono pensati per funzionare all'interno di un'unica amministrazione. Sostanzialmente sono pensati per essere gestiti da una stessa organizzazione (basta pensare al comportamento delle distribute-list in OSPF). Ad esempio un router di una rete OSPF, se mal configurato, puo' creare problemi alla rete intera. Ogni router OSPF contiene nella sua tabella informazioni topologiche su tutti i router della sua area. Ma la rete Internet mondiale e' tutt'altra cosa. Due router possono appartenere a due amministrazioni differenti ed essere gestiti da persone di enti differenti. Non attiverei mai l'OSPF del mio ISP all'interno dei router dei clienti, a meno che essi non siano privi della possibilita' di amministrarli. Se c'e' necessita' di amministrazione configurerei la macchina del cliente con delle route statiche, oppure, usando il BGP se il cliente ha un proprio numero di AS.

BGP interviene ai confini del nostro AS, scambiando le informazioni di routing con gli altri AS. Con BGP vi e' la possibilita' di definire chiaramente cosa annunciare ai router degli AS vicini e cosa accettare da loro. Una buona configurazione BGP rifiuta dagli AS vicini cio' che gli AS vicini non sono amministrativamente tenuti ad annunciare. Ma ecco un esempio:

All'interno dell'AS numero 65512 vi e' un'organizzazione unica, che ad esempio puo' essere un ISP, oppure una enterprise. All'interno dell'organizzazione vi sara' una rete con decine di router, con protocollo EIGRP, o OSPF ad esempio. Ma a noi interessano le relazioni di routing tra questa organizzazione e le altre, che potrebbero essere altri ISP. Cosi' se AS65512 e' un provider nazionale allora AS65513, AS65522 e AS65533 potrebbero essere i tre provider che gli forniscono la banda internazionale. Oppure AS65533 e' una enterprise che prende banda Internet dai due provider nazionali AS65512 e AS65513. Poi il provider AS65512 prende la sua banda internazionale da AS65513. AS65522 non ha banda internazionale diretta ma la compra da AS65512.

BGP consente l'interfacciamento tra queste diverse entita' in modo sicuro ed efficiente. Ecco come:

estesa possibilita' di controllo su quali route annunciare ai vicini e cosa accettare dai vicini; agli altri AS arrivano solo le route prescelte e dagli AS vicini si accettano solo le route volute;
algoritmo di scelta della route migliore pensato per gestire le macroregioni dell'Internet mondiale; non si usano delay, bandwidth, MTU, reliability, hop count. Si utilizzano l'AS-PATH (numero di AS per raggiungere una destinazione), il peso, l'eta' delle route, la provenienza della route;

Tra due router con BGP sono possibili due tipi di sessioni: I-BGP, E-BGP. Il primo, internal BGP, si ha quando i due router appartengono allo stesso AS, come A ed F in figura. Il secondo, external BGP, e' tra AS differenti, come A e B, o A e C in figura.

Nel caso di I-BGP vale la seguente importante regola:

Le route provenienti da un link IBGP vengono propagate solo attraverso links EBGP

La figura mostra sicuramente meglio il concetto:

Il router B riceve la tabella dal router A ma non la propaga al router C. Il router D riceve la tabella dal router E e la propaga al router C. Il router C non la propaga al router B. Se il nostro scopo e' di avere entrambe le tabelle di routing su B e C in modo da poter scegliere il percorso migliore allora e' necessario creare le sessioni BGP formando una topologia FULL-MESH: dobbiamo aggiungere delle sessioni BGP tra A e C e tra D e B.

Esempio di configurazione

router bgp 65300 OPPURE NEL CASO DI AS a 32BIT: router bgp 3.143 (196751=3*65536+143)	In questo caso il RIPE ha assegnato al nostro provider il numero di AS 65300\ Nota per gli AS a 32bit: In questo caso l'AS va inserito in notazione dotted. Si calcola come nell'esempio qui accanto, dove l'AS e' il 196751. Non tutte le versioni di IOS supportano gli AS a 32bit. Ecco cosa appare nel caso di supporto presente: gianrico(config)#router bgp ? <1-65535> Autonomous system number <1.0-XX.YY> 4 Octets Autonomous system number Ad esempio nei router 28XX il supporto e' dalla versione 124-24.T Attenzione che un router che non supporta gli AS a 32bit vede questi con il numero "23456" che figura nell'AS path invece del valore reale a 32bit.
no synchronization	Un BGP router con la synchronization abilitata non annuncera' le route acquisite tramite iBGP se non le puo' validare in IGP. Se nella vostra configurazione BGP il router non annuncia nulla probabilmente avete bisogno di "no synchronization"
network 82.85.14.0	Questa e' la rete che ci e' stata assegnata dal RIPE e che il router deve annunciare al mondo tramite i neighbor definiti nelle righe successive. Affinche' l'annuncio parta correttamente questa classe dev'essere nella tabella di route. Conviene inserire la riga "ip route 82.85.14.0 255.255.255.0 null0" nella configurazione.
neighbor 217.223.243.9 remote-as 65400	217.223.243.9 e' un vicino. Si tratta del router dell'ISP da cui prendiamo banda Internet normalmente. Questo IP deve essere indicato dall'ISP. In questo esempio il nostro ISP 'BOBNETWORKS' ha as 65400
neighbor 217.223.243.9 description -- PROVIDER BOBNETWORKS --	Un semplice commento
neighbor 217.223.243.9 ebgp-multihop 255	Permette sessioni bgp con router non direttamente connessi. Se ad esempio le nostre sessioni BGP terminano su un router che non e' quello direttamente connesso al provider senza questo comando la sessione BGP potrebbe non andare nello stato di UP. In altri casi anche se siamo direttamente connessi e' il provider che ci indica di inserire questo comando a causa della strutturazione della sua rete.
neighbor 217.223.243.9 update-source Loopback0	Il router di 'BOBNETWORKS', con ip 217.223.143.9, deve inviare al nostro la sua tabella di routing. Cosi' a 'BOBNETWORKS' dobbiamo indicare in quale ip inviare questi dati.Questo si comunica ai sistemisti di BOBNETWORKS, normalmente tramite l'email di attivazione del servizio. Se c'e' un peering diretto con BOBNETWORKS allora gli si puo' chiedere di terminare la sessione BGP sull'IP del punto-punto, ovvero su un IP della rete di BOBNETWORKS, oppure su un IP da inserire in una interfaccia di Loopback o differente. Conviene indicare l'ip di una interfaccia di Loopback. Cosi', in questa riga, indichiamo che gli aggiornamenti dal router vicino provengono attraverso la Loopback0. L'indirizzo ip di terminazione di una sessione BGP con una rete esterna e' bene che sia di compenza amministrativa della rete esterna. Usare un proprio IP ripe in alcuni casi puo' creare dei problemi, ad esempio in configurazioni multihoming (il router dell'operatore A potrebbe cercare di raggiungere il router B per via diversa dal collegamento punto-punto)
neighbor 217.223.243.9 route-map filtricubeIN in	Non tutta la tabella di routing inviata da 'BOBNETWORKS' dev'essere presa in considerazione. Alcune route vanno scartate, probabilmente perche' vogliamo che si esca attraverso un altro ISP fornitore di banda per queste destinazioni. Nel nostro caso 216.133.69.2 definito sotto.
neighbor 217.223.243.9 route-map localonly out	Qui si decide cosa annunciare attraverso 'BOBNETWORKS'. Di tutti gli IP che il RIPE ci ha assegnato normalmente vogliamo che una parte venga annunciata verso 'BOBNETWORKS' e un'altra verso il secondo fornitore di banda, che chiamiamo 'JOHNSNET'

neighbor 216.133.69.2 description --- PROVIDER JOHNSNET ---
neighbor 216.133.69.2 remote-as 65500	Ecco 'JOHNSNET'. Questo e' il nostro secondo fornitore di banda Internet. Ha numero di AS 65500. Le righe successive riflettono per 'JOHNSNET' le considerazioni di sopra.

neighbor 216.133.69.2 ebgp-multihop 255
neighbor 216.133.69.2 route-map filtriPROVIDERA in
neighbor 216.133.69.2 route-map localonly out
FINE CONFIGURAZIONE BGP INIZIO FILTRI
ip as-path access-list 4 permit .*
ip as-path access-list 6 deny _1299_
ip as-path access-list 6 permit .*	.* fa matching con tutto. Si usa come "permit any" al termine di una serie di route-map. Infatti queste, come le access-list, hanno un deny any di default alla fine.

route-map filtricubeIN permit 10
match as-path 5	Si controlla l'as-path per ogni riga di routing che proviene dal vicino. Se c'e' un matching con l'espressione regolare 5, che vediamo piu' sopra in colore arancio, allora gli si associa un peso di 200 (tutte le altre avranno peso 0, che e' il default). Le route con peso piu' alto sono le preferite. Il nostro obiettivo qui e' di uscire con "BOBNETWORKS" quando le destinazioni passano per gli AS 1267, 3257 e 12876
set weight 200	Accetta solo gli as-path provenienti dagli AS 1267,3257,12876 che sono a monte del nostro neighbor che ha AS 65400. In questo modo scarichiamo una parte della tabella BGP.
ip as-path access-list 5 permit _65400 1267_
ip as-path access-list 5 permit _65400 3257_
ip as-path access-list 5 permit _65400 12876_
route-map filtricubeIN permit 20
match as-path 4
route-map filtriPROVIDERA permit 10	Da JOHNSNET si accetta una parte della tabella BGP. Quindi verra' scelto per i pacchetti di uscita quando la destinazione passa per 3269, 3257, 12874 secondo le espressioni regolari di cui sopra. JOHNSNET e' anche di default ma stiamo esplicitando le destinazioni principali in questa configurazione.
match as-path 11
set weight 200
ip as-path access-list 11 permit _65500 3269_
ip as-path access-list 11 permit _65500 3257_
ip as-path access-list 11 permit _65500 12874_
route-map filtriPROVIDERA permit 20
match as-path 4
route-map altopeso permit 10
set weight 200
route-map pesoPROVIDERA permit 10	Dando peso 20 a tutto cio' che proviene da JOHNSNET, in accordo con quanto visto nella sezione arancione concludiamo che di default si esce con JOHNSNET perche' il peso e' piu' basso.
set weight 20	Vedi anche la sezione in arancio
route-map localonly permit 10
match as-path 10
ip as-path access-list 10 permit ^$	^$ vuol dire "originate da questo AS". In caso contrario in una configurazione MULTIHOMING si rischia di annunciare in una sessione BGP l'intera tabella di routing proveniente da una seconda sessione.

ip route 217.223.243.9 255.255.255.255 NEXTHOP	L'ip del bgp peer dev'essere indicato esplicitamente, per evitare possibili router loop
ip route 216.133.69.2 255.255.255.255 NEXTHOP	L'ip del bgp peer dev'essere indicato esplicitamente, per evitare possibili router loop
ip route 82.85.14.0 255.255.255.0 null0	Le classi da annunciare devono essere in tabella di routing (la classe C qui e' solo un esempio)

Annunciare solo le route originate da questo AS

!
neighbor 192.168.30.1 filter-list 61 out
!
ip as-path access-list 61 permit ^$
!

Numeri di AS dei principali operatori (aggiornato 5 Gennaio 2010)

Eutelia	AS15589
Tiscali Italia	AS8612
Tiscali International Network	AS3257
Deutsche Telekom AG	AS3320
Wind	AS1267
Fastweb	AS12874

Community

Le community sono delle sequenze numeriche che si possono agganciare a delle route. Sostanzialmente sono delle informazioni aggiuntive che si possono 'attaccare' come etichette a delle route. Con parole semplici l'utilita' sta nel fatto che se possiamo agganciare delle sequenze numeriche a delle route possiamo inviare ai router BGP delle informazioni aggiuntive che possono utilizzare, ad esempio, per differenziale le route per provenienza.

In questo esempio vediamo una route proveniente da un provider che non ha associato delle community (o che ha filtrato) e un provider che le invia. Ci sono numerose community associate alla riga di route d'esempio, e ognuna di esse e' una indicazione della provenienza della route (Le X sono delle cifre cancellate appositamente).

gianrico#sh ip bgp 8.2.120.0
BGP routing table entry for 8.2.120.0/24, version 468729
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x8C0
Not advertised to any peer
XXXX 1299 3549 4436 20473, (received & used)
XX.94.58.17 from XX.94.58.17 (192.168.2.10)
Origin IGP, localpref 100, valid, external
XXXX 3257 20473
192.168.54.2 from 192.168.54.2 (192.168.54.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 83034277 83034312 213454752 213458844 213500754 213501852 213501853 4294967044

Per propagare le community ad un router con cui facciamo peering e' necessario usare il comando:

neighbor XX.XX.XX.XX send-community both

he community attribute is a transitive, optional attribute in the range of 0 to 4,294,967,200. The community attribute is a way to group destinations in a certain community and apply routing decisions according to those communities.

Load-balancing

Con il comando "maximum-path" si puo' fare in modo che BGP tenga piu' route verso le destinazioni attive. Di default vengono scartate tutte tranne una.
Se si attiva il load-balancing questo poi segue la configurazione del router (cef, route-cache etc.). Il load-balancing ha senso nel caso di multihoming.

Fact #1: Load-balancing is always unidirectional

CEF can use three load distribution methods:

Per-host load-balancing, where the algorithm selects the outgoing path based on the combination of the source and destination IP address.

Per-port load balancing, where even distinct layer-4 (TCP or UDP) sessions between the same pair of hosts can flow over different paths.

Per-packet load balancing, where each successive packet is sent onto a different outbound path.

Per-packet load balancing can easily result in out-of-order packets that significantly reduce TCP session throughput or result in loss of data in some UDP-based protocols, for example SNA or NetBIOS Fast Sequenced Transport (FST) or Voice-over-IP (VoIP) transport. Even worse, out-of-order packets might be interpreted as attacks by some firewalls.

RULE

Avoid per-packet load balancing at all cost.

Last but not least, sometimes you should replace IP-based load balancing with layer-2 mechanisms, for example link bundling with multilink PPP (for serial links) or EtherChannel (for Ethernet-based point-to-point links).

Local-preference

Il parametro local-preference di default e' 100. Il valore e' da 0 to 4294967295. Il valore e' inviato solo ai router con lo stesso AS. I valori piu' bassi hanno priorita' inferiore di quelli piu' alti.
Internal BGP sessions use a metric called the local preference, which is carried in internal BGP update packets in the path attribute LOCAL_PREF. This metric indicates the degree of preference for an external route. The route with the highest local preference value is preferred.

The LOCAL_PREF path attribute is always advertised to internal BGP peers and to neighboring confederations. It is never advertised to external BGP peers

ESEMPIO DI FILTRI IN INGRESSO

1. Nell'esempio che segue, che possiamo considerare applicato alle route BGP in input, il traffico che fa match con la community-list 98 avra' una local-preference di 70 ovvero inferiore a quello di default. Pertanto avra' priorita' inferiore. Avra' conseguenze sul traffico in uscita verso queste destinazioni.

neighbor 192.168.30.100 route-map PROVIDER1_IN in

route-map PROVIDER1_IN permit 15
description --- PROVIDER2 ---
match community 98
set local-preference 70
!
ip community-list 98 permit 23034302

2. Nell'esempio che segue, che possiamo considerare applicato alle route BGP in input, viene assegnata una priorita' locale solo ad alcune classi che cadono in una access-list che avranno priorita' inferiore. Avra' conseguenze sul traffico in uscita verso queste destinazioni.

route-map PROVIDER1_IN permit 20
match ip address 3
set local-preference 70
!
route-map PROVIDER1_IN permit 30
!

La seconda route-map vuota e' un permit any per le righe restanti. Altrimenti in tabella BGP resteranno SOLO quelle che fanno match con l'access-list 3 !!! Se non si mette nulla e' come se ci fosse un "route-map PROVIDER1_IN deny 30"

3. Nell'esempio che segue rifiutiamo in ingresso dalla sessione BGP con PROVIDER1 classi <= /7 (ovvero raggruppamenti di piu' classi A) o >= /25 (ovvero sottoclassi di classi C)

route-map PROVIDER1_IN deny 5
match ip address prefix-list DENY_from_PROVIDER1
!
ip prefix-list DENY_from_PROVIDER1 seq 5 permit 0.0.0.0/0 le 7
ip prefix-list DENY_from_PROVIDER1 seq 10 permit 0.0.0.0/0 ge 25

4. Nell'esempio che segue abbiamo sempre una sessione BGP con PROVIDER1 che ci fornisce connettivita'. Vogliamo dare una priorita' piu' alta in uscita (250) solo verso reti all'interno dell'AS di PROVIDER (che in questo esempio e' il numero 65000), dando priorita' inferiore a tutte le altre. Questo e' abbastanza ovvio perche' in ogni caso il percorso piu' breve per raggiungere le reti di PROVIDER1 e attraverso la connettivita' che ci fornisce. Si ricordi che si presume che il valore di default di local-preference sia 100.

route-map PROVIDER1_IN permit 5
description --- E' il solo AS di Provider1 ---
match as-path 26
set local-preference 250
!
ip as-path access-list 26 permit ^65000$

route-map PROVIDER_IN permit 10
description --- Tutte le altre classi hanno priorita' inferiore ---
match as-path 25
set local-preference 80
!
ip as-path access-list 25 permit ^65000_

5. match con tutti i path che iniziano con 1267 e hanno almeno 3 AS aggiuntivi

L'espressione regolare si evince dal seguente comando "show ip bgp regexp ^1267_[0-9]+_[0-9]+_[0-9]+_"

Annuncio delle classi alla rete BGP

1. Supponiamo di avere un peering con ISP1 e di voler annunciare le nostre classi, assegnate dal RIPE (o da altro LIR). Possiamo ovviamente decidere di annunciare una parte o tutte le classi che utilizziamo. L'annuncio e' fondamentale in quanto il routing di ritorno dalla rete Internet e' possibile solo dopo l'annuncio.
In questo esempio, annunciamo al neighbor 192.94.219.197, le classi 111.246.61.0/24 e 49.38.72.0/21.

Nota: SE AVETE UNA CONFIGURAZIONE MULTIHOMING SENZA FILTRI IN USCITA LE ROUTE IN ARRIVO DA UN FORNITORE VERRANNO ANNUNCIATE SUGLI ALTRI!!! E' BENE CREARE UNA ROUTE-MAP CHE SPECIFICHI ESATTAMENTE COSA ANNUNCIARE (ad es. "neighbor ... route-map 63 out", se non e' presente la route-map equivale ad un deny any negli annunci)

router bgp 64000
neighbor 192.94.219.197 route-map ANNUNCIO_OUT out
...

route-map ANNUNCIO_OUT permit 10
match ip address prefix-list MIOANNUNCIO_OUT

ip prefix-list MIOANNUNCIO_OUT seq 5 permit 111.246.61.0/24
ip prefix-list MIOANNUNCIO_OUT seq 6 permit 49.38.72.0/21

Potete verificare la corretta applicazione della regola come segue:

GIA7600#show ip bgp neighbors 192.94.219.197 advertised-routes
BGP table version is 77073666, local router ID is 192.168.30.30
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network                Next Hop    Metric LocPrf     Weight    Path
*> 49.38.72.0/21   0.0.0.0                 0                32768       i
*> 111.246.61.0    0.0.0.0                 0                32768       i

CASO NEXT-HOP ERRATO:

catalystsec#show ip bgp nei A.B.C.D adv
BGP table version is 1238, local router ID is A1.B1.C1.D1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.31.72.0/21    10.11.12.13              0         32768 i
*> 192.242.61.0     10.11.12.13              0         32768 i

Allora il router ricevente scartera' gli annunci in quanto il next-hop (un ip privato) e' irraggiungibile.
Per sistemare il next-hop fare in modo che le reti annuniciate abbiamo una riga di routing con "null0" come next-hop
creando eventuali sottoreti con next-hop differente se necessario.

2. Annuncio delle classi con peso alterato (as-path prepending)

route-map ASPREPEND permit 10
 set as-path prepend 24994 24994 24994   <-- OCCHIO NON SI VEDE CON show ip bgp nei 2222 adverti.Devi vedere looking
!

Con una semplice espressione regolare possiamo verificare che le route-map vengano applicate correttamente:

7600#show ip bgp regexp ^65000$
BGP table version is 20202742, local router ID is 192.168.61.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop         Metric   LocPrf     Weight       Path
*> 62.94.0.0/18 62.94.209.197             250        0            65000 i
*> 62.94.0.0/16 62.94.209.197             250        0            65000 i
*> 62.94.64.0/18 62.94.209.197             250        0            65000 i
...

7600#show ip bgp regexp ^65000_
BGP table version is 20202893, local router ID is 192.168.61.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

Network         Next Hop         Metric   LocPrf   Weight   Path
* 3.0.0.0       62.94.209.197             80       0        65000 6453 2914 9304 80 i
* 4.0.0.0/9     62.94.209.197             80       0        65000 6453 3356 i
...

Nell'esempio che segue abbiamo una sessione BGP con PROVIDER1 e una seconda con PROVIDER2.
Nostro obiettivo e' che parte del traffico Internet in uscita vada sempre verso PROVIDER2.
Le destinazioni coinvolte sono quelle con community-list 99 verso PROVIDER2 il cui peer BGP e' con 192.128.150.137.
Poiche' le righe BGP provenienti da PROVIDER1 hanno come next-hop il router di PROVIDER1, alteriamo queste righe prime di inserirle in tabella di routing, sostituendo il next-hop:

route-map PROVIDER1_IN permit 10
description --- gestisce il traffico verso ISP1 ---
match community 99
set ip next-hop 192.128.150.137
set local-preference 260
!

3. annuncio delle classi con distribute list

In the following example, an access list and a distribute list are defined to configure the BGP routing process to advertise only network 192.168.0.0. An outbound route refresh is initiated to activate the distribute-list.

If this command is configured without a predefined access list, the distribute list will default to permitting all traffic. <--- QUINDI METTERE SEMPRE UN'ACCESS-LIST

Router(config)# access-list 1 permit 192.168.0.0 0.0.255.255

Router(config)# access-list 1 deny 0.0.0.0 255.255.255.255   <--- OCCHIO A QUESTA DENY. Se non c'e' niente nell'acl di default e' permit any per distribute
Router(config)# router bgp 50000

Router(config-router)# distribute-list 1 out

Router(config-router)# end

Router# clear ip bgp out

SESSIONE IBGP tra due ROUTER

I router ITESYS1 e ITESYS2 sono collegati tra loro in back-to-back. Ognuno ha una sessione BGP con un differente ISP esterno.
Poiche' il gateway della rete e' ITESYS1, vogliamo fare il merging della tabella BGP di ITESYS1 con ITESYS2 in modo da utilizzare
contemporaneamente entrambe le connettivita', ed avere una piena ridondanza e un multihoming correttamente funzionante.

Il collegamento back-to-back tra i due router ha degli IP privati, diciamo 192.168.12.14 lato ITESYS2 e 192.168.12.13 lato ITESYS1.
Allora

ISP1 -------- ITESYS2-192.168.12.14---------------------192.168.12.13-ITESYS1--------------ISP2
LAN GW
|

quindi la parte blu e' LAN (ethernet) mentre la parte nera e' WAN (potrebbe essere ATM, fibra ottica ethernet, SDH etc.)

1. Innanzitutto decidiamo cosa deve uscire da ITESYS2 verso ISP1.
Allora diamo alle route di ITESYS2 local-preference di 1000 per le destinazioni che devono andare verso ISP1:

route-map FILTROINGRESSO1 permit 10
 description --- destinazioni accettate da ITESYS1 ---
 match as-path 28
 set local-preference 1000

2. Facciamo in modo che ITESYS1 rifiuti qualsiasi route di aggiornamento da ITESYS2 e che mandi a ITESYS2 solo le destinazioni che scegliamo:

itesys2:

neighbor 192.168.12.13 remote-as 24994
neighbor 192.168.12.13 route-map VERSOITESYS1IN in
neighbor 192.168.12.13 route-map VERSOITESYS1OUT out

route-map FILTROINGRESSO1 permit 10
 description --- queste sono le destinazioni accettate da ISP1---
 match as-path 28
 set local-preference 1000

route-map VERSOITESYS1OUT permit 10
 description --- manda verso ITESYS1 solo queste route ---
 match as-path 29
!
route-map VERSOITESYS1IN permit 10
 description --- non accetta nulla da ITESYS1 in ingresso ---
!

3. Facciamo in modo che ITESYS2 accetti gli annunci da ITESYS1 cambiando il next-hop del BGP (che di fatto diventa ITESYS2 e non piu' ISP1)

itesys1:

route-map ANNUNCIOCATSECIN permit 10
 description --- tutto cio' che arriva da ITESYS2 ha next hop 192.168.12.14 ---
 set ip next-hop 192.168.12.14
!
route-map ANNUNCIOCATSEC permit 10
 description --- non invia nulla a ITESYS2 ---
 match ip address 14
!
access-list 14 deny any
!

Si noti che in itesys1 arriveranno le route da ITESYS2 con il parametro local-preference correttamente settato a 1000. Ovvero non si perde
questo dato nella sessione IBGP.

ALTRI COMANDI UTILI

Se siete interessati ad un template BGP sicuro vedete qui:

http://www.team-cymru.org/ReadingRoom/Templates/secure-bgp-template.html

Esempio di dimensione delle tabelle BGP al Settembre 2008 e risorse necessarie

Come si vede 256mega di RAM e' il minimo (i numeri di AS sono alterati)

7600#show ip bgp summary
BGP router identifier 192.168.61.1, local AS number 65000
BGP table version is 20207182, main routing table version 20207182
262644 network entries using 26527044 bytes of memory
524421 path entries using 25172208 bytes of memory
190522 BGP path attribute entries using 11434980 bytes of memory
84326 BGP AS-PATH entries using 2348054 bytes of memory
3671 BGP community entries using 267530 bytes of memory
95291 BGP route-map cache entries using 1524656 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 67274472 total bytes of memory
BGP activity 781973/519329 prefixes, 14334964/13810543 paths, scan interval 60 secs

Neighbor        V AS     MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.158.209.197 4 65001 5227753 84087   20207096 0   0    3d23h    262020
192.148.144.100 4 65002 7332723 168211 20207100 0   0    6d12h    262399

Esempio di dimensione delle tabelle BGP al Giugno 2009 e risorse necessarie

eutelia#sh ip bgp sum
BGP router identifier 192.168.88.1, local AS number 1.111
BGP table version is 736250, main routing table version 736250
285152 network entries using 37640064 bytes of memory
567748 path entries using 29522896 bytes of memory
101764/50159 BGP path/bestpath attribute entries using 17096352 bytes of memory
90320 BGP AS-PATH entries using 3730376 bytes of memory
3888 BGP community entries using 252452 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 2 (at peak 2) using 60 bytes of memory
BGP using 88242200 total bytes of memory
BGP activity 1355377/1070188 prefixes, 1693852/1126104 paths, scan interval 60 secs

Neighbor      V AS    MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
62.94.58.17   4 15589 675005 22656   736190 0   0   3d14h    283327
192.168.120.33 4 1267 60109   57681   736190 0   0   01:12:49 284420

Debugging e comandi

1. Verifichiamo che le sessioni BGP (due in questo esempio) siano attive e funzionanti.

gw-3640-A# sh ip bgp summ
BGP router identifier 10.70.80.13, local AS number 65300
BGP table version is 6824365, main routing table version 6824365
112585 network entries and 224554 paths using 19004689 bytes of memory
40195 BGP path attribute entries using 2413080 bytes of memory
35837 BGP AS-PATH entries using 997492 bytes of memory
9 BGP community entries using 280 bytes of memory
20268 BGP route-map cache entries using 324288 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP activity 343026/5982225 prefixes, 1190775/966221 paths, scan interval 15 sec

Neighbor       V   AS     MsgRcvd MsgSent TblVer   InQ OutQ Up/Down State/PfxRcd
217.223.243.9 4   65400 849309       3765         6824365   0      0       17:21:09     112084
216.133.69.2   4   65500 541631       2893         6824351   0      0        1d15h       112469

2. Verifichiamo i dettagli dei router neighbor BGP

gw-3640-A#sh ip bgp nei
BGP neighbor is 217.223.243.9, remote AS 65400, external link
Description: -- PROVIDER1 --
BGP version 4, remote router ID 217.223.243.9
BGP state = Established, up for 17:21:12
Last read 00:00:12, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)
Address family IPv4 Unicast: advertised and received
Received 849309 messages, 0 notifications, 0 in queue
Sent 3765 messages, 2 notifications, 0 in queue
Route refresh request: received 0, sent 13
Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast
BGP table version 6824365, neighbor version 6824365
Index 1, Offset 0, Mask 0x2
Inbound path policy configured
Outbound path policy configured
Route map for incoming advertisements is filtricubeIN
Route map for outgoing advertisements is localonly
112084 accepted prefixes consume 4035024 bytes
Prefix advertised 5, suppressed 0, withdrawn 0

Connections established 5; dropped 4
Last reset 17:22:08, due to Peer closed the session
External BGP neighbor may be up to 255 hops away.
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.70.80.13, Local port: 179
Foreign host: 217.223.243.9, Foreign port: 49922
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0xD8EC8AC):
Timer Starts Wakeups Next
Retrans 1082 32 0x0
TimeWait 0 0 0x0
AckHold 13841 3337 0x0
SendWnd 0 0 0x0
KeepAlive 551 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0

iss: 2781263762 snduna: 2781283769 sndnxt: 2781283769 sndwnd: 16194
irs: 991799584 rcvnxt: 1005201028 rcvwnd: 16084 delrcvwnd: 300

SRTT: 300 ms, RTTO: 303 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 12 ms, maxRTT: 1696 ms, ACK hold: 200 ms
Flags: passive open, nagle, gen tcbs

Datagrams (max data segment is 536 bytes):
Rcvd: 32455 (out of order: 4314), with data: 31599, total data bytes: 13401443
Sent: 32969 (retransmit: 32), with data: 1049, total data bytes: 20006

BGP neighbor is 216.133.69.2, remote AS 65500, external link
Description: --- PROVIDERB ---
BGP version 4, remote router ID 216.133.69.2
BGP state = Established, up for 1d15h
Last read 00:00:24, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh: advertised and received(new)
Address family IPv4 Unicast: advertised and received
Received 541631 messages, 1 notifications, 0 in queue
Sent 2893 messages, 2 notifications, 0 in queue
Route refresh request: received 0, sent 8
Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast
BGP table version 6824365, neighbor version 6824365
Index 2, Offset 0, Mask 0x4
Inbound path policy configured
Outbound path policy configured
Route map for incoming advertisements is pesoPROVIDERA
Route map for outgoing advertisements is localonly
112469 accepted prefixes consume 4048884 bytes
Prefix advertised 5, suppressed 0, withdrawn 0

Connections established 5; dropped 4
Last reset 1d15h, due to BGP Notification sent, hold time expired
External BGP neighbor may be up to 255 hops away.
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 213.92.14.23, Local port: 11083
Foreign host: 216.133.69.2, Foreign port: 179

Enqueued packets for retransmit: 0, input: 0 mis-ordered: -225 (0 bytes)

Event Timers (current time is 0xD8ED14C):
Timer Starts Wakeups Next
Retrans 2707 301 0x0
TimeWait 0 0 0x0
AckHold 29417 8472 0xD8ED1C0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0

iss: 3173509963 snduna: 3173555775 sndnxt: 3173555775 sndwnd: 16251
irs: 1534877445 rcvnxt: 1559531265 rcvwnd: 16341 delrcvwnd: 43

SRTT: 355 ms, RTTO: 526 ms, RTV: 171 ms, KRTT: 0 ms
minRTT: 4 ms, maxRTT: 1168 ms, ACK hold: 200 ms
Flags: higher precedence, nagle

Datagrams (max data segment is 536 bytes):
Rcvd: 63450 (out of order: 8606), with data: 59865, total data bytes: 24654031
Sent: 64241 (retransmit: 301), with data: 2405, total data bytes: 45811

3. Leggiamo la tabella bgp

gw-3640-A#sh ip bgp path
Address Hash Refcount Metric Path
0x65C58938 0 1 0 65500 7176 286 517 15772 21112 i
0x638D4BC0 0 1 0 65400 1299 2914 25626 i
0x639336B4 0 1 0 65400 1299 3561 7501 2525 i
0x638B0B58 0 1 0 65400 1299 702 15814 i
0x65C553C8 0 6 0 65400 1299 1239 11183 i
0x657E519C 0 6 0 65400 1299 7018 22026 25625 i
0x6252E284 0 1 0 65500 5400 1239 9237 10030 i
0x65EF565C 0 1 0 65500 1267 20993 i
0x62DAA910 0 1 0 65500 5400 1239 21818 i
0x639996E8 0 2 0 65500 7176 1 701 4230 13353 21741 i
0x65C60AA8 0 1 0 65500 5400 7018 724 5872 2721 i
0x65C25214 0 1 0 i
0x62527920 1 3 0 65400 1299 15742 i
0x639E281C 1 2 0 65500 7176 1 701 11329 i
0x639E13EC 1 1 0 65500 7176 6461 10530 18059 18059 4832 i
0x64D26EE0 1 1 0 65500 7176 1299 15855 i
0x642AEDA0 1 2 0 65500 7176 1 3561 17173 i
0x65C5F7A8 1 2 0 65500 7176 1 9942 9942 17982 9408 i
0x62615328 1 1 0 65500 5400 209 568 721 1494 i
0x65335368 1 5 0 65500 7176 3549 1313 i
0x62E0AD30 1 1 0 65500 7176 1 10912 10912 10912 18526 i
0x65B1FF00 1 1 0 65500 7176 1 14589 i

Address Hash Refcount Metric Path
0x639D6124 2 3 0 65400 6461 14679 14679 1467
....

gw-3640-A#sh ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

B 208.221.13.0/24 [20/0] via 217.223.243.9, 06:42:59
B 206.51.253.0/24 [20/0] via 217.223.243.9, 01:51:01
B 205.204.1.0/24 [20/0] via 217.223.243.9, 06:43:10
B 204.255.51.0/24 [20/0] via 217.223.243.9, 06:43:11
B 204.238.34.0/24 [20/0] via 216.133.69.2, 06:45:04
B 204.17.221.0/24 [20/0] via 216.133.69.2, 06:45:06
B 203.238.37.0/24 [20/0] via 217.223.243.9, 06:43:16
B 203.34.233.0/24 [20/0] via 216.133.69.2, 06:45:07
B 200.68.140.0/24 [20/0] via 216.133.69.2, 06:45:10
B 198.17.215.0/24 [20/0] via 217.223.243.9, 06:43:37
B 192.68.132.0/24 [20/0] via 216.133.69.2, 06:45:19
170.170.0.0/16 is variably subnetted, 3 subnets, 3 masks
B 170.170.0.0/19 [20/0] via 217.223.243.9, 03:35:21
B 170.170.224.0/20[20/0] via 216.133.69.2, 06:45:21
B 170.170.254.0/24[20/0] via 217.223.243.9, 03:35:23
B 216.239.54.0/24 [20/0] via 216.133.69.2, 06:44:56
B 216.220.5.0/24 [20/0] via 216.133.69.2, 06:44:56
B 216.103.190.0/24[20/0] via 216.133.69.2, 06:44:57
B 213.239.59.0/24 [20/0] via 217.223.243.9, 06:42:48
B 213.152.76.0/24 [20/0] via 217.223.243.9, 03:15:30
B 212.205.24.0/24 [20/0] via 216.133.69.2, 06:44:58
B 207.254.48.0/24 [20/0] via 217.223.243.9, 06:43:04

....

gw-3640-A#sh ip bgp

BGP table version is 6667706, local router ID is 10.70.80.13
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete