alcoma ping problémy?

[okoun]

děláš si legraci asi ne?
to řeším furt aktivované flow control nepomohlo, výměna za silnější router také nepomohla, teď jsem ještě změnil frontu na ifacu z only HW na pfifo 100 tak uvidíme...

100 packetu hahaha. To nema smysl ani nastavovat. Prijde ti 100 50ti bytovych packetu a fronta jako by nebyla.

Zkusil bych
1) proverit, ze flowcontrol neco dela - tj chodi rxPausy od Alcomy. Novejsi verse ROSu zobrazuje na interfacu pocitadlo rxPause ramcu - pokud roste, pak Alcoma posila rxPause requesty. Pokud neroste tak bud neni dost burtu v provozu nebo Alcoma nic neposila. Obcas jdou chytit Pause ramci i snifferem (https://ask.wireshark.org/questions/9718/pause-frame)
2) nastavil bych na MT shaper na hodnoty o neco nizsi nez je max prenosovka te Alcomy a pak bych zkusil co se deje se ztratovosti. Pokud bude stratovost pokracovat a zaroven bude shaper hlasit, ze zahazuje packety cca ve stejnem poctu pak je to na dobre ceste. Zvysenim delky fronty na interfacu by se to melo spravit (ale 100 packetu fakt IMHO stacit nebude - pokud teda nebezi radio na modulaci ala 32mbps). Obvykle na switchich nastavuji (pokud to jde) 2MB frontu. Razantni ubytek discardu nastava od velikosti fronty v par stovkach MB (tj ne fronta na pocet packetu ale na celkovou velikost).

No a je to vůbec tím? Vemte si že to rádio má rychlost 300Mb (licence) a večer tam dle grafů teče reálně 170Mb jedním směrem a druhým 30Mb více ne!, dá se vůbec mluvit o nějakém zahlcení? A nebo tedy nějaké mikrobursty které jdou na hranici 300Mb a nejsou vidět v grafech?

[Dalibor Toman]

No a je to vůbec tím? Vemte si že to rádio má rychlost 300Mb (licence) a večer tam dle grafů teče reálně 170Mb jedním směrem a druhým 30Mb více ne!, dá se vůbec mluvit o nějakém zahlcení? A nebo tedy nějaké mikrobursty které jdou na hranici 300Mb a nejsou vidět v grafech?

Pricin samozreme muze byt vic. Je nutne ty mozne (a caste) bud potvrdit nebo eliminovat . Postup pro overeni jednoho typu puvodu potizi jsem poskytl.

Kolik tou linkou tece prumerne fakt nehraje moc roli. Dulezitejsi je pomer mezi rychlosti uplinku a downlinku a delkou fronty (v radiu pripadne pak na predrazenem switchu/routeru). Cili v Tvem pripade zrejme 1000/300. To ze realne tece 170mb neni az tak podstatne. Pribehne par packetu nekde cestou se nahlouci do vlacku bez mezer a vypadnou z 1gbps uplinku a radio je nestiha prenest a nema kam ulozit.

Tenhle problem resim na vsech switchich, kde je rychlost linek ven mensi nez privodni linka (ci soucet rychlosti privodnich linek). A budu se opakovat - je treba pouzivat zarizeni, ktera tento problem (kdyz uz ho maji) alespon umozni monitorovat a odhalit a take eliminovat (grafy discardu, grafy rx/txPause ramcu, moznost nastavit fronty atd). Bohuzel Alcoma neumoznuje monitorovat tail dropy z packetove fronty pred radiem (koukal jsem ted do MIBu na web pro MP600 a ani ty pause ramce v nem nejsou videt - definicni file je ale z roku 2014)

Je pravda, ze se tu v minulosti vyskytli lidi, kteri tvrdi, ze tento problem s radii nemaji ale IMHO o nem jen nevedi nebo k nim z nejakeho duvodu tece nejak vyhlazeny traffic

[GRFS]

No Okoun zrejme hleda nejakou levnou a rychlou radu Jednu bych mel. Zkus navysit kapacitu te Alcomy a uvidis, ze problem zmizi, nebo se to alespon zlepsi. A to tim vice, cim se bude rychlost WAN blizit rychlosti LAN interfejsu. O tom, ze prumerne statistiky nezohlednuji bursty a okamzite shlukove pretizeni lajny netreba polemizovat, to tak proste je. Jinak jsem toho nazoru, ze QoS (traffic policing, shaping atp) a diagnostika tail dropu je otazkou spise aktivniho prvku, nikoliv trubky, v nasem pripade (bez)dratu. Pokud to umi i trubka, jedine dobre, ale co do ni tece stejne sama moc neovlivni.

