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-tapsNě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-tapspasivní 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.
Zobrazit příspěvky
