<< Torna agli Approfondimenti Tematici

Premesse

In “Optimal Routing Design” scritto da Russ White,Don Slice e Alvaro Retana edito da Cisco Press si legge relativamente alla possibilità di aggregazione delle rotte EIGRP in una rete altamente magliata “Reducing the information propagated through the mesh is difficult, at best.”

In questo articolo presenterò una soluzione relativamente semplice per ottenere alta scalabilità di una rete EIGRP in presenza di forte magliatura e backbone MPLS tramite aggregazione dei link.

La soluzione proposta si baserà su un uso attento dell’ aggregazione dei prefissi e uso di tunnel GRE (Generic Encapsulation Protocol) come meccanismo di protezione per diverse condizioni di fault.

L’architettura derivante da questa soluzione garantisce la ridondanza della rete tramite un core mpls e backdoor link di backup senza ricorrere all’uso di EIGRP Site of Origin o BGP cost community, caratterizzandosi quindi per semplicità nella gestione e implementazione.

Requisiti

Supponiamo che la rete sia caratterizzata da una topologia come quella in figura. Tale topologia è solo di esempio, la soluzione proposta può scalare per reti di centinaia se non migliaia di router.

Le caratteristiche topologiche principali sono una forte magliatura oltre alla presenza di un backbone mpls.

Possiamo supporre che vengano implementate VPN di livello 3 sul backbone mpls, anche se questo aspetto è inessenziale rispetto alla soluzione proposta.

Possiamo supporre che i router di figura siano router di distribuzione e che a questi afferiscano altri rami di accesso della rete che possono contare altre decine di router.

I requisiti nel dettaglio:

• La rete deve essere resistente a guasto singolo, i router di topologia, che potremmo considerare di distribuzione (mentre i PE di core), devono sempre rimanere disponibili anche in caso di fault di un link.
• I percorsi di traffico devono prediligere l’utilizzo di backdoor link per certi percorsi geograficamente vicini, mentre devono preferire un percorso su backbone mpls per tutti gli altri percorsi.
• Deve essere garantito il funzionamento della rete anche in caso di fault totale del backbone MPLS (questo ultimo requisito può essere garantito dalla soluzione proposta in questo articolo, ma richiede ulteriori considerazioni che per semplicità qui vengono solamente accennate).

Problematiche

Di seguito una rapida disamina dei problemi più comuni in caso di topologia multihomed verso core MPLS in presenza di backdoor link

Problema 1: backdoor link preferito rispetto al backbone MPLS

Supponiamo che relativamente alla rete connessa a CE1 10.0.0.0/24 avvengano i seguenti eventi nel seguente ordine:
1. CE1 invii una update EIGRP relativa alla rete 10.0.0.0/24 a CE2 e PE1
2. CE2 invii una update per la stessa rete a PE2
3. PE2 Redistribuisca la rete 10.0.0.0/24 in MPBGP
4. PE1 Redistribuisca la rete 10.0.0.0/24 in MPBGP
5. PE2 Invii una NLRI MPBGP verso PE1 riguardante la rete 10.0.0.0/24
6. PE1 Invii una NLRI MPBGP verso PE2 riguardante la rete 10.0.0.0/24

In questo caso PE2 non installerà la rotta imparata in MPBGP dal suo neighbor PE1 in quanto la sua “best” sarà la rotta localmente generata dalla redistribuzione EIGRP->BGP, questo dovutamente al fatto che eventuali informazioni relative alla metrica verranno prese in considerazione solamente dopo l’attributo di “localmente originata”, particolarmente su IOS Cisco alle rotte originate localmente viene assegnato un weight 32768 che quindi viene selezionato prima di ogni altro attributo.

L’effetto finale di questo processo è che PE2 utilizzerà il backdoor link CE1-CE2 per raggiungere la rete 10.0.0.0/24 a prescindere dalla metrica assegnata al backdoor link.

L’esatta sequenza degli eventi dipende dall’ordine con cui le operazioni vengono svolte e questo non è predicibile a priori.

Generalmente questo tipo di problematica può essere gestito con l’utilizzo di BGP Cost Community descritto nel draft draft-retana-bgp-custom-decision-00. Utilizzando questa soluzione si forza il BGP ad un comportamento assimilabile a quello di un IGP, data però la diversa natura del protocollo devono essere attentamente considerate le implicazioni di questa scelta sul funzionamento della rete.

