Jak tu zminujete ty meraky.. o jaky modely konkretne jde? Jen ty "tupy" UDPckovy? Ktery zjistej, ze linka je po fyzicky vrstve ok?
Byl bych velice rad a zrejme kontaktuju ociora, aby mi problematiku mereni linky dle RCF2244 vysvetlil trosku detailneji, jelikoz se mnozi castejsi problemy s vytizenim linek jednim tcp spojenim a poskytovatel prvni co udela, tak zmeri lajnu prave merakem na UDP, ten samozrejme neukaze zadnej problem a trouble ticket uzavrenej. Ani PL na tech problematickejch linkach neni, ale vytizit se je proste na jedno spojeni nepodari. A muze tam bejt Debian, Ubuntu nebo blby widle. Prave proto by me zajimalo, zda existuje nejakej eth merak, kterej umi pracovat s TCP, dokaze tak nasimulovat de fakto realnej provoz (vc. ACK, SYN atd) a pracovat s winsows size.
❗️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ů
-
sub_zero
- Příspěvky: 1741
- Registrován: 19 years ago
- antispam: Ano
- Bydliště: Olomouc
- Kontaktovat uživatele:
Re: Test a analýza hraničních routerů
0 x
Říkáš-li, že něco nejde, znamená to, že to neumíš.
Jirka Lazorčák
PS: Ta fotka je stará, už mám +15kilo..
Jirka Lazorčák
PS: Ta fotka je stará, už mám +15kilo..
sub_zero píše:Jak tu zminujete ty meraky.. o jaky modely konkretne jde? Jen ty "tupy" UDPckovy? Ktery zjistej, ze linka je po fyzicky vrstve ok?
Byl bych velice rad a zrejme kontaktuju ociora, aby mi problematiku mereni linky dle RCF2244 vysvetlil trosku detailneji, jelikoz se mnozi castejsi problemy s vytizenim linek jednim tcp spojenim a poskytovatel prvni co udela, tak zmeri lajnu prave merakem na UDP, ten samozrejme neukaze zadnej problem a trouble ticket uzavrenej. Ani PL na tech problematickejch linkach neni, ale vytizit se je proste na jedno spojeni nepodari. A muze tam bejt Debian, Ubuntu nebo blby widle. Prave proto by me zajimalo, zda existuje nejakej eth merak, kterej umi pracovat s TCP, dokaze tak nasimulovat de fakto realnej provoz (vc. ACK, SYN atd) a pracovat s winsows size.
Mame 2ks EXFO AXS200/850
0 x
Dan Skoupý
no je pravda že většina problemů je s konektivitou a neni možný dokopat dodavatele k nápravě a je na to hluchej. Kolik chceš za provedení testu a co k tomu potřebuješ případně jak test probíhá?
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
hapi píše:no je pravda že většina problemů je s konektivitou a neni možný dokopat dodavatele k nápravě a je na to hluchej. Kolik chceš za provedení testu a co k tomu potřebuješ případně jak test probíhá?
Kopani dodavatele probiha jedinou moznou cestou, tusit kde ma chybu a donutit ho se na to misto podivat. Takze nemluvit s nekym na NOC, ale s konkretnim technikem, ktery ma chut neco resit.
To, ze si strcis merak na linku a ukaze/neukaze chybovost neznamena vubec nic. Kdyz vidim co k nam pada za sracky z dohledu operatoru, kterym zakaznik neco reklamuje a my dodavame cast okruhu, tak bych blil. Skoro mam pocit, ze vsichni na dohledu si mysli, ze jejich sit je dokonala a az vsichni ostatni vrati zpet vyjadreni, ze je vse ok, mozna to u nich eskaluji nekam vys. Takze at nameris co nameris nebude ti to ve finale vubec k nicemu. A v dnesni dobe kupuje kazdy od kazdeho, takze nemas tuseni kudy ta linka opravdu jde.
Uz jsem ti psal nekolikrat co mas udelat, zmerit a porovnat, aby ses dostal k nejakemu zaveru a tuseni co muze byt spatne. Merak ma jedinou vyhodu u tvych problemu, kdyz z nej vyleze chyba a posles s reklamaci protokol, tak si kazdy dvakrat rozmysli ti rict, ze jde o chybu mereni.
0 x
Dan Skoupý
-
sub_zero
- Příspěvky: 1741
- Registrován: 19 years ago
- antispam: Ano
- Bydliště: Olomouc
- Kontaktovat uživatele:
ok, jak dodavatele dokopat, aby pres portovou konektivitu to jelo na jedno TCP spojeni alespon rekneme 100Mbit /http, ftp/, kdyz u konkurencni site to na to jedno spojeni na identickej server jede.
0 x
Říkáš-li, že něco nejde, znamená to, že to neumíš.
Jirka Lazorčák
PS: Ta fotka je stará, už mám +15kilo..
Jirka Lazorčák
PS: Ta fotka je stará, už mám +15kilo..
no já nevim ale z dodavatele konektivity nevytřískáš nic když nechce. Nechápu jak můžu něco já najít když v dnešní době to jde přes MPSL skrz celou republiku a nemáš šanci zjistit vůbec nic. Jak pak mám zjistit kde je něco špatně? Jo určitě mě pustí s měřákem na jeho popy po cestě 
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
Pridam zase jednu k dobru.
Meli jsme kdysi od Aliatelu 2Mbps a navysovali na 6Mbps. Tehdy velka akce, chteli jsme dal rychle rust, takze se pro nas privedla cela STM1, o ktere nikdo nechtel rict jak je smerem nahoru zapojena. Dostal jsem FE port a bylo vymalovano, vsechno slapalo. Pak se navysilo na 10Mbps a to uz takova sranda nebyla. Ta linka to chvili dala, chvili ne. Ztratovala neztratovala. Takze jsem ve tri rano odpojil sit a zacal zkoumat co je zle, chybu jsem hledal u sebe a nenasel jsem nic. Bylo uz rano, pripojil jsem zpet sit a zavolal na dohled, zapsal TT a sel spat do auta. Vzbudil me telefon, ze u nich vsechno v poradku. Tak znova jsem hledal, nenasel. Dalsi hovor na dohled a uz me poslali do haje, ze je to OK a nic zapisovat nebudou. Mel jsem interni tel. seznam Aliatelu a dovolal se technickemu rediteli co byl na horach s rodinou, ktery zjebal dohled a dal hledali. Po trech dnech hledani na obou stranach panum rikam, ze se mi zda jakoby ta linka po ceste byla na 10Mbps HD. Za pet minut telefon, ze to tak fakt bylo. Technicky vyreseno, omluva zadna, sleva zadna.
Od tech dob zadna zmena, netrivialni problemy si clovek musi najit a vyrvat sam.
Nez jsem to dopsal, tak se ptas.
Udelej si na obou sitich idealne i stranach tcpdump toho spojeni a najdi v cem je ten rozdil, ktery to brzdi. Dohodnou se na jine velikosti TCP okna? Nebo je to po jedne trase vyrazne dal? Jako merici stroj pouzij neco idealne s freebsd, ktere dava v ip stacku windows, dokonce i linuxu (mozna uz je to lepsi) na prdel.
Meli jsme kdysi od Aliatelu 2Mbps a navysovali na 6Mbps. Tehdy velka akce, chteli jsme dal rychle rust, takze se pro nas privedla cela STM1, o ktere nikdo nechtel rict jak je smerem nahoru zapojena. Dostal jsem FE port a bylo vymalovano, vsechno slapalo. Pak se navysilo na 10Mbps a to uz takova sranda nebyla. Ta linka to chvili dala, chvili ne. Ztratovala neztratovala. Takze jsem ve tri rano odpojil sit a zacal zkoumat co je zle, chybu jsem hledal u sebe a nenasel jsem nic. Bylo uz rano, pripojil jsem zpet sit a zavolal na dohled, zapsal TT a sel spat do auta. Vzbudil me telefon, ze u nich vsechno v poradku. Tak znova jsem hledal, nenasel. Dalsi hovor na dohled a uz me poslali do haje, ze je to OK a nic zapisovat nebudou. Mel jsem interni tel. seznam Aliatelu a dovolal se technickemu rediteli co byl na horach s rodinou, ktery zjebal dohled a dal hledali. Po trech dnech hledani na obou stranach panum rikam, ze se mi zda jakoby ta linka po ceste byla na 10Mbps HD. Za pet minut telefon, ze to tak fakt bylo. Technicky vyreseno, omluva zadna, sleva zadna.
Od tech dob zadna zmena, netrivialni problemy si clovek musi najit a vyrvat sam.
sub_zero píše:ok, jak dodavatele dokopat, aby pres portovou konektivitu to jelo na jedno TCP spojeni alespon rekneme 100Mbit /http, ftp/, kdyz u konkurencni site to na to jedno spojeni na identickej server jede.
Nez jsem to dopsal, tak se ptas.
Udelej si na obou sitich idealne i stranach tcpdump toho spojeni a najdi v cem je ten rozdil, ktery to brzdi. Dohodnou se na jine velikosti TCP okna? Nebo je to po jedne trase vyrazne dal? Jako merici stroj pouzij neco idealne s freebsd, ktere dava v ip stacku windows, dokonce i linuxu (mozna uz je to lepsi) na prdel.
0 x
Dan Skoupý
zdar lidi, tak přinášim po dlouhé době výsledky s tím když kopete do dodavatele aby vše udělal ke správnému obrazu a řešil packet losty nebo našel kde je problem.
Asi před půl rokem jsme měnily dodavatele konektivity. Předchozí dodavatel byl katastrofální a nechtěl nic řešit se slovy "packet lost je běžný". Packet lost dosahoval v tu dobu na 1% při špičkách. V tu dobu jsem ještě nepřijímal netflow data od jiných ISPíků. Rychlost 60Mbit. Desktop server + intel ethernety. Později jsem zprovoznil sběr netflow dat a PL furt stejný.
Takže jsme po vypršení smlouvy odešly a přešly k dial telecomu. Postavila se příhrada, dial přes cbl nasadil 18GHz ceragona a my začly sledovat packet lost. A na co se nepřišlo. Po propojení ceragonu s bránou začali naskakovat RX errory na ethernetu routeru. RX errory začnou naskakovat tehdy, když například ethernet neni schopný z media správně vyčíst ethernetový rámec a nesouhlasí s kontrolním součtem. Síťová karta okamžitě začne vypisovat RX errory. Nejde o softwarovou chybu ale o chybu přenosovýho media, hardwarová chyba. Co nás tedy napadlo. Vložily jsme do cesty mediakonvertory a počet rx errorů se výrazně snížil ale i tak naskakovaly v řádu desítek za minutu. Vzaly měřák a začali měřit zemní potencialy. Našlo se 70-110V mezi šasím mediakonvertoru a routerem. To samé u ceragonu. Uzemnily jsme tedy konvertory na každý straně s šáskem routeru případně ceragonu a rx errory jsou fuč. Časem se nahradily stíněnými patch kabely a je klid. 70-100V rozdílů vymizel a ethernetový tráfka si nejspíš oddychly.
No ale obecnej packet lost byl stále přítomen. Takže jsme oslovily dial telecom a začli jsme řešit. Přijel první technik od nich s nějakým měřákem. On nenaměřil žádný PL i přesto že jsme při měřený pozorovaly packet lost na obyčejném pingu. No nicméně, odjel že je to ok. Tak jsme začaly řešit sami. Výměna routeru jakožto prvního podezřelého prvku. Ve vnitřní síti sice PL nebyl což nás hodně mátlo. Proč by router skr dva ethernety chyboval a skrz jeden ne. Nicméně výměna za jiný desktop a i jiné ethernety nepomohla a vše bylo jako přes kopírák. Dokonce se ze zoufalství zapůjčilo z i4wifi i RB1100AHx2. Nastoupíla druhá fáze. Našetřilo se na nový router a koupilo se supermicro protože furt v hlavě hlodá "co kdyby za to mohl nějakej ten desktop". Což přineslo jak lepší pocit z lepšího hardware tak ke snížení spotřeby a i k obrovské výkonové rezervě. Nicméně packet lost zůstal nezměněn.
Zvednul se telefon a opět zavolal dial telecom. Jiný technik přijel s daleko větší a nabušenější krabičkou a cisco switchem (3650) jako monitoring rychlosti. Vložil ho mezi bránu a ceragon a mohl testovat za provozu. Říká, byl jsem teď na druhý straně ceragonu a 3 hodiny jsem pouštěl do Prahy asi 200Mbit a nevypadnul ani jediný packet. Zapnul test na naší straně a packet lost jak vyšitý. Defakto při >60Mbit datovýho toku (ceragon licence na 100mbit, profil 103Mbit). Tak a co teď? Technik volá cblků, povoluje se licence ceragonu na 150mbit a stále to samé. Povoluje shaping na jejich hlavnim routeru a stále to samé. Pak někdo z cbl kouká a ceragon na straně dialu ukazuje RX dropy na ethernetu. RX drop (neplést s RX errorem) je převážně způsobený tím, že zařízení nestíhá přijímat datový tok a proto pakety zahodí. Je to jedna z forem obrany když neni zapnuté flow control. Ovšem ono to může být i z jiných důvodu. Jeden se nabízel okamžitě a tím důvodem byl špičkový neboly nárazový datový tok který tekl do ceragonu a on se chudák malej musel bránit tak, že zadropoval. Jelikož do něj může po ethernetu téct až 1Gbit ovšem radiová strana unese pouze 150Mbit. To je obrovskej nepoměr kterej našponovává buffery ceragonu až k dropům. Ok, vyzbrojeni touto myšlenkou se přenastavilo naše omezení na hlavnim routeru dial telecomu. Zkrátila se fronta na jejich centrálnim ciscu a omezila na 100mbit. Tedy, zkoušelo se všelicos ale packet lost stále odolával. Po 4 hodinách se tedy usoudilo že to rozpustíme a dial bude věc přezkoumávat v jejich kolektivu s více techniky a že se ozvou. Byrokracie nějaký čas trvá a mě začala nahlodávat myšlenka těch špiček a co by to asi tak mohlo děla.
Jednoho dne mě napadlo, že nějaký klient který posílá netflow data může mít špatně nastavený nějaký buffer v traffic flow v mikrotiku. Je tam totiž taková nevinně vypadající položka "cache entries". Pokud si přečtete co znamená zjistíte, že to je buffer pro zběr dat kam se ukládají data před odesláním na server. Ano, traffic flow se posílá v UDP. Rozeslal jsem klientům nové nastavení traffic flow a hle, ukázalo se že jeden klient, ten největší klient se dvěmi routery a každý s konektivitou 250Mbit měl na obou z nich nastavený cache entries na 512k. Standartně bývá 4k. Co to může způsobit? No, ten klient má tyto dva routery připojeny konektivitou 1Gbit. Pokud se touto rychlostí pošle 512k datovej tok a první výrazná brzda je právě ten ceragon, dojde k dropu v ceragonu jakožto nejužší hrdlo. Teorie se potvrdila a okamžite po upravení nastavení cache entries na původních 4k packet lost téměř vymizel. Z extrémních až 2% se vytratil někam k 0.02% a to ještě tyhle dvě setiny jsou způsobený vlastním laborováním. Ok tedy, proběhla komunikace s dial telecomem a vše bylo v pořádku.
Jelikož už 100Mbit je pro nás málo, rovnou jsme je požádaly na test o 150Mbit aby se to vyzkoušelo jestli tam opět nebude nějaký packet lost. Při prvním testu byla maximální rychlost pouze cca 140Mbit. Dial říká 142Mbit, mikrotik 138Mbit. Packet lost logicky při dosažení této hranice jinak ne. Takže opět telefon a na drátě dial že se na to podívaji. Řešilo se vše možné, nějaký stahovací testy po telefonu a všichni shodně vidíme cca 140Mbit. Tak technik s měřákem, ok, přijel. Vyndal měřák, opět měřák + cisco na propojení. Zapnul a opět PL. To je divný, my ho moc neregistrujem a on to vidí okamžitě. Volá se cbl, zvednou licenci na 300Mbit. Stále skrz spoj 138Mbit. Je jasný že chyba je v ceragonu. Loopback je připojenej do switche na popou ceragonu takže se testuje pouze ceragon. Ok, co teď. Ví se, že to je ceragon ale neví se proč. Tady vzniká hlavní chyba. Velký firmy jsou si totiž vždy jisté, že u nich chyba není. Je to celkem oprávněné. V drtivé většině bývá chyba u odběratele. Ovšem když už technik dial telecomu prohlásí že měřák ukazuje PL a rychlost je nizká, cbl začne konečně pořádně prozkoumávat ceragon. Zjistí se jedna špatná zátržka. Rychlost okamžitě vyletěla duplexně na 330Mbit. Všichni si oddychnem a zdělujem cblku že to je ok. cblko říká že to přenastavý do finální podoby (150Mbit) a vše se vrátí tak jak by to mělo být (dial telecom), čeká se na závěrečný telefonát. Telefon zazvoní, otestuje se, linka duplexně 152Mbit, vše ok. Technik dialu se ptá technika cbl po telefonu kde byla chyba. Logicky, neřek nic konkrétního, jenom řek že to bylo něco v nastavení a víc nám neřekne a nechce říct. No co, dial odjíždí s tím že konektivita frčí 150Mbit, PL není. cca před 90 minutami vyřešeno.
Hlavní poznatky:
Pokud chcete s někym o něčem takovém jednat a řešit problem s nějakou velkou firmou která prostě nezaměstnává blbce (pokud to neni blbá firma
) tak oni vědí. Oni vědí tolik aby vás dostaly do rohu a že je chyba u vás. V tom případě musíte vědět víc než oni a mít už plno testů a předpokládat to, na co se budou ptát. Např: kam testuju rychost? je to spolehlivý zdroj? nemá ten zdroj taky packet lost? Je tedy dobré mít víc referencí a okamžitě jim vracet potažmo i vyvracet nějaký teorie který na vás bude mít helpdesk připravený. To se mi dařilo velmi úspěšně. Nevyplácí se říkat věci typu: za co vám platim takový prachy když to nejede? nebo proč vám to trvá tejden než se něco pohne? atd.. je třeba si uvědomit že čim větší firma, tim větší byrokratický kolečko. Můžete se stavit na hlavu ale nic s tim neuděláte. Jednoduše slušnost na prvni místě. Technik prostě nemůže jenom tak něco někde změnit aniž by to něčim někde neprošlo. Jo nějaký věci dočasně může ale ne všechno a ne okamžitě když jim zavoláte na helpdesk. Dál například je i věc ta, že ne každej technik umí s měřákem měřit viz. první technik. To že má nabušenej měřák na x stovek tisíc neznamená že ho umí používat.
Závěr si udělejte sami. Z mého pohledu se dial suveréně o nás postaral a měly zájem na tom aby jsme byly spokojeni. Přesný údaje od nás podložený reálnými daty a případně přiznání vlastních chyb celou situaci jenom ulehčuje. Jo, všechno toto trvalo 5 měsíců ale odměnou z to je konektivita která funguje tak jak má. Ano, prvotní chyba s packet lostem byla čistě naše vinna způsobená špatnym nastavení cache v traffic flow čimž se nejspíš rozjelo kolečko dalších chyb a slepích cest v hledání problemů ale hlavní je že se problem nakonec našel.
Asi před půl rokem jsme měnily dodavatele konektivity. Předchozí dodavatel byl katastrofální a nechtěl nic řešit se slovy "packet lost je běžný". Packet lost dosahoval v tu dobu na 1% při špičkách. V tu dobu jsem ještě nepřijímal netflow data od jiných ISPíků. Rychlost 60Mbit. Desktop server + intel ethernety. Později jsem zprovoznil sběr netflow dat a PL furt stejný.
Takže jsme po vypršení smlouvy odešly a přešly k dial telecomu. Postavila se příhrada, dial přes cbl nasadil 18GHz ceragona a my začly sledovat packet lost. A na co se nepřišlo. Po propojení ceragonu s bránou začali naskakovat RX errory na ethernetu routeru. RX errory začnou naskakovat tehdy, když například ethernet neni schopný z media správně vyčíst ethernetový rámec a nesouhlasí s kontrolním součtem. Síťová karta okamžitě začne vypisovat RX errory. Nejde o softwarovou chybu ale o chybu přenosovýho media, hardwarová chyba. Co nás tedy napadlo. Vložily jsme do cesty mediakonvertory a počet rx errorů se výrazně snížil ale i tak naskakovaly v řádu desítek za minutu. Vzaly měřák a začali měřit zemní potencialy. Našlo se 70-110V mezi šasím mediakonvertoru a routerem. To samé u ceragonu. Uzemnily jsme tedy konvertory na každý straně s šáskem routeru případně ceragonu a rx errory jsou fuč. Časem se nahradily stíněnými patch kabely a je klid. 70-100V rozdílů vymizel a ethernetový tráfka si nejspíš oddychly.
No ale obecnej packet lost byl stále přítomen. Takže jsme oslovily dial telecom a začli jsme řešit. Přijel první technik od nich s nějakým měřákem. On nenaměřil žádný PL i přesto že jsme při měřený pozorovaly packet lost na obyčejném pingu. No nicméně, odjel že je to ok. Tak jsme začaly řešit sami. Výměna routeru jakožto prvního podezřelého prvku. Ve vnitřní síti sice PL nebyl což nás hodně mátlo. Proč by router skr dva ethernety chyboval a skrz jeden ne. Nicméně výměna za jiný desktop a i jiné ethernety nepomohla a vše bylo jako přes kopírák. Dokonce se ze zoufalství zapůjčilo z i4wifi i RB1100AHx2. Nastoupíla druhá fáze. Našetřilo se na nový router a koupilo se supermicro protože furt v hlavě hlodá "co kdyby za to mohl nějakej ten desktop". Což přineslo jak lepší pocit z lepšího hardware tak ke snížení spotřeby a i k obrovské výkonové rezervě. Nicméně packet lost zůstal nezměněn.
Zvednul se telefon a opět zavolal dial telecom. Jiný technik přijel s daleko větší a nabušenější krabičkou a cisco switchem (3650) jako monitoring rychlosti. Vložil ho mezi bránu a ceragon a mohl testovat za provozu. Říká, byl jsem teď na druhý straně ceragonu a 3 hodiny jsem pouštěl do Prahy asi 200Mbit a nevypadnul ani jediný packet. Zapnul test na naší straně a packet lost jak vyšitý. Defakto při >60Mbit datovýho toku (ceragon licence na 100mbit, profil 103Mbit). Tak a co teď? Technik volá cblků, povoluje se licence ceragonu na 150mbit a stále to samé. Povoluje shaping na jejich hlavnim routeru a stále to samé. Pak někdo z cbl kouká a ceragon na straně dialu ukazuje RX dropy na ethernetu. RX drop (neplést s RX errorem) je převážně způsobený tím, že zařízení nestíhá přijímat datový tok a proto pakety zahodí. Je to jedna z forem obrany když neni zapnuté flow control. Ovšem ono to může být i z jiných důvodu. Jeden se nabízel okamžitě a tím důvodem byl špičkový neboly nárazový datový tok který tekl do ceragonu a on se chudák malej musel bránit tak, že zadropoval. Jelikož do něj může po ethernetu téct až 1Gbit ovšem radiová strana unese pouze 150Mbit. To je obrovskej nepoměr kterej našponovává buffery ceragonu až k dropům. Ok, vyzbrojeni touto myšlenkou se přenastavilo naše omezení na hlavnim routeru dial telecomu. Zkrátila se fronta na jejich centrálnim ciscu a omezila na 100mbit. Tedy, zkoušelo se všelicos ale packet lost stále odolával. Po 4 hodinách se tedy usoudilo že to rozpustíme a dial bude věc přezkoumávat v jejich kolektivu s více techniky a že se ozvou. Byrokracie nějaký čas trvá a mě začala nahlodávat myšlenka těch špiček a co by to asi tak mohlo děla.
Jednoho dne mě napadlo, že nějaký klient který posílá netflow data může mít špatně nastavený nějaký buffer v traffic flow v mikrotiku. Je tam totiž taková nevinně vypadající položka "cache entries". Pokud si přečtete co znamená zjistíte, že to je buffer pro zběr dat kam se ukládají data před odesláním na server. Ano, traffic flow se posílá v UDP. Rozeslal jsem klientům nové nastavení traffic flow a hle, ukázalo se že jeden klient, ten největší klient se dvěmi routery a každý s konektivitou 250Mbit měl na obou z nich nastavený cache entries na 512k. Standartně bývá 4k. Co to může způsobit? No, ten klient má tyto dva routery připojeny konektivitou 1Gbit. Pokud se touto rychlostí pošle 512k datovej tok a první výrazná brzda je právě ten ceragon, dojde k dropu v ceragonu jakožto nejužší hrdlo. Teorie se potvrdila a okamžite po upravení nastavení cache entries na původních 4k packet lost téměř vymizel. Z extrémních až 2% se vytratil někam k 0.02% a to ještě tyhle dvě setiny jsou způsobený vlastním laborováním. Ok tedy, proběhla komunikace s dial telecomem a vše bylo v pořádku.
Jelikož už 100Mbit je pro nás málo, rovnou jsme je požádaly na test o 150Mbit aby se to vyzkoušelo jestli tam opět nebude nějaký packet lost. Při prvním testu byla maximální rychlost pouze cca 140Mbit. Dial říká 142Mbit, mikrotik 138Mbit. Packet lost logicky při dosažení této hranice jinak ne. Takže opět telefon a na drátě dial že se na to podívaji. Řešilo se vše možné, nějaký stahovací testy po telefonu a všichni shodně vidíme cca 140Mbit. Tak technik s měřákem, ok, přijel. Vyndal měřák, opět měřák + cisco na propojení. Zapnul a opět PL. To je divný, my ho moc neregistrujem a on to vidí okamžitě. Volá se cbl, zvednou licenci na 300Mbit. Stále skrz spoj 138Mbit. Je jasný že chyba je v ceragonu. Loopback je připojenej do switche na popou ceragonu takže se testuje pouze ceragon. Ok, co teď. Ví se, že to je ceragon ale neví se proč. Tady vzniká hlavní chyba. Velký firmy jsou si totiž vždy jisté, že u nich chyba není. Je to celkem oprávněné. V drtivé většině bývá chyba u odběratele. Ovšem když už technik dial telecomu prohlásí že měřák ukazuje PL a rychlost je nizká, cbl začne konečně pořádně prozkoumávat ceragon. Zjistí se jedna špatná zátržka. Rychlost okamžitě vyletěla duplexně na 330Mbit. Všichni si oddychnem a zdělujem cblku že to je ok. cblko říká že to přenastavý do finální podoby (150Mbit) a vše se vrátí tak jak by to mělo být (dial telecom), čeká se na závěrečný telefonát. Telefon zazvoní, otestuje se, linka duplexně 152Mbit, vše ok. Technik dialu se ptá technika cbl po telefonu kde byla chyba. Logicky, neřek nic konkrétního, jenom řek že to bylo něco v nastavení a víc nám neřekne a nechce říct. No co, dial odjíždí s tím že konektivita frčí 150Mbit, PL není. cca před 90 minutami vyřešeno.
Hlavní poznatky:
Pokud chcete s někym o něčem takovém jednat a řešit problem s nějakou velkou firmou která prostě nezaměstnává blbce (pokud to neni blbá firma
) tak oni vědí. Oni vědí tolik aby vás dostaly do rohu a že je chyba u vás. V tom případě musíte vědět víc než oni a mít už plno testů a předpokládat to, na co se budou ptát. Např: kam testuju rychost? je to spolehlivý zdroj? nemá ten zdroj taky packet lost? Je tedy dobré mít víc referencí a okamžitě jim vracet potažmo i vyvracet nějaký teorie který na vás bude mít helpdesk připravený. To se mi dařilo velmi úspěšně. Nevyplácí se říkat věci typu: za co vám platim takový prachy když to nejede? nebo proč vám to trvá tejden než se něco pohne? atd.. je třeba si uvědomit že čim větší firma, tim větší byrokratický kolečko. Můžete se stavit na hlavu ale nic s tim neuděláte. Jednoduše slušnost na prvni místě. Technik prostě nemůže jenom tak něco někde změnit aniž by to něčim někde neprošlo. Jo nějaký věci dočasně může ale ne všechno a ne okamžitě když jim zavoláte na helpdesk. Dál například je i věc ta, že ne každej technik umí s měřákem měřit viz. první technik. To že má nabušenej měřák na x stovek tisíc neznamená že ho umí používat.Závěr si udělejte sami. Z mého pohledu se dial suveréně o nás postaral a měly zájem na tom aby jsme byly spokojeni. Přesný údaje od nás podložený reálnými daty a případně přiznání vlastních chyb celou situaci jenom ulehčuje. Jo, všechno toto trvalo 5 měsíců ale odměnou z to je konektivita která funguje tak jak má. Ano, prvotní chyba s packet lostem byla čistě naše vinna způsobená špatnym nastavení cache v traffic flow čimž se nejspíš rozjelo kolečko dalších chyb a slepích cest v hledání problemů ale hlavní je že se problem nakonec našel.
1 x
správná otázka, je vidět že někdo dával pozor. Nad timhle jsme s technikem kroutily hlavou taky. Dokonce i když ceragon byl na 150Mbit a shaping v dialu na 100Mbit, bylo to tam a to i když se laborovalo s délkou bufferu ve shaperu atd... až nastavení shaperu hluboko pod 100Mbit to bylo ok. Nechápem.
0 x
Podobnou vec z PL jsem tez resil s dialem.Mezi jejich ciskem a moji 1s10 narustaly chyby na ethernetu a rychlost byla max. 40mbit/s. Az po vlozeni obycejneho Gbit swithe mezi ne pomohlo a rychlost je jak ma byt a PL uz neni.. 
0 x
tohle se stává docela často mezi radiama a ciscama. Můj problem byl ale v návalu UDP paketů do ceragonu.
0 x
Neni to tak dlouho, co se bohuzel jeden znamy rozloucil po X mesicni tahanici o kvalitach sluzby s GTS. V hlavni roli tam byl taky ceragon a bylo to asi i misto problemu. Bohuzel velka firma, velka byrokracie, mala pruznost...
0 x
Nemáš od nich náhodou i IPV6 adresy? A shaping provádí korektně pouze pro IPV4? Tam by to taky mohlo přetékat. Teď taky laborujem s centrálním IPV6 shapingem
0 x
sub_zero píše:Hele, jen jedna technická.. jak a kde Dial shapoval? Pokud shapoval někde na PE ještě před Ceragonem (což je nejpravděpodobnější), tak jak se na něm mohly přervat buffery?
teď sem si vzpoměl že ten technik říkal že na shapingu maji určitej burst kterej jede bez shapingu než to chytne. Jestli tohle mohlo za to že to přeteklo na ceragonu nevim.
0 x