Poco prima delle ferie estive ho tenuto un corso/consulenza a un gruppo di ottimi tecnici di una primaria Istituzione Italiana, che ha una delle reti Enterprise più estese nel panorama nazionale. Argomento, le mirabilie del Traffic Engineering MPLS (MPLS-TE), con tutti gli annessi e connessi. In due giorni abbiamo approfondito praticamente tutti gli aspetti chiave.
Durante la presentazione e discussione, uno dei partecipanti mi ha posto una domanda molto interessante: è possibile, tra i vari vincoli che MPLS-TE consente di definire, prevederne uno che tenga conto del percorso fisico, oltre che logico, seguito dai LSP MPLS-TE ?
La risposta è certamente si. I principali vendor hanno introdotto nei loro software i cosiddetti vincoli SRLG (Shared Risk Link Group). Visto che pochi li conoscono, e che reputo questo tipo di vincoli molto importante da un punto di vista applicativo, ritengo interessante illustrarli al pubblico dei lettori di questo blog. L'argomento non è certamente nuovo, ma è poco conosciuto. E poi credo che abbia una sua rilevanza pratica importante.
Prima di inziare, un piccolo refresh su MPLS-TE. Chi conosce già gli aspetti base può saltare questa sezione.
MPLS-TE PRIMER
Come arcinoto, nelle reti IP convenzionali la determinazione dei percorsi è demandata a un protocollo di routing IP (OSPF, IS-IS, ecc.). Nelle reti IP+MPLS vi sono invece due tipi di percorsi, o LSP (Label Switched Path) come sono chiamati nel gergo MPLS:
- LSP Hop-by-Hop: il percorso viene scelto da un protocollo di routing IP. MPLS, tramite il suo protocollo LDP, si limita in questo caso ad associare delle etichette per il forwarding.
- LSP Explicitly Routed: il percorso viene scelto in modo indipendente dal protocollo di routing IP, tramite tecniche off-line (es. tramite un programma di calcolo) oppure on-line (Constrained Based Routing). In entrambi i casi, viene utilizzato per la segnalazione il protocollo RSVP-TE.
La determinazione di questi ultimi ricade nel cappello più generale dei servizi MPLS-TE. MPLS-TE è uno dei primi servizi sviluppati per le reti IP che adottano MPLS, e consente ad un amministratore di rete di costruire percorsi arbitrari, diversi da quelli eventualmente determinati dal protocollo di routing IP, su cui far fluire determinati flussi di traffico. In questo contesto, i percorsi MPLS-TE possono essere assimilati a dei Canali Virtuali Permanenti (CVP) in tecnologia ATM o Frame Relay (con delle differenze, la principale delle quali è che i LSP MPLS sono undirezionali, mentre i CVP ATM/Frame Relay sono bidirezionali).
Come citato sopra, i percorsi arbitrari possono essere determinati manualmente, sulla base di criteri stabiliti dall’amministratore della rete, oppure attraverso un qualche algoritmo "ottimo", che può essere on-line oppure off-line, basato eventualmente su dei vincoli, dove i vincoli possono essere sia di tipo amministrativo (es. evitare comunque un determinato collegamento), che legati alla banda, e "ottimo" è riferito a una qualche metrica o funzione obiettivo da minimizzare.
La determinazione on-line dei percorsi arbitrari soggetti a vincoli, richiede la conoscenza dettagliata della topologia (logica !, vedi prossima sezione) della rete. La topologia è definita oltre che dall’insieme dei nodi e la loro connettività, anche dagli attributi dei collegamenti fisici (es. banda trasmissiva, classe amministrativa di appartenenza, % di banda utilizzabile, ecc.). La topologia della rete e gli attributi associati ai vari collegamenti devono essere noti ai nodi della rete MPLS, i quali hanno bisogno quindi delle informazioni necessarie per costruire il TE-LSDB (Traffic Engineering - Link State DataBase), ossia l’archivio contenente le informazioni topologiche e gli attributi associati ai collegamenti. Lo scambio delle informazioni avviene utilizzando i messaggi dei protocolli di routing convenzionali di tipo Link-State come OSPF e IS-IS, opportunamente estesi per trasportare oltre alle informazioni topologiche, attributi di vario tipo (es. banda prenotabile, classe amministrativa di appartenenza, ecc.).
Per la realizzazione dei percorsi espliciti è necessario un protocollo di segnalazione, tramite il quale informare i LSR (Label Switching Router) del percorso sulle caratteristiche dei flussi di traffico, e scambiarsi le etichette MPLS che consentano la realizzazione del LSP. Il protocollo sviluppato da IETF per queste funzioni è RSVP-TE (RSVP–Traffic Engineering). La figura seguente riassume gli "ingredienti" necessari per implementare tutto il macchinario necessario per la realizzazione ottimale dei LSP MPLS-TE (ossia, di LSP Explicitly Routed).
La figura seguente riporta invece il flusso logico delle operazioni, che consente di realizzare LSP MPLS-TE.
Questa è solo una brevissima idea di cosa siano i servizi MPLS-TE. Non mi addentro nemmeno ad illustrare i servizi MPLS-TE Fast ReRouting, che di MPLS-TE sono certamente uno delle aspetti più importanti, poiché non pertinenti all'argomento di questo post. Però non voglio lasciare i volenterosi nel limbo di una conoscenza estremamente parziale. Molti anni fa scrissi un libro su MPLS, con un intero Capitolo di ben 120 pagine dedicato a MPLS-TE. Il libro si è ovviamente invecchiato, ma i fondamenti di MPLS-TE sono rimasti quelli. Per cui se volete approfondire l'argomento, potete scaricarvi a questo link il Capitolo 7 del mio vecchio tomo "MPLS: fondamenti e applicazioni alle reti IP", Ed. Hoepli, 2003, dove troverete molto e ancor di più su MPLS-TE (ma non troverete i vincoli SRLG, altrimenti non avrei scritto questo post. La ragione è presto detta, la RFC che ha introdotto i vincoli SRLG è del 2005 !).
TOPOLOGIA LOGICA, FISICA E GRUPPI SRLG
Nella sezione precedente, quando ho parlato di topologia ho evidenziato il fatto che nel TE-LSDB sono memorizzate le informazioni necessarie alla costruzione della topologia logica della rete. Quando si parla di vincoli SRLG è necessario avere chiare le differenze tra topologia logica e fisica della rete. Concetti arcinoti, per carità, ma repetita iuvant !
Per far capire la differenza, faccio l'esempio di una topologia banale, un collegamento multi-link di due link tra una coppia di router, R1 e R2. Questa è la mia topologia logica. Ma fisicamente come sono realizzati i due link ? Qui le soluzioni sono tante, ne illustro due che mi faranno poi comodo per introdurre il concetto di gruppo SRLG.
Tra i due router, per la realizzazione dei link viene utilizzata una rete fisica di trasporto, costituita da tutto quell'insieme di apparati (es. MUX DWDM, ADM, ROADM, amplificatori ottici, ecc,) e cavi (oggi in fibra ottica) che consentono di realizzare "fisicamente" i link logici di collegamento. In un certo senso, la rete IP, costituita dai router e dai link (logici) tra i router è una rete overlay, che ha come rete underlay la rete di trasporto fisico.
Allora, una prima soluzione per realizzare i nostri due link logici tra i due router R1 e R2 potrebbe essere quella riportata nella figura seguente.
La figura mostra che i collegamenti logici utilizzano due diverse "lambda", sugli stessi identici cavi in fibra ottica (NOTA: anche il collegamento tra router e OADM potrebbe utilizzare una singola fibra partizionata in due "lambda", tutto dipende dal tipo di interfaccia disponibile sul router, se è di tipo (D)WDM o meno). Il punto debole di questa soluzione è ovvio, se per un qualche motivo uno dei cavi utilizzati venisse "tranciato", o uno dei due OADM a cui sono attestati andasse fuori servizio, entrambi i link logici andrebbero fuori servizio. Allo stesso modo, se invece di utilizzare due dark fiber tra router e OADM, si utilizzasse sul router una singola interfaccia (D)WDM, il fuori servizio dell'interfaccia metterebbe fuori servizio entrambi i link logici. In altre parole, in questa prima soluzione, i due link logici condividono lo stesso "fato" (fate-sharing), ossia lo stesso rischio.
Supponiamo invece di adottare una soluzione come quella della figura seguente, dove i link logici sono realizzati utilizzando collegamenti fisici completamente separati (path diversity).
E' ovvio che in questo caso, l'interruzione di un collegamento fisico implica il fuori servizio di un solo link logico e non di entrambi. Una soluzione molto più affidabile rispetto alla precedente.
Per concludere, la topologia logica è sempre quella, due router collegati da due "fili". E' la topologia fisica con cui sono sono realizzati i "fili" che cambia.
Dai due esempi illustrati sopra nasce la definizione di gruppo SRLG:
Un gruppo SRLG è un insieme di link logici che condividono tutte o parte della risorse fisiche della rete di trasporto.
Tutti i link logici appartenenti allo stesso gruppo SRLG condividono quindi la stessa sorte: in caso di fuori servizio delle risorse condivise, vanno tutti fuori servizio contemporaneamente.
L'implementazione dei vincoli SRLG prevede due passi, che poi si traducono in due passi di configurazione:
Per far capire la differenza, faccio l'esempio di una topologia banale, un collegamento multi-link di due link tra una coppia di router, R1 e R2. Questa è la mia topologia logica. Ma fisicamente come sono realizzati i due link ? Qui le soluzioni sono tante, ne illustro due che mi faranno poi comodo per introdurre il concetto di gruppo SRLG.
Tra i due router, per la realizzazione dei link viene utilizzata una rete fisica di trasporto, costituita da tutto quell'insieme di apparati (es. MUX DWDM, ADM, ROADM, amplificatori ottici, ecc,) e cavi (oggi in fibra ottica) che consentono di realizzare "fisicamente" i link logici di collegamento. In un certo senso, la rete IP, costituita dai router e dai link (logici) tra i router è una rete overlay, che ha come rete underlay la rete di trasporto fisico.
Allora, una prima soluzione per realizzare i nostri due link logici tra i due router R1 e R2 potrebbe essere quella riportata nella figura seguente.
La figura mostra che i collegamenti logici utilizzano due diverse "lambda", sugli stessi identici cavi in fibra ottica (NOTA: anche il collegamento tra router e OADM potrebbe utilizzare una singola fibra partizionata in due "lambda", tutto dipende dal tipo di interfaccia disponibile sul router, se è di tipo (D)WDM o meno). Il punto debole di questa soluzione è ovvio, se per un qualche motivo uno dei cavi utilizzati venisse "tranciato", o uno dei due OADM a cui sono attestati andasse fuori servizio, entrambi i link logici andrebbero fuori servizio. Allo stesso modo, se invece di utilizzare due dark fiber tra router e OADM, si utilizzasse sul router una singola interfaccia (D)WDM, il fuori servizio dell'interfaccia metterebbe fuori servizio entrambi i link logici. In altre parole, in questa prima soluzione, i due link logici condividono lo stesso "fato" (fate-sharing), ossia lo stesso rischio.
Supponiamo invece di adottare una soluzione come quella della figura seguente, dove i link logici sono realizzati utilizzando collegamenti fisici completamente separati (path diversity).
E' ovvio che in questo caso, l'interruzione di un collegamento fisico implica il fuori servizio di un solo link logico e non di entrambi. Una soluzione molto più affidabile rispetto alla precedente.
Per concludere, la topologia logica è sempre quella, due router collegati da due "fili". E' la topologia fisica con cui sono sono realizzati i "fili" che cambia.
Dai due esempi illustrati sopra nasce la definizione di gruppo SRLG:
Un gruppo SRLG è un insieme di link logici che condividono tutte o parte della risorse fisiche della rete di trasporto.
Tutti i link logici appartenenti allo stesso gruppo SRLG condividono quindi la stessa sorte: in caso di fuori servizio delle risorse condivise, vanno tutti fuori servizio contemporaneamente.
DEFINIZIONE DEI VINCOLI SRLG
Tra i tanti vincoli che è possibile definire nella realizzazione di LSP MPLS-TE, come ad esempio, appartenenza a un determinato livello di priorità, quantità di banda, appartenenza a determinate classi amministrative, ecc., successivamente alle prime RFC che hanno standardizzato MPLS, sono stati introdotti anche vincoli di tipo SRLG. La prima RFC a trattare questo problema è stata la RFC 4202 - Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), pubblicata nell'Ottobre 2005. Altre due RFC fondamentali per il trattamento dei vincoli SRLG sono:- RFC 4203 - OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), Ottobre 2005.
- RFC 5307 - IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), Ottobre 2008.
L'implementazione dei vincoli SRLG prevede due passi, che poi si traducono in due passi di configurazione:
- Configurare l’appartenenza a un determinato gruppo SRLG, sulle interfacce agli estremi dei link logici. Si noti che un link logico può appartenere a più gruppi SRLG. L’appartenenza a un gruppo SRLG viene passata al protocollo IGP, diffusa (via LSA opachi per OSPF e TLV 22 per IS-IS), e quindi inserita nel TE-LSDB insieme alle altre informazioni topologiche.
- Aggiungere alle configurazioni ordinarie il comando per escludere dai percorsi di backup, i collegamenti appartenenti allo stesso gruppo SRLG.
- Il percorso di backup viene realizzato se e solo se esiste un percorso che soddisfa i vincoli SRLG.
- Il percorso di backup viene realizzato comunque, anche se non esiste un percorso che soddisfa i vincoli SRLG.
Prima di illustrare i due Case Study, è però opportuna una breve premessa sui tipi di protezione supportati da MPLS-TE. MPLS-TE prevede tre tipi di protezione del traffico:
- Protezione dei percorsi (Path Protection) : richiede un LSP MPLS-TE di backup per ciascun LSP MPLS-TE primario (protezione 1:1). Idea estremamente semplice ma poco scalabile. Non è molto adottato nelle applicazioni pratiche, a mia conoscenza, in Italia c'è una sola rete, di modeste dimensioni, che lo adotta.
- Facility backup (RFC 4090, Sezione 3.2): è un tipo di protezione 1:N che prevede la realizzazione, da parte di un LSR (di ingresso o di transito) attraversato da più LSP MPLS-TE, di un percorso di bypass, ossia, un percorso che aggira un LSR o link fuori servizio, unico per tutti o parte dei LSP MPLS-TE.
- One-to-one backup (RFC 4090, Sezione 3.1): è un tipo di protezione 1:1 che prevede la realizzazione, da parte del LSR di ingresso e di ciascun LSR di transito di un LSP MPLS-TE, di un Detour Path, ossia, un percorso che aggira un LSR o link fuori servizio.
CASE STUDY IN AMBIENTE CISCO
Il Case Study in ambiente Cisco di questa sezione implementa un tipo di protezione Facility backup, mentre nel Case Study in ambiente Juniper della prossima sezione, supporrò di utilizzare la Path Protection.
Cisco implementa l'utilizza dei vincoli SRLG in tutte le sue versioni dell'IOS (IOS, IOS XE, IOS XR). Il Case Study che mostrerò nel seguito è basato su una rete di router che utilizzano l'IOS.
La rete test è descritta nella figura seguente. Nella figura è evidenziato anche un LSP MPLS-TE, realizzato attraverso le seguenti classiche configurazioni:
interface Tunnel1121
ip unnumbered Loopback0
tunnel destination 192.168.1.21
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 1 explicit name UNO
tunnel mpls traffic-eng path-option 2 dynamic
tunnel mpls traffic-eng fast-reroute
!
ip explicit-path name UNO enable
next-address 192.168.2.11
next-address 192.168.2.22
next-address 192.168.1.21
Si noti che è stata abilitata la protezione del traffico, tramite il comando "tunnel mpls traffic-eng fast-reroute".
Nel test utilizzerò una metodologia Cisco nota come "Backup Auto-Tunnels", che consente la realizzazione automatica di percorsi di protezione sia dei link (percorsi di tipo NHOP) che dei nodi (percorsi di tipo NNHOP). L'implementazione di questa metodologia avviene attraverso il seguente comando in configurazione globale:
router(config)# mpls traffic-eng auto-tunnel [nhop-only]
che va eseguito su tutti i router attraversati dai LSP MPLS-TE. Nel nostro Case Study, il comando va eseguito sui router P11, CS11 e CS22. L’opzione “nhop-only” restringe la realizzazione a LSP di backup per la protezione dei soli collegamenti (LSP di tipo NHOP). Ai LSP di backup creati, viene assegnato automaticamente l’indirizzo IP dell’interfaccia "Loopback 0" (ricordo che assegnare un indirizzo IP a una interfaccia è fondamentale, altrimenti l'interfaccia non può essere utilizzata come transito per il traffico dati).
Vi sono poi due comandi opzionali:
- router(config)# mpls traffic-eng auto-tunnel backup tunnel-num [min min] [max max] : questo comando consente di ridefinire l’intervallo di numerazione dei LSP di backup creati automaticamente; l'intervallo di default è 65.436 - 65.535.
- router(config)# mpls traffic-eng auto-tunnel backup timers removal unused scan-time unused-time : questo comando consente un controllo periodico (scan-time) per rimuovere LSP di backup non utilizzati per il tempo unused-time. Il valore di default è 3.600 secondi per entrambi i timer. Il valore unused-time = 0 significa "non rimuovere mai i LSP di backup".
Nel Case Study, ho utilizzato le seguenti configurazioni su P11, CS11 e CS22 :
mpls traffic-eng auto-tunnel backup
mpls traffic-eng auto-tunnel backup tunnel-num min 100 max 199
mpls traffic-eng auto-tunnel backup timers removal unused 43200 43200
Per vedere come l'applicazione dei vincoli SRLG cambia il percorso dei LSP di backup, controlliamo dapprima il risultato delle configurazioni effettuate sin qui (ossia, prima dell'introduzione di vincoli SRLG). La figura seguente riporta i LSP di backup creati (automaticamente) da P11 per proteggere il traffico rispettivamente da fuori servizio del link P11-CS11 (LSP di tipo NHOP) e del nodo CS11 (LSP di tipo NNHOP).
Si noti che il LSP di backup di tipo NHOP termina all'altro estremo del link protetto, e per questo si chiama di tipo NHOP, che è una abbreviazione per Next-HOP. Il LSP di backup di tipo NNHOP termina invece sul Next-Hop successivo (CS22) del LSP MPLS-TE principale, e per questo si chiama di tipo NNHOP, che è una abbreviazione per Next-to-Next-HOP. Solo per completezza, vi riporto nella figura seguente la verifica della creazione dei due LSP di backup in questione (l'interpretazione dei comandi "show" è lasciata come esercizio" ...).
Per completare questa prima parte del Case Study, la figura seguente riporta gli altri LSP di backup creati (sempre automaticamente) a fronte delle configurazioni effettuate.
Vi lascio come esercizio la verifica dei percorsi realizzati e quali elementi di rete questi proteggono. A questo punto il quadro dovrebbe essere abbastanza chiaro.
Vediamo ora cosa accade introducendo dei vincoli SRLG. Supponiamo per ipotesi che i due link (logici) CS11-CS12 e CS11-CS22 utilizzino risorse fisiche comuni. Ciò comporta che il fuori servizio di queste risorse comporti il fuori servizio contemporaneo di entrambi i link logici. In altre parole, i due link appartengono allo stesso gruppo SRLG.
Senza introdurre ulteriori vincoli, è facile rendersi conto che con questa ipotesi, il LSP di backup di tipo NHOP creato da CS11 non protegge un bel niente. Infatti, CS11 crea questo LSP di backup per proteggere il traffico che scorre sul LSP MPLS-TE principale, dal fuori servizio del collegamento CS11-CS22. Ma poiché il fuori servizio di questo link implica il fuori servizio anche del link CS11-CS12 utilizzato dal LSP di backup, quest'ultimo non può essere attivato.
E qui entrano in gioco i vincoli SRLG. Come detto sopra, la configurazione prevede due passi. Nel primo bisogna definire l'appartenenza ai vari gruppi SRLG delle singole interfacce. Nel nostro Case Study supporrò di assegnare entrambe le interfacce lato CS11 dei link CS11-CS12 e CS11-CS22 al gruppo SRLG 10. Queste interfacce sono rispettivamente "POS 1/0" e "POS 1/4". Le configurazioni da eseguire su CS11 sono le seguenti:
interface pos 1/0
mpls traffic-eng srlg 10
!
interface pos 1/4
mpls traffic-eng srlg 10
Il secondo passo serve ad abilitare l'utilizzo dei vincoli SRLG e a scegliere la modalità di realizzazione dei LSP di backup. Il comando aggiuntivo è il seguente:
router(config)# mpls traffic-eng auto-tunnel backup srlg exclude (force | preferred)
dove l'opzione "force" indica che il LSP di backup viene realizzato se e solo se esiste un percorso che soddisfa i vincoli SRLG, mentre l'opzione "preferred" indica che il LSP di backup viene realizzato comunque, anche se non esiste un percorso che soddisfa i vincoli SRLG. Nel Case Study ho utilizzato l'opzione "force", quindi il comando aggiuntivo ai precedenti che ho eseguito sul router CS11 è il seguente:
mpls traffic-eng auto-tunnel backup srlg exclude force
La figura seguente mostra come può essere eseguita la verifica dell'appartenenza delle due interfacce "POS 1/0" e "POS 1/4" al gruppo SRLG 10.
Infine, per completare il Case Study, la figura seguente riporta come sono cambiati i percorsi dei LSP di backup, tenendo conto dei vincoli SRLG (in realtà è cambiato un solo percorso, indicato nella figura con un asterisco, gli altri erano OK).
CASE STUDY IN AMBIENTE JUNIPER
Come citato nella sezione precedente, per il Case Study in ambiente Juniper supporrò di utilizzare la modalità di protezione Path Protection. Lo scenario di rete è identico a quello della sezione precedente, solo le interfacce utilizzate sono diverse. In particolare supporrò che l'interfaccia "POS 1/0" della sezione precedente sia sostituita dall'interfaccia "ge-2/0/1" e l'interfaccia "POS 1/4" dall'interfaccia "ge-2/0/2".
La configurazione è un po' più articolata rispetto a quella Cisco, ma i concetti sono sempre quelli. Nel primo passo si assegna un nome (possibilmente mnemonico) ai gruppi SRLG. In questo Case Study, come in quello della sezione precedente, supporrò di utilizzare il solo gruppo SRLG 10. La configurazione per assegnare un nome al gruppo SRLG 10, va eseguita sotto la gerarchia di configurazione "routing-options" ed è la seguente (il nome assegnato è SRLG-10):
routing-options {
srlg {
SRLG-10 {
srlg-value 10;
}
}
}
Nel secondo passo si assegnano le interfacce "ge-2/0/1" e "ge-2/0/2" al gruppo SRLG appena "battezzato" SRLG-10:
protocols {
mpls {
interface ge-2/0/1.0 srlg SRLG-10;
interface ge-2/0/2.0 srlg SRLG-10;
}
}
Infine, si abilita la Path Protection sul router P11. La seguente è una configurazione molto minimale, che consente al router di ingresso P11 di realizzare il LSP MPLS-TE primario in modo automatico, senza alcun vincolo (NOTA: il percorso viene determinato utilizzando il classico algoritmo SPF, utilizzando le metriche del Traffic Engineering (metriche TE)). Anche il percorso secondario viene determinato allo stesso modo.
protocols {
mpls {
label-switched-path P11-->P21 {
to 192.168.1.21;
primary LSP-1;
secondary LSP-2 standby;
}
path LSP-1;
path LSP-2;
}
}
Si noti l'opzione "standby", che è quella che consente di abilitare il Path Protection. Con questa opzione, il percorso di backup viene "pre-segnalato", ossia, è pronto all'uso in caso di fuori servizio del percorso primario. Questo abbrevia di molto i tempi di convergenza dal percorso primario a quello secondario.
A questo punto una domanda è lecita. Come utilizza il JUNOS i vincoli SRLG ? Bene, il JUNOS impone di default due vincoli nella determinazione del percorso secondario:
- Evitare il più possibile i link utilizzati dal percorso primario.
- Evitare i link che appartengono allo stesso gruppo SRLG dei link utilizzati dal percorso primario.
Entrambi questi vincoli sono automatici e non hanno bisogno di ulteriori configurazioni. Nel caso di esistenza di più percorsi a costo minimo che soddisfano i due vincoli, il JUNOS sceglie quello con il numero minimo di salti (minimum hop count). In caso di ulteriore parità sceglie a caso, anche se è possibile configurare altri tipi di criteri.
Nel nostro Case Study, il risultato finale, mostrato con il comando "show" seguente, è che viene selezionato come percorso primario il percorso P11-CS11-CS22-P21 (e questo l'ho forzato io attraverso la definizione di opportune metriche TE), mentre il percorso secondario, tenendo conto dei due vincoli sopra citati, è P11-CS12-CS22-P21.
... < output omesso > ...
*Primary LSP-1 State: Up
... < output omesso > ...
SRLG: SRLG-10
Computed ERO (S [L] strict [loose] hops): (CSPF metric: 30)
172.20.11.11 S 172.30.14.2 S 10.0.0.8 S 172.20.23.21 S
... < output omesso > ...
Standby LSP-2 State: Up
... < output omesso > ...
SRLG: SRLG-10
Computed ERO (S [L] strict [loose] hops): (CSPF metric: 250)
172.20.13.12 S 172.30.24.22 S 10.0.0.13 S 172.20.23.21 S
... < output omesso > ...
NOTA: anche Cisco, nelle sue piattaforme che utilizzano l'IOS XR consente di creare dinamicamente il percorso di backup e pre-segnalarlo. La configurazione minimale equivalente a quella JUNOS è la seguente:
interface tunnel-te1121
path-protection
path-option 1 dynamic
dove, come si può notare, non è necessario nemmeno specificare il percorso di backup.
Vi è però una piccola differenza tra IOS XR e JUNOS, nella determinazione del percorso di backup. L'IOS XR ragiona in modo più stringente, nel senso che se non esiste un percorso di backup che utilizza link completamente diversi dal percorso primario e link non appartenenti allo stesso gruppo SRLG, il percorso non viene pre-segnalato.
CONCLUSIONI
Avevo in animo di scrivere questo post da molto tempo. Non perché come ho già detto all'inizio tratti un tema particolarmente nuovo, ma credo tratti un tema poco conosciuto. MPLS-TE ha perso negli anni un po' del suo fascino iniziale, ma è ancora utilizzato da vari ISP e da varie reti Enterprise. L'utilizzo dei vincoli SRLG ne rafforza sicuramente la valenza, e rende più interessante la sua applicabilità.
Coming up next ... un post dal titolo "Banda e Throughput: un po' di chiarezza".
Coming up next ... un post dal titolo "Banda e Throughput: un po' di chiarezza".
Nessun commento:
Posta un commento