
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Test a analýza hraničních routerů
Re: Test a analýza hraničních routerů
Jejda tak tahle chybka nikoho z nás nenapadla měli jsme Orcave proti Ciscu také do Dialu a PL docela dost velký. Vyřešili jsme to také Gbit switchem. Pravda je, že od Cisca k anténě to bylo nějakých 90m kabelu z toho 20 napájených. Po vložení switche vše ok. Mysleli jsme si totiž, že délka kabelu je kritická a ztrácí se to díky tomu. Když teď nad tím přemýšlím tak když to jelo na původní nyní už záložní lince také tehdy od Dialu s jiným Orcave a Ciscem tak to dělalo taky a switch tam musel být taky. A fakt je, že v té době to jelo do 100 Mbit. Ted je to přepojené do ČDT a tam to nedělá. Nemohla by to být jen chyba v nastavování Dialáckých Cisco switchů? Aktuálně tam máme Siklu tak schválně prubnu vyndat Switch co to udělá. 

0 x
No, možná místo strkání dalšího switche mezi to Cisco a rádio by stačilo na tom Ciscu pro daný port napsat "flowcontrol receive on" nebo slušněji "flowcontrol desired", pokud rádio podporuje korektně proces autonegace na Ethernet portu. Cisco má defaultně zakázán příjem pause rámců (802.3x) a většina Cisek je neumí vůbec generovat.
Možná příčina problému:
Mám koupenou lajnu 100 Mbps, rádio třeba dává 150 Mbps a teď mi přijde malý burst dat, který k rádiu jde po 1 Gpbs lajně a je větší, než přenosová kapacita rádia a delší, než co pojmou vstupní bafry v rádiu (rádio je většinou šmejd a má vstupní bafr na pár paketů). Blíží se plno, posílá pause rámec a Cisco nic, protože na to kašle a rádiu nezbude než to zahazovat. Vložíte tam switch z produkce čínského domácí zemědělství a máte opraveno, protože většina těch krabic má defaultně 802.3x zapnut (kolikrát natvrdo a nejde vypnout i když v nastavení na to volby jsou), neboť jejich výrobci jsou realisti a ví, že ty jejich krabice občas nestíhají, tak si natvrodo pomáhají pomocí flowcontrol a velkých vyrovnávacích bafrů na jednotlivé porty, což pak budí navenek a z dálky pocit, že vše teče suprově a na max.
To postihlo evidentně i Hapiho. To centrální shapovátko k němu posílalo data v blocích víc, než kolik sneslo rádio a měl výopadky. A ten vysílaný provoz netflow dat ve velkých burst blocích mu k tomu jen přihrával. Mylsím, že technik ani tak nesnižoval velikost shapovací fronty k němu (tím by paket loss nevyřešil, pakety by se zahazovaly místo na rádiu už na vstupu shaperu), jako spíše měnil parametry odesílání dat z té fronty. Ta bedna vyrábí na výstupu 100 Mbps v průměru, krátkodob to pošle víc a pak chívli čeká. Pokud rozpotřel to odesílání na kratší bloky a častěji (což těm bednám ne úplně vyhovouje z pohledu celkového výkonu), tak dá šanci tomu rádiu postupně to odvysílat. Zkrátka shapovaíc bedna nesmí vypustit naráz víc, než poberou ty bafry v posledním switchi před tím rádiem, kde nastává větší zůžení přenosu. Tím, že tam nacpu polotupý switch, tak obvkyle výrazně zvětším ten záchytný bafr a problém se ztrátou paketů v podstatě vyřeším. Správné řešení je kopat za to, aby to shapovátko to neposílalo víc, než co unese to rádio.
Protože toto řešení s velkým vyrovnávacícm bafrem a 802.3x má jednu drobnou slabinu - také tu bylo někde vlákno, kde se plakalo nad tím, že nedokážete vytížit jedním TCP spojením plně konektivitu - velké bafry a 802.3x je pro maximálnu TCP přenosu smrtící.
Možná příčina problému:
Mám koupenou lajnu 100 Mbps, rádio třeba dává 150 Mbps a teď mi přijde malý burst dat, který k rádiu jde po 1 Gpbs lajně a je větší, než přenosová kapacita rádia a delší, než co pojmou vstupní bafry v rádiu (rádio je většinou šmejd a má vstupní bafr na pár paketů). Blíží se plno, posílá pause rámec a Cisco nic, protože na to kašle a rádiu nezbude než to zahazovat. Vložíte tam switch z produkce čínského domácí zemědělství a máte opraveno, protože většina těch krabic má defaultně 802.3x zapnut (kolikrát natvrdo a nejde vypnout i když v nastavení na to volby jsou), neboť jejich výrobci jsou realisti a ví, že ty jejich krabice občas nestíhají, tak si natvrodo pomáhají pomocí flowcontrol a velkých vyrovnávacích bafrů na jednotlivé porty, což pak budí navenek a z dálky pocit, že vše teče suprově a na max.
To postihlo evidentně i Hapiho. To centrální shapovátko k němu posílalo data v blocích víc, než kolik sneslo rádio a měl výopadky. A ten vysílaný provoz netflow dat ve velkých burst blocích mu k tomu jen přihrával. Mylsím, že technik ani tak nesnižoval velikost shapovací fronty k němu (tím by paket loss nevyřešil, pakety by se zahazovaly místo na rádiu už na vstupu shaperu), jako spíše měnil parametry odesílání dat z té fronty. Ta bedna vyrábí na výstupu 100 Mbps v průměru, krátkodob to pošle víc a pak chívli čeká. Pokud rozpotřel to odesílání na kratší bloky a častěji (což těm bednám ne úplně vyhovouje z pohledu celkového výkonu), tak dá šanci tomu rádiu postupně to odvysílat. Zkrátka shapovaíc bedna nesmí vypustit naráz víc, než poberou ty bafry v posledním switchi před tím rádiem, kde nastává větší zůžení přenosu. Tím, že tam nacpu polotupý switch, tak obvkyle výrazně zvětším ten záchytný bafr a problém se ztrátou paketů v podstatě vyřeším. Správné řešení je kopat za to, aby to shapovátko to neposílalo víc, než co unese to rádio.
Protože toto řešení s velkým vyrovnávacícm bafrem a 802.3x má jednu drobnou slabinu - také tu bylo někde vlákno, kde se plakalo nad tím, že nedokážete vytížit jedním TCP spojením plně konektivitu - velké bafry a 802.3x je pro maximálnu TCP přenosu smrtící.
0 x
já mám lepší... do popelnice s ciscama
neumí flow control a neumí ani shapovat 
proč Majklík opakuje to co jsem já říkal? Jo on do toho plete flow control ale to se z principu vypíná tak ho do toho nemontuju. Jo a technik měnil délku fronty na ciscu. Chtěly jsme aby shaping na ciscu zareagoval dřív než zářez na ceragonu a chybovost se měřila na ceragonu. Bohužel cisco. To už snad udělá lepší práci MKčko
maximálku TCP přenosu by měla řešit velikost window size, bohužel všichni víme jak to "nefunguje". Nicméně aby ten maličký buffer ve switchy udělal nějaký extra spoždění tak aby se přenosovka tcp podstatně snížila... nevim nevim, na síti jsou daleko větší latenční prvky než tupej switch. No, kdyby to ten switch přece nestíhal což teda dost pochybuju, tak něco zahodí a rychlost tsp pujde samovolně stejně dolu takže výsledek by byl nejspíš uplně stejnej.
Paradoxem je, že ten kdo má router na popu a pak si to posílá dál, nebude mít packet losty ale ten, kterej si to nechá poslat k sobě a až u sebe bude mít router je mít nebude
mám takovej pocit že když přehodnotim všechny který se zapojily do testu tak zjistim že to tak bude a nebude v tom mít prsty desktopová deska 
Nicméně pokud se najde někdo jako já kterej honí dodavatele s měřákama aby našly chybu, tak pak přijde i majklík s velkym objevem že to tak je


