Errori dell'interface Ethernet

L'interface ethernet di server Ubuntu che collega al multiplexer dell'ISP mostra gli 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'interface di Ubuntu è in grado di duplex completo, ma negozia solo la connessione half duplex. Quando ho collegato un dispositivo diverso (un router) a MUX, ho anche mostrato tali errori. La width di banda assegnata è di 50 mbps, ma ho solo 20 mbps. L'ISP è riluttante a cambiare il proprio dispositivo (sembra un interruttore ethernet o hub) nel MUX. Gli ingegneri dell'ISP accusano che la sua 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 profondamente le cause di quegli errori, o c'è qualcosa che posso fare per riconfigurare l'interface del mio server per liberarmi di quegli errori?

  • quale dovrebbe essere l'indirizzo MAC di destinazione per un indirizzo broadcast limitato (255.255.255.255)
  • Risoluzione hostname in una macchina con più porte di esecuzione eth
  • Cosa succede quando la richiesta ARP viene da una substring differente?
  • Inviare il segnale di networking su una lunga distanza di rame
  • Che cosa è e quali problemi provocano un "errore carrier"
  • Quale strumento devo fidarmi, mii-tool e ethtool non mi mostrano gli stessi valori
  • Tutti i messaggi di avvio di Debian
  • Cosa succede se un controllore cloud di OpenStack muore?
  • L'unità disco ha letto errori che ... fermano?
  • One Solution collect form web for “Errori dell'interface Ethernet”

    Molto probabilmente avete un duplex non corrispondente a causa dell'hard-coding dell'ISP al loro lato a 100-Full che distriggers essenzialmente la negoziazione automatica sul ISP Ethernet PHY.

    Con l'ISP impostato a 100-Full e il tuo lato rimanente a auto / auto (un appuntamento, ma comune), la negoziazione automatica dal tuo lato configurerà l'interface a 100-Half – un duplex non corrispondente come lato ISP rimarrà 100-Full.

    fissare

    È ansible risolvere il problema codificando la tua Ethernet PHY a 100-Full – o specificamente qualunque sia l'ISP impostato. La maggior parte degli ISP utilizza 100-Full.

    Ulteriori dettagli

    Con la mancata corrispondenza duplex di 100-Full a 100-Half, il lato 100-Full distriggers CSMA / CD mentre CSMA / CD rimane in vigore sul lato 100-Half. Il lato 100-Full trasmette senza riguardo al fatto che il mezzo sia libero. Il lato 100-Half effettua controlli CSMA / CD e backoff come definito da CSMA / CD. Ecco perché puoi raggiungere solo 20 Mb / s su quello che dovrebbe essere un circuito Internet di 50 Mb / s . Il CSMA / CD backoff a causa delle collisioni di rilevazione laterale 100-Half sta limitando il throughput.

    Dall'hard-coding dell'interface a 100-Full per abbinare l'ISP, entrambe le parti avranno distriggersto CSMA / CD, pertanto il rilevamento di backoff e collisione sarà disabilitato e si dovrebbero get numbers molto più vicini alla velocità di trasmissione dati di 50 Mb / s.

    Storia

    Molti hard-code di ISP hanno scambiato la loro networking Ethernet PHY poiché c'era un momento in cui era molto più affidabile. Quando è stato rilasciato lo standard 802.3u Fast Ethernet standard di 100 Mb / s, è stata rilasciata la negoziazione automatica della velocità e il duplex, ma non richiesto . Non era fino a quando standard 802.3z di 1 Gb / s Gigabit Ethernet quando la negoziazione automatica era richiesta dalla norma.

    Molti ingegneri di networking hanno idee sbagliate sulla negoziazione automatica. Il più grande errore è che la negoziazione automatica può negoziare correttamente velocità e duplex se solo un lato implementa la negoziazione automatica. Questo è falso – come hai visto.

    La ragione di questo probabilmente deriva dal seguente – se un lato è hard-coded a 100-Full, l'altro lato che esegue l'auto-negoziazione sembra sempre capire la parte di 100 Mb / s. Stesso se un lato è hard-coded a 10-Full – l'altro lato che esegue l'auto-negoziazione può capire la parte di 10 Mb / s. La capacità di determinare la velocità di collegamento è da una funzionalità chiamata rilevamento parallelo che prova il segnale di livello fisico ricevuto su tutte le velocità di collegamento supportte 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 si possono verificare disallineamenti duplex: un'interface ricadrà sempre a metà duplex quando non è in grado di determinare l'altro lato attraverso la negoziazione automatica.

    palco improvvisato

    A un certo tempo ci fu un supporto spotty per la negoziazione automatica e provocò altrettanti problemi di cui era destinato a risolvere. Quel momento, in questa opinione di ingegnere di networking – è passato. Sebbene esistano ancora problemi di negoziazione automatica, il numero di problemi che ho visto a causa della negoziazione automatica negli ultimi 5 anni sono nani il numero di problemi che ho visto a causa della disconnessione della negoziazione automatica.

    Non ho mai avuto un ISP che non voleva cambiare il loro handoff Ethernet per auto / auto al momento della richiesta. Con la maggior parte dei modem e gateway via cavo e DSL questo non è un problema. Sono i router CPE NxT1 e fibre gestite con handoff Ethernet where risiede normalmente questo problema. Il problema è che un amministratore di networking deve chiedere in primo luogo.

    Con un ISP che codifica a 100-Full hanno dato l'obbligo . Un obbligo che deve essere documentato e proseguito. La negoziazione automatica è la tecnologia stabile, è stata da anni e si occupa di questo problema per noi. Come accennato in precedenza, il numero di problemi causati dalla negoziazione automatica è ben al di là del numero di problemi che sorgono per il fatto che esso è disabilitato nel 2011. La tecnologia esiste per risolvere questo problema, usarlo. Forse dovremmo impostare manualmente l'iniziale TCP SYN, MSS e gestire la window di ricezione per each circuito virtuale TCP? Sto scherzando.

    Rant off.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.