Problema 2: count to infinity

La seconda problematica è invece quella della possibilità che si inneschi un loop di control plane in EIGRP. Sempre con riferimento alla topologia precedente, si consideri che si stia facendo uso di BGP Cost Community e quindi PE2 e CE2 preferiscano raggiungere la rete 10.0.0.0/24 passando su core MPLS.

Si consideri la seguente sequenza di eventi:
1. CE1 perde connettività verso la rete 10.0.0.0/24
2. CE1 invia una query relativa alla rete 10.0.0.0/24 verso PE1 e CE2
3. PE1 apprende di non avere percorsi alternativi verso la rete in fault ed invia una reply a CE1, questo porta anche la tabella BGP a cancellare l’informazione dovuta a redistribuzione della rete 10.0.0.0/24
4. PE1 invia quindi un messaggio di withdraw relativo alla rete 10.0.0.0/24 verso PE2, allo stesso tempo CE2 inoltra la query originata da CE1 verso PE2.
5. Se la query EIGRP raggiunge PE2 prima del messaggio BGP, allora PE2 risponde alla query proponendosi come percorso alternativo per la rete 10.0.0.0/24
6. CE1 installa quindi una rotta verso la rete 10.0.0.0/24 con next hop CE2
7. CE1 aggiorna PE1 sulla presenza di questo nuovo percorso, PE1 redistribuisce questa informazione in BGP
8. Contestualmente PE2 riceve il messaggio BGP di withdraw della rete 10.0.0.0/24, capisce di aver perso il suo unico percorso verso la rete ed invia una query a CE2, tale query viene quindi inviata anche verso CE1.
9. CE1 capisce di aver perso la sua unica rotta verso la rete 10.0.0.0/24 ed invia una query verso PE1 di fatto replicando quanto avviene nel punto 1.

Questa serie di eventi può ciclare in maniera virtualmente infinita e dipende strettamente dall’ordine delle operazioni, se ad esempio il messaggio di withdraw del punto 4 raggiunge PE2 prima della query del punto 5, la rete si stabilizza nella perdita di raggiungibilità della rete 10.0.0.0/24. La sequenza riportata è da considerarsi un esempio del ciclo di loop, sono possibili variazioni.

Si noti anche che il numero di hop dell’update inviata da CE1 a PE1 nel punto 6 incrementa ad ogni ciclo del loop. Questo ciclo potrà arrestarsi al raggiungimento del massimo numero di hop (si ricordi che EIGRP tiene conto del numero di hop non come parametro di metrica ma come meccanismo di gestione di fenomeni di count to infinity).

Il problema proposto può essere attenuato riducendo i tempi advertisement di EIGRP, di fatto riducendo i tempi di convergenza in caso di loop, che però rimarrebbero estremamente variabili. Una soluzione al problema più deterministica può essere gestita con il parametro EIGRP Site of Origin.

Soluzione senza utilizzo di BGP Cost Community e EIGRP Soo

Piano di indirizzamento e aggregazione degli indirizzi

La soluzione proposta ha come base fondante quello di un piano di indirizzamento facilmente aggregabile.

A questo scopo il primo passo da effettuare è separare le regioni geografiche che si desidera abbiano una raggiungibilità intra-regione tramite backdoor link invece del core MPLS.

Inoltre sarà necessario suddividere la regione in almeno due aree, ognuna afferente ad un diverso PE.

Le due aree di una regione devono avere indirizzamento tale da poter essere aggregato in un’unica rete rappresentante la regione.

Ad esempio si potrebbe assegnare alla regione di PE1 e PE2 la rete 10.0.0.0/15, suddividendo ulteriormente la rete in un’area 10.0.0.0/16 (PE1,CE1,R11) e un’area 10.1.0.0/16 (PE2,CE2,R21,R22). Ai fini di tale suddivisione non è rilevante a quale area vengano assegnati i link inter-areacome quello R11-R21.

Secondo aspetto è quello di eliminare momentaneamente eventuali link inter-regione come R21-R31.

Eliminare questi link potrebbe violare i requisiti di resistenza a guasto singolo e di resistenza a fault della backbone MPLS, essi verranno in parte riattivati successivamente una volta effettuate ulteriori considerazioni.

