Normalizzare i tag VLAN agli estremi del pseudowire: un runbook

Definite quale trama deve ricevere ciascun estremo cliente prima di toccare il pseudowire. Nel caso semplice, il CE A invia un tag che delimita il servizio e il CE B si aspetta trame non taggate, ed è l’estremo del provider il punto in cui questa differenza viene risolta. Il tag è politica locale e non fa parte del contratto Ethernet del cliente, e il pseudowire trasporta la trama concordata invece di quella originale. Scrivete entrambe le direzioni prima di qualsiasi configurazione.

Scrivere prima il contratto di trama

La direzione di andata rimuove un tag e quella di ritorno lo riaggiunge. Se ne scrivete solo una, testerete un percorso funzionante in una direzione e dichiarerete sano il circuito.

Mantenete il contratto abbastanza breve da incollarlo nel ticket di modifica: quale estremo invia taggato, quale si aspetta non taggato e quale valore di tag delimita il servizio.

Concordare la modalità del pseudowire

La RFC 4448 distingue le modalità pseudowire raw e tagged e descrive come vengono gestiti i tag che delimitano il servizio. La modalità raw può comunque trasportare tag che appartengono alla trama del cliente, quindi la distinzione riguarda il ruolo di servizio di un tag e non la mera presenza di un’intestazione 802.1Q. Leggere la modalità come tagged rispetto a untagged è il modo più comune di inquadrare male questo lavoro. Concordate la modalità con il peer prima di decidere quali operazioni vi servono.

Poi verificate il tipo effettivo di pseudowire e i parametri del peer. Un collegamento VLAN locale e un collegamento di porta remota richiedono un accordo di interworking supportato, e due istruzioni di riscrittura locali non dimostrano che i tipi di circuito annunciati coincidano.

Se le aspettative su control word e MTU differiscono, avete un problema di negoziazione che nessuna riscrittura risolverà. Confermatele entrambe dalla configurazione in esecuzione del peer invece che dal documento di progetto.

Applicare le operazioni locali sui tag

guida alla riscrittura VLAN CCC di Juniper documenta le operazioni pop, push e swap con restrizioni specifiche della piattaforma. Per un’unità taggata compatibile già configurata, la direzione illustrativa è input-vlan-map pop in ingresso e output-vlan-map push in uscita. Quelle righe illustrano operazioni, non una configurazione completa di interfaccia o di circuito. Confermate la piattaforma e la release esatte invece di applicare ovunque l’esempio di una famiglia di dispositivi.

Le impostazioni VLAN e di incapsulamento supportate dall’unità devono comunque definire il tag e la classificazione previsti. Un’istruzione di riscrittura su un’unità che classifica le trame sbagliate sposta il problema invece di risolverlo.

Preservate gli eventuali tag cliente interni richiesti dal servizio. Per i tag in pila, stabilite quale tag esterno state manipolando prima di rimuovere qualsiasi cosa.

Dimensionare il budget, non solo i tag

Includete i tag mantenuti, lo stack MPLS effettivo e la control word nel budget di dimensione. La RFC 8469 raccomanda una control word per i pseudowire Ethernet, e questa raccomandazione cambia il budget di trama che la vostra piattaforma la abiliti o meno per impostazione predefinita. Riconciliate una discrepanza di MTU invece di sopprimerne l’avviso come riparazione. Un avviso soppresso è un’interruzione pianificata a cui è stata cancellata la data.

Verificate lo stesso budget su entrambi gli estremi del provider, perché basta che un lato aggiunga un tag e l’altro aggiunga una control word per rompere un payload che prima funzionava.

Se i numeri non concordano, cambiate il piano invece del livello di log.

Accettarlo trama per trama

Per l’accettazione, ispezionate la trama attesa su ogni collegamento cliente in entrambe le direzioni. Poi esercitate il traffico applicativo e di controllo di cui il servizio ha davvero bisogno secondo il piano di test approvato, perché un ping dimostra molto meno di una trama taggata che arriva intatta. Registrate il contratto di trama in ingresso e in uscita insieme alla configurazione del circuito. È quel registro che rende verificabile la modifica successiva.

Tenete modalità, operazioni sui tag, budget MTU e risultato del test in un unico posto, perché hanno senso solo insieme. Suddividerli su tre ticket garantisce che il prossimo ingegnere riscopra lo stesso vincolo.

Il circuito è finito quando entrambe le direzioni corrispondono al contratto scritto all’inizio, non quando passa la prima direzione.