Szerver nem elérhető aztán mégis

Hálózatok általános

Ez ~20 másodperc alatt játszódott le úgy, hogy közben semmi mást nem csináltam:

joco@joco-l:~$ ssh 192.168.0.2
ssh: connect to host 192.168.0.2 port 22: No route to host
joco@joco-l:~$ ssh 192.168.0.2
ssh: connect to host 192.168.0.2 port 22: No route to host
joco@joco-l:~$ ssh 192.168.0.2
ssh: connect to host 192.168.0.2 port 22: No route to host
joco@joco-l:~$ ssh 192.168.0.2
ssh: connect to host 192.168.0.2 port 22: No route to host
joco@joco-l:~$ ssh 192.168.0.2
ssh: connect to host 192.168.0.2 port 22: No route to host
joco@joco-l:~$ ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
From 192.168.0.115 icmp_seq=1 Destination Host Unreachable
From 192.168.0.115 icmp_seq=2 Destination Host Unreachable
From 192.168.0.115 icmp_seq=3 Destination Host Unreachable
From 192.168.0.115 icmp_seq=4 Destination Host Unreachable
From 192.168.0.115 icmp_seq=5 Destination Host Unreachable
64 bytes from 192.168.0.2: icmp_seq=6 ttl=64 time=2086 ms
64 bytes from 192.168.0.2: icmp_seq=7 ttl=64 time=1065 ms
64 bytes from 192.168.0.2: icmp_seq=8 ttl=64 time=40.8 ms
64 bytes from 192.168.0.2: icmp_seq=9 ttl=64 time=3.74 ms
64 bytes from 192.168.0.2: icmp_seq=10 ttl=64 time=4.12 ms
^C
--- 192.168.0.2 ping statistics ---
10 packets transmitted, 5 received, +5 errors, 50% packet loss, time 9137ms
rtt min/avg/max/mdev = 3.742/639.968/2086.197/829.487 ms, pipe 3
joco@joco-l:~$ ssh 192.168.0.2
joco@192.168.0.2's password: 
Linux hp 4.19.0-20-amd64 #1 SMP Debian 4.19.235-1 (2022-03-17) x86_64
...
joco@hp:~$

Ha egyszer elérhetővé vált, akkor az is marad, egy ideig...

Kliens egy laptop, szerver egy HP Microserver gen10, mindkettőn Debian, a szerveren eggyel régebbi verzió. Mindkettő wifin lóg, az AP egy Ruckus R710, egyéb hálózati szolgáltatásokban nem érzékelhető kimaradás. Szóval a wifi probléma kizárható. Nem hiszem, hogy a HP elaludna, de ha mégis, akkor rejtély, hogy mitől ébred fel. /var/log/messages és syslog alapján semmi érdekes, közvetlen a bejelentkezésem előttről is voltak friss üzenetek.

Nem olyan kritikus probléma, mert tudok várni pár másodpercet, és nemsokára úgyis legyalulom a HP-t és egy friss rendszer megy rá. De azért idegesítő és kíváncsi vagyok, mi lehet.

  • 1174 megtekintés

( andrej_ v | 2022. 05. 04., sze – 22:42 )

Hálókártya energia gazdálkodás, illetve IP ütközés ami elsőre eszembe jut. Ezen kívül rossz hálózati kábel, vagy switch port még esetleg.

Ettől még lehet IP ütközés, mert szerinted fix. :) A szerver is wifizik?

Apropó a wifi eszköz milyen régi? Többféle cuccal fordult nekem elő, hogy néhány év után azért már jöttek mindenféle gyanús hibák, amik vagy túlmelegedés vagy valamilyen együttállásos fw issuek lehettek.

A szerver IP-je tuti .2, a laptop más eszközökkel együtt DHCP-n kap IP-t egy 100+ fölötti tartományból. Tehát az a tipp, hogy a laptop egy másik dinamikus IP-s eszközzel ütközik? Ilyenkor a két eszköz hogy tud együtt létezni, és mitől javul meg a szerver elérése pár másodperc alatt?

