Perché il tuo L2VPN ignora l'RSVP-TE LSP che hai appena costruito

Due ingegneri possono uscire dalla stessa finestra di manutenzione convinti che il nuovo percorso sia in servizio, ed entrambi sbagliarsi per motivi diversi. Uno ha costruito l'LSP e ha dato per scontato che il servizio lo seguisse. L'altro ha lasciato in pace il servizio e ha dato per scontato che nulla fosse cambiato. Uno pseudowire usa sempre e solo il trasporto verso cui l'indirizzo del suo peer si risolve in quel momento, quindi la domanda vera è che cosa produce ora quella risoluzione, e i due progetti rispondono in modo diverso.

Un'etichetta nomina un servizio, l'altra sposta un pacchetto

L'etichetta dello pseudowire, segnalata da LDP mirato come descritto nella RFC 4447, dice al bordo del provider ricevente quale circuito di collegamento deve ricevere il frame. Non dice nulla su come il frame sia arrivato lì. L'etichetta sottostante appartiene al trasporto, e quello stack è costruito da qualunque cosa abbia annunciato raggiungibilità per il loopback del peer, che sia LDP, RSVP-TE o un percorso instradato a segmenti. Poiché protocolli diversi segnalano i due livelli, uno può essere sano mentre l'altro è obsoleto. Quella separazione è tutta la fonte della confusione.

Vale la pena dirlo chiaramente: lo pseudowire non sceglie l'LSP. Consegna un frame al trasporto, e il trasporto decide in base all'indirizzo di destinazione che gli è stato dato.

È anche per questo che un ping pulito attraverso il nuovo LSP dimostra così poco. L'LSP può essere attivo, etichettato e trasportare altri servizi mentre il tuo pseudowire si risolve ancora attraverso un altro next hop. Finché non leggi il binding, quei due fatti non hanno rapporto.

Opzione A: fissare lo pseudowire a un trasporto scelto

Fissare significa rendere deterministica la risoluzione di trasporto del servizio. A seconda della piattaforma, ciò prende la forma di una politica di selezione del tunnel, di un endpoint di trasporto esplicito sul servizio, o di una politica di routing che riscrive il next hop per l'indirizzo del peer. Tutte e tre fanno la stessa cosa sotto: forzano la risoluzione di una destinazione su un LSP specifico. È questo che rende il risultato verificabile dopo.

Il costo è l'ampiezza. Una politica che corrisponde a un indirizzo di peer tocca ogni servizio puntato a quel peer, non solo lo pseudowire che avevi in mente.

Il ripiego merita una decisione prima della finestra di cambiamento, non durante. Se l'LSP fissato cade, o lasci che il servizio percorra un altro percorso approvato o lo lasci fermare. Una politica che ripiega in silenzio su un percorso che viola un vincolo di latenza o di disgiunzione ha trasformato un'interruzione pulita in qualcosa di molto più difficile da spiegare a chiunque.

Opzione B: lasciare che l'IGP scelga e osservare cosa succede

Lasciare in pace il servizio è un progetto legittimo, e spesso il migliore. Lo pseudowire segue la stessa risoluzione di qualsiasi altro traffico verso il loopback del peer, quindi eredita la convergenza dell'IGP, la soppressione dei prefissi e la ridondanza che il core già offre. Meno politiche significano meno posti dove una corrispondenza obsoleta può nascondersi. Lo scambio è che non controlli più quale percorso prende il servizio, solo che un percorso esista.

Il multipath a costo uguale acuisce quello scambio più di quanto sembri a prima vista. L'hashing è per flusso, quindi due conversazioni dentro un solo pseudowire possono partire con etichette esterne diverse.

Leggi l'inoltro installato prima di fidarti di uno dei due

Parti dall'indirizzo del peer invece che dal servizio. Su Junos, show route 203.0.113.1 detail stampa il next hop selezionato e l'operazione di etichetta, e show route table mpls.0 mappa l'etichetta in ingresso a quell'operazione. Su IOS XR, show mpls l2transport vc 100 detail dà lo stato dello pseudowire insieme allo stack imposto.

Conferma l'LSP che il trasporto usa davvero, non quello che nomina il tuo documento di progetto. traceroute mpls ipv4 203.0.113.1/32 su IOS XR percorre il cammino commutato da etichette ed elenca le etichette e le interfacce in uscita lungo di esso, che è la cosa più vicina a guardare il percorso da soli. Poi ripeti l'esercizio dal bordo del provider remoto, perché la direzione di ritorno si risolve in modo indipendente e l'asimmetria è comune dopo un'implementazione parziale delle politiche. Un percorso giusto in una direzione e sbagliato nell'altra è peggio di uno uniformemente sbagliato, perché metà dei tuoi test passerà.

Conserva le prove con la scheda del servizio: indirizzo del peer, next hop, etichetta esterna e la data in cui hai verificato. Le politiche di routing invecchiano male, e nessuno ricorda quale fosse in vigore due trimestri fa.

Scegli per modalità di guasto, non per preferenza

Il fissaggio si adatta ai servizi con un vincolo che l'IGP non può esprimere, e ai team che riescono a mantenere la politica attraverso ogni cambiamento. Lasciarlo all'IGP si adatta ai servizi che devono sopravvivere a ogni singolo guasto senza una persona nel ciclo.

La domanda decisiva è quanto ti costa un percorso sbagliato. Se un servizio sull'LSP sbagliato rende solo un po' peggio, lascia decidere l'IGP e spendi lo sforzo nel monitoraggio. Se un percorso sbagliato rompe un contratto, un rilievo di audit o un requisito di disgiunzione, fissalo e scrivi il ripiego. Poi prova il ripiego, perché un ripiego non testato è un presupposto e non un piano. In ogni caso, rileggi il binding installato dopo qualsiasi cambiamento al core, e tratta uno pseudowire che è salito come prova di nulla se non che la segnalazione funziona.