Un tunnel logico Junos è due collegamenti, non un solo link

All’interno del router, un’interfaccia lt- sembra esattamente un cavo, e proprio questa impressione causa gran parte della confusione. Non è un solo link ma due collegamenti: ogni estremità appartiene a un servizio, ogni estremità ha il proprio incapsulamento, e la coppia inoltra solo quando entrambi i servizi sono uniti correttamente. Seguite i cinque passi qui sotto in ordine e considerate un commit pulito come l’inizio della verifica, non come la fine del lavoro. Ogni passo lascia un documento che l’ingegnere successivo può controllare senza ripetere l’indagine.

Passo 1: scrivete il foglio di lavoro dei collegamenti

Prima di toccare la configurazione, disegnate cosa deve unirsi a cosa. Un lato termina un circuito di livello 2 punto a punto, l’altro si unisce a un’istanza VPLS, e il tunnel logico sta in mezzo trasportando frame dall’uno all’altro. Nominate esplicitamente entrambi i servizi, perché un circuito punto a punto, un’istanza VPLS e un’interconnessione EVPN-VXLAN non sono intercambiabili solo perché ciascuno può essere descritto come una cucitura.

Annotate i numeri di unità su entrambe le estremità e a quale servizio appartiene ciascuna. Quel foglio è l’unico artefatto che resterà corretto dopo tre modifiche e un rollback.

Passo 2: fissate le unità peer e l’incapsulamento

Le due unità devono risiedere sulla stessa interfaccia di tunnel logico e puntarsi a vicenda, e un’unità può avere esattamente un peer. La documentazione Juniper sul tunnel logico indica entrambi i vincoli insieme agli incapsulamenti supportati e alle risorse di piattaforma consumate dall’interfaccia. Verificateli rispetto all’hardware e alla release installati, non rispetto a un esempio di laboratorio di un’altra scheda di linea. Un’unità peer referenziata su due interfacce lt diverse viene confermata senza errori e non inoltra nulla.

Poi scegliete l’incapsulamento che corrisponde al servizio di ciascuna estremità. Uno schizzo della coppia è questo:

set interfaces lt-0/0/0 unit 0 encapsulation vlan-ccc
set interfaces lt-0/0/0 unit 0 peer-unit 1
set interfaces lt-0/0/0 unit 1 encapsulation vlan-vpls
set interfaces lt-0/0/0 unit 1 peer-unit 0

Copiare le parole chiave Ethernet-CCC ed Ethernet-VPLS in un servizio VLAN senza armonizzare il tagging è l’altro modo comune di produrre una coppia che sale e non inoltra nulla.

Passo 3: collegate ogni estremità al proprio servizio

Ogni unità appartiene a una definizione di servizio, e il servizio deve davvero includerla. Per le disposizioni MX di livello 2 supportate, la documentazione indica l’appartenenza a bridge-domain o VPLS come ciò che rende bidirezionale l’inoltro, il che significa che una coppia peer corretta con un’unità senza appartenenza è una coppia di estremità che parlano al nulla. Aggiungete l’appartenenza nello stesso commit delle unità, così le due non potranno mai contraddirsi.

Configurate la segnalazione del pseudowire e l’appartenenza all’istanza come parte della stessa modifica, perché è l’estremità remota del circuito a dare al lato VPLS qualcosa da cui imparare.

Passo 4: preventivate risorse e dimensione del frame

Un collegamento interno consuma comunque risorse di inoltro. La documentazione elenca le implicazioni di larghezza di banda della piattaforma per i tunnel logici, quindi controllatele invece di supporre che interno significhi gratuito.

Allineate l’MTU del servizio e il modello di tagging su entrambi i collegamenti e sullo pseudowire remoto. Non copiate un valore MTU di esempio senza stabilire quali intestazioni conti l’impostazione interessata, perché un salto interno che riduce silenziosamente il budget fallirà esattamente dove il traffico utente è maggiore.

Passo 5: verificate l’inoltro, poi cercate i loop

Inviate traffico in entrambe le direzioni e ispezionate lo stato del servizio, non solo quello dell’interfaccia. show interfaces lt-0/0/0 vi dice che la coppia è amministrativamente attiva, e show vpls connections vi dice se l’istanza ha una connessione su cui imparare. Nessuno dei due dimostra che un frame entrato su un servizio sia uscito sull’altro, quindi provatelo esplicitamente. Inviate da un host su un lato a un host sull’altro, con lo stato del servizio visibile mentre il traffico scorre.

Infine, verificate se un altro percorso fisico o logico è già unito allo stesso dominio Ethernet. Aggiungere questo collegamento può cambiare il comportamento di flooding e creare un loop che prima non esisteva, e il sintomo comparirà altrove del tutto. Pianificate la ridondanza che volete invece di scoprire un percorso di livello 2 non sorvegliato durante un incidente.