Én mindent értek, viszont az van, hogy vagy végignézed azokat a pontokat konkrétan (ip ütközés, energia gazdálkodás hálókártyákon, rossz kábel, és társaik), hogy kizárd őket ténylegesen tesztelsésel, vagy hajtogatod, hogy dehát az nem lehet.

Néhány szemelmény, a teljesség igénye nélkül, hogy mikkel találkoztunk, amik dehát nem lehetnek, és a kályhától kellett indulni:

  • Félig rossz, gyári új UTP kábel. Azaz linkelt, de nem volt forgalom, majd kiderült, hogy egyirányú... kettévágtuk kuka.
  • A 00:00:00:00:00:00 MAC address-t prezentáló eszköz, amit egy újabb menedzselt HP switch nem kultivált igazán, az egyedi eszköz gyártójával beszélve nem is értették a problémát, nem tudtuk a régi switchet elengedni...
  • Windows Serveren (igen, nekem újdonság volt 12 éve ez még), energiagazdálkodás kb. "forced" módon a hálókártyán, mindezt iSCSI interfészen, nagyon boldogok voltunk, mikor kikapcsoltuk.
  • Az idő vasfoga által megrágott integrált hálókártya által produkált random hibák, a cserekártyával még fél évig elment az alaplap, aztán vége lett teljesen.
  • Még b-s vagy g-s wifit nagyjából beszélő nyomtató eltűnése, ha a 20/40MHz-es spektrum szélesítést bekapcsoltuk az AP-n, hogy jobban eloszoljanak.
  • Nem hálózat, de roppant tanulságos volt. Végső soron RAM hiba, ami csak úgy derült ki, hogy ha a modulokat másik alaplapban 36 órát járattuk, egyébként linux softraid akadásokat okozott. Még a gépházat is kicseréltük kínunkban, hátha valami alaplapi összeérés van és néha valamiket rövidre zár.
  • Szintén nem hálózat. Az adott gyártó teljes szerverében a saját fw-rel ellátott saját diszkje halt meg, de már a konkrét meghalása előtt is bazira lelassította a teljes RAID tömböt, és jónéhány óra kellett mire kidobta, hogy hát igazából fail. Ugyanezen gyártó az általános SAS diszkeket azonnal prefailbe, illetve fail-be vágja, és nem jön a lassulós mutatvány.

Csatlakozom a felettem szólóhoz. ;)

Még a 90-es évek elején történt. Lunux - nem grafikus - munkahely, linux -> AIX telnetes kliens. A jelenség: vi editorban a page up/down billentyűk nem működnek. A hálózati szaki szerint hálókártyát kell cserélni. Gondoltam, biztosan hülye, mert minden bonyolult képeryős alkalmazás minden billentyűvel működött, és nagyméretű fájlok másolása oda-vissza szintén hibátlan volt.

De a kártya cseréje megoldotta!

Tékozló Homár - Azért szar, mert KONDENZÁTOR van benne!

Egyik kollégám meg mindenbe is diszket cserélne. Néha működik.

A 90-es évek végén 2db RS/6000 43P gépünkben cseréltek garanciálisan alaplapot, mert néha hibázott a hálózaton. A bűnös 1db kondenzátor, amelynek az értéke nem felelt meg a vonatkozó szabványnak. Ezért a precíz DEC eszközökkel nem működött együtt. Az alaplap ára kb. 1,5 MFt volt.

Az előző gépemben gyakran lefagyott a hálózat firefox alatt. Semmihez nem volt szabad nyúlni, csak az újraindítás segített - komolyabb baleset nélkül.

Két oka is volt a hibának. Kicseréltem a cpu hűtőt, de az új hűtő nem fújta a chipset hűtőbordáját. Nagyobb terhelésnél (firefox) túlmelegedett a chipset és lehalt a hálózat. A megoldás ventillátoros chipset hűtés. A másik eset szintén hálózat, de azt egy vadiúj, jó minőségű táp okozta. Természetesen az volt az utolsó amit ellenőriztem. ;) Ha "elgyengült" a 3,3 V, akkor dadogott a hálózat.

