Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Ladislav Zitka 23. 02. 2018, 09:59:35
-
Zdravim, v Brusellu provozujeme operacni centrum, pripojujeme se odtamtud do dvou datovych center ve Francii.
Aplikace tahaji data hrozne pomalu, vypada to, jako by nekdo saturoval sit, ale na firewallech neni v logu videt nic zvlastniho, sit se jevi jako volna, resp. to jsou ukazky naseho infrastructure vendora, ktery uz nekolik mesicu neni schopen odhalit a napravit pricinu.
Napadlo me, jestli to nemuzou zpusobit nejake cykly v siti, spatne nastavene routy, apod.
Existuji nejake nastroje, ktere by dokazali odhalit nabo pomoci odhalit pricinu z klientske stanice? Jinak je sit nase a muzeme si tam delat co chceme samozrejme, takze instalace i nejakych tools typu nmap nebo kali linux neni problem. Jde o to, ze tahani z francie je pomale, ale oni tvrdi, ze sit je prazdna. To mi trochu nahrava do scenare, ze je problem nekde v nasi budove, ale vendor nam take vylozene nekdy lze, takze je tu problem s duverou informaci, ktere nam prezentuje... Jedna se o firmu Atos.
Diky za jakekoli podnety, napady, jak na odhaleni takoveho problemu. Pristup na firewally osobne nemame, zadali jsme read only, ale bylo to zamitnuto ze strany vendora.
Ja osobne zde navrhuju microservice architektury, ale tohle nas uz tizi delsi dobu, tak me napadlo zeptat se zdejsi TOP class komunity, jestli nekdo vidi nejakou cestu, jak se zhostit teto trisky v noze.
Diky.
Lada
-
Z klienta zkuste iperf. Pokud mate pristup na switche, tak lze pripadne vytizeni sledovat primo na switchich at uz v realnem case, nebo pres snmp. To by mohlo ukazat bottleneck. Dalsi pomuckou by mohlo byt mtr.
-
Nice.
-
Nastroju je spousta, zalezi co vsechno mas v ceste, pokud mas pristup na veskery hopy, tak si je nejak pripoj, a podivej se jaky prenosy jsou na portech/celkove, zatizeni CPU atd. Zkontroluj taky pocet prenasenych paketu - kazdej sitovej prvek je primarne omezenej prave tim, a ne rychlosti portu.
Co se tyce routovani, to by se ti projevilo ztratama paketu/vysokou latenci, pripadne obrovskym rozptylem latence. Na zakladni diagnostiku ti staci ping (teda asi ne ten windowsi). On se da do jisty miry pouzit i na prekontrolovani prenosovy rychlosti - kdyz posles velky pakety.
-
A jste si jisty, ze za to muze sit a ne ta vase aplikace? Treba kdyz si pustite netcat mezi Francii a Bruselem, tak to chodi pomalu take?
-
Diky za podnety, pristi tyden odzkousim zde navrhovane postupy a postnu vysledky.
-
Taky pingplotter je fajn, kreslí historii
-
A jste si jisty, ze za to muze sit a ne ta vase aplikace? Treba kdyz si pustite netcat mezi Francii a Bruselem, tak to chodi pomalu take?
Co teprv ze Sitborich do Jardikovic :)
-
Zdravim, v Brusellu provozujeme operacni centrum
Ja osobne zde navrhuju microservice architektury
A to v té Bruseli nemáte nějaké síťaře, kteří by to vyřešili? To je hroznej úpadek, když Belgikánci musí škemrat o pomoc zadarmo zde na divokém východě....
-
Co vidim v linkedinu ...
Ladislav Jech
3rd degree connection3rd
Architect at Coreso SA
Coreso SA
Brussels, Brussels Capital Region, Belgium 500+ 500+ connections
Aneb tohle fakt musí řešit architekt, to už probublalo všude?
A) znáte svou aplikaci, požadavky? Jak komunikuje, kolik má streamů, spojení, jak velké pakety posílá, jaká je architektura a logika aplikace?
B) odkud kam to nejde, plošně? Nebo jen "někde", mezi některými body sítě?
-
Mozna jen nestiha firewall, staci prekrocit limit poctu conntracku, ktere ma drzet v pameti a sit zacne pekne haprovat. Projevuje se to zahazovanim paketu, treba pri dlouhodobem pingu to jde pekne videt.
-
Kdyby to byla "korporátní síť" přes síť poskytovatele, tak vezmu jeden "packet capture" na straně serveru (aplikace) a druhý na straně klienta. Co vyleze na jedné straně se musí dostat na druhou stranu. Ideálně bez znatelného zpoždění.
-
Ještě jedna věc: vy jakožto "uživatel" můžete komunikovat tak nějak šifrovaně, udělat si testovací tunel mezi náhodnými lokalitami, pokud je toho víc. A pozorovat chování sítě a provozu a podle toho zjišťovat co je se sítí. (Pokud nemáte jak identifikovat provoz aplikace, u ipsecu byste to snad mohli umět)
Aneb když nějaká Cisco ASA je přetížená, může dropovat 10% provozu a běžný admin si toho nevšimne.
Firewally se běžně chovají jako TCP proxy, tj. přeposílají komunikaci dál až když jí rozumějí, až když má z jejich pohledu smysl. Dělají retransmise paketů/rámců, hýbají s TCP oknem apod.
Každopádně by bylo dobře, kdyby se sešli všichni, kdo do toho vidí, všechny týmy.
-
Zdravim, v Brusellu provozujeme operacni centrum, pripojujeme se odtamtud do dvou datovych center ve Francii.
Takovej světák a ptá se na fóru pro pubertální trolly :o
-
Jj, uz to musi resit i architekt :-)))
Vec se ma tak, ze behame na tzv black fibers (fyzicke nesdilene linky) vs white fibers (sdilene linky). Nasim infrastructure vendorem je firma Atos, ktera nam samozrejme dodala i "sitove experty", kteri behem nekolika dni na nic neprisli :-((( s tim, ze nevidi nic podezreleho. Tato firma si ale nektere sitove linky pronajima od dalsiho providera, tj. litame z Belgie po dalsich zemich, nez se dostaneme do Francie....
Tech aplikaci, ktere jsou afektovane je vicero, vsechny. Jelikoz v tom sam nejsem zainteresovany naplno, ale uz me to sere, protoze ta blokada trva uz nekolik tydnu a uzivatele mi breci u stolu v oficu, tak jsem si rekl, ze to zkusime nejak objevit z nasi klientske strany, ackoli chapu, ze moznosti jsou v tomto pripade omezene.
Opravdu tato diskuze neni o tom, jestli architekt resi sitove problemy od vendora, proste kdyz je kriticky problem, tak delam cokoli :-)) Takze diky pouze za podnety technickeho razu, ktere mohou pomoci k objeveni priciny ze strany klienta (nas)
Ja budu zpet v officu az ve stredu, tak to proberem, protoze zrovna ted jsem dostal dalsi pozdavake na pomoc s resenim :-))) jako ja se tomu taky smeju, ale evidentne si s tim nevedi nejak rady... me osobne napadlo, ze je tam nejaka smycka, nebo neco u nas v lokalni siti, protoze aplikace jsou pomale na servery (remote), ale linky nemaji zadny velky provoz...
-
Zdravim, v Brusellu provozujeme operacni centrum
Ja osobne zde navrhuju microservice architektury
A to v té Bruseli nemáte nějaké síťaře, kteří by to vyřešili? To je hroznej úpadek, když Belgikánci musí škemrat o pomoc zadarmo zde na divokém východě....
Bohuzel mame celou infrastrukturu jako sluzbu vcetne personalu a sam jsem je uz nekolikrat usvedcil z prime lzi. Priravujeme i reseni je kompletne opustit a prejit jinam, ale vzheledem k tomu, ze poskytujeme sluzby tykajici se bezpecnostnich analyz v ramci pumpovani elektriny po evrope, tak to neni uplne jednoducha zalezitost, i z pohledu legislativy, norem, ktere jsou ruzne pres ruzne staty, apod....
-
Kdyby to byla "korporátní síť" přes síť poskytovatele, tak vezmu jeden "packet capture" na straně serveru (aplikace) a druhý na straně klienta. Co vyleze na jedné straně se musí dostat na druhou stranu. Ideálně bez znatelného zpoždění.
Sit nemame rozhodne pod kontrolou ani v nejakem read only modu na urovni switchu a firewallu, proste nam nechtej dat ani observable mode. Asi vedi proc, nebo rikaj, ze to neni mozne :-)))) tomu se vzdycky vysmeju na meetingu, kdyz to slysim. Ale servery jsou pod nasi kontrolou, nektere jen user, jine root. Zkusime udelat tento scenar. To dava smysl
-
Ve smlouvě byste měli mít i jak co, jakým způsobem, ověříte, plus nějaké SLA.
Jestli tam mají dark fiber, tak to je nedohlížené vlákno, bez kontroly. Pak by měly být na obou stranách nějaké převodníky. Obvykle se tohle řešilo testem linky v délce 1+ hodiny, pokud bylo bez chyb tak ok.
Mimochodem kdybyste pro ně byli lukrativní partner tak vám nabídnou nějakou zálohu a pořeší to jako poskytovatel infrastruktury sami. I tohle je možnost - po technologii X nám to šlape jak víno a po infrastruktuře od vás se to se*e ... dělejte s tím něco.
-
Samozrejme existuje realne podezreni, ze je problem nekde na MPLS levelu, ale tam to resi vendor...
-
Ve smlouvě byste měli mít i jak co, jakým způsobem, ověříte, plus nějaké SLA.
Jestli tam mají dark fiber, tak to je nedohlížené vlákno, bez kontroly. Pak by měly být na obou stranách nějaké převodníky. Obvykle se tohle řešilo testem linky v délce 1+ hodiny, pokud bylo bez chyb tak ok.
Mimochodem kdybyste pro ně byli lukrativní partner tak vám nabídnou nějakou zálohu a pořeší to jako poskytovatel infrastruktury sami. I tohle je možnost - po technologii X nám to šlape jak víno a po infrastruktuře od vás se to se*e ... dělejte s tím něco.
Diky za hint, tak SLA je proste spatne o tom zadna, to uz vime, mame ted objednany audit, ktery by mel overit soucasny setting a zejmena doporucit, jak to resit za soucasneho stavu a i doporucit a navrhnout, co to bude znamenat, kdyz budeme chtit prejit k jinemu vendorovi, protoze tohle je spis tresnicka na dortu :-)) je to pozen
-
Vymlouvat se na nemoznost observable modu, divny...
Prinutit udelat packet capture.
-
K téhle debatě jsem se přitočil trochu pozdě, ale možná to pomůže někomu dalšímu...
Asi nejdůležitější poznatek zní:
o problému nelze konkrétněji debatovat bez konkrétních údajů. Velmi konkrétních.
Topologie sítě, přinejmenším té co máte sami pod palcem,
struktura softwarového řešení které nad tou sítí běží.
Chápu, že toto z principu nemůžete ventilovat ve veřejném debatním kroužku.
Říkáte, že máte pronajatý dark fiber, a zároveň zmiňujete, že to může být kdesi v MPLS levelu?
Slyšel jsem, že se over IP (skrz MPLS) dá transportovat dneska už i SDHčko, ale tmavé vlákno ani lambdu jaksi z principu snad ne :-) Trochu si z Vás utahuju - chci říct, že nelze smíchat jabka a hrušky z několika vrstev a chtít po lidech ve fóru, aby něco od stolu poradili.
Vážně dost srandy:
Aplikujte obecný postup pro hledání závad v topologii. Jestli začnete od konců, nebo odspoda, to je jedno - prostě odněkud. Vyhrnout si rukávy a do toho. Najděte si místo, kam připojíte odposlechovou sondu, a nahrávejte. Neukázal jste ani traceroute. Jsou po cestě nějaké firewally / proxiny skrz které traceroute neproleze? Nebo jenom holé routery? Sem tam nějaký paketový filtr? Je v cestě nějaká VPN technologie? Pokud jsou tam firewally, kolik jich je za sebou? Jak moc krutopřísně jsou zafiltrované? Hrozí po cestě application-level proxy pro konkrétní použité protokoly? A jsem u toho zpátky - pokud mluvíte o pronajatém holém vlákně, tak se asi nebavíme o firewallech? Nebo se to dá chápat tak, že Vám vede mezi lokalitami holé vlákno, ale dodavatel infrastruktury "as a service" si nad tím jede nějaký svůj vlastní obláček, do kterého nevidíte?
Svou sondu můžete vřadit klidně do holého vlákna - pokud si naplánujete výpadek a "poskytovatel as-a-service" Vás k tomu pustí. Pokud nezní zdravě, odposlouchávat to switchem s mirrorovým portem (třeba protože RSTP to pozná a konverguje v desítkách vteřin), existují fiber tapy.
https://www.garlandtechnology.com/products/passive-fiber-network-taps
Nějakých 600 EURO za zcela pasivní duplexní optický odposlech není takový ranec ve srovnání s tím, kolik času jsou bílí límečci schopni strávit vzájemným přesvědčováním v hromadných mailech.
Podobně se dá odposlouchávat metalika - koupíte sice spíš forwardující aktivní tap,
https://www.garlandtechnology.com/products/copper-network-taps
pasivní jsem si musel ubastlit, a zcela pasivně lze odposlechnout jenom 10/100, nikoli gigabit... asi proto jsou metalické tapy většinou forwardující. Ale neměly by drbat do provozu, jenom přidají trochu zpoždění.
Kolik dat Vám tam teče? Na jaké rychlosti to provozujete? Do 1 Gbps to není moc velký problém. Grabovat 10Gbps tak abyste neztrácel pakety, to už chce trochu slušné vybavení.
Ve větší firmě jsem kdysi dělal a chápu, že pokud máte všechno "as a service", tak běžně nemáte po kapsách zbytečný počítač se dvěma optickými síťovkami. Nad tím mohu jenom pokrčit rameny.
Odhaduji, že v dnešní době na holém vlákně nebo lambdě máte Ethernet. Na to stačí wireshark. Odhadem i kdyby tam v IP bylo vmezeřené ještě MPLS, podle mého to Wireshark zvládne dissectovat. A jakmile máte capture, můžete především sledovat TCP relaci a Wireshark sám zvýrazní retransmise = ztracené pakety. Vybavuju si, že jsem docela úspěšně koukal Wiresharkem i na databázovou relaci (MSSQL) - sice jsem neměl dissector/analyzátor, ale v surových datech byly vidět z jedné strany SQL dotazy a z druhé strany data, a podle časových značek šlo docela dobře poznat rozestup mezi dotazem a odpovědí. Na koleně, ale dalo se. (Lepší by bylo nějaké statistické vyhodnocení latence dotaz/odpověď, ale to chce protokolově specifický analyzátor.) Toto provést na dvou koncích té komunikace. A nejlíp třeba porovnat, jak funguje "klient" lokálně v rámci LAN poblíž serveru, ve srovnání s provozem skrz WAN infrastrukturu.
Kromě wiresharku lze přímo z koncových zařízení ledacos zjistit pingem, nebo třeba FTP klientem. Záleží jistě na kapacitě... v dávných dobách bylo na FTP se zapnutým hashováním na VGA konzoli hezky vidět, když jel přenos maximem co dala linka, vs. když se zadrhával kvůli ztraceným paketům - ať už to bylo přetížením, rate-limitem po cestě, nebo třeba špatně nastaveným duplexem. V jednoduchosti je síla. Ping nekecá. A když zkusíte třeba různé délky paketů, možná najdete na round-trip zpoždění a ztrátovosti nějaký zlom či jinou anomálii.
Hloupé je, pokud firewall třeba pustí ping/traceroute skrz, ale vybrané služby odklání do inteligentních filtrů/keší/překladů... pak nemá test pingem moc velkou vypovídací hodnotu.
A při sniffování odposlechovou sondou trochu zkazí náladu, když je payload zavřený v nějaké šifrované VPNce. No aspoň se pak dá odhadnout MTU a případné na něj navázané nectnosti.
Klasický problém u VPNek je MTU pronajaté transportní sítě vs. MTU payloadu, z toho plynoucí fragmentace, a když třeba řešitel firewallu (resp. admin některého z routerů po cestě) nevhodně zařízne "ICMP couldn't fragment", tak je o zábavu postaráno. Pokud klient pořád dokola navazuje TCP relace, a na každé z nich musí proběhnout PMTU black-hole detection, tak to "trochu" zdržuje.
Ale pokud máte pronajatá holá vlákna, tak asi není problém trochu zvednout "vnější" MTU na fyzických rozhraních, nádobíčko na MPLS VPN (pokud se Vás týká) už asi na MTU taky není skoupé, takže k fragmentaci ani nemusí docházet...
Pokud máte v cestě firewall (firewally) tak se skutečně můžou dít věci. Softwarové zpracování provozu, proprietární vychytávky výrobce FW... je to svět sám pro sebe.
Jednou z vlastností WAN linek je vyšší latence oproti LAN. Zejm. pokud provoz prochází nějakým šifrujícím zařízení (VPN tunel endpointy). Různé druhy provozu jsou na latence různě háklivé, ve smyslu subjektivního uživatelského dojmu. Třeba pokud je na jedné lokalitě DB a aplikační server s HTTP rozhraním, a klienti za WAN spojem mají jenom browser, tak naservírovat uživateli stránku přes rychlou WAN není problém, protože se uplatní TCP window (nečeká se na potvrzení každého paketu zvlášť). Ale pokud je na jedné lokalitě DB a "aplikační" část leze do té DB z jiné lokality skrz WAN, a nejlíp chrlí větší počet SQL dotazů, které navíc serializuje, třeba detailní formulář přes celou obrazovku co tahá milion číselníků v jednom vlákně, to už může uživatel pociťovat jako zdržování. Přitom procesory na obou stranách se flákají, disky na serveru se flákají, síť se fláká, pakety se neztrácejí, ale prostě těch transakcí dotaz/odpověď je na jeden formulář tolik, že už pocítíte rozdíl mezi 100 us v rámci LAN vs. 5-10 ms v rámci rychlé WAN (round-trip jedné transakce).
V zásadě pokud Vás "poskytovatel řešení" nepustí čenichat na páteřních linkách = dark fiberu (nebo tam není nic moc k vidění), velmi dobrou vypovídací hodnotu má záznam provozu pořízený na předávacích bodech, tzn. co Vám skutečně leze ven z "LAN+WAN solution as a service" ke koncovým počítačům. Dá se pořídit záznam wiresharkem a nějak se v něm nimrat/analyzovat, nebo třeba pořídit v průběhu prime time video-záznam chování softwaru na klientu 1) v LANce pohromadě se serverem a 2) na jiné lokalitě skrz WAN. Prostě to nějak zdokumentovat. Pokud z toho vyplyne jednoznačný rozdíl, tak ať se solution provider kouká snažit, nebo poletí i se SLAčkem.
Taky se vám ale může stát, že zjistíte chybu na své straně, resp. na koncových bodech. Mě třeba dost nemile překvapilo, že sedmičkám a desítkám už v podstatě nestačí 4 GB RAM na provoz bez swapování (hint: sedmičky měly resmon.exe ještě samostatný, v desítkách je na něj odkaz ze správce procesů). Upgrade na 8 GB znamená zásadní rozdíl. A taky není špatné koukat po očku do resmonu, "co to zase štrachá diskem" (nebo co to sežralo celý procesor) - obvyklých podezřelých je v moderních windowsech několik. Tolik ke klientovi. Přetížení na straně serveru je třeba také vyloučit, než se budete mračit na dodavatele síťového řešení. Opět nejsnáz porovnáním A/B (blízko u serveru vs. skrz WAN).
A jsem zpátky u toho: je potřeba především zvednout kapotu a snažit se něco změřit. Dokud se nepodíváte, tak jenom věštíte. Teprve když se podíváte, tak třeba něco zjistíte. Já třeba většinou zjistím "nene, tady problém není". A občas mi naopak pěkně klesne čelist :-) Osobně se snažím, než zcela vážně otravuju dodavatele, mít napřed "zameteno před vlastním prahem" = umět problém přesně specifikovat na předávacím bodě. A dost často při tom úklidu na vlastním prahu zjistím problém na své straně - a dodavatele pak už ani neotravuju.
Nemusíte zrovna nacvičovat složitou akrobacii s wiresharkem, které nebudou rozumět ani technici Vašeho dodavatele. Jak už jsem navrhl výše, třeba jenom pořiďte krátký videozáznam desktopu "lokálně" a "skrz WAN". A dejte si záležet, když srovnáváte A vs. B, ať neporušíte princip "za jinak stejných okolností" = nejlépe v tomtéž čase a ať mají oba klienti tentýž HW a OS (nebo hodně podobný). Přesněji řečeno, pokud chcete prokázat problém v síti, tak ať je testovací klient v obou případech pokud možno nabušený, aby ani náhodou nemohl být úzkým hrdlem.
-
Zacal bych treba tim iperfem/netcat/raw traffic z obou koncu. Pokud bude vysledek spatny, zkusil bych je dotlacit k nejake tymove akci, kde byste pustili iperf znovu a oni by identifikovali uzly a statistiky pres vsechny nody co to bezi. Melo by Vam z toho minimalne vypadnout kde zacina problem. Pokud bude vysledek iperfu ok, pak problem muze byt v aplikaciich (ale vzhledem k tomu ze pisete ze afektnuty jsou vsechny pak to nepredpokladam). Minimalne budete mit ale v ruce mereni ze raw performance je mizerna. Po procesni strance zkusit eskalovat na vyssi mista jak u vas ve firme tak i poskytovatele (...jiz x mesicu tu resime s Vami problem a deti stale placi a maji hlad..)