[Dalibor Toman]

Jinak jsem toho nazoru, ze QoS (traffic policing, shaping atp) a diagnostika tail dropu je otazkou spise aktivniho prvku, nikoliv trubky, v nasem pripade (bez)dratu. Pokud to umi i trubka, jedine dobre, ale co do ni tece stejne sama moc neovlivni.

nechci po radiu QoS ale nejenom ja byl bych rad, kdyby umoznilo sledovat kolik packetu zahodi (nejlepe s oddelenymi countery pro ruzne priciny). Ono kdyby Okoun (a ne jenom on) videl v SNM a ASDcku, ze mu kazdou vterinu naskakuje par desitek dropu, nemusel by patrat, kde se to vlastne ztraci.

[GRFS]

Pokud jde o total drop counter, pak souhlas. Mozna namet pro budouci release ASD, MiB a fw do Alcomy Na zaklade infa z drop a pause frames counteru, se da uz cosi resit. Stejne tak bych bral treba neco jako "unicast filter" (statistiky poctu zaregistrovanych MAC v konkretni VLAN a z ktereho switchportu prichazi), aby se dalo snadno zjistit, zda je to na L2 pruchozi.

S pojmem Tail droping jsem se potkaval prave spise u QoS, kdy je uz provoz nejak klasifikovan a tim "ocaskem" je vetsinou minen nejmene kriticky provoz, ktery se zahodi jako prvni, pokud dojde k preplneni bufferu a neni to uz kam "futrovat", coz me trochu zmatlo s ohledem na puvodni smer debaty

[okoun]

Pokud jde o total drop counter, pak souhlas. Mozna namet pro budouci release ASD, MiB a fw do Alcomy Na zaklade infa z drop a pause frames counteru, se da uz cosi resit. Stejne tak bych bral treba neco jako "unicast filter" (statistiky poctu zaregistrovanych MAC v konkretni VLAN a z ktereho switchportu prichazi), aby se dalo snadno zjistit, zda je to na L2 pruchozi.

S pojmem Tail droping jsem se potkaval prave spise u QoS, kdy je uz provoz nejak klasifikovan a tim "ocaskem" je vetsinou minen nejmene kriticky provoz, ktery se zahodi jako prvni, pokud dojde k preplneni bufferu a neni to uz kam "futrovat", coz me trochu zmatlo s ohledem na puvodni smer debaty

mohu se zeptat zdali tento problém s PL postihuje i tdd pojítka? například SIKLU?

[GRFS]

Ano ten problem se principielne tyka jakekoliv technologie, respektive sitove topologie zalozene na "trubkach" jejichz rychlost je nizsi nez rychlost "dratoveho" interfejsu. V nasem pripade dratovym interfejsem muzeme rozumet Gigabit Ethernet a trubkou libovolne prenosove medium, v nasem pripade radiovy spoj, jehoz prenosova rychlost je nizsi nez gigabit.

Jinak receno, problemy popsaneho typu nebudou napriklad u AL80GE, nebot tam jsou prenosove rychlosti za vsech okolnosti identicke na radiove i linkove casti. Toto zarizeni pouziva DBPSK modulaci a neumi ACM, takze nepodrazuje, coz prave nasledne vede ke skokovym zmenam plneni bufferu a problemum s tim spojenym. Proste AL80GE jede gigabit az do roztrhani tela. Samozrejme je to na ukor sirky pasma, ale z pohledu prenosove stability se to nejvic blizi dratu, nebo FO vlaknu, jak kdo chce.

Cele je to treba vnimat nikoliv jako vadu na strane pojitka, nybrz jako popis reality v nerizenych datovych sitich. Proto prave existuje QoS, shaping atd. Aby se dal regulovat provoz na siti podle toho, jak jsou kde uzka hrdla. Resenim je bud nemit uzka hrdla, nebo je treba pouzivat QoS a klasifikaci provozu tak, aby kdyz uz se neco zahodi, necht je to skutecne a pouze ten provoz, ktery je nejmene kriticky. Bohuzel, v takovem pripade je ICMP echo request jeden z typu provozu, ktery neni kriticky a podle toho se k nemu sit chova, viz odkazovane RFC. Proto packet loss na pingu.

[Dalibor Toman]

jak uz jsem psal ten problem vznikne kdekoliv kde je zuzeni (pomer input/output rychlosti rozhrani je > 1).

