Dotaz: Výpadok sieťového spojenia - hľadanie dôvodu

[pupala]

Pri pingu na server s verejnou IP mám packet loss 15% . V rovnakom čase mám spustený ping zo servera na jeho gw a ten ping tiež eviduje packet loss 15% v tom istom čase ako z opačného smeru. Hľadám dôvod, čo je za tým. Spočiatku som si myslel, že chyba bude na porte switchu, alebo s mojou sieťovou kartou. Ale keď som pozrel záznam pingov, tak sa to chová tak, že nevypadávajú pakety náhodne, ale v pravidelných intervaloch a to tak, že napr. prejde 170 a následných 30 neprejde, potom opäť 170 prejde a 30 nie a takto s malými obmenami čísel dookola. Pre testovanie som vypol najprv fail2ban na serveri a neskôr aj celý firewall, ale chyba trvá a prejavuje sa rovnako. Tak som v pomykove, či to nemôže robiť aj nejaká iná aplikácia. Ale v logoch som nič okrem brutte-force attackov na sshd ftp a mailový sasl nenašiel. Tieto štandardne ošetrujem cez fail2ban, ale po jeho vypnutí sa situácia nezlepšila. Je možné zo strany servera nejako otestovať, či nie je vadná sieťová karta a ako je možné dohľadať zdroj, ak to robí nejaká aplikácia resp. služba na serveri? Alebo ako na to? Nestretli ste sa už s takýmto chovaním niekto?

Odpovědi

[pupala]

OS Debian 9 - situácia trvá tak 2-3 týždne, žiadna služba nepridaná na server, top, kým sa server na tých 30 pingov neodmlčí je hlboko pod možnosti servera.

[X]

Problemy s vlastni sitivky by jsi mohl zjistit ze vypisu statistik sitovky, nebo dmesg. Take ze statistik portu/logu na prepinaci. Jinak se to resi postupne jeden sitovy prvek za druhym.

[PetebLazar]

Jaký je výsledek mtr? Jsou na nějakém z hopů na cestě pozorovány ztracené packety?

https://cs.wikipedia.org/wiki/MTR

[vencour]

Pokud je pointou pouze to, že nedostanu odpověď na 30 pingů z 200, tak bych to neřešil.
Aneb jak moc je složitá topologie mezi zdrojem a cílem v icmp testu a jak moc jsou zatížené prvky a lajny mezi nimi?
Teorie je hezká věc, že má vše projít všude a vždycky. Občas je méně více a třeba i těch pár pingů jsou tím, co přeteče a jsou zahozeny?

[X]

Neresil? 15% ztrata paketu mezi zarizenin a branou je docela problem..

[vencour]

Paketů nebo pingu?
Tak ať si tazatel vytvoří tunel, narve do něj vše a pak ať říká, že mu vypadávaj pakety.
ICMP není běžně prioritizovaná služba, odbavuje se naposled.

[Petr Šobáň]

Ano to že vypadává ping ještě nic neznamená, ale když ho vypadává tolik a v pravidelných intervalech tak to chce zjistit kde je problém.

Podle mě to taky nemusí být nic vážného třeba je na bráně nějaký limit na ping tak stejně někde po cestě může být nějaký limit.

Vypadávají i jiné služby?

[pupala]

Toto je presne to, čo sa deje. Nevypadáva len ping v tú dobu mi nefunguje ani ssh spojenie na server. Testoval som to tal, že z ntb som dal ping na server, zároveň som som sa z NTB druhým terminálom prihlásil na server ces ssh a z tohoto spojenia som zo servera pustil ping na jeho gateway. V čase výpadku spojenia nešlo server ovládať ani cez ssh totálny výpadom, vrátane nedostupnosti apache, posfixu, proste nič. Ale ssh spojenie mi za ten čas nespadlo, nakoľko mám nastavené vyššie timeouty pre ssh. Keď sa obnovilo spojenie na server a ssh sa rozbehlo porovnal som priebeh pingov z ntb na sever a zo servera na gateway a a výpadok úplne rovnaký. Ako to bolo v tom filme "Číslo 5 žije"? "Sem z toho celej vedle sebe" . Dnes cestujem do serverovne, a skúsim pripojiť ntb na s IP serverovej gw priamym káblom na server a otestujem ho tak. A potom sa pripojím z ntb s IP servera na port switchu, kde je pripojený server a tiež to testnem a uvidím. Keďže sa neorientujem tak dobre ako vy v problematike, aký test by som mal použiť keď nie ping. Na serveri pri pripojení na NTB stopnem firawall takže tam nebudú žiadne limity ale čo pri teste na switch v DC resp. na gw? ĎAakujem.

[Vantomas]

Pravidelný výpadek na cca 30 sekund bych viděl na problém s STP na síti.

[pupala]

OK, ale toto je chyba na strane providera. Bol by som rád, keby to nebolo serverom. Ako takúto chybu na strane providera zistiť zo strany zákazníka?

[vencour]

Ten server nemá něco jako ILO, RMM, remote console nebo jen "konsolový port"? Abyste viděl, co se děje, i když není dostupný z internetu.
Ze strany serveru můžete pustit tcpdump a logovat do souboru, dát traceroute "do internetu" a zkoumat, kde to přestane odpovídat.
Můžete ještě zkoumat přes ethtool -S0 <interfejs_do_internetu> jestli nenarůstaj někde chyby.
Nemáte na tom serveru bridge se zaplým STP?

[pupala]

