Cum diagnosticăm pierderile de pachete și dovedim că problema NU e în "curtea clientului"?

[Viper]

Salut, sunt multe postări pe forum despre pierderi de pachete (packet loss) și efectele acestora: lag în aplicații, streaming întrerupt, deconectări din jocuri și alte situații neplăcute, mai ales într-un anumit interval orar. Nu știu câte dintre ele au fost rezolvate și câți au renunțat la bătălia cu "suportul tehnic" și au plecat pe la alți operatori. Dar pentru cei care nu au alte variante și sunt totuși afectați de așa ceva, aceștia nu trebuie ignorați doar pentru că "nu au unde să plece".

Când deschideți o sesizare pentru a raporta acest lucru, de foarte multe ori se începe cu plasarea problemei în "curtea clientului". Se pierde timp cu repornirea, resetarea sau reprovizionarea ONT-ului (sau chiar înlocuirea acestuia), în loc să se diagnosticheze corect problema de la bun început.

Ce scriu aici se adresează celor care vor să înțeleagă exact unde se pierd pachetele. Totodată, aceste descoperiri pe care le faceți singuri NU ar trebui ignorate de către cei care preiau sesizarea, ci trimise la departamentul abilitat dacă ați oferit suficiente informații despre problemă, cum s-a mai întâmplat ...

Regula de aur: sesizarea de pierderi de pachete / congestie NU se face pentru testele prin wireless, ci exclusiv pentru testele făcute prin cablu, cu un dispozitiv conectat direct în ONT. (Dacă aveți ONT-ul în mod Bridge, cereți trecerea lui temporară în mod Router înainte să deschideți sesizarea, ca să nu vi se închidă tichetul instant pe motiv că e vinovat routerul personal și nu se oferă suport pentru acesta).

Sesizarea se face doar după ce ați eliminat rețeaua locală ca potențial vinovat. Recent am citit pe undeva: "eu ți-am dat dovada chiar din ONT". Nu, dacă dai ping de pe un PC conectat prin wireless sau chiar prin cablu la ONT, acel test nu se încadrează la "direct din ONT" și nu reprezintă o dovadă incontestabilă. Direct din ONT ar putea doar cei de la suport să "dovedească" pierderile, dacă vor. Între ONT și PC există: mufe, cabluri, drivere, sistem de operare, antene, surse de bruiaj etc., în funcție de tipul conexiunii (cablu sau wireless).

Revenind, toată lumea a auzit de ping. Dăm un ping într-un IP public, vedem pierderi, gata, problemă. Corect, dar un ping nu ne spune și UNDE sunt acele probleme.

Ce facem? Folosim utilitare mai potrivite! mtr sub Linux sau WinMTR pentru Windows (personal m-am înțeles bine cu fork-ul de aici: WinMTR (Redux) v1.00). Sau alte utilitare similare.

Bun, dar ce fac diferit aceste utilitare față de un simplu ping și cum funcționează?
Pe scurt, în loc să trimită pachete direct la destinația finală, ele îți arată fiecare hop (router) dintre dispozitivul tău și IP-ul destinație, măsurând continuu pierderile și latența pentru fiecare nod în parte, nu doar la capăt de linie.

Ok, și la ce ajută? În primul rând, te ajută să elimini o problemă locală. Primul hop care apare este routerul tău (ONT-ul, dacă NU este în Bridge). Dacă la acest hop apar 0 pachete pierdute, dar începând cu al doilea se raportează pierderi, problema este clar după ONT. Adică în "curtea" Orange: de la nivel optic pe fibră până la setări neoptimizate pentru limitările de trafic sau altele.

Exemplu de "mtr" OK:

 Exemple de "mtr" cu probleme în curtea Orange:

 

 

(Ultimele două sunt luate din topicul menționat anterior).

Atenție totuși că pot exista hop-uri care nu răspund la aceste pachete de test (sau nu la toate), după cum se vede în primul screenshot, hop-ul 4 are 100% pierderi, dar hop-ul nr. 5 are 0% pierderi, deci este ok, nu ne îngrijorează acel hop.

Dacă în schimb avem ca în screenshot-ul al 2-lea, unde avem 6% loss la hop-ul nr. 2 iar această pierdere se propagă la toate hop-urile următoare (hop 3, 5, 6 (destinație)), acolo este saturația, acolo e problema. Ignorăm hop-ul nr. 4 fiindcă pare să nu răspundă la toate pachetele (11% vs 6% imediat după el).

Cât despre ce anume să "monitorizați" cu WinMTR: dacă de exemplu, aveți probleme cu un serviciu de streaming, deschideți acel serviciu într-un browser pe un PC (închideți orice alt tab sau instanță a browserului respectiv) deschideți utilitarul inclus în Windows: Resource Monitor (resmon.exe), mergeți pe tab-ul Network, bifați doar procesul browser-ului și sortați după "Total". Vedeți de pe ce IP vă vine stream-ul video, treceți acel IP în WinMTR și monitorizați pierderile până la acel IP, cel puțin 100 de pachete trimise.

Către cei care răspund inițial la sesizări (deși n-o să ajungă niciodată la ei acest mesaj, dar cel puțin încerc):

Nu mai presupuneți automat că e vina clientului, mai ales dacă sunt mai multe sesizări raportate în zonă, sau chiar dacă nu sunt, mulți se complac cu ideea că atât se poate și "aia e", din păcate.

Escaladați tichetul pentru verificări suplimentare și monitorizarea conexiunii clientului sau a clienților deserviți de acel port PON pe o perioadă îndelungată, dar nu direct din OLT-ul unde este conectat acel ONT al clientului, fiindcă congestia s-ar putea să fie localizată mai "sus".

Pentru alte păreri, sugestii și reclamații...

[MosGerila]

Multumim pentru efort!

[Radutuby]

Un test si de la mine 🙂

Am facut un test mai lung 🙂

[Radutuby]

Si DNS Cloudflare

WinMTR statistics

Host	%	Sent	Recv	Best	Avrg	Wrst	Last
2a02:a58:9470:6e01:12e6:6bff:fe24:c069	0	194	194	0	0	10	0
2a02:a58:110:5::1	0	194	194	3	3	10	3
2a02:a58:8953::3	14	123	106	0	10	15	10
2a02:a58:8953:6::2	0	194	194	9	17	109	12
2400:cb00:50:3::	0	194	194	9	13	75	10
one.one.one.one	0	194	194	9	9	13	10