Takze muze nastat napr i v situaci, kdy je uplink do switche 1gbp a ke switchi jsou pripojena zarizeni (napr routerboard) slinkovana na 100mbps. Proste obcas prijde burst tim gigabitem tak velky, ze se ucpe odchozi 100M port a switch nema buffery pred tim portem tak velke, aby to nemusel zahodit. Tady pomuze jen donuti switch zvetsit buffer nebo posilat uplinkem predrazenemu zarizeni TX Pause (ale to neni IMHO v tomto scenari moc rozumne).

Co se tyce testu pingem - ja se ho nebojim. Bezne pouzivam k detekci problemu z linuxove konzole "ping x.x.x.x -A [-s y]" .
Jen je treba vedet na co pingam. Tedy jestli cil ma dost silne CPU, aby stihal v pohode odpovidat a nema nastavene nejake limity. Je treba vedet, ze packety se muzou ztratit i kvuli necemu jinemu nez vade po trase (viz ten zminovany QoS pokud je v siti pouzivan, icmp rate limit na cilovem stroji, unavene cpu atd).

Tady je napr graf OutDiscards ze switche (3560g, ktere ma fakt malo bufferu - 384kB na kazdy Asic (Asic obsluhuje 4 porty) - takze se s tim neda moc carovat). Prichod 1x1gbps. Graf je z portu, kde je nejaky Mikrotik AP slinkovane na 100M, datovy tok do 20mbps. Je videt, ze sem tam se neco z odchozi fronty zahodi.

[KoZLiCeK]

To by me zajimalo jaky buffer ma MK CRS 125 nebo RB3011 ci RB2011.Neví nedo?

[Dalibor Toman]

To by me zajimalo jaky buffer ma MK CRS 125 nebo RB3011 ci RB2011.Neví nedo?

staci najit datasheet k prislusnemu switchipu. RB3011 zrejme ma 1MB pameti na chipu"
https://www.arrow.com/en/products/qca83 ... c/qualcomm

to by mohlo stacit - ale zalezi jak se s tou pameti hospodari. Je to sdilena pamet? Nebo se rozdeli rovnym dilem na port (to by bylo horsi).
netusim jestli ten chip umi flowcontrol. V kazdem pripade vyresit problemy s radiovym spojem pomoci shaperu nebude mozne (shaping v ROSu jezde k nicemu)

V bridge CFG je samozrejme k dispozici pamet RBcka 0- jen se musi prislusne nastavit fronta na odchozim interfacu pripadne i shaper

[okoun]

To by me zajimalo jaky buffer ma MK CRS 125 nebo RB3011 ci RB2011.Neví nedo?

staci najit datasheet k prislusnemu switchipu. RB3011 zrejme ma 1MB pameti na chipu"
https://www.arrow.com/en/products/qca83 ... c/qualcomm

to by mohlo stacit - ale zalezi jak se s tou pameti hospodari. Je to sdilena pamet? Nebo se rozdeli rovnym dilem na port (to by bylo horsi).
netusim jestli ten chip umi flowcontrol. V kazdem pripade vyresit problemy s radiovym spojem pomoci shaperu nebude mozne (shaping v ROSu jezde k nicemu)

V bridge CFG je samozrejme k dispozici pamet RBcka 0- jen se musi prislusne nastavit fronta na odchozim interfacu pripadne i shaper

No a co v případě CFG režim router? To je stejné jako bridge?

[Dalibor Toman]

No a co v případě CFG režim router? To je stejné jako bridge?

pokud to nekombinujes se switchem pak ano Staci se predstavit kudy behaji packety - zda se v ceste vyskytne CPU nebo ne

[okoun]

no já právě nikde žádný switch nemám, mam jeden router x86 a druhý router rb3011 a to spojuje alcoma klasicky rozsahem /29 žádná věda že

[Dalibor Toman]

no já právě nikde žádný switch nemám, mam jeden router x86 a druhý router rb3011 a to spojuje alcoma klasicky rozsahem /29 žádná věda že

bavili jsme se o RB3011. Takze tim switchem jsem myslel switch (switchchip) v ni...

[okoun]

no já právě nikde žádný switch nemám, mam jeden router x86 a druhý router rb3011 a to spojuje alcoma klasicky rozsahem /29 žádná věda že

bavili jsme se o RB3011. Takze tim switchem jsem myslel switch (switchchip) v ni...

jasně ale to je pro mě tabu že když to mám na čistý routing...