Na serveri je nastavený bridge ale na rozhraní eno2 bez nastaveného STP. Týmto rozhraním sú pripojené len 2 virtuálne servre. Všetky služby bežiace na tomto servri sú nakonfigurované pre beh na IP adrese rozhrania eno1. A to nie je ani v bridge. Remote console na serveri je, ale nie je sprevádzkovaná. Dnes večer ju sprevádzkujem. Čo sa týka ethtool voľbu -SO nemám implementovanú, ale:

ethtool -S eno1 | grep error

rx_error_bytes: 0
tx_error_bytes: 0
tx_mac_errors: 0
tx_carrier_errors: 0
rx_crc_errors: 0
rx_align_errors: 0

brctl show

bridge name     bridge id               STP enabled     interfaces
xenbr0          8000.0024e84a8bde       no              eno2

netstat -i

Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eno1      1500 359886998      0    166 0      554657169      0      0      0 BMRU
eno1:0    1500      - no statistics available -                        BMRU
eno1:1    1500      - no statistics available -                        BMRU
eno1:2    1500      - no statistics available -                        BMRU
eno1:3    1500      - no statistics available -                        BMRU
eno2      1500 16442773      0     35 0        179693      0      0      0 BMRU
lo       65536 13127591      0      0 0      13127591      0      0      0 LRU
xenbr0    1500 16438193      0      0 0        179693      0      0      0 BMRU

Neidentifikujem nič, čo by poukazovalo na nejakú chybu servera.Čo sa týka tcpdump-u, tak ho viem realizovať aj bez remote konzoly.

[Jar-Jar Blinks]

 
   a co takhle chovani otestovat pres sluzbu 
   ktera ma prioritu uzavrit VPN ... a pingat skrz.

protoze i neco jako 
 v iptables 
             --limit 
             --limit-burst
   ??? 

icmp jako echo a echo-reply taky jako dost zahazuju 
resp kdyz jsem hodnej tak markuju jako CS2

na tohle jsou nastroje jako iptraf a taaak 
ping vam rekne prdlajs

a ktem statistikaam co takhle full/half na eth

Vy full  ...... vy cistej
Gw half  ...... tuna kolizi pod stressem

sezente si statistiky te GW 

[Jar-Jar Blinks]

#---------------------------------------------
protoze i neco jako 
 v iptables 
             --limit 
             --limit-burst
   ??? 
#---------------------------------------------
bylo mysleno jako nastaveni Firewallu te GW 

Napřiklad neořezaný strom na trase wifi signálu.

[j]

Pricina muze byt naprosto cokoli ... nejen firewall, pingy specielne se dost casto vsemozne omezujou, takze kdyz posles nejakou delsi sekvenci, tak ti ji to zacne zahazovat.

Pricinu na svy strane snadno vyresis tim, ze si to pripojis pres kabel trebas k NB naprimo, a vyzkousis to tak.

Jinak jak tu zaznelo, resit ping je knicemu, ty potrebujes resit to, co na tom stroji bezi. Web? Pak potrebujes resit http a ztraty na nem. Navic si uvedom jednu prostou vec, standardni ping je pidipaket, pokud je problem na sitovy vrstve, a ty mas pidipakety na 15%, tak jakakoli jina komunikace s datama nemuze prakticky vubec fungovat, protoze na kilovych paketech budes mit 90%. Opet, muzes checknou i ten ping ale nastav si ty kilovy pakety, pokud jsou ztraty stejny, na 99% neni pricina v HW ani ve fyzicky siti.

Dalsi vhodny nastroje - tcpdump/wireshark. Minimalne v tom rozsahu, abys zjistil, jestli po request nasleduje respond. Nekdy pakety neco pozadujici dorazej, ale srv na ne neodpovi, nekdy je to opacne. Oped duvodu muze byt hromada.

---

Dete s tim guuglem dopice!

[pupala]

Nedeľná návšteva v DC. NTB pripojený namiesto servera, testovaný FTP up/down všetko v poriadku. Potom opačne, NTB nastavený ako gw a z neho ftp down/up zo servera. Ani len stratený paket. Testoval som to cca. 1 hodinu. 2 hodiny cesta domov. Z domu ftp down/up na server vypadával s rovnakými príznakmi, ak osom uviedol pri teste s ping-om. Pri výpadku bol nedostupný server ani pre ssh konekt ani pre imaps, ani pre smtp. PO chvíli opäť všetko OK. V čase výpadku pri teste zo servera nefungoval ani ping na jeho gw. Pustil som ho na pozadí a po obnove som si pozrel štatistiku. V pondelok som svoje zistenia zaslal na NOC v DC . V pondelok večer som dostal info, že u nich je všetko OK. Ale od utorka sa mi všetko funguje tak, ako pred poruchou. Tak neviem. Asi serveru pomohlo, že som odpojil RJ45 kábel a následne opäť pripojil a po chvíli sa dal dokopy . Pripravoval som sa na to, že na chvíľu použijem dropwatch a následne aj tcpdump, ale už nemám na čom, zatiaľ spojenie so serverom od utorka funguje korektne.

[Luboš]

Na supportu ISP lhali. Bylo jim hamba přiznat chyby. Po tichu to opravili. Taky jsem takhle nakoupil novou síťovou infrastrukturu, protože mi lhali že mají všechno v pořádku. Opravili to až když jsem utratil prachy a zdokumentoval ty nákupy za nové železo. Teď mi to leží ve skříni a zastarává to...

[vencour]

1) Opravdu to píše autor vlákna?
2) I tohle se stane, je fajn s tím počítat a poradit si, když nechodí vše ok.