1 TCP spojení Mikrotik - VELMI POMALÉ

[cmgn]

Chlapi, tak UDP projde relativně OK. To, že to předtím nepropustila AHx4 dělal zřejmě NAT. Nevím a nenapadá mě teda proč, ale budiž... Když jsem to hodil na veřejné adresy, jede to.
Graf UDP při receive a rychlosti 250 Mbps je relativně klidný. Je ale fakt, že sem tam se to o cca 10 Mbps hýbne. Nicméně, dělá mi to jak na lince CETIN tak na lince CDT, která končí ale úplně v jiném DC, ale taky na AHx4...... A že by obě linky byly nakonfigurovány špatně?

co je na tom relativně ok? vidim tam 900 lossů!!! pokud ti tam nic jinýho neteče tak tam má bejt 0

No, to je taky fakt. Pokud neucpu linku celou, měla by tam být 0 že? Nicméně, dělá mi to i pouze mezi dvěma 3011 přes UBNT EdgeSwitch 12 Fiber. Tam ale taky teče další provoz navíc, nicméně, linka mezi tím je samozřejmě gigabit.

Každopádně, tahle chyba se projevuje i pouze mezi 2 tiky na tom L2 okruhu a dělá to jak na ČDT okruhu, tak na CETINu. Plus ty dropy skáčou. Chvíli 0, chvilku 200, pak 0 pak 400, pak zas dlouho nula atd...

[hapi]

tak sniž rychlost testu na 50Mbit aby si vyloučil bursty normál provozem.

Mimochodem tohle je jedna z věcí proč nekupujem okruh a na konci konekt protože když tohle nastane tak si tě pak dotčený subjekty přehazujou jak horkej brambor. Taky jsme to řešili a zved sem telefon, dial poslal technika s nějakym měřákem a zjistilo se že to může pojítko. Vyřešeno.

[Ispič]

Pokud jsi malý isp ano, ale pokud zálohuješ jiným okruhem k jinému poskytovateli, nemáš jinou šanci. U nás nikdy s žádným okruhem co se týče propustnosti, ztrátovosti nebyl. Buď to jede, nebo nejede :)
Další věc je pak když si pronajmeš okruh k nějakému ne uplně velkému ispíkovi, tam se taky může projevit šetření. Tam potom chápu, že dokazovat chybovost jednomu nebo druhému subjektu může být problém.

[sub_zero]

u okruhu CETINu jsem řešil úplně stejný problém. Nakonec to bylo nastavením MTU, protože okruh byl konfigurovanej jako QinQ (zjistili jsme samozřejmě až později při troubleshootingu) a tomu jsme museli přizpůsobit MTU.

[cmgn]

u okruhu CETINu jsem řešil úplně stejný problém. Nakonec to bylo nastavením MTU, protože okruh byl konfigurovanej jako QinQ (zjistili jsme samozřejmě až později při troubleshootingu) a tomu jsme museli přizpůsobit MTU.

Jaké MTU jste použili? Já mám default 1500

[midnight_man]

no hej ale od teba ku miestu kde meras je dalsich XY zariadeni

[cmgn]

no hej ale od teba ku miestu kde meras je dalsich XY zariadeni

No proto mě zajímá, co jaká hodnota by tam tak mohla sedět Je fakt, že při zvýšení na 1600 se to už docela dost zlepšilo

[Dalibor Toman]

u okruhu CETINu jsem řešil úplně stejný problém. Nakonec to bylo nastavením MTU, protože okruh byl konfigurovanej jako QinQ (zjistili jsme samozřejmě až později při troubleshootingu) a tomu jsme museli přizpůsobit MTU.

to je snad problem dodavatele okruhu - aby si zvetsil MTU tak, aby se mu tam cely normalni eth frame vesel i s dalsima VLAN hlavickama. Prece nebudu kvuli okruhu od 3ti strany zmensovat MTU a pridelavat si tezko resitelne problemy...

[cmgn]

MTU se zdá být asi OK. MTU 9000 to protlačí. Na stole funguje vše dobře, ale asi opravdu zlobí ten okruh. Za ním to dělá problémy.

[hapi]

mtu si měl zmenšit a ne zvětšit.

[radik]

u okruhu CETINu jsem řešil úplně stejný problém. Nakonec to bylo nastavením MTU, protože okruh byl konfigurovanej jako QinQ (zjistili jsme samozřejmě až později při troubleshootingu) a tomu jsme museli přizpůsobit MTU.

Pokud je konfiguracne QinQ, tak u poskytovatel se zvetsi MTU v podstate + se neresi tag vlany. Velikost MTU je jen jak maximalne velky se prenese ramec, takze nepredpokladam, ze by problem mohl byt v tomto.