Una volta suddivisa la rete in regioni e sotto-regioni sarà possibile inviare un prefisso aggregato della regione e dell’area di appartenenza dal CE al PE. Il PE verso il CE potrebbe inviare esclusivamente una rotta di default che verrà propagata all’interno della regione stessa.

Si può considerare che i router di distribuzione aggreghino tutti gli eventuali prefissi dei router di accesso a questo afferenti, come ad esempio la rete 10.0.160/19 afferente a R11 appartenente all’area 10.0.0.0/16 e alla regione 10.0.0.0/15.

Il traffico intra-regione seguirà il percorso migliore calcolato dal DUAL EIGRP.

Il traffico inter-regione sarà così caratterizzato:

• Il traffico uscente dalla sotto-regione andrà verso il PE più vicino (seguendo la rotta di default)
• Il traffico di ritorno in condizioni normali verrà inviato verso il PE dell’area, quello cioè che ha ricevuto la summary di area e la ha redistribuita in MPBGP.

Si noti che il traffico uscente dalla sotto-regione potrebbe passare per il PE dell’altra sotto-regione in dipendenza da valutazioni di metrica. Questo comportamento implicherebbe un routing asimmetrico poiché il traffico di ritorno continuerà ad essere inviato invece verso il PE della sotto-regione a cui appartiene il router che lo ha originato. Si può eventualmente assegnare una metrica alta sui link inter sotto-regione per evitare questo comportamento.

Gestione del partizionamento

Può accadere che nonostante la ridondanza della regione, una sotto-regione diventi partizionata in seguito ad un fault di un link.

Questo evento porterebbe i router di distribuzione distaccati dalla loro sotto-regione (come R11 nella figura di esempio) a non poter più ricevere traffico, infatti in questo scenario il traffico sarebbe così caratterizzato:

• Il traffico uscente dalla sotto-regione partizionata potrebbe ancora uscire dal PE dell’altra sotto-regione, utilizzando la rotta di default iniettata dal PE dell’area adiacente nella regione
• Il traffico di ritorno verrebbe inviato al CE relativo alla sotto-regione che ha subito il partizionamento e conseguentemente essere scartato poiché i pacchetti intercetterebbero una rotta summary verso null0 (caratteristica della summarizzazione EIGRP CE-PE)

Per risolvere questo problema si può ricorrere ad un tunnel di protezione della regione. Verrà aggiunto un link logico tramite un tunnel GRE tra i due CE appartenenti ad aree diverse della stessa regione.

Questo tunnel (in verde tratteggiato) dovrebbe avere una metrica alta in modo da non essere utilizzato se non in caso di partizionamento della regione. Sul tunnel verrà comunque instaurata una neighborship EIGRP. In caso di partizionamento il CE della sotto-regione partizionata conoscerà il dettaglio delle rotte EIGRP della regione partizionata attraverso il tunnel GRE.

In caso di partizionamento della regione il traffico originato da un router distaccato dalla sua sotto-regione in seguito al partizionamento, sarà così caratterizzato:

• Il traffico di uscita dalla sotto-regione partizionata passerà per il PE dell’altra sotto-regione
• Il traffico di ritorno verrà prima inviato al CE relativo alla sotto-regione partizionata, per poi essere inoltrato attraverso il tunnel GRE al CE dell’altra sotto-regione.

Gestione dell’isolamento

Conseguentemente allo spegnimento di link inter-regione potrebbero causarsi situazioni di mancanza di ridondanza su una rete originariamente ridondata. Ad esempio in figura, il router R22 resta isolato per un fault del link R21-R22 nonostante esista un link fisico alternativo che collega R22 a CE3.

A questo scopo chiamiamo:

• Regione protetta: la regione che può subire l’isolamento di un suo router
• Router protetto: il router che può subire isolamento
• Regione di protezione: la regione che consentirà di gestire l’isolamento del router protetto
• Router di protezione: router appartenente alla regione di protezione, direttamente connesso al router protetto.

In questi casi è necessario riattivare il link inter-regione, tuttavia alcuni accorgimenti sono fondamentali per preservare l’uso del backdoor link se non per protezione del router isolato.

