Zamyšlení - Více hopů na 5GHz

[net.work]

asi tam mas nekde spunt... nebo nevim

[Majklik]

podle mikrotiku velikost cell radiusu ovlivnuje pouze to jestli se klient po testu vzdálenosti do něj vejde nebo ne. Aspoň tak to někdo z nich na foru tvrdil. Prý to na nic jiného vliv nemá ale kdo ví.

Ten cell ovlivňuje velikost time slotu pro nepřipojené klienty. Dle té zadané vzdálenosit ho natahuje tak, aby i tak vzdálený kleint se připojil. Si to zkuš, když ztam bud o hodně menší číslo, tak se vzdálený nepřipojí, pokud je na tom AP několik klientů a aktivní provoz, dostane nějakou sync error chybu. Až po té, co se úspěšně asociue, se provádí měřneí vzdálenosti a dle toho se pak už další sloty pro daného klienta nastavují s ohledem na jeho skutečnou vzdálenost.
Ale ta věta je v podstatě správná, když jsem dál, tak se nepřipojím. Ale proto, že se asi vůbec do fáze měřneí vzdálenosti nedostanu. Koukám, že i wikina to tak říká, že s eto číslo nemá přehánět nad realitu klientů, že má dopad na propustnost.

Jasně, proto říkám u nstreme že upload nebyl ošetřenej. Download z pohledu klienta se přetížit nedal.

Hele to nstreme také nemá v popisu práce. Nechová se ti to hezky s dělbou na download mezi klienty proto, že před tím máš nějaký shaperek, co ty toky podělí, takže jeden sosálista to nevyžere celé? Se mi to tak tu i chová na druhé lince, kde si to neřežu a dokáži ostantí prakticky odrovnat.

když už jsme to tu takhle pěkne rozvířily, na jinou stranu sítě, říkejme tomu 3 směr, to jede dobře a přitom tam jsou taky dva duální spoje na RB711kách + konečnej duál na ptmp. TCP test tam jede 30Mbit.

A ličí se ta cfg v něčem proti těm předchozím? Když restartneš RBčka, jede to po restartu pořád tak hezky?
Napadla mě takovéá blbost, nezkoušel jsem. Má nějaký dopad, pokud na těch RB je zapnuta časová synchronizace - SNTP klient (řekněmě, že by ty periody odvozovali od vztahu k reálnému času, čímž by ty RBčka v řadě synchornizovali pro vysílání)?

[hapi]

mno takže jeden problém nalezen. Zaměřil jsem se proč na jednu stranu to jede ok a na druhou ne. Došel jsem k závěru že problém bude v jednom switchy přes který dva směry jdou. Před chvíly jsem ho vyměnil za RB250GS a hle, rychlost z 8Mbit se zvýšila na 17-18Mbit. Ještě mám podezření na jeden switch kterej je ale mezi spoji dál takže výměna bude chvíly trvat.

[hapi]

předtím:
xeon --- RB711G ( 300Mbit TDMA 1ms ) RB711G --- Omnitik ( 130Mbit TDMA 2ms PTMP ) --- SXT = cca pod 10Mbit

potom:
xeon --- RB711G ( 300Mbit TDMA 1ms ) RB711G --- Omnitik ( 130Mbit TDMA 2ms PTMP ) --- SXT = cca 18Mbit

pokud se veme obrázek:



tak první hop kterej dával pouze 15Mbit tak teď dává cca 38Mbit což je limit btestu na RB711G. Za ním je ještě jeden switch na kterej jsem měl taky spadeno.

[sub_zero]

co si tam měl za ty switche? shitLinky?

[hapi]

na obrázku je to ten vpravo nahoře

původně:
TP-LINK: TL-SG1016 16-port 10/100/1000 mbps ethernet switch

aktuálně:
RB: RB250GS

takový sraní s tim. Na druhý straně je ještě nějaký zyxelová sračka (na mapě nahoře vlevo) do racku nebo co. Fotr chtěl ušetřit voe. Asi mu naúčtuju čas ztrávenej nad hledáním problemu aby věděl kolik že ho má stát příště pořádej switch.

[net.work]

ted je otazka co je vlastne poradny switch? na 90% bodu nepotrebujes management (jasne, muze byt, ale realne nevyuzity) a ktery z tech nemanagetovatelnych je vlastne dobry???

