Ce poate cauza pachete de rețea constând din PUU?

Avem un sistem care suferă de întreruperi de comunicații pe o rețea ethernet gigabit. Sarcina de trafic în rețea este de așa natură încât să streseze ușor o rețea de 100 Mb, dar există switch-uri gigabit și NIC-uri și cabluri peste tot - sau cel puțin așa mi-a spus clientul care a construit rețeaua la care ne conectăm.

Am conectat un laptop care rulează Wireshark printr-un hub 100baseT și am constatat că a raportat o mulțime de pachete „Ethernet II” în care datele brute, atunci când sunt afișate ca ASCII, arată, practic, așa:

PUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU

Desigur, am numit imediat această problemă „Network PUU” și au urmat multe chicoteli.Cu toții avem aproximativ patruzeci de ani, dar cred că unii dintre noi nu cresc niciodată (vinovați!)

Oricum, mai serios, alte pachete perfect valide erau corupte de aceste date. Antetele IPv4 au fost înlocuite cu octeți U octeți, precum și existența corupției datelor care ar determina software-ul să respingă datele, chiar dacă sumele de verificare IP nu au eșuat să se potrivească. Suntem destul de siguri că aceste date care răspândesc în rețea cauzează întreruperile comunicațiilor. Ceea ce nu știm este de unde ar putea veni.

A mai văzut cineva să se întâmple asta? ai rezolvat-o? Ți-ai dat seama de unde a venit?

====EDITAT====

S-a adăugat mențiunea hub-ului la descrierea originală, deoarece, judecând după comentariile de mai jos, este cea mai probabilă sursă a corupției! Instrumentul pe care l-am folosit pentru a încerca să găsim problema de rețea pare să fi adăugat o problemă de rețea nouă și mai gravă.

Oricum, mai serios, alte pachete perfect valide erau corupte de aceste date. Antetele IPv4 erau înlocuiți de octeți cu octeți U, precum și coruperea datelor care ar determina software-ul să respingă datele, chiar dacă sumele de verificare IP nu se potriveau.

Este surprinzător că doar biți alternativi (U este ASCII 0x55 sau 01010101b) alcătuiesc de fapt cadre Ethernet valide sau chiar pachete IP valide.Dacă această corupție se accesează cu crawlere și în cadre/pachete în principal intacte, poate fi cauzată doar de - cel mai probabil - un comutator defect (memorie tampon proastă) sau o gazdă defectuoasă (NIC sau RAM).

Dacă datele de cadru sunt corupte în transport, pe cablu, FCS-ul foarte probabil să nu reușească să verifice, făcând chiar următorul comutator să piardă acel cadru. Cu toate acestea, dacă un astfel de cadru este transportat prin rețea cu un FCS valid, trebuie să fi fost corupt inainte de acel FCS a fost calculat, ceea ce impune un comutator sau gazdă defecte.

Va trebui să urmăriți traficul respectiv. Dacă adresa MAC sursă nu este validă sau nu poate fi verificată pe comutatoarele intermediare (negestionate), va trebui să urmăriți drumul înapoi de-a lungul cablurilor.

Se pare că ai un card NIC prost. Dacă adresa MAC sursă este validă, o puteți găsi verificând tabelele MAC ale comutatorului. Dacă este corupt, va trebui doar să începeți să deconectați dispozitivele pentru a-l găsi.

Sună ca și cum ai avea un dispozitiv (probabil un comutator de 100 Mb/s) undeva care nu poate face față fluxului de trafic și începe să corupă pachetele atunci când bufferele sale interne depășesc.
(Sau doar are o memorie RAM proastă).

Nu observă că are pachete corupte și le va retransmite cu plăcere, cu sume de control noi proaspăt calculate.Deci pachetele proaste sunt acceptate de alte switch-uri (checksum este bun, switch-urilor nu le pasă că conținutul nu are sens) și redirecționate prin întreaga rețea.

