Uno dei criteri di routing più noti è il famoso Hot Potato Routing. Il principio è molto semplice, ogni volta che un router di un determinato AS riceve un pacchetto IP, la cui destinazione è al di fuori del proprio AS, cerca di liberarsene quanto prima, consegnandolo all'exit point dall'AS più vicino, dove "più vicino" va inteso secondo il costo complessivo del protocollo di routing IGP utilizzato. Il perché è presto detto, per utilizzare il minimo numero di risorse interne. (NOTA: il nome curioso deriva dall'analogia "fisica" secondo la quale se uno riceve in mano una patata bollente, cerca di liberarsene il più presto possibile, onde evitare possibili ustioni (qualsiasi altra interpretazione è assolutamente vietata !)).
Si consideri ad esempio la figura seguente. Il router R1 dell'AS 1, riceve un pacchetto IP che ha destinazione un Host dell'AS 2 (o anche, un Host raggiungibile attraverso l'AS2). R1 ha due exit point verso l'AS 2, i due router R2 e R3. Il costo interno IGP R1-->R2 sia 10 e il costo interno IGP R1-->R3 sia 20. Secondo il principio dell'Hot potato routing, R1 sceglie come BGP Next-Hop il router più vicino secondo il costo totale IGP, ossia R2.
La scelta avviene attraverso uno dei passi del processo di selezione BGP, in particolare quello che tiene conto del costo interno IGP: viene selezionato come BGP Next-Hop il BGP peer più vicino secondo il costo interno IGP. Questo ovviamente, a parità di tutte precedenti metriche utilizzate nel processo di selezione, ad esempio, Local Preference, lunghezza dell'AS_PATH, Origin, ecc.).
ROUTE REFLECTOR E HOT POTATO ROUTING
La presenza di un Route Reflector (RR) crea però problemi all'Hot potato routing. Ho già trattato questo problema nel documento sulle nuove funzionalità di convergenza per il BGP, che potete scaricare a questo link.
Il problema nasce dal fatto che un RR, al pari di un qualsiasi BGP speaker, esegue il processo di selezione, il quale a un certo punto potrebbe utilizzare il punto citato sopra che riguarda il costo minimo IGP.
Per mettere in evidenza il problema, vi riporto lo stesso esempio illustrato nel documento sulle nuove funzionalità di convergenza per il BGP citato sopra. Lo scenario di riferimento è riportato nella figura seguente, dove si ipotizza che sui router PE sia attivo il BGP Next-Hop-Self.
Il router CE-12 annuncia ai router PE-1 e PE-2, via eBGP, il prefisso "NET X". I router PE-1 e PE-2 propagano l'annuncio al RR, il quale esegue il processo di selezione sui due annunci. A parità di tutti gli attributi BGP classici, il processo di selezione sceglie come best-path l'annuncio ricevuto da PE-1, perché il costo IGP verso il BGP Next-Hop PE-1, pari a 5, è inferiore al costo IGP verso il BGP Next-Hop PE-2, pari a 10. Il RR propaga a PE-3 il best-path, e nella tabella BGP di PE-3 si troverà quindi un solo annuncio del prefisso "NET X", con BGP Next-Hop PE-1. Ma come si vede dalla figura, il BGP Next-Hop più vicino a PE-3 non è PE-1, che è "distante" 20 (ossia con costo IGP da PE-3 a PE-1 pari a 20), bensì PE-2, distante 10. In sostanza, il RR scegli come best-path il suo exit point più vicino e non quello che è più vicino al punto di ingresso del traffico. Il principio dell'Hot potato routing viene così violato.
Anche in presenza di due o più RR il routing sub-ottimo è sempre in agguato (vedi ancora il documento sulle nuove funzionalità di convergenza per il BGP citato sopra).
In reti dove i RR non sono nel forwarding path, come ad esempio nel caso di utilizzo di virtual RR trattato in questo post, dove la loro localizzazione è arbitraria, il problema diventa ancora più acuto. Oltre a ciò, vi sono anche scenari in cui un ISP vuole il completo controllo sulla scelta degli exit point del traffico dei propri clienti, sulla base ad esempio di altri fattori (es. tipo di traffico, volume di traffico, ecc.).
UNA POSSIBILE SOLUZIONE : BGP ADD-PATH
In reti dove i RR non sono nel forwarding path, come ad esempio nel caso di utilizzo di virtual RR trattato in questo post, dove la loro localizzazione è arbitraria, il problema diventa ancora più acuto. Oltre a ciò, vi sono anche scenari in cui un ISP vuole il completo controllo sulla scelta degli exit point del traffico dei propri clienti, sulla base ad esempio di altri fattori (es. tipo di traffico, volume di traffico, ecc.).
UNA POSSIBILE SOLUZIONE : BGP ADD-PATH
Una soluzione al problema è utilizzare la funzionalità BGP Add-Path, ampiamente illustrata nel solito documento più volte citato. Ricordo che questa funzionalità consente di annunciare, oltre al best-path, anche uno o più best-path alternativi. L'aspetto critico del BGP Add-Path è che aumenta di molto il numero annunci BGP presenti nei RR-Client. In scenari dove la rete riceve la Full Internet Routing Table (FIRT) in molti punti, questo comporta che i vari RR-Client potrebbero ricevere molti annunci dello stesso prefisso (che moltiplicato per il numero di prefissi della FIRT, potrebbe portare a notevoli occupazioni di memoria).
Nonostante questo svantaggio, vi sono però anche molte buone ragioni per utilizzare la funzionalità BGP Add-Path, in primis la Path Diversity, che consente l'applicazione del BGP PIC (Prefix Independent Convergence), e quindi convergenza più veloce. La Path Diversity è poi un requisito fondamentale per il Load Balancing.
Il problema con l'Hot Potato Routing potrebbe però persistere. Infatti, di norma con il BGP Add-Path non vengono inviati tutti i possibili percorsi alternativi (altrimenti si potrebbero avere problemi di memoria come prima citato), ma solo un sottoinsieme. Ma chi ci garantisce che in questo sottoinsieme vi sia anche il best exit point secondo il costo IGP ?
Qualche altro fantasioso workaround potrebbe anche essere pensato, ma quello che serve in realtà è una soluziione più generale, che consenta di mettere i RR in qualsiasi punto della rete, e nel contempo mantenere il principio dell'Hot Potato Routing.
UNA SOLUZIONE PIU' GENERALE (BGP-ORR)
Una proposta di soluzione più generale a questo problema, già implementata dai principali vendor (anche se da alcuni ancora in forma sperimentale), è contenuta nel draft IETF draft-ietf-idr-bgp-optimal-route-reflection - BGP Optimal Route Reflection (BGP-ORR), il cui percorso per diventare RFC volge ormai al termine. L'idea è molto semplice e ingegnosa, virtualizzare la posizione del RR, o in altre parole, rendere la localizzazione del RR indipendente dal processo di selezione del best-path.
Vediamo come si esplicita l'idea. Come noto, il RR partecipa necessariamente al processo IGP, che, come accade nelle applicazioni pratiche, è di tipo Link-State (OSPF o IS-IS). Il RR conosce quindi la topologia totale o parziale della rete.
Supponiamo per il momento di essere in presenza, nel caso di OSPF di area singola (tipicamente l'area 0), e nel caso di IS-IS di un singolo livello (tipicamente livello 2). Con questa ipotesi il RR, partecipando al processo IGP, ha a disposizione l'intero LSDB (Link-State DataBase), e quindi è in grado di determinare i costi totali IGP tra ogni coppia di RR-Client. In particolare, è in grado di determinare una matrice dei costi, dove l'elemento <X, Y> della matrice è il costo IGP complessivo dal RR-Client X al RR-Client Y (NOTA: la diagonale della matrice non viene ovviamente utilizzata. Inoltre, come sovente accade in pratica, supporrò che la matrice sia simmetrica, ossia l'elemento <X, Y> coincida con l'elemento <Y, X>; ma questo a dire il vero non è indispensabile).
Per determinare l'elemento <X, Y> della matrice, il RR, avendo a disposizione l'intero LSDB non fa altro che determinare l'albero SPF con radice in X, ottenendo i costi ottimi verso tutti gli altri router della rete, tra cui il RR-Client Y. La figura seguente riassume il concetto.
A questo punto il gioco è fatto. Per vedere come, farò di nuovo riferimento all'esempio riportato sopra. Il RR, determina tre alberi SPF supplementari, ciascuno con radice un RR-Client (nella figura PE-1, PE-2 e PE-3). A valle di questi calcoli, il RR mantiene in memoria la seguente matrice dei costi:
Ora, nel momento in cui RR riceve da PE-1 e PE-2 gli annunci della "NET X", esegue il processo di selezione BGP. Ammesso che debba basare la sua decisione sul solo costo IGP verso il BGP Next-Hop, ossia a parità di tutte le metriche BGP dei punti precedenti il processo di selezione, il RR nella scelta del best-path non considera come costo da confrontare quello tra lui stesso e i due BGP Next-Hop PE-1 e PE-2, ma quello tra il RR-Client a cui riflette l'annuncio (nell'esempio PE-3) e i due RR-Client che hanno inviato l'annuncio (nell'esempio PE-1 e PE-2). Poiché il costo IGP minimo è quello tra PE-3 e PE-2, il RR elegge come best-path l'annuncio che ha BGP Next-Hop PE-2, e non quello con BGP Next-Hop PE-1, come farebbe di default. Il best-path viene quindi propagato a PE-3 con BGP Next-Hop PE-2, permettendo a PE-3 di seguire la logica dell'Hot Potato Routing.
Si noti che con questo modo di procedere, il best-path non è univoco, ma dipende dal RR-Client a cui viene riflesso l'annuncio. Due diversi RR-Client potrebbero ricevere due diversi best-path, in funzione della loro vicinanza a chi ha originato l'annuncio.
Nel caso in cui il dominio IGP sia partizionato in aree, potrebbe accadere che RR e RR-Client risiedano su aree diverse, e quindi il RR non conosce l'intera topologia della rete. Ma questo non cambia alcunché, basta solo adottare gli accorgimenti giusti. Supponiamo ad esempio che il protocollo IGP sia OSPF e che il RR sia nell'area 0 e i RR-Client X e Y siano rispettivamente nelle aree periferiche 10 e 20 (vedi figura seguente).
Il RR può comunque determinare il costo complessivo <X, Y> sommando il costo tra ABR-1 e Y, che conosce dal Summary Link LSA che ABR-1 invia nell'area 10 per annunciare i prefissi (inter-area) di Y (in particolare l'Host Route associata alla sua interfaccia di Loopback utilizzata per la sessione iBGP con il RR), e il costo tra X e ABR-1, che conosce dal Summary Link LSA che ABR-1 genera nell'area 0 per annunciare i prefissi (inter-area) di X.
E' bene tener presente che questa idea, "battezzata" nel draft IETF citato sopra, BGP-ORR (BGP - Optimal Route Reflection), non è alternativa al BGP Add-Path o ad altri metodi per la Path Diversity. Può essere utilizzata congiuntamente a questi per migliorare la "qualità" degli annunci multipli da propagare, inserendo tra questi sempre quello che garantisce di conservare il principio dell'Hot Potato Routing.
SUPPORTO NEI ROUTER CISCO E JUNIPER
Il BGP-ORR è supportato dal JUNOS Juniper in versioni molto recenti, ma solo quando il protocollo IGP è IS-IS. Non avendo a disposizione una versione JUNOS che lo supporta, sono costretto a darvi questo link sul sito Juniper, dove trovate i comandi necessari per l'implementazione.
Cisco invece supporta il BGP-ORR, per ora in via sperimentale, sull'ASR 9kv, un software basato sull'IOS XR Cisco, che potete utilizzare per implementare un vRR. Anche qui, non mi resta che darvi questo link, per maggiori informazioni, non avendo a disposizione il software dell'ASR 9kv.
CONCLUSIONI
Il BGP-ORR è un'idea molto semplice ed efficace, che consente di virtualizzare la posizione dei RR, rendendola indipendente dai suoi RR-Client. Questo consente di "recuperare" il principio dell'Hot Potato Routing, che altrimenti in molti casi pratici verrebbe perso. Il prezzo da pagare è un po' di lavoro in più che il RR deve svolgere, per mantenere la matrice delle distanze IGP tra i suoi RR-Client e per svolgere il processo di selezione, che diventa più pesante poiché è necessario determinare un best-path per ciascun RR-Client. Ma utilizzando dei virtual RR (vedi post precedente), che secondo i buoni principi della progettazione sono al di fuori del forwarding path, questo non dovrebbe costituire un problema. I moderni server hanno sufficiente capacità di elaborazione per fare questo e molto altro.
Siete nuovi al BGP, oppure avete bisogno di ulteriori approfondimenti ? Acquistate il mio libro "BGP: dalla teoria alla pratica" (al prezzo speciale di 30 Euro per i lettori del blog, spese di spedizione gratuite; per l'acquisto inviate una e-mail a libri@ssgrr.com). Oppure seguite i nostro corsi IPN246 "BGP: aspetti base" e IPN247 "BGP: aspetti avanzati".
Nonostante questo svantaggio, vi sono però anche molte buone ragioni per utilizzare la funzionalità BGP Add-Path, in primis la Path Diversity, che consente l'applicazione del BGP PIC (Prefix Independent Convergence), e quindi convergenza più veloce. La Path Diversity è poi un requisito fondamentale per il Load Balancing.
Il problema con l'Hot Potato Routing potrebbe però persistere. Infatti, di norma con il BGP Add-Path non vengono inviati tutti i possibili percorsi alternativi (altrimenti si potrebbero avere problemi di memoria come prima citato), ma solo un sottoinsieme. Ma chi ci garantisce che in questo sottoinsieme vi sia anche il best exit point secondo il costo IGP ?
Qualche altro fantasioso workaround potrebbe anche essere pensato, ma quello che serve in realtà è una soluziione più generale, che consenta di mettere i RR in qualsiasi punto della rete, e nel contempo mantenere il principio dell'Hot Potato Routing.
UNA SOLUZIONE PIU' GENERALE (BGP-ORR)
Una proposta di soluzione più generale a questo problema, già implementata dai principali vendor (anche se da alcuni ancora in forma sperimentale), è contenuta nel draft IETF draft-ietf-idr-bgp-optimal-route-reflection - BGP Optimal Route Reflection (BGP-ORR), il cui percorso per diventare RFC volge ormai al termine. L'idea è molto semplice e ingegnosa, virtualizzare la posizione del RR, o in altre parole, rendere la localizzazione del RR indipendente dal processo di selezione del best-path.
Vediamo come si esplicita l'idea. Come noto, il RR partecipa necessariamente al processo IGP, che, come accade nelle applicazioni pratiche, è di tipo Link-State (OSPF o IS-IS). Il RR conosce quindi la topologia totale o parziale della rete.
Supponiamo per il momento di essere in presenza, nel caso di OSPF di area singola (tipicamente l'area 0), e nel caso di IS-IS di un singolo livello (tipicamente livello 2). Con questa ipotesi il RR, partecipando al processo IGP, ha a disposizione l'intero LSDB (Link-State DataBase), e quindi è in grado di determinare i costi totali IGP tra ogni coppia di RR-Client. In particolare, è in grado di determinare una matrice dei costi, dove l'elemento <X, Y> della matrice è il costo IGP complessivo dal RR-Client X al RR-Client Y (NOTA: la diagonale della matrice non viene ovviamente utilizzata. Inoltre, come sovente accade in pratica, supporrò che la matrice sia simmetrica, ossia l'elemento <X, Y> coincida con l'elemento <Y, X>; ma questo a dire il vero non è indispensabile).
Per determinare l'elemento <X, Y> della matrice, il RR, avendo a disposizione l'intero LSDB non fa altro che determinare l'albero SPF con radice in X, ottenendo i costi ottimi verso tutti gli altri router della rete, tra cui il RR-Client Y. La figura seguente riassume il concetto.
A questo punto il gioco è fatto. Per vedere come, farò di nuovo riferimento all'esempio riportato sopra. Il RR, determina tre alberi SPF supplementari, ciascuno con radice un RR-Client (nella figura PE-1, PE-2 e PE-3). A valle di questi calcoli, il RR mantiene in memoria la seguente matrice dei costi:
Ora, nel momento in cui RR riceve da PE-1 e PE-2 gli annunci della "NET X", esegue il processo di selezione BGP. Ammesso che debba basare la sua decisione sul solo costo IGP verso il BGP Next-Hop, ossia a parità di tutte le metriche BGP dei punti precedenti il processo di selezione, il RR nella scelta del best-path non considera come costo da confrontare quello tra lui stesso e i due BGP Next-Hop PE-1 e PE-2, ma quello tra il RR-Client a cui riflette l'annuncio (nell'esempio PE-3) e i due RR-Client che hanno inviato l'annuncio (nell'esempio PE-1 e PE-2). Poiché il costo IGP minimo è quello tra PE-3 e PE-2, il RR elegge come best-path l'annuncio che ha BGP Next-Hop PE-2, e non quello con BGP Next-Hop PE-1, come farebbe di default. Il best-path viene quindi propagato a PE-3 con BGP Next-Hop PE-2, permettendo a PE-3 di seguire la logica dell'Hot Potato Routing.
Si noti che con questo modo di procedere, il best-path non è univoco, ma dipende dal RR-Client a cui viene riflesso l'annuncio. Due diversi RR-Client potrebbero ricevere due diversi best-path, in funzione della loro vicinanza a chi ha originato l'annuncio.
Nel caso in cui il dominio IGP sia partizionato in aree, potrebbe accadere che RR e RR-Client risiedano su aree diverse, e quindi il RR non conosce l'intera topologia della rete. Ma questo non cambia alcunché, basta solo adottare gli accorgimenti giusti. Supponiamo ad esempio che il protocollo IGP sia OSPF e che il RR sia nell'area 0 e i RR-Client X e Y siano rispettivamente nelle aree periferiche 10 e 20 (vedi figura seguente).
Il RR può comunque determinare il costo complessivo <X, Y> sommando il costo tra ABR-1 e Y, che conosce dal Summary Link LSA che ABR-1 invia nell'area 10 per annunciare i prefissi (inter-area) di Y (in particolare l'Host Route associata alla sua interfaccia di Loopback utilizzata per la sessione iBGP con il RR), e il costo tra X e ABR-1, che conosce dal Summary Link LSA che ABR-1 genera nell'area 0 per annunciare i prefissi (inter-area) di X.
E' bene tener presente che questa idea, "battezzata" nel draft IETF citato sopra, BGP-ORR (BGP - Optimal Route Reflection), non è alternativa al BGP Add-Path o ad altri metodi per la Path Diversity. Può essere utilizzata congiuntamente a questi per migliorare la "qualità" degli annunci multipli da propagare, inserendo tra questi sempre quello che garantisce di conservare il principio dell'Hot Potato Routing.
SUPPORTO NEI ROUTER CISCO E JUNIPER
Il BGP-ORR è supportato dal JUNOS Juniper in versioni molto recenti, ma solo quando il protocollo IGP è IS-IS. Non avendo a disposizione una versione JUNOS che lo supporta, sono costretto a darvi questo link sul sito Juniper, dove trovate i comandi necessari per l'implementazione.
Cisco invece supporta il BGP-ORR, per ora in via sperimentale, sull'ASR 9kv, un software basato sull'IOS XR Cisco, che potete utilizzare per implementare un vRR. Anche qui, non mi resta che darvi questo link, per maggiori informazioni, non avendo a disposizione il software dell'ASR 9kv.
CONCLUSIONI
Il BGP-ORR è un'idea molto semplice ed efficace, che consente di virtualizzare la posizione dei RR, rendendola indipendente dai suoi RR-Client. Questo consente di "recuperare" il principio dell'Hot Potato Routing, che altrimenti in molti casi pratici verrebbe perso. Il prezzo da pagare è un po' di lavoro in più che il RR deve svolgere, per mantenere la matrice delle distanze IGP tra i suoi RR-Client e per svolgere il processo di selezione, che diventa più pesante poiché è necessario determinare un best-path per ciascun RR-Client. Ma utilizzando dei virtual RR (vedi post precedente), che secondo i buoni principi della progettazione sono al di fuori del forwarding path, questo non dovrebbe costituire un problema. I moderni server hanno sufficiente capacità di elaborazione per fare questo e molto altro.
Siete nuovi al BGP, oppure avete bisogno di ulteriori approfondimenti ? Acquistate il mio libro "BGP: dalla teoria alla pratica" (al prezzo speciale di 30 Euro per i lettori del blog, spese di spedizione gratuite; per l'acquisto inviate una e-mail a libri@ssgrr.com). Oppure seguite i nostro corsi IPN246 "BGP: aspetti base" e IPN247 "BGP: aspetti avanzati".
Nessun commento:
Posta un commento