Cum să simulăm ceea ce se întâmplă în buffer-ul de pachete al unui comutator simplu?

Depanez un caz de pachete UDP pierdute într-un comutator gigabit store-and-forward și am vrut să vizualizez ce se întâmplă în interiorul comutatorului pentru a înțelege mai bine esenta problemei.

Scenariul este simplu - două fluxuri de date în rafală vin prin 2 porturi din interiorul comutatorului și ambele doresc să-l părăsească printr-un al treilea port (comun ambelor). Deci, comutatorul trebuie să rețină câteva date în buffer-ul de pachete pentru o perioadă.

Problema este: pe baza calculelor mele simple, tampoanele ar trebui să fie suficient de mari pentru a gestiona cazul pe care îl examinez. Un flux de date trimite rafale de 25 kB (împărțit la 1514 pachete B) la fiecare 1,56 ms, celălalt trimite rafale de 60 kB la fiecare 1 ms. Acum, chiar și un comutator Soho precum Netgear GS105E are o dimensiune tampon de 128 kB. Deci matematica simplă (25+60 < 128) spune că ar trebui să funcționeze chiar dacă fluxurile intră în același timp (având în vedere că nu există alt trafic substanțial).

Testele reale arată că o mulțime de pachete din ambele fluxuri se pierd pe unele comutatoare (pare a fi legat de dimensiunea tamponului, dar nu numai de aceasta). În simularea mea, nu pot face ca tamponul să se umple în exces când este setat la 128 kB.

Am înregistrat această animație pentru un buffer de dimensiunea de 24 kB unde există supraumplere. Cu toate acestea, puteți vedea cu ușurință că creșterea bufferului cu doar câțiva octeți ar rezolva problema și toate pachetele ar trece.

Am făcut câteva simplificări în această simulare. Toate pachetele au aceeași QoS (care este și în cazul real). Așa că am omis cozile QoS din simulare și tratez tot traficul ca fiind la fel de important. Apoi, am omis gestionarea memoriei tamponului. Îmi pot imagina că este o parte importantă a problemei, dar aș fi surprins dacă simplificarea mea cu alocări perfecte ar fi greșită cu peste 10% din cazul real. De asemenea, pretind că comutatorul știe lungimea cadrului atunci când primește primii octeți, astfel încât să rezerve toată memoria necesară la început. Deoarece nu am putut găsi nicio documentație despre dimensiunea cozilor de intrare/ieșire ale porturilor, presupun că toate sunt plasate în buffer-ul de pachete partajat și pot lua cât mai multă parte din buffer (deși cred că vinovatul poate fi undeva aici).Am setat întârzierea de procesare a fiecărui pachet la 512 ns (întârzierea de propagare a unui pachet de 64 B).

Nu sunt sigur dacă joacă un rol, dar fluxurile constau din pachete UDP fragmentate (adică explozia de 25 kB este un singur pachet UDP fragmentat la 17 fragmente IP). Al doilea flux creează explozia ca 2 sau 3 pachete UDP de 20 kB, fiecare fragmentat la 14 fragmente IP.

Comenzile Iperf 3.7 pentru a replica fluxuri similare cu cele reale sunt:

iperf3 -c sink -u -b 128M -t 600 -l 25256 --pacing-timer 1560
iperf3 -c sink -u -b 400M -t 600 -l 20k --pacing-timer 1000

Aveți vreo idee ce altceva am uitat să iau în considerare care ar putea face ca simularea să fie atât de departe de realitate? Multumesc pentru ajutor!

Codul sursă pentru animație este la https://gist.github.com/peci1/a0346538acc6c289b2c6d596b184ad21 .

Iată tabelul meu de rezultate din experimentele reale. Fluxul de date unul este fix - 128 Mbps în pachete UDP de 25 kB fiecare 1,56 ms. Am schimbat parametrii celui de-al doilea flux încercând să găsesc limita la care pachetele primului flux vor începe să se piardă de comutator. Schimbam -l (lungime) parametru care specifică dimensiunea pachetului UDP și -b (lățime de bandă) parametru care specifică ce lățime de bandă ar trebui să genereze aceste pachete. --temporizator de ritm a fost întotdeauna setat la 1000 pentru al doilea flux. Puteți vedea că D-Link și Netgear GS105 nu pot face față deloc exploziilor de 60 kB. GS108 se descurcă mult mai bine decât GS105, în timp ce are aproape același cip de comutare (aceeași „familie”, doar un număr diferit de porturi și un buffer puțin mai mare).

(Această întrebare a fost migrată din https://networkengineering.stackexchange.com/questions/78529/how-to-simulate-what-happens-inside-the-packet-buffer-of-a-simple-switch unde a fost marcat ca off-topic).