Este de fapt mai rău de atât:
Luați în considerare modul în care comutatoarele învață ce dispozitiv (adresă Mac) se află în spatele fiecărui port. Orice pachet destinat unei adrese mac care nu este încă învățată de către comutator este inundat către toate porturile de comutare (cu excepția celui de la care a venit). Acest lucru transformă efectiv un pachet pentru o adresă Mac neînvățată într-o difuzare temporară.
Deoarece switch-urile dvs. nu vor învăța niciodată aceste adrese mac (la urma urmei sunt corupție, nu adrese mac reale), TOATE sunt tratate ca niște transmisii...
Acest lucru inundă în esență întreaga rețea cu pachete care nu pot fi livrate.
(Și rețineți că atenuările normale ale furtunii de difuzare nu funcționează în acest caz. Ele acționează numai asupra pachetelor de difuzare REALE, nu asupra acestor inundații de învățare.)

Singura modalitate de a depana acest lucru este să dezactivați câte un comutator la un moment dat și să vedeți dacă asta face ca problema să dispară. Dacă îl puteți restrânge la 1 comutator, acesta va fi acel comutator în sine sau un dispozitiv conectat în spatele acelui comutator.

Diferența dintre un hub și un comutator este că, atunci când un comutator primește o coliziune, fie aruncă al doilea pachet, fie îl stochează și apoi îl redirecționează când primul pachet se termină; unde un hub va permite cu bucurie să aibă loc coliziunea și doar înlocuiește conținutul pachetului cu 10101... pentru a indica că a fost o coliziune și continuă să trimită până când ambele pachete s-au terminat.

Soluția aici este să scapi de butuci, deoarece sunt depășiți. Au încetat să mai producă hub-uri înainte ca 1G să fie disponibil, așa că un hub trebuie să fie 100M sau mai lent. Standardul de rețea 1G nu acceptă hub-uri.

Pentru un pic de istorie, înainte de a exista hub-uri, au existat repetitoare. Diferența dintre un repetor și un hub este că repetorul primește semnalul analogic, îl curăță ușor înapoi într-un val pătrat frumos și apoi îl retransmite, unde un hub se uită puțin la ceea ce este în pachet și încearcă să asigurați-vă că pachetul este bine format. Cu toate acestea, niciunul dintre ei nu face nimic pentru a remedia coliziunile, ci doar le lasă să se întâmple. Repetoarele și hub-urile sunt din vremea când Ethernetul era considerat a fi o magistrală fără tampon și doar un dispozitiv din rețea poate vorbi odată. Când ethernetul era o magistrală adevărată (10base2 și 10base5), pentru a porni un pachet, transmiteți biți de pornire (10101...) până când primul bit ajunge la cele mai îndepărtate capete ale rețelei și dacă nimeni altcineva nu v-a întrerupt între timp , apoi vă continuați pachetul. Dacă sunteți întrerupt, aveți o coliziune și ambele părți se retrag și încearcă din nou la un moment dat mai târziu. Dacă una dintre părți nu avortează, atunci ai o coliziune târzie. Hub-ul tău transformă coliziunile tale târzii în toate elementele de pornire. Este posibil ca ceva din cale să nu recunoască pachetul ca o coliziune târzie și, în loc să-l abandoneze, îl reformează ca un pachet valid. Sau snifferul dvs. de pachete promiscue vede pachete nevalide, precum și pe cele valide.

Comparați acest lucru cu un comutator, care nu numai că remediază coliziunile, dar poate suporta full duplex, în cazul în care un pachet este transmis în timp ce este primit altul diferit. Standardul 100M acceptă comutatoare care acceptă și nu full duplex, iar acest lucru este negociat între dispozitive atunci când cablul este conectat. Standardul Ethernet 1G necesită ca toate dispozitivele să accepte full duplex, astfel încât un hub nu este permis pe o conexiune 1G, și, prin urmare, hub-urile 1G nu există.