L’idea è quella di instaurare un tunnel di protezione inter-regione tra il router potenzialmente isolato e il suo CE di sotto-regione. Si noti che perché questo tunnel funzioni deve essere prevista come sorgente del tunnel, lato router protetto, un indirizzo appartenente alla sotto-regione di protezione. Scegliendo opportunamente gli indirizzi sorgenti del tunnel si può garantire la raggiungibilità del router isolato da parte del CE della regione partizionata attraverso il backbone MPLS.

Un altro accorgimento è quello di instaurare una adiacenza EIGRP sul tunnel di protezione ed inviare su questa adiacenza i prefissi di regione da parte del CE e le informazioni dell’area di indirizzamento ad esso afferenti da parte del router protetto. Il router protetto non dovrà inoltrare alcuna informazione di routing verso il router di protezione, se non l’indirizzo sorgente del tunnel di protezione affinchè questo possa essere raggiunto nella regione di protezione dalla regione protetta.

Sarà anche necessario inoltrare verso il router protetto una default route da parte del router di protezione (in figura CE3), la metrica del link Router protetto-Router di protezione deve essere sufficientemente alta da non essere utilizzato se non come ultima risorsa. In ogni caso la default route inviata dal router di protezione verso il router protetto non dovrebbe essere inoltrata all’interno della regione protetta per evitare traffico su backdoor link inter-regione (questa ultima considerazione dovrebbe essere rivisitata per soddisfare il requisito di backup completo del backbone MPLS).

Perché si può evitare l’uso di EIGRP Soo e BGP Cost Community.

La soluzione proposta consente di evitare l’uso di EIGRP Soo senza il rischio di creare loop perché tutto si basa sull’aggregazione dei link CE-PE, questo fa si che un fault di una rete o di un’ intera area di indirizzamento, all’interno di una sotto-regione, venga di fatto nascosta verso il PE, eliminando la problematica della propagazione dell’evento in MPBGP. Il tunnel di protezione intra-regione garantisce la gestione corretta del partizionamento della regione in qualunque caso di fault.

Nell’ architettura proposta si è di fatto risolto il problema dell’uso dei backdoor link inter-regione con la loro disattivazione. Con alcuni accorgimenti è possibile preservare i link inter-regione e utilizzarli solamente in caso di fault del backbone mpls, per fare questo è necessario che sui link inter-regione venga annunciata la rete aggregata di regione e iniezione della rete aggregata delle singole regioni in EIGRP da MPBGP, cambiando quindi il routing inter-regione che non dipenderà più soltanto da una rotta di default.

Conclusioni

La soluzione proposta descrive una topologia di regione caratterizzata da due-sottoregioni afferenti a due differenti PE, essa può essere facilmente estesa a topologie caratterizzate da regioni con un qualunque numero di PE: ulteriori considerazioni dovrebbero essere fatte relativamente ai tunnel di protezione da partizionamento.

L’architettura proposta e la soluzione individuata può essere adattata con alcuni accorgimenti anche ad una rete che abbia come protocollo PE-CE OSPF, tuttavia in questo caso sarà bene tenere conto delle insite differenze tra un protocollo link state e un distance vector. L’aggregazione delle rotte potrà essere fatta solamente sugli ABR che quindi dovrebbero essere i CE, individuando quindi la presenza di un’area zero oltre al super-backbone MPLS. Particolarmente critica la gestione del traffico inter-regione su backoor link che può essere gestita considerando funzionalità di control plane inter-area senza che si transiti in area zero.

La soluzione proposta mantiene la sua validità anche nel caso di router non-Cisco sul backbone MPLS, che escluderebbero quindi la possibilità di utilizzare EIGRP come protocollo PE-CE. In questo caso si dovrebbe utilizzare eBGP come protocollo PE-CE ed effettuare opportune redistribuzioni tra EIGRP e BGP sui CE. In questo caso data la soluzione di aggregazione potrebbe non essere necessaria una redistribuzione mutua tra protocolli.

In conclusione l’architettura qui presentata vuole essere di ausilio alla gestione della scalabilità e ridondanza di reti EIGRP magliate; essa è decisamente flessibile ma in fase di design saranno necessari aggiustamenti e analisi di dettaglio per adattarla alla specifica topologia di rete.