[hapi]

jinak bych osvětlil metodiku meření. Pokud měřim mezi RBčky tak se problem tolik neprojevuje. Pokud byl zdroj btestu na x86 tak byl problém velmi znatelný a totožný s tím co naměřili klienti na měřákách v netu. Takže já od této doby btestu na TCP 1 spojení vysílaný z x86 plně důvěřuji. Odhalilo to totiž krásně příčinu akorát stačilo si to správně poskládat do hromady a neosočovat mikrotiky že to maji nějak zkurvený

takže oči otevřené chlapci a neukvapovat se v závěrech. Nejlepší je vzít papír a tužku a kreslit. Ject RBčko po RBčku v síti a testovat proti hlavní bráně. Hlavní brána vám poskytne plnej průtok na jedno TCP i když jede na max (pokud nemáte vyloženě plečku na bráně). Mít na paměti že 400MHz procáky daji max 40Mbit na přijmu když jsou ve formě a 680MHz dají něco nad 50Mbit. Potom si to pěkně nakreslit včetně všech kabeláží kudy to teče a popsat rychlostmi. Pak dojdete na bod kde to hnije. Taky je dobrý koukat na UDP test a třeba ho omezit na 10, 20, 30Mbit a sledovat kolonku "lost packets" která hodně napoví. UDPčko nezajimá že data přišly špatně, zajimáho že dorazili nicméně to že došly špatně se napočítá a je to v tý kolonce vidět. Dal bych ruku do ohně že tam vždy nějaký packety vadný byli jenom jsem si nedokázal vysvětlit proč. Jestli tedy ztrátoval switch, tak se to tim dalo poznat.

Jedno je tedy jasný, pokud máte na btestu s 1 TCP spojením nízký download, je problém. Problém se dá hledat i pomocí UDP kde je potřeba sledovat kolonku "lost packets" a mít test omezenej pod maximální hranici testovaný trasy.

[hapi]

teď by mě zajímalo jestli existuje nějaký tester kterej by odhalil tenhle problem. Pokud uvažuju správně tak pokud chci dosahnout toho aby switch nebo nějaký prvek nějak omezoval tcpko tak musí chybovat čimž se donutí snížit tcp winwdow size a to musí bejt někde debugovatelný případně nějak debugovatelná chyba toho že něco někdě zahodilo pakety. Existuje tedy nějaký soft který by to nějak rozumně uměl ukázat a hlavně rozpoznat že něco neni ok?

[ludvik]

Jo, měřáky na IP vrstvě, třeba ty EXFO.

teď by mě zajímalo jestli existuje nějaký tester kterej by odhalil tenhle problem. Pokud uvažuju správně tak pokud chci dosahnout toho aby switch nebo nějaký prvek nějak omezoval tcpko tak musí chybovat čimž se donutí snížit tcp winwdow size a to musí bejt někde debugovatelný případně nějak debugovatelná chyba toho že něco někdě zahodilo pakety. Existuje tedy nějaký soft který by to nějak rozumně uměl ukázat a hlavně rozpoznat že něco neni ok?

Jenže nevím a podle mě není teoreticky ani možné, aby switch tohle ovlivňoval. Ještě tak si umím představit rozdíl třeba 100Mbit <> 90Mbit. Ale rozhodně neznám způsob, jak by switch zasahoval do TCP (zvlášť při rychlostech, co píšeš). To mu je přeci naprosto fuk. Maximálně může mít nějaké L3/L4 funkce (ACL např.), ale ani to neovlivňuje toky jako takové. Buď to paket pustí, nebo ne ... a to každý, ne jenom nějaký občas.

Nebo máš někde jumbo pakety a zároveň ti někde něco požírá ty správné ICMP.

Dle mého názoru ti tam někde habrovala vyloženě chybovost na první vrstvě. Něco špatně s kabeláží a tak podobně. Případně se ta zařízení nedohodla na rychlosti a z jedné strany to bylo třeba 10Mbit a z druhé 100Mbit. To pak dělá vyloženě ptákoviny co se dost blbě hledají, zvlášť pokud nejsou statistiky z těch portů (což u leckterých mikrotiků problém je).

