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.