A "cserélj tápot" nem hülyeség, ha van egy garantáltan jó (???) tápod. Megúszod a táp műszeres vizsgálatát üzem közben. A csicsás monitorozó programok nem tudják megállapítani a tranziens terhelés következményeit. Nekem ilyen célra van egy 18 éves Antec tápom. A fiatalok szerint ciripel, de öreg vagyok, úgyse hallom. :-D

Jut eszembe... létezik olyan eszköz (nehezítésképp olyan, amit meg is lehet fizetni), amire rádugja az ember a tápot, és kis szöszölés után megmondja, hogy jó-e? Nyilván a multiméternél okosabb dolog kéne, olyan, ami mér terheléssel, tranzienssel, nézi hogy mennyire szőrös a DC, meg olyan dolgokat, amikről nekem fogalmam sincs, de a "jó táp" fogalmába beletartozik.

Természetesen létezik ilyen, mutatom.

A tápegységet megbízható gyártótól kell vásárolni! A tápegységnek létezik egy névleges terhelése és élettartama. Ha nem használod a megadott élettartamon túl, akkor csak ki kell cserélni egy hasonló újra - és örök élet.

A tápegység pont olyan, mint egy autógumi. Ha az üzemi paramétereken belül használod, akkor már csak a véletlenszerű katasztrofális meghibásodás fordulhat elő. Ha túlterheled, akkor csökken az élettartam. (nagyobb sebesség, üzemi hőmérsékleten kívül vagy érdesebb úttest)

Nem kell mesterséges avulást rikácsolni, mert csak az ár/élettartam optimalizálásáról van szó.

A kérdésedre konkrét válasz akkor adható, ha megmondod mit kell mérni. Az 500 W névleges teljesítményű tápomnál az 500 W a mértékadó, vagy a valós terhelés, ami 38 W konnektorról?

A DC sosem "szőrös", hanem adott ferkvciá(ko)n brummos. Kapcsolóüzemnél ez van, csak a brumm minimum- és maximum értéke nem mindegy. De még az is mindegy lehet, ha a tápcsatlakozótól legtávolabbi ponton kicserélek egy kondenzátort tized értékűre. (meghibásodás) Azt a hatást nem fogod mérni a tápcsatlakozón, mégis valami hibás lesz.

Könnyebb a névleges teljesítményt megmérni. A feszültségek és tűrések + a névleges áram jöhet a szabványból. A tápegységre specifikált komplex terhelés jöhet a gyártótól/adatbázisból. Ezt megadod a képzeletbeli műszernek, és megméri. Ehhez kell némi dinamikus műterhelés is. A végén egész drágára is sikerülhet. Utána jöhet a valós terhelés: három grafikus kártyád van, vagy 12 diszked, és hogyan használod őket? Naugye!

Én meg annyit tudok, hogy a 500 -> 38 W terheléssel a 3 év garancia helyett >>3 évig fogom használni a tápot. Csak nem tudom a >>3 év pontos értékét. Ilyenkor nem mindegy, hogy az öregedő alkatrészek élettartamát mennyire méretezték túl és valjon mindegyékét vagy csak néhányat? Lehet olyan, aminek az élettartama a kisebb terhelés ellenére nem növekszik.

Ha kicsit jobban hajtom a gépet, de rosszabb a hűtés (mondjuk +12 ℃ a növekmény), akkor a névleges élettartam alá is lehet kerülni.

Összefoglalom: Lehet ilyen műszert készíteni, de nem lesz olcsó. Hogy pontosan mit kellene mérni vele, azt úgy sem tudod megmondani.

Tehát goto eleje!