[hapi]

to si nemyslim. Já prostě věřim v to že ten switch je nějakej vadnej a nebo ho ruší ceragon co je vedle. Pak dělá chyby a podepíše se to na tcpku. Ale kdo ví. Ať už to dělá cokoliv tak je třeba na to nějak rychle a jasně přijít.

Chybovost by se ukázala na dropech/errorech v rbčkách. To samí i nějaký přepínání rychlostí nebo tak. Prostě by se zrovna na tohle přišlo.

[reset]

@hapi: kolik ti to udela v 40x40 ?

[hapi]

100Mbit jedním směrem, víc nevim a nečekám od toho víc.

[Hatatitla]

711<--nv2-1ms-1x1-->711<-->cisco3550-<-->Alcoma17<-->cisco3550<-->nb22<--airmax-2x2-->nb22<-->rb25gs<-->rb250gs<-->tplink-SL2210<-->x86_mikrotik<-->nb22<-->airmax-2x2<-->RB750G<-->X86_mikrotik

Prvý hop 39 mbit 1TCP/UDP
Za prvým UBNT airmaxom (x86) 1TCP 18 Mbit UDP 39 mbit
Za druhým UBNT amx (RB750G) 1TCP 15 Mbit UDP 39mbit
Posledný X86 1 TCP 5Mbit UDP 39 Mbit

Pritom posledný x86 a 750G sú prepojené len kusom káblu a 750G routuje , nejak mi nejde do hlavy ten výrazný prepad 15 vs 5 Mbit .

[Majklik]

Jenže nevím a podle mě není teoreticky ani možné, aby switch tohle ovlivňoval. Ještě tak si umím představit rozdíl třeba 100Mbit <> 90Mbit. Ale rozhodně neznám způsob, jak by switch zasahoval do TCP (zvlášť při rychlostech, co píšeš). To mu je přeci naprosto fuk. Maximálně může mít nějaké L3/L4 funkce (ACL např.), ale ani to neovlivňuje toky jako takové. Buď to paket pustí, nebo ne ... a to každý, ne jenom nějaký občas.

Switch to může ovlivňovat prakticky velmi dobře, zvláště s dopadem na TCP. A zrovny tyto TPlinky s nevypnutelným a trvle zapnutým flow control jsou ideální příklad (802.3x). Ale je blbost, aby se tak dělo při tokách kolem pár desítek Mbps,jestli-že oba zapojene porty jsou na gigu (ke xeonu i rb711g). Pokud to není tak, že xeon krmí do toho switche mnohem víc svým portem, než jen tu jednu linku do RB711 a další někam downlink odbočují na 100 nebo 10 Mbps. A ještě hůř je případ, že se nad tím switchem ppřípadně prohání VLANy, když je ten switch sám neumí (pokud je multipoint zapojen). V takovém případě to může ten switch nabourávat velice úspěšně (předpokládám, že Mikrotikové nemodifikují drivery intel síťovek, které v defaultu jsou ochotny se nechat ovlivňovat pause rámci).

Kbyby se Hapi moc nudil. Co se stane, když mezi ten TPlink a xeon strčíš tu RB250GS? Jde to blbě nebo dobře (signalizačně a elektricky jsi oddělil intel síťovku a tplinkl)? A co se stane, kdyř pak na tom 250GS zapneš MAC filtr, který nebude propouštět rámce s cílovou MAC 01:80:C2:00:00:01 (zablokuji doručování pauze rámců do xeonu)? Má to dopad?

Ale nemělo by to mít na nic vliv. Spíše si myslím, že si to nesedlo elektricky, L1 signalizačně, rušení , nabořený switch (zkusit zapojit jinde, zda bude nabourávat komunikaci také) atd. I když může zkusit chytat pakety přes packet sniffer na xeonu na rx mac 01:80:C2:00:00:01, zda piři ztěžování linky nezačnou chodit, když tam je ten TPlink (muselo by se pak ale dekódovat obsah, zda v tom doopravdy je pauze command 1, nejlépe s quantum 65535)...
Ale tohle se neřeší na switchi, kterým teče sumárně do 50 Mbps (to by bylo opravdu hodně smutné), to řeší na switchi, přes který se posílá 20x 600 Mbps!