Disallineamento del duplex su una porta gateway VPN: leggete entrambe le estremità

Una copia di file attraverso il tunnel si blocca per un secondo, riprende, e i log della VPN non mostrano nulla. L'applicazione dà la colpa alla rete, la rete dà la colpa all'applicazione, e la porta dello switch è attiva da undici mesi. Questa analisi parte dalla pausa e si sposta verso il collegamento fisico: cosa sta facendo davvero la porta, cosa sta facendo l'estremità remota e cosa hanno fatto i contatori mentre osservavate. Vale la pena farlo prima che qualcuno tocchi un'impostazione del duplex.

Partite dalla pausa, non dalla porta

Descrivete il sintomo in modo che sia verificabile. Un blocco di circa un secondo durante un trasferimento massivo è un problema diverso da una connessione che si reimposta, e una pausa che si verifica una volta all'ora è diversa da una che si verifica ogni pochi secondi. Annotate il carico, la direzione e l'intervallo approssimativo.

Poi riproducetelo mentre osservate l'interfaccia. Un problema fisico si manifesta come movimento nei contatori durante il carico interessato, e un problema che non muove affatto i contatori è probabilmente sopra il livello di collegamento. Osservate per un minuto, non per un secondo, perché questi guasti spesso richiedono traffico sostenuto prima di manifestarsi. Il monitoraggio a riposo non dimostra nulla su un collegamento che si comporta male solo sotto carico.

Questo conta perché i disallineamenti del duplex hanno una firma: errori che compaiono solo sotto carico, nella direzione del traffico, mentre i ping piccoli e le sessioni interattive restano perfetti. Se anche il traffico a riposo fallisce, cercate prima altrove.

Leggete il modo operativo su entrambe le estremità

La configurazione salvata non è lo stato operativo. Una porta può essere configurata per l'autonegoziazione e finire in half duplex, oppure essere configurata su una velocità fissa che l'altra estremità non ha mai accettato. Leggete cosa sta facendo il collegamento in questo momento su entrambi i lati.

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

Annotate velocità, duplex e se l'autonegoziazione è attiva, poi ricavate gli stessi tre fatti dallo switch adiacente o dalla porta del provider. Una sola estremità non dice nulla, perché il disallineamento è una relazione e non un'impostazione. Mettete le due righe una accanto all'altra nel ticket, con l'ora in cui le avete lette. Metà del valore dell'esercizio è avere le due letture nello stesso posto.

Se non riuscite a leggere l'estremità remota, non potete diagnosticarlo. Chiedete al proprietario il modo operativo e i contatori, oppure organizzate l'accesso prima di iniziare a cambiare il vostro lato.

Che aspetto ha il caso 10/100 in half duplex

Sui collegamenti in rame 10/100, un'estremità che autonegozia può rilevare la velocità di un peer forzato senza apprendere la sua impostazione del duplex. Il rilevamento parallelo determina la velocità dal segnale, e il duplex viene assunto anziché negoziato, quindi un lato può finire in half duplex mentre l'altro funziona a duplex pieno.

La guida all'autonegoziazione di Cisco spiega proprio quel caso. Non è un argomento per disattivare la negoziazione ovunque, e non dice nulla di utile sul rame gigabit, dove il duplex è fisso e l'autonegoziazione è necessaria perché il collegamento si alzi.

La prova osservabile è un misto di errori che esistono solo in una direzione: errori FCS o CRC sul lato a duplex pieno, collisioni o collisioni tardive sul lato a mezzo duplex, e una velocità di trasferimento che crolla sotto carico mentre la latenza resta normale a riposo. Quell'asimmetria è la firma. Un collegamento semplicemente sovraccarico peggiora in entrambe le direzioni e in ogni momento.

Cambiate entrambe le estremità insieme, con una via di ritorno

Una correzione del duplex è un cambiamento coordinato, non locale. Forzare il proprio lato senza l'accordo dell'estremità remota è il modo in cui un collegamento funzionante diventa guasto, e il fatto che la CLI accetti il comando dimostra solo che la sintassi era valida.

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

Prima di eseguire qualcosa del genere, confermate che la piattaforma supporti la combinazione e che l'estremità remota venga modificata nella stessa finestra. Conservate un modo indipendente per amministrare il dispositivo, perché la porta che state per cambiare potrebbe essere quella che trasporta la vostra sessione di gestione.

Su molti collegamenti moderni la risposta corretta è lasciare l'autonegoziazione attiva su entrambe le estremità invece di forzare qualcosa. Forzare è un rimedio per un disallineamento specifico su una tecnologia specifica, non un miglioramento generale. Il rame gigabit in particolare ha bisogno dell'autonegoziazione perché il collegamento si alzi, quindi il consiglio per 10/100 non si trasferisce.

Confermate che i contatori si sono mossi in meglio

Dopo la modifica, rileggete lo stato operativo su entrambe le estremità e confermate che concordino. Poi eseguite lo stesso carico che ha prodotto la pausa e confrontate le differenze dei contatori invece dei totali dall'inizio, perché un totale che si accumula da un anno non può dirvi cosa è successo negli ultimi dieci minuti.

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

Un collegamento senza nuovi errori sotto lo stesso carico è la prova che vi mancava. Un collegamento che sbaglia ancora, o uno in cui i contatori non si sono mai mossi, vi manda al confine successivo invece che più a fondo nella discussione sul duplex. Entrambi gli esiti sono un progresso, che è più di quanto il file di configurazione possa darvi. Non saltate la seconda lettura perché la prima sembrava corretta.

Scrivete i numeri prima e dopo nel ticket con marche temporali. È quel registro che trasforma «la VPN va meglio» in qualcosa su cui il prossimo ingegnere può costruire.