Ha jól rémlik, hogy gyorstesztelő van, de az különösebben nem terhel szerintem. Példul: https://www.newegg.com/p/pl?d=power+supply+tester

Ahol komolyabban megnézik, pl. régebbi Anandtech-es tesztek, ott labortápokkal, ellenőrzött hőmérséklettel, és jó drága teszt berendéssel operáltak. Emitt még cikket is találtam, ahol részletesen, eszközökkel együtt leírják: https://www.anandtech.com/show/2259 és https://www.anandtech.com/show/7820/how-we-test-psus-2014

A gyorstesztelő azért nem rossz szervizeseknek, mert sokszor az első hiba az valamelyik feszültség ingadozása. Ezért aki teheti, és tudja is a gépe, az monitorozza ezeket.

Az a vicc, hogy akkoriban annyi ótvar tápot vettek (vettünk), hogy az hihetetlen. Celeron mellé nem volt zseton, az akkor tizenezres csodatápokra sokaknál, nekem sem mindíg. Ráadásul a közismerten rettegett típusok/gyártók elkerülése sem volt tuti, mert pár ezressel drágább "azért ez legalább működhet" típusú tápok is pukkantak el úgy hogy semmi extra terhelést nem kaptak. Szóval ez nem volt azért véletlen.

Nekem a kedvencem a hwsw fórumról, hogy valaki panaszkodott, hogy nagyon nehezen pattant be a helyére a RAM modul, de végül egy jó mozdulattal sikerült. Ezzel szemben sajnos a gép nem bootolt, sőt mintha füstölt volna. Kiderült, hogy a DDR1-et fordítva pakolta be, és izomból.

( wlaszi | 2022. 05. 05., cs – 08:47 )

Ha felkötöd a 2. portját is, akkor a port/kábelhibát talán ki tudod szűrni. (Persze a duplahiba vagy kártyahiba esetét nem)

Amúgy szerintem is ip ütközés/dns szabály lehet a ludas.

"The only valid measurement of code quality: WTFs/min"

A szerverbe dugtál valami wifi dongle-t? Az emlékeim és  a gugli alapján egy 2 portos eth kártya a gyári kiépítés.

Elő tudod idézni a hibát, vagy elég gyakori ahhoz hogy gyorsan meglásd javult-e? Én kihúznék egy kábelt és akkor kiderül, hogy wifi hiba-e, vagy más?

"The only valid measurement of code quality: WTFs/min"

( peterson v | 2022. 05. 06., p – 08:15 )

Elméletileg kizárt, de azért én láttam már MAC ütközést.

Pont így néz ki... ;)

(Meg a fentiek is így néznek ki, de ha azokat kizártad...)

"A megoldásra kell koncentrálni nem a problémára."

Na MAC address ütközést szép meló felismerni, főleg ha az ember sosem hallott róla, ill. nem számít rá. Talán 1 esetben lehet feltünő, ha managed switch van a hálózatban és 2 eltérő lábán látja ugyanazt a MAC-et rövid idő különbséggel ugrálni (ilyenkor szokott MAC flapping-et loggolni).

A MAC-tábla: melyik switchporton van "otthon" egy adott MAC cím --> ha itt ugrálás van (egyik pillanatbam az 1-es porton látszódik a MAC, következő pillanatban egy másik porton) akkor az esélyesen MAC cím ütközést jelent. Ezt leginkább Layer2 eszköz pl. a switch látja egyszerűen. Hétköznapi esetben meg az szokott előfordulni, hogy a wifi kliens ugrál 2 AP között, a switch meg azt latja h. 1x az egyik AP vezetékes lába felől jön a wifi kliens, másszor meg a másik AP vezetékes lába felöl, és a switch ezt MAC flapping-ként értelmezi.