proč Majklík opakuje to co jsem já říkal? Jo on do toho plete flow control ale to se z principu vypíná tak ho do toho nemontuju. Jo a technik měnil délku fronty na ciscu. Chtěly jsme aby shaping na ciscu zareagoval dřív než zářez na ceragonu a chybovost se měřila na ceragonu. Bohužel cisco. To už snad udělá lepší práci MKčko

maximálku TCP přenosu by měla řešit velikost window size, bohužel všichni víme jak to "nefunguje". Nicméně aby ten maličký buffer ve switchy udělal nějaký extra spoždění tak aby se přenosovka tcp podstatně snížila... nevim nevim, na síti jsou daleko větší latenční prvky než tupej switch. No, kdyby to ten switch přece nestíhal což teda dost pochybuju, tak něco zahodí a rychlost tsp pujde samovolně stejně dolu takže výsledek by byl nejspíš uplně stejnej.
Paradoxem je, že ten kdo má router na popu a pak si to posílá dál, nebude mít packet losty ale ten, kterej si to nechá poslat k sobě a až u sebe bude mít router je mít nebude


Nicméně pokud se najde někdo jako já kterej honí dodavatele s měřákama aby našly chybu, tak pak přijde i majklík s velkym objevem že to tak je

0 x
- sub_zero
- Příspěvky: 1741
- Registrován: 19 years ago
- antispam: Ano
- Bydliště: Olomouc
- Kontaktovat uživatele:
Ale prd Hapi... přečti si, na co sem se Tě ptal jako první
Jak je možný, že když shapujou u carriera na PE, PROČ k Tobě dojde špička.. taky jsi nedokázal odpovědět.. a ani technik od Dialu 
To "smekám" sem myslel obecně na Majklíka, že se mi snad ještě nestalo, aby na nějakej problém nezareagoval podrobně a tech. erudovaně
Žádný "odborný typy" jako já apod 


To "smekám" sem myslel obecně na Majklíka, že se mi snad ještě nestalo, aby na nějakej problém nezareagoval podrobně a tech. erudovaně


0 x
to sem si přečet. Nicméně odpověd neni zapni si flow control ale vyhoď cisco který neumí shapovat 

0 x
- sub_zero
- Příspěvky: 1741
- Registrován: 19 years ago
- antispam: Ano
- Bydliště: Olomouc
- Kontaktovat uživatele:
Stando! Tak naposled..
Koho z vás napadlo to flow zapnout? Nejde o to, že Cisco v defaultu neumí "dobře" shapovat, jde o to, že Majklík detailně a přitom jednoduše napsal, jak se to mohlo odstranit BEZ vřazení tupýho switche. Nic víc.. samý egoisti tady.. 


1 x
na začátku má že většina cisek neumí flow control ani generovat. Pokud by tedy došel buffer i tomu ciscu, nedokázal by poslat flow control ciscu přednim 
nicméně i zapnout flow control by člověka napadlo kdyby ty zařízka byly jeho a mohl se v nich hrabat. Nicméně cbl nedovolilo hrabat dialům do ceragonu a naopak
Stejně by mě zajímalo jestli by to flow control vůbec ukočírovalo nebo jestli by ten switch pomohl. Přecejenom ty peaky byly fakt brutální když ani 2x rezerva v pojítku nestačila.

nicméně i zapnout flow control by člověka napadlo kdyby ty zařízka byly jeho a mohl se v nich hrabat. Nicméně cbl nedovolilo hrabat dialům do ceragonu a naopak

Stejně by mě zajímalo jestli by to flow control vůbec ukočírovalo nebo jestli by ten switch pomohl. Přecejenom ty peaky byly fakt brutální když ani 2x rezerva v pojítku nestačila.
0 x
Připojuji se k těm, co slušně poděkují za hodnotný příspěvek.
Děkuji.
Děkuji.
0 x
sub_zero píše:7 stránek dohadů a jedním příspěvkem vyřešenoSmekám
A vyresi zapnuti toho flowcontrol na ciscu ty obcasne PL (viz smokeping u sub_zera) i když mi tam nikdy neteče vice, nez mam nakoupeno konektu?
0 x
- sub_zero
- Příspěvky: 1741
- Registrován: 19 years ago
- antispam: Ano
- Bydliště: Olomouc
- Kontaktovat uživatele:
2 net.work: Není nic jednodušího, než to vyzkoušet. Ale ty nemáš z toho Ceragonu žádnej switch, ne? Máš kabel přímo do MK?
Jinak Hapi, přihoď na ten smoke ping IP:
62.168.49.49 GTS OS222 TGE-10-4-3
193.86.175.229 BOA169 TGE-10-2-3
jsou to naše GW z ASRka. Za tejden ani žádnej PL, tak sem zvědavej, co to naměří Tobě.
Jinak Hapi, přihoď na ten smoke ping IP:
62.168.49.49 GTS OS222 TGE-10-4-3
193.86.175.229 BOA169 TGE-10-2-3
jsou to naše GW z ASRka. Za tejden ani žádnej PL, tak sem zvědavej, co to naměří Tobě.
0 x
net.work píše:sub_zero píše:7 stránek dohadů a jedním příspěvkem vyřešenoSmekám
A vyresi zapnuti toho flowcontrol na ciscu ty obcasne PL (viz smokeping u sub_zera) i když mi tam nikdy neteče vice, nez mam nakoupeno konektu?
jestli můžeš, zapni to. Taky jsme nevyužívaly kapacitu na max a PL tam byl i tak a to dost velkej.
0 x
sub_zero píše:Jinak Hapi, přihoď na ten smoke ping IP:
máš to tam
0 x
sub_zero píše:2 net.work: Není nic jednodušího, než to vyzkoušet. Ale ty nemáš z toho Ceragonu žádnej switch, ne? Máš kabel přímo do MK?
Nene, z ceragonu to vede do CPE gtsky (nejake cisco) a z cisca az pak ke me do MT...
Takze to by museli aktivovat v GTS, ale nejak moc nevim co po nich mam chtit a jestli me s tim neposlou do riti

0 x