Pomalá síť a nic na firewallech

[Ladislav Zitka]

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

[Reklama]

[MP]

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.

[Ladislav Zitka]

Nice.

[j]

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.

[JardaP .]

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?

[Reklama]

[Ladislav Zitka]

Diky za podnety, pristi tyden odzkousim zde navrhovane postupy a postnu vysledky.

[Phd]

Taky pingplotter je fajn, kreslí historii

[pan co nema nazor]

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

[starej Vajtyngr]

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ě....

[V.]

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ě?

[Fantomas]

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.

[V.]

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í.

[V.]

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.

[pepicekk]

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

[Ladislav Zitka]

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...