Az ARP tábla: adott IP címhez milyen MAC cím tartozik. Ez az információ IP ütközés felfedezésére használható (azaz amikor ugyanaz az IP 1x ehhez a MAC címhez, másszor meg 1 másik MAC címhez látszik rendelődve). Ezt Layer3-as eszköz látja csak, pl. a rúter szokott ilyenkor figyelmeztetni, egy Layer2 switch nem foglalkozik IP címekkel így az nem is vesz észre egy esetleges IP ütközést.

  • nagyon dzsunga (értsd: józan ember rögtön kukázza) cuccoknál egyszer már láttam ilyet,
  • régen (lehet ma is?) lehetett állítani néhány hálókártya MAC címét. (Egy időben keresettek voltak ezek a kártyák/router-ek, mert a szolgáltatók regisztrálták a MAC címet telepítéskor.)

https://naszta.hu

kb a világ minden ethernet kártyája engedi átírni driverböl a MAC címet. Rútereknél is teljesen hétköznapi dolog a WAN oldali MAC átírása. Szóval relatíve könnyű MAC ütközést elkövetni.

Illetve a MAC cím csak 48 bites, már rég elfogyott valószínűleg a kiosztható mennyiség ahhoz h. a föld összes eszközének egyedi MAC címe legyen

Virtualizált környezetnél előfordul, főleg amikor klónozol egy VM-et.

De fizikailag sem kizárt, ha figyelembe vesszük, hogy volt már a történelemben olyan, hogy egy gyártó nyilvánosan befoglalt (hasamracsapok...) ~2.000.000 MAC address-t, aztán az év végi beszámolóban leírta, hogy eladott 5.000.000 hálókártyát. Nem jön ki a matek. ;)

Persze ez csak akkor jelent veszélyt, ha két azonos MAC egy fizikai LAN-on van, de a valószínűsége nem zérus.

"A megoldásra kell koncentrálni nem a problémára."

( joco01 v | 2022. 05. 08., v – 08:57 )

Ma megint előjött.

arp:

192.168.0.2                      (incomplete)                              wlp0s20f3

A szerver élt, mert épp valaki a TV-n nézett egy szerverről hosztolt filmet DLNA-val. Az AP felületen is megnéztem, a szerver fent volt, és megnéztem a MAC címét.

arping:

$ sudo arping -c 5 6c:3b:6b:f1:a2:e5
arping: lookup dev: No matching interface found using getifaddrs().
arping: Unable to automatically find interface to use. Is it on the local LAN?
arping: Use -i to manually specify interface. Guessing interface wlp0s20f3.
ARPING 6c:3b:6b:f1:a2:e5
Timeout
Timeout
Timeout
Timeout
Timeout

--- 6c:3b:6b:f1:a2:e5 statistics ---
5 packets transmitted, 0 packets received, 100% unanswered (0 extra)

Ránéztem Wiresharkkal is, egyszerűen nem jött válasz az ARP broadcastra. Aztán egyszer csak jó lett.

Megint arp:

192.168.0.2              ether   6c:3b:6b:f1:a2:e5   C                     wlp0s20f3

A MAC címek gyáriak, nem látok se IP se MAC ütközést. Azt gondolom, hogy vagy az AP hibázik layer 2-n, vagy a laptopon a tűzfal.

És ugyanabban az időpillanatban egy másik (nem az AP) ip-je elérhető? A laptopot is ki tudod zárni egy másik eszközről (akár telefon) pingeléssel. Mondjuk a TV-t is elfogadhatjuk 2. eszköznek, szóval valószínűleg az AP és a szerver között lesz valami gyík.

Továbbra is azt tippelem, hogy egy kanóc kihúzásával gyorsan behatárolódik a hiba. Ha értejössz, adok annyi tyúkbélt amennyi kell. :)

"The only valid measurement of code quality: WTFs/min"

Anno folytasásos teleregényben fejtegette, hogy tripla pénzből miként lehet átlőni a betonfalon: https://hup.hu/node/176789

Voltak benne képek is ha jól emlékszem, de most már mintha nem lennének elérhetőek. De mondjuk mivel onlyWifi....annyira nem lényeges talán.

"The only valid measurement of code quality: WTFs/min"