Errori dell'interfaccia Ethernet

L'interfaccia Ethernet dei miei server Ubuntu che si collega al multiplexer dell'ISP mostra errori. Ecco l'istantanea:

          RX packets:204564288 errors:3193970 dropped:0 overruns:0 frame:3138402
          TX packets:29305799 errors:38752 dropped:0 overruns:0 carrier:38762
          collisions:2205053 txqueuelen:1000

L'interfaccia di Ubuntu è capace di full duplex ma negozia solo la connessione half duplex. Quando ho collegato un dispositivo diverso (un router) a MUX, ha anche mostrato tali errori. La larghezza di banda assegnata è di 50 Mbps, ma ottengo solo 20 Mbps. L'ISP è riluttante a cambiare il proprio dispositivo (sembra uno switch o un hub Ethernet) nel MUX. Gli ingegneri dell'ISP danno la colpa al mio fianco. Ma ho controllato con più di 3 dispositivi, tutti hanno mostrato errori. Quindi, ci sono strumenti per Linux che posso usare per sondare in profondità le cause di quegli errori o c'è qualcosa che posso fare per riconfigurare l'interfaccia del mio server in modo da sbarazzarmi di quegli errori?

È molto probabile che si abbia una mancata corrispondenza duplex a causa dell'ISP che codifica a fondo il loro lato su 100-Full, essenzialmente disabilitando la negoziazione automatica sull'ISP Ethernet PHY.

Con l'ISP impostato su 100-Full e il tuo lato rimane su auto / auto (un sospetto, ma uno comune), la negoziazione automatica sul tuo lato configurerà l'interfaccia su 100-Half - una mancata corrispondenza duplex come lato ISP rimarrà 100 pieno.

fix

Puoi risolvere il problema codificando il tuo Ethernet PHY su 100-Full - o specificamente qualunque sia l'ISP impostato. La maggior parte degli ISP usa 100-Full.

Dettagli aggiuntivi

Con la mancata corrispondenza duplex da 100 pieno a 100 metà, il lato 100 pieno disabilita CSMA / CD mentre CSMA / CD rimane attivo sul lato 100 metà. Il lato 100-Full trasmette indipendentemente dal fatto che il mezzo sia libero o meno. Il lato 100 esegue controlli e backoff CSMA / CD come definito da CSMA / CD. Questo è il motivo per cui puoi ottenere solo 20 Mb / s su quello che dovrebbe essere un circuito Internet a 50 Mb / s . Il backoff di CSMA / CD a causa delle collisioni di rilevamento del lato 100 sta limitando la velocità di trasmissione.

Codificando a fondo l'interfaccia su 100-Full per adattarsi all'ISP, entrambe le parti avranno CSMA / CD disabilitato, quindi il backoff e il rilevamento delle collisioni saranno disabilitati e si dovrebbero ottenere numeri molto più vicini alla velocità dei dati del circuito Internet di 50 Mb / s.

Storia

Molti ISP codificano i loro hand-off Ethernet PHY dato che c'era un tempo in cui era molto più affidabile farlo. Quando è stato rilasciato lo standard Fast Ethernet 802.3u 100 Mb / s originale, era presente la negoziazione automatica di velocità e duplex, ma non necessaria . Non era fino allo standard Gigabit Ethernet 802.3z 1 Gb / s quando lo standard richiedeva la negoziazione automatica .

Molti ingegneri di rete hanno idee sbagliate sulla negoziazione automatica. Il più grande malinteso è che la negoziazione automatica può negoziare correttamente la velocità e il duplex se solo una parte implementa la negoziazione automatica. Questo è falso - come hai visto.

La ragione di ciò probabilmente deriva da quanto segue: se una parte è hard-codificata a 100-Full, l'altra parte che esegue la negoziazione automatica sembra sempre capire la parte da 100 Mb / s. Lo stesso se un lato è hardcoded su 10-Full - l'altro lato che esegue la negoziazione automatica può capire la parte da 10 Mb / s. La capacità di determinare la velocità del collegamento proviene da una funzione chiamata rilevamento parallelo che prova il segnale del livello fisico ricevuto su tutte le velocità di collegamento supportate localmente fino a quando non viene trovata una corrispondenza. Tuttavia, il rilevamento parallelo funziona solo per la velocità, non per la corrispondenza duplex. Questo è il motivo per cui possono verificarsi disallineamenti duplex - poiché un'interfaccia tornerà sempre al mezzo duplex quando non è in grado di determinare l'altro lato attraverso la negoziazione automatica.

palco improvvisato

Un tempo c'era un supporto discutibile per la negoziazione automatica e causava tutti i problemi che doveva risolvere. Quella volta, secondo l'opinione dell'ingegnere di rete, è passato. Sebbene esistano ancora problemi di negoziazione automatica, il numero di problemi che ho riscontrato a causa della configurazione della negoziazione automatica negli ultimi 5 anni riduce il numero di problemi che ho riscontrato a causa della disabilitazione della negoziazione automatica.

Non ho mai avuto un ISP non disposto a cambiare il loro handoff Ethernet in auto / auto quando mi è stato chiesto. Con la maggior parte dei modem e gateway via cavo e DSL questo non è un problema. È il NxT1 e i router CPE gestiti in fibra con handoff Ethernet dove di solito si trova questo problema. Il problema è che un amministratore di rete deve prima chiedere.

Con un ISP hard-coding su 100-Full hanno dato un obbligo . Un obbligo che deve essere documentato e continuato. La negoziazione automatica è una tecnologia che è ormai stabile, esiste da anni e si occupa di questo problema per noi. Come accennato in precedenza, il numero di problemi causati dalla negoziazione automatica è di gran lunga superiore al numero di problemi che sorgono a causa della sua disabilitazione nel 2011. La tecnologia esiste per risolvere questo problema, usarlo. Forse dovremmo impostare manualmente i SYN TCP iniziali, MSS e gestire la finestra di ricezione anche per ogni circuito virtuale TCP? Sto scherzando.

Rant off.