Le regole dei protocolli di routing non sempre portano ad avere percorsi ottimi. Si possono fare vari esempi, sia con OSPF che con IS-IS, dove i percorsi end-to-end non sono ottimali, ferme restando le regole che questi utilizzano per determinare i percorsi ottimi. La ragione principale di questo fenomeno è la partizione in aree, oppure i meccanismi di redistribuzione nel protocollo, da domini di routing esterni.
Il BGP, benché non preveda la partizione in aree, ha però insito comunque un concetto di partizione, che come è noto è quello degli Autonomous Sysytem (AS). E per come sono concepite le regole che il BGP segue nella scelta dei percorsi ottimi, anche con il BGP si può verificare il fenomeno dei percorsi end-to-end non ottimi. Ho già in passato trattato in questo post un caso riguardante l'allocazione ottima dei Route Reflector, dove è possibile il verificarsi di percorsi end-to-end non ottimi, in funzione dell'allocazione dei Route Reflector all'interno della rete.
In questo post voglio illustrare come, con l'introduzione di un nuovo attributo BGP, sia possibile risolvere il problema quando sorgente e destinazione del traffico appartengono a due (o più) AS diversi.
IL PROBLEMA
Esistono molte situazioni di reti, che benché siano suddivise in AS diversi, ricadono nello stesso dominio amministrativo. Questo può avvenire perché ad esempio:
- Il protocollo IGP non scala e quindi vi è la necessità di partizionare il dominio di routing in sottodomini separati ed indipendenti (caso sempre più raro per la verità, poiché oggi sono in esercizio reti OSPF o IS-IS in area singola, costituite da centinaia se non migliaia di router).
- Un ISP, per ragioni storiche gestisce due o più AS diversi, vuoi perché ha acquisito un altro ISP e la sua rete non è stata ancora fusa nel proprio backbone IP o anche perché magari ha per qualche ragione due reti su cui fornisce gli stessi servizi ai suoi Clienti (un esempio lo abbiamo avuto per anni qui in Italia).
- Diverse divisioni aziendali hanno internamente una propria rete logicamente separata dalle reti di altre divisioni.
- Nei servizi L3VPN basati sul paradigma BG/MPLS, viene utilizzato il BGP come protocollo di routing CE-PE, con il CE che appartiene (come buona regola) a un AS diverso da quello del provider.
- . . .
L'esempio della figura seguente illustra il problema di fondo.
La figura rappresenta due AS, interconnessi tra loro tramite due coppie di ASBR (Autonomous System Boundary Router). Tra queste due coppie sono stabilite due classiche sessioni eBGP. Su entrambe le sessioni eBGP, i due ASBR dell'AS 2 annunciano ai due ASBR dell'AS 1 il prefisso IP "NET X". La raggiungibilità interna tra i router di un AS e gli ASBR dello stesso AS è garantita da un protocollo IGP (OSPF o IS-IS non fa differenza).
La figura riporta anche i costi IGP "ottimi" (minimi) tra un generico router di un AS e gli ASBR. Ad esempio, i costi IGP minimi tra il router R1 dell'AS 1 e gli ASBR dello stesso AS 1, ossia ASBR-11 e ASBR-12, sono rispettivamente 20 e 40. Allo stesso modo, i costi IGP minimi tra gli ASBR dell'AS 2, ossia ASBR-21 e ASBR-22, e il router R2 dell'AS 2 sono rispettivamente 30 e 20.
L'obiettivo è fare in modo che il traffico originato dal router R1 e diretto verso un Host del prefisso IP "NET X", segua il percorso a minimo costo, ossia:
R1-->ASBR-11-->ASBR-21-->R2-->"NET X".
La prima soluzione che viene in mente è l'utilizzo dell'attributo MED (Multi Exit Discriminator), che assomiglia nel suo funzionamento a una metrica IGP. Ma il MED, come mostrerò nel prossimo paragrafo, non funziona !
UTILIZZO DELL'ATTRIBUTO MED
Prima di vedere come può essere utilizzato il MED nel nostro problema, un breve riassunto delle sue proprietà. Il MED è un attributo Optional Non Transitive che specifica una metrica, utilizzabile per assegnare un grado di preferenza ad un annuncio BGP. La lunghezza del valore di MED è 4 byte.
Il suo utilizzo tipico si ha nella definizione di politiche di routing inbound, per forzare il punto di ingresso del traffico da un AS. È una metrica debole, nel senso che viene considerata, nel processo di selezione BGP, dopo altre metriche come Local Preference, lunghezza dell'AS_PATH e Origin.
Il valore di MED viene assegnato, su base configurazione, da BGP speaker che inviano annunci eBGP. Una volta assegnato il valore, il MED viene propagato solo all’interno dell’AS che riceve l’annuncio, e viene tolto se l’annuncio viene propagato ad altri AS (a meno che non si ridefinisca attraverso delle policy outbound). Quando un AS riceve un annuncio senza attributo MED, automaticamente, secondo quanto definito nella RFC 4271, assegna comunque un valore di MED = 0.
Il valore di MED contenuto negli annunci ricevuti, consente a tutti i router di un AS di scegliere un comune punto di uscita per il traffico destinato verso l’AS che ha inviato gli annunci. La regola di scelta è la seguente: tra tutti gli annunci provenienti dallo stesso AS, viene preferito quello che ha valore associato di MED più basso (ovviamente a parità delle metriche "più forti" nel processo di selezione BGP). Si noti che di default non è possibile la comparazione del MED di annunci provenienti da AS diversi.
Bene, vediamo ora come il MED potrebbe essere utilizzato nel nostro esempio. Per rappresentare all'AS 1 la "distanza IGP" tra gli ASBR e il router R2, supponiamo che l'ASBR-21 annunci il prefisso "NET X" con MED associato pari a 30, ossia, pari alla distanza IGP tra ASBR-21 e R2. E lo stesso faccia l'ASBR-22, come mostrato nella figura seguente.
Ora, per le regole dell'attributo MED ricordate sopra, il MED non varia all'interno dell'AS 1, e quindi R1 riceverà due annunci del prefisso "NET X", uno dall'ASBR-11 con MED = 30, e uno dall'ASBR-12 con MED = 20. Seguendo la regola della scelta del percorso ottimo basata sul MED (a parità quindi di tutte le altre metriche "più forti" nel processo di selezione BGP), R1 sceglierà come BGP Next-Hop ottimo l'ASBR-12, ossia l'ASBR sbagliato !
Si vede subito che il problema nasce dal fatto che il MED non viene aggiornato con le metriche IGP all'interno dall'AS 1, per cui l'unico modo che ha R1 per determinare il percorso ottimo è quello di fare affidamento sul valore di MED più piccolo.
Il problema è ben noto e in altri protocolli di routing è stato brillantemente risolto. Il BGP fino a poco tempo fa non aveva alcuno strumento per la soluzione di questo problema. Fino a che non è stato introdotto il nuovo attributo AIGP ...
La figura riporta anche i costi IGP "ottimi" (minimi) tra un generico router di un AS e gli ASBR. Ad esempio, i costi IGP minimi tra il router R1 dell'AS 1 e gli ASBR dello stesso AS 1, ossia ASBR-11 e ASBR-12, sono rispettivamente 20 e 40. Allo stesso modo, i costi IGP minimi tra gli ASBR dell'AS 2, ossia ASBR-21 e ASBR-22, e il router R2 dell'AS 2 sono rispettivamente 30 e 20.
L'obiettivo è fare in modo che il traffico originato dal router R1 e diretto verso un Host del prefisso IP "NET X", segua il percorso a minimo costo, ossia:
R1-->ASBR-11-->ASBR-21-->R2-->"NET X".
La prima soluzione che viene in mente è l'utilizzo dell'attributo MED (Multi Exit Discriminator), che assomiglia nel suo funzionamento a una metrica IGP. Ma il MED, come mostrerò nel prossimo paragrafo, non funziona !
UTILIZZO DELL'ATTRIBUTO MED
Prima di vedere come può essere utilizzato il MED nel nostro problema, un breve riassunto delle sue proprietà. Il MED è un attributo Optional Non Transitive che specifica una metrica, utilizzabile per assegnare un grado di preferenza ad un annuncio BGP. La lunghezza del valore di MED è 4 byte.
Il suo utilizzo tipico si ha nella definizione di politiche di routing inbound, per forzare il punto di ingresso del traffico da un AS. È una metrica debole, nel senso che viene considerata, nel processo di selezione BGP, dopo altre metriche come Local Preference, lunghezza dell'AS_PATH e Origin.
Il valore di MED viene assegnato, su base configurazione, da BGP speaker che inviano annunci eBGP. Una volta assegnato il valore, il MED viene propagato solo all’interno dell’AS che riceve l’annuncio, e viene tolto se l’annuncio viene propagato ad altri AS (a meno che non si ridefinisca attraverso delle policy outbound). Quando un AS riceve un annuncio senza attributo MED, automaticamente, secondo quanto definito nella RFC 4271, assegna comunque un valore di MED = 0.
Il valore di MED contenuto negli annunci ricevuti, consente a tutti i router di un AS di scegliere un comune punto di uscita per il traffico destinato verso l’AS che ha inviato gli annunci. La regola di scelta è la seguente: tra tutti gli annunci provenienti dallo stesso AS, viene preferito quello che ha valore associato di MED più basso (ovviamente a parità delle metriche "più forti" nel processo di selezione BGP). Si noti che di default non è possibile la comparazione del MED di annunci provenienti da AS diversi.
Bene, vediamo ora come il MED potrebbe essere utilizzato nel nostro esempio. Per rappresentare all'AS 1 la "distanza IGP" tra gli ASBR e il router R2, supponiamo che l'ASBR-21 annunci il prefisso "NET X" con MED associato pari a 30, ossia, pari alla distanza IGP tra ASBR-21 e R2. E lo stesso faccia l'ASBR-22, come mostrato nella figura seguente.
Ora, per le regole dell'attributo MED ricordate sopra, il MED non varia all'interno dell'AS 1, e quindi R1 riceverà due annunci del prefisso "NET X", uno dall'ASBR-11 con MED = 30, e uno dall'ASBR-12 con MED = 20. Seguendo la regola della scelta del percorso ottimo basata sul MED (a parità quindi di tutte le altre metriche "più forti" nel processo di selezione BGP), R1 sceglierà come BGP Next-Hop ottimo l'ASBR-12, ossia l'ASBR sbagliato !
Si vede subito che il problema nasce dal fatto che il MED non viene aggiornato con le metriche IGP all'interno dall'AS 1, per cui l'unico modo che ha R1 per determinare il percorso ottimo è quello di fare affidamento sul valore di MED più piccolo.
Il problema è ben noto e in altri protocolli di routing è stato brillantemente risolto. Il BGP fino a poco tempo fa non aveva alcuno strumento per la soluzione di questo problema. Fino a che non è stato introdotto il nuovo attributo AIGP ...
L'ATTRIBUTO AIGP
Per risolvere il problema esposto nelle due sezioni precedenti, è stato introdotto nella RFC 7311 - The Accumulated IGP Metric Attribute for BGP, dell'Agosto 2014, un nuovo attributo BGP, denominato Accumulated IGP Metric (AIGP), il cui scopo è tenere memoria delle metriche IGP, quando gli annunci vengono propagati all'interno di un AS.
Al pari dell'attributo MED, l'attributo AIGP è di tipo Optional Non Transitive e specifica una metrica, però in questo caso "cumulata". Cosa significhi questo è bene spiegarlo riprendendo il nostro esempio. L'idea di fondo è semplice, l'attributo ad ogni suo passaggio tiene conto del costo totale dal BGP speaker che riceve l'annuncio al BGP Next-Hop.
Ad esempio, supponiamo di aver abilitato l'utilizzo dell'AIGP in tutti i BGP speaker della nostra rete esempio (in una sezione successiva vedremo come si fa). Inoltre, supponiamo che vi siano sessioni iBGP dirette tra i router R1 e R2 e i rispettivi ASBR, ipotizzando per entrambi gli AS l'utilizzo di MPLS (che rende inutile la presenza del BGP nei router interni). Ora, R2 annuncia il prefisso "NET X" ai propri ASBR-21 e ASBR-22 con attributo AIGP = 0, perché "NET X" è direttamente connesso a R2 (NOTA: se il prefisso "NET X" fosse stato appreso da un protocollo di routing IGP e redistribuito nel BGP, avrebbe avuto AIGP = MED = costo totale presente nella Tabella di Routing IP).
I due ASBR che ricevono questo annuncio, ossia ASBR-21 e ASBR-22, propagheranno automaticamente (ricordate però la RFC 8212 trattata in questo post !) ai rispettivi ASBR dell'AS 1 l'annuncio, rispettivamente con attributo AIGP = 30 (= costo IGP tra ASBR-21 e BGP Next Hop R2) e AIGP = 20 (= costo IGP tra ASBR-22 e BGP Next Hop R2). Ora, il router R1, che riceverà i due annunci, aggiungerà al valore di costo contenuto nell'attributo AIGP, il proprio costo IGP verso il rispettivo BGP Next Hop (= 20 per ASBR-11 e = 40 per ASBR-12). Il valore totale di AIGP determinato da R1 risulta a questo punto:
A questo punto il gioco è fatto, se il router R1 dovesse scegliere sulla base del valore dell'attributo AIGP, a parità di tutte le metriche "più forti" nel processo di selezione BGP, sceglierebbe come percorso ottimo quello a minimo costo, ossia:
R1-->ASBR-11-->ASBR-21-->R2
che è il percorso ottimo desiderato.
Manca solo un piccolo, ma non trascurabile dettaglio: nel processo di selezione BGP classico l'attributo AIGP non è contemplato. E quindi ? E quindi è ora di un po' "poesia" (= teoria), poi passeremo alla "prosa" (= pratica).
UN PO' DI TEORIA ...
Dopo aver visto il funzionamento dell'attributo AIGP e come questo viene aggiornato, vediamo tre aspetti teorici:
Ogni attributo BGP è identificato dal campo Attribute Type, che nel caso dell'attributo AIGP è 26. Il campo Attribute Value, nel caso dell'attributo AIGP, è costituito da una serie di moduli TLV (Type-Length-Value). La RFC 7311 definisce un solo modulo TLV, definito da Type = 1, Length = 11 (byte), Value = valore dell'attributo AIGP (8 byte). La lunghezza di 8 byte deriva dal fatto che molte metriche IGP hanno lunghezza 4 byte, e con 8 byte è possibile sommarne un numero più che sufficiente per gli scopi pratici.
Per i più curiosi, questo è il formato completo dell'attributo AIGP:
E questa è invece la cattura di un messaggio BGP UPDATE con l'attributo AIGP:
Passiamo ora al secondo aspetto, ossia, come viene valutato il valore di AIGP nel processo di selezione BGP ? Per essere utile, dovrebbe essere una metrica abbastanza forte, non certamente debole come il MED. La RFC 7311 stabilisce che il valore di AIGP venga valutato immediatamente dopo il Local Preference (che rimane quindi la metrica più forte), ma prima della lunghezza dell'AS_PATH. E come per il MED, vince il valore più piccolo.
In conclusione, il processo di selezione standard viene così modificato:
Il valore iniziale dell'attributo AIGP viene di solito definito tramite una routing policy, ed è di solito posto al valore del costo IGP già presente nella Tabella di Routing IP (come accade ad esempio per il MED).
L'aggiornamento dell'attributo AIGP può essere effettuato solo da router che hanno abilitato il suo supporto. Questo implica che la configurazione del supporto dell'attributo AIGP va fatta su tutti i BGP speaker, altrimenti essendo l'attributo di tipo Non Transitive, un BGP speaker non abilitato al supporto toglie l'attributo nel propagare gli annunci ricevuti.
Bene, è l'ora di passare dalla poesia alla prosa ...
UN PO' DI PRATICA ...
Per vedere un po' più da vicino il funzionamento dell'attributo AIGP faremo riferimento alla seguente rete, costituita da router Cisco che supportano l'IOS XR.
La rete è composta dai due AS 65001 e 65002, che ricadono sotto un unico dominio amministrativo. I numeri associati ai vari link rappresentano le metriche IGP. Sul router PE2-1, oltre all'interfaccia Loopback0, il cui indirizzo IP è utilizzato per le sessioni iBGP, è configurata una interfaccia di Loopback10 il cui indirizzo IP è 2.2.2.2/32, e che viene utilizzata come rete test. Su tutti i router è abilitato il protocollo LDP, ad esclusione (ovviamente !) dei due link che connettono gli ASBR (nella figura indicati per brevità con BR-xy). Si noti che sui router P1 e P2 non è abilitato il protocollo BGP.
Come si può notare da una rapida occhiata alla figura, il percorso ottimo da PE1-1 verso il prefisso 2.2.2.2/32 è (NOTA: le metriche dei link di interconnessione tra gli ASBR non vengono considerate):
PE2-1-->P1-->BR-11-->BR-21-->BR-22-->PE2-1
Vediamo dapprima la configurazione che consente di originare, sul router PE2-1, l'attributo AIGP (NOTA: sono mostrate le sole configurazioni di interesse):
route-policy SET-AIGP
set aigp-metric igp-cost
end-policy
!
router bgp 65002
address-family ipv4 unicast
network 2.2.2.2/32 route-policy SET-AIGP
!
neighbor-group ASBR
remote-as 65002
update-source Loopback0
address-family ipv4 unicast
aigp
next-hop-self
!
neighbor 192.168.1.5
use neighbor-group ASBR
description "SESSIONE VERSO BR-21"
!
neighbor 192.168.1.6
use neighbor-group ASBR
description "SESSIONE VERSO BR-22"
!
!
Con questa configurazione, il router PE2-1 invia ai due BGP peer BR-21 e BR-22, l'annuncio del prefisso 2.2.2.2/32 con l'attributo AIGP con un valore pari al valore di costo del prefisso 2.2.2.2/32 nella tabella di Routing IP. Poiché 2.2.2.2/32 è una rete direttamente connessa, questo valore è pari a 0:
RP/0/0/CPU0:PE2-1# show bgp ipv4 unicast 2.2.2.2/32
Wed Jun 20 17:12:37.424 UTC
BGP routing table entry for 2.2.2.2/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 7 7
Last Modified: Jun 20 15:12:00.516 for 02:00:37
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.2
Local
0.0.0.0 from 0.0.0.0 (192.168.0.21)
Origin IGP, metric 0, localpref 100, weight 32768, aigp metric 0, valid, local, best, group-best
Received Path ID 0, Local Path ID 0, version 7
Total AIGP metric 0
Nella route policy, è possibile definire manualmente un valore diverso, basta mettere il valore desiderato in luogo di "igp-cost".
Su tutti gli altri BGP speaker della rete (tutti i router ad esclusione di P1 e P2) è sufficiente abilitare il supporto dell'attributo AIGP con il comando:
router bgp X
address-family ipv4 unicast
!
neighbor x.y.z.w
...
address-family ipv4 unicast
aigp
Vediamo ad esempio sul router BR-21 il valore assunto dall'attributo AIGP:
RP/0/0/CPU0:BR-21# show bgp ipv4 unicast 2.2.2.2/32
Wed Jun 20 17:20:39.072 UTC
BGP routing table entry for 2.2.2.2/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 8 8
Last Modified: Jun 20 15:12:01.137 for 02:08:38
Paths: (1 available, best #1)
Advertised to peers (in unique update groups):
172.16.35.3
Path #1: Received by speaker 0
Advertised to peers (in unique update groups):
172.16.35.3
Local
192.168.0.21 (metric 7) from 192.168.0.21 (192.168.0.21)
Origin IGP, metric 0, localpref 100, aigp metric 0, valid, internal, best, group-best
Received Path ID 0, Local Path ID 0, version 8
Total AIGP metric 7
Il valore indicato come "aigp metric 0" indica il valore dell'attributo AIGP ricevuto, mentre il valore indicato come "Total AIGP metric 7" indica il valore cumulato dell'attributo AIGP, risultante dalla somma:
Valore dell'attributo AIGP ricevuto (= 0) + costo totale IGP verso il BGP Next-Hop (= 7).
Infine, vediamo il valore assunto dall'attributo AIGP sul router PE1-1:
RP/0/0/CPU0:PE1-1# show bgp ipv4 unicast 2.2.2.2/32
Wed Jun 20 17:28:58.758 UTC
BGP routing table entry for 2.2.2.2/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 8 8
Last Modified: Jun 20 15:12:12.337 for 02:16:46
Paths: (2 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65002
192.168.1.3 (metric 3) from 192.168.1.3 (192.168.1.3)
Origin IGP, metric 7, localpref 100, aigp metric 7, valid, internal, best, group-best
Received Path ID 0, Local Path ID 0, version 8
Total AIGP metric 10
Path #2: Received by speaker 0
Not advertised to any peer
65002
192.168.1.4 (metric 13) from 192.168.1.4 (192.168.1.4)
Origin IGP, metric 6, localpref 100, aigp metric 6, valid, internal
Received Path ID 0, Local Path ID 0, version 0
Total AIGP metric 19
A questo punto dovreste aver capito tutto il meccanismo di aggiornamento dell'attributo AIGP, e quindi per verificare la correttezza dei valori di AIGP dovrete cavarvela da soli. Volevo solo farvi notare che PE1-1 sceglie come best path l'annuncio che ha BGP Next-Hop 192.168.1.3, che è l'indirizzo IP dell'interfaccia Loopback 0 di BR-11 utilizzata come estremo della sessione iBGP tra PE1-1 e BR-11 (fidatevi !). E quindi in conclusione il traffico IP dal router PE1-1 verso il prefisso IP 2.2.2.2/32 segue il percorso desiderato. Per una ulteriore prova, cosa c'è meglio di un traceroute ?
RP/0/0/CPU0:PE1-1# traceroute 2.2.2.2
Wed Jun 20 17:45:45.449 UTC
Type escape sequence to abort.
Tracing the route to 2.2.2.2
1 10.1.11.1 [MPLS: Label 24001 Exp 0] 19 msec 59 msec 0 msec
2 172.16.13.3 0 msec 0 msec 19 msec
3 172.16.35.5 9 msec 0 msec 0 msec
4 172.16.56.6 [MPLS: Label 24000 Exp 0] 19 msec 19 msec 9 msec
5 10.2.22.2 19 msec * 9 msec
Gli indirizzi IP nel risultato del traceroute sono quelli delle seguenti interfacce (anche qui, fidatevi !):
10.1.11.1 --> interfaccia Gi0/0/0/3 di P1
172.16.13.3 --> interfaccia Gi0/0/0/1 di BR-11
172.16.35.5 --> interfaccia Gi0/0/0/2 di BR-21
172.16.56.6 --> interfaccia Gi0/0/0/0 di BR-22
10.2.22.2 --> interfaccia Gi0/0/0/1 di PE2-1
E comunque, per chi non si fida, a questo link potete scaricare tutte le configurazioni dei router della rete esempio, così potrete replicare il Case Study.
NOTA: questo Case Study può essere replicato facilmente anche in ambiente Juniper, le configurazioni seguono la stessa logica. Per chi di voi fosse interessato ai comandi Junos per l'implementazione del supporto AIGP, rimando alla documentazione ufficiale sul sito Juniper.
E INFINE, UNA DOMANDA DA UN MILIONE DI EURO ...
A questo punto del post, voglio porvi una domanda da un milione di Euro: A cosa vi assomiglia l'utilizzo dell'attributo AIGP nel BGP ? Se avete pensato alla modalità di redistribuzione di un famoso protocollo di routing IGP, meritate un premio (purtroppo per voi non dispongo del milione di euro !). Altrimenti, per svelare l'arcano vi invito a leggere l'Appendice dopo le Conclusioni ...
CONCLUSIONI
Questo post mi è stato ispirato da una caso reale che mi sono trovato di fronte durante una delle mie consulenze. Il problema era legato all'utilizzo di OSPF come protocollo di routing CE-PE in un servizio L3VPN BGP/MPLS. In realtà funzionava tutto secondo i desiderata di routing dell'amministratore della rete, però a me non piaceva (e in generale non piace) l'idea di utilizzare OSPF come protocollo di routing CE-PE, perché questo comporta necessariamente delle redistribuzioni (in entrambi i sensi) che a volte sono complesse da gestire. Ma OSPF si prestava molto bene per risolvere i loro desiderata di routing. E così ho proposto l'utilizzo del BGP corredato dal nuovo attributo AIGP, che ha consentito di semplificare le configurazioni e al contempo di lasciare inalterato il routing desiderato.
L'attributo AIGP può essere utilizzato in casi particolari, soprattutto quando diversi AS ricadono al di sotto dello stesso dominio amministrativo. Non va utilizzato quindi in un ambiente inter-provider. Per il resto è semplice da capire e semplice da configurare.
APPENDICE: REDISTRIBUZIONE E1/E2 IN OSPF
Nel protocollo OSPF, la determinazione del percorso verso prefissi esterni al dominio OSPF, può essere considerato alla stessa stregua della determinazione dei percorsi intra-area e inter-area, con la differenza fondamentale che la destinazione del percorso è sempre l’ASBR che ha redistribuito all’interno del dominio OSPF il prefisso esterno.
Come accade per ogni tipo di redistribuzione, a ciascun prefisso esterno redistribuito viene associato un costo esterno (seed metric). Nell'implementazione Cisco di OSPF ad esempio, questo valore è di default sempre pari a 20, ad eccezione della redistribuzione del BGP in OSPF, dove la seed metric assume il valore 1. Il valore di costo esterno può comunque essere modificato arbitrariamente su base configurazione.
OSPF prevede due tipi di percorsi, verso prefissi esterni al dominio OSPF, differenziati dal calcolo del costo totale:
Il cammino ottimo da R3 verso il prefisso esterno "NET X", redistribuito nel dominio OSPF dai due router ASBR-1 e ASBR-2, che hanno entrambi le funzioni di ASBR, è il seguente:
Ritornando a noi, l'analogia è:
Al pari dell'attributo MED, l'attributo AIGP è di tipo Optional Non Transitive e specifica una metrica, però in questo caso "cumulata". Cosa significhi questo è bene spiegarlo riprendendo il nostro esempio. L'idea di fondo è semplice, l'attributo ad ogni suo passaggio tiene conto del costo totale dal BGP speaker che riceve l'annuncio al BGP Next-Hop.
Ad esempio, supponiamo di aver abilitato l'utilizzo dell'AIGP in tutti i BGP speaker della nostra rete esempio (in una sezione successiva vedremo come si fa). Inoltre, supponiamo che vi siano sessioni iBGP dirette tra i router R1 e R2 e i rispettivi ASBR, ipotizzando per entrambi gli AS l'utilizzo di MPLS (che rende inutile la presenza del BGP nei router interni). Ora, R2 annuncia il prefisso "NET X" ai propri ASBR-21 e ASBR-22 con attributo AIGP = 0, perché "NET X" è direttamente connesso a R2 (NOTA: se il prefisso "NET X" fosse stato appreso da un protocollo di routing IGP e redistribuito nel BGP, avrebbe avuto AIGP = MED = costo totale presente nella Tabella di Routing IP).
I due ASBR che ricevono questo annuncio, ossia ASBR-21 e ASBR-22, propagheranno automaticamente (ricordate però la RFC 8212 trattata in questo post !) ai rispettivi ASBR dell'AS 1 l'annuncio, rispettivamente con attributo AIGP = 30 (= costo IGP tra ASBR-21 e BGP Next Hop R2) e AIGP = 20 (= costo IGP tra ASBR-22 e BGP Next Hop R2). Ora, il router R1, che riceverà i due annunci, aggiungerà al valore di costo contenuto nell'attributo AIGP, il proprio costo IGP verso il rispettivo BGP Next Hop (= 20 per ASBR-11 e = 40 per ASBR-12). Il valore totale di AIGP determinato da R1 risulta a questo punto:
- 30 + 20 = 50 per il BGP Next Hop ASBR-11
- 20 + 40 = 60 per il BGP Next Hop ASBR-12
R1-->ASBR-11-->ASBR-21-->R2
che è il percorso ottimo desiderato.
Manca solo un piccolo, ma non trascurabile dettaglio: nel processo di selezione BGP classico l'attributo AIGP non è contemplato. E quindi ? E quindi è ora di un po' "poesia" (= teoria), poi passeremo alla "prosa" (= pratica).
UN PO' DI TEORIA ...
Dopo aver visto il funzionamento dell'attributo AIGP e come questo viene aggiornato, vediamo tre aspetti teorici:
- Il formato dell'attributo.
- Il suo ruolo nel processo di selezione BGP.
- La creazione e la modifica dell'attributo AIGP.
Ogni attributo BGP è identificato dal campo Attribute Type, che nel caso dell'attributo AIGP è 26. Il campo Attribute Value, nel caso dell'attributo AIGP, è costituito da una serie di moduli TLV (Type-Length-Value). La RFC 7311 definisce un solo modulo TLV, definito da Type = 1, Length = 11 (byte), Value = valore dell'attributo AIGP (8 byte). La lunghezza di 8 byte deriva dal fatto che molte metriche IGP hanno lunghezza 4 byte, e con 8 byte è possibile sommarne un numero più che sufficiente per gli scopi pratici.
Per i più curiosi, questo è il formato completo dell'attributo AIGP:
E questa è invece la cattura di un messaggio BGP UPDATE con l'attributo AIGP:
In conclusione, il processo di selezione standard viene così modificato:
- Scegliere l'annuncio con il valore di Local Preference più elevato.
- Scegliere l'annuncio con il valore di AIGP più basso.
- Scegliere l'annuncio con AS_PATH più breve.
- ... < resto del processo di selezione identico > ...
- L'annuncio deriva dalla redistribuzione in BGP di route statiche che hanno un Next Hop che non punta al di fuori dell'insieme di AS appartenenti allo stesso dominio amministrativo.
- L'annuncio deriva dalla redistribuzione in BGP di un qualsiasi protocollo IGP (incluse le reti direttamente connesse).
- L'annuncio è appreso da una sessione iBGP e ha l'atttributo AS_PATH vuoto.
- L'annuncio è appreso da una sessione eBGP e ha l'attributo AS_PATH contenete solo AS appartenenti allo stesso dominio amministrativo del BGP speaker ricevente l'annuncio.
Il valore iniziale dell'attributo AIGP viene di solito definito tramite una routing policy, ed è di solito posto al valore del costo IGP già presente nella Tabella di Routing IP (come accade ad esempio per il MED).
L'aggiornamento dell'attributo AIGP può essere effettuato solo da router che hanno abilitato il suo supporto. Questo implica che la configurazione del supporto dell'attributo AIGP va fatta su tutti i BGP speaker, altrimenti essendo l'attributo di tipo Non Transitive, un BGP speaker non abilitato al supporto toglie l'attributo nel propagare gli annunci ricevuti.
Bene, è l'ora di passare dalla poesia alla prosa ...
UN PO' DI PRATICA ...
Per vedere un po' più da vicino il funzionamento dell'attributo AIGP faremo riferimento alla seguente rete, costituita da router Cisco che supportano l'IOS XR.
La rete è composta dai due AS 65001 e 65002, che ricadono sotto un unico dominio amministrativo. I numeri associati ai vari link rappresentano le metriche IGP. Sul router PE2-1, oltre all'interfaccia Loopback0, il cui indirizzo IP è utilizzato per le sessioni iBGP, è configurata una interfaccia di Loopback10 il cui indirizzo IP è 2.2.2.2/32, e che viene utilizzata come rete test. Su tutti i router è abilitato il protocollo LDP, ad esclusione (ovviamente !) dei due link che connettono gli ASBR (nella figura indicati per brevità con BR-xy). Si noti che sui router P1 e P2 non è abilitato il protocollo BGP.
Come si può notare da una rapida occhiata alla figura, il percorso ottimo da PE1-1 verso il prefisso 2.2.2.2/32 è (NOTA: le metriche dei link di interconnessione tra gli ASBR non vengono considerate):
PE2-1-->P1-->BR-11-->BR-21-->BR-22-->PE2-1
Vediamo dapprima la configurazione che consente di originare, sul router PE2-1, l'attributo AIGP (NOTA: sono mostrate le sole configurazioni di interesse):
route-policy SET-AIGP
set aigp-metric igp-cost
end-policy
!
router bgp 65002
address-family ipv4 unicast
network 2.2.2.2/32 route-policy SET-AIGP
!
neighbor-group ASBR
remote-as 65002
update-source Loopback0
address-family ipv4 unicast
aigp
next-hop-self
!
neighbor 192.168.1.5
use neighbor-group ASBR
description "SESSIONE VERSO BR-21"
!
neighbor 192.168.1.6
use neighbor-group ASBR
description "SESSIONE VERSO BR-22"
!
!
Con questa configurazione, il router PE2-1 invia ai due BGP peer BR-21 e BR-22, l'annuncio del prefisso 2.2.2.2/32 con l'attributo AIGP con un valore pari al valore di costo del prefisso 2.2.2.2/32 nella tabella di Routing IP. Poiché 2.2.2.2/32 è una rete direttamente connessa, questo valore è pari a 0:
RP/0/0/CPU0:PE2-1# show bgp ipv4 unicast 2.2.2.2/32
Wed Jun 20 17:12:37.424 UTC
BGP routing table entry for 2.2.2.2/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 7 7
Last Modified: Jun 20 15:12:00.516 for 02:00:37
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.2
Local
0.0.0.0 from 0.0.0.0 (192.168.0.21)
Origin IGP, metric 0, localpref 100, weight 32768, aigp metric 0, valid, local, best, group-best
Received Path ID 0, Local Path ID 0, version 7
Total AIGP metric 0
Nella route policy, è possibile definire manualmente un valore diverso, basta mettere il valore desiderato in luogo di "igp-cost".
Su tutti gli altri BGP speaker della rete (tutti i router ad esclusione di P1 e P2) è sufficiente abilitare il supporto dell'attributo AIGP con il comando:
router bgp X
address-family ipv4 unicast
!
neighbor x.y.z.w
...
address-family ipv4 unicast
aigp
Vediamo ad esempio sul router BR-21 il valore assunto dall'attributo AIGP:
RP/0/0/CPU0:BR-21# show bgp ipv4 unicast 2.2.2.2/32
Wed Jun 20 17:20:39.072 UTC
BGP routing table entry for 2.2.2.2/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 8 8
Last Modified: Jun 20 15:12:01.137 for 02:08:38
Paths: (1 available, best #1)
Advertised to peers (in unique update groups):
172.16.35.3
Path #1: Received by speaker 0
Advertised to peers (in unique update groups):
172.16.35.3
Local
192.168.0.21 (metric 7) from 192.168.0.21 (192.168.0.21)
Origin IGP, metric 0, localpref 100, aigp metric 0, valid, internal, best, group-best
Received Path ID 0, Local Path ID 0, version 8
Total AIGP metric 7
Il valore indicato come "aigp metric 0" indica il valore dell'attributo AIGP ricevuto, mentre il valore indicato come "Total AIGP metric 7" indica il valore cumulato dell'attributo AIGP, risultante dalla somma:
Valore dell'attributo AIGP ricevuto (= 0) + costo totale IGP verso il BGP Next-Hop (= 7).
Infine, vediamo il valore assunto dall'attributo AIGP sul router PE1-1:
RP/0/0/CPU0:PE1-1# show bgp ipv4 unicast 2.2.2.2/32
Wed Jun 20 17:28:58.758 UTC
BGP routing table entry for 2.2.2.2/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 8 8
Last Modified: Jun 20 15:12:12.337 for 02:16:46
Paths: (2 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65002
192.168.1.3 (metric 3) from 192.168.1.3 (192.168.1.3)
Origin IGP, metric 7, localpref 100, aigp metric 7, valid, internal, best, group-best
Received Path ID 0, Local Path ID 0, version 8
Total AIGP metric 10
Path #2: Received by speaker 0
Not advertised to any peer
65002
192.168.1.4 (metric 13) from 192.168.1.4 (192.168.1.4)
Origin IGP, metric 6, localpref 100, aigp metric 6, valid, internal
Received Path ID 0, Local Path ID 0, version 0
Total AIGP metric 19
A questo punto dovreste aver capito tutto il meccanismo di aggiornamento dell'attributo AIGP, e quindi per verificare la correttezza dei valori di AIGP dovrete cavarvela da soli. Volevo solo farvi notare che PE1-1 sceglie come best path l'annuncio che ha BGP Next-Hop 192.168.1.3, che è l'indirizzo IP dell'interfaccia Loopback 0 di BR-11 utilizzata come estremo della sessione iBGP tra PE1-1 e BR-11 (fidatevi !). E quindi in conclusione il traffico IP dal router PE1-1 verso il prefisso IP 2.2.2.2/32 segue il percorso desiderato. Per una ulteriore prova, cosa c'è meglio di un traceroute ?
RP/0/0/CPU0:PE1-1# traceroute 2.2.2.2
Wed Jun 20 17:45:45.449 UTC
Type escape sequence to abort.
Tracing the route to 2.2.2.2
1 10.1.11.1 [MPLS: Label 24001 Exp 0] 19 msec 59 msec 0 msec
2 172.16.13.3 0 msec 0 msec 19 msec
3 172.16.35.5 9 msec 0 msec 0 msec
4 172.16.56.6 [MPLS: Label 24000 Exp 0] 19 msec 19 msec 9 msec
5 10.2.22.2 19 msec * 9 msec
Gli indirizzi IP nel risultato del traceroute sono quelli delle seguenti interfacce (anche qui, fidatevi !):
10.1.11.1 --> interfaccia Gi0/0/0/3 di P1
172.16.13.3 --> interfaccia Gi0/0/0/1 di BR-11
172.16.35.5 --> interfaccia Gi0/0/0/2 di BR-21
172.16.56.6 --> interfaccia Gi0/0/0/0 di BR-22
10.2.22.2 --> interfaccia Gi0/0/0/1 di PE2-1
E comunque, per chi non si fida, a questo link potete scaricare tutte le configurazioni dei router della rete esempio, così potrete replicare il Case Study.
NOTA: questo Case Study può essere replicato facilmente anche in ambiente Juniper, le configurazioni seguono la stessa logica. Per chi di voi fosse interessato ai comandi Junos per l'implementazione del supporto AIGP, rimando alla documentazione ufficiale sul sito Juniper.
E INFINE, UNA DOMANDA DA UN MILIONE DI EURO ...
A questo punto del post, voglio porvi una domanda da un milione di Euro: A cosa vi assomiglia l'utilizzo dell'attributo AIGP nel BGP ? Se avete pensato alla modalità di redistribuzione di un famoso protocollo di routing IGP, meritate un premio (purtroppo per voi non dispongo del milione di euro !). Altrimenti, per svelare l'arcano vi invito a leggere l'Appendice dopo le Conclusioni ...
CONCLUSIONI
Questo post mi è stato ispirato da una caso reale che mi sono trovato di fronte durante una delle mie consulenze. Il problema era legato all'utilizzo di OSPF come protocollo di routing CE-PE in un servizio L3VPN BGP/MPLS. In realtà funzionava tutto secondo i desiderata di routing dell'amministratore della rete, però a me non piaceva (e in generale non piace) l'idea di utilizzare OSPF come protocollo di routing CE-PE, perché questo comporta necessariamente delle redistribuzioni (in entrambi i sensi) che a volte sono complesse da gestire. Ma OSPF si prestava molto bene per risolvere i loro desiderata di routing. E così ho proposto l'utilizzo del BGP corredato dal nuovo attributo AIGP, che ha consentito di semplificare le configurazioni e al contempo di lasciare inalterato il routing desiderato.
L'attributo AIGP può essere utilizzato in casi particolari, soprattutto quando diversi AS ricadono al di sotto dello stesso dominio amministrativo. Non va utilizzato quindi in un ambiente inter-provider. Per il resto è semplice da capire e semplice da configurare.
APPENDICE: REDISTRIBUZIONE E1/E2 IN OSPF
Nel protocollo OSPF, la determinazione del percorso verso prefissi esterni al dominio OSPF, può essere considerato alla stessa stregua della determinazione dei percorsi intra-area e inter-area, con la differenza fondamentale che la destinazione del percorso è sempre l’ASBR che ha redistribuito all’interno del dominio OSPF il prefisso esterno.
Come accade per ogni tipo di redistribuzione, a ciascun prefisso esterno redistribuito viene associato un costo esterno (seed metric). Nell'implementazione Cisco di OSPF ad esempio, questo valore è di default sempre pari a 20, ad eccezione della redistribuzione del BGP in OSPF, dove la seed metric assume il valore 1. Il valore di costo esterno può comunque essere modificato arbitrariamente su base configurazione.
OSPF prevede due tipi di percorsi, verso prefissi esterni al dominio OSPF, differenziati dal calcolo del costo totale:
- External di tipo 1 (E1) : il costo totale è la somma del costo esterno e del costo OSPF verso l’ASBR che annuncia il prefisso esterno.
- External di tipo 2 (E2) : il costo totale è dato dal solo costo esterno.
Il cammino ottimo da R3 verso il prefisso esterno "NET X", redistribuito nel dominio OSPF dai due router ASBR-1 e ASBR-2, che hanno entrambi le funzioni di ASBR, è il seguente:
- Nel caso di percorso di tipo E1 : costo via ASBR-1 = 10 + 1 = 11; costo via ASBR-2 = 8 + 2 = 10. Il percorso ottimo è quindi via ASBR-2. Il costo è la composizione del costo (interno) tra R3 e ASBR e del costo esterno.
- Nel caso di percorso di tipo E2 : costo via ASBR-1 = 1; costo via ASBR-2 = 2. Il percorso ottimo è quindi via ASBR-1. Il costo è in questo caso costituito dal solo costo esterno.
Ritornando a noi, l'analogia è:
- Utilizzo del solo MED, equivalente alla redistribuzione di tipo E2.
- Utilizzo dell'attributo AIGP, equivalente alla redistribuzione di tipo E1.
Sempre un piacere leggerti
RispondiElimina