Egy céges hálózat, helyi hálózat, 3 iroda, a fokozatos bővítés vége az, hogy van 3 nagyobb switch (2 db 24 es és 1 16 os.) ezek gyakorlatilag sorba uplinkelve, és ahol kell még további switchekkel tovább osztva a hálózat, összesen van egy pár switch a hálózaton, gigabites mind, és többnyire márkásak, smck, de van más is (gigabyte, dlink pl.).
Van egy dhcp szerver, az osztja a vegyes operációs rendszerű gépeknek az ipt, és van egy pár szerver, ezek fix ipvel (dhcp static, de ez mindegy, mert nem ezzel van a gond).
A probléma:
időnként (naponta többször) rövid időra (1-2 perc) BIZONYOS gépekről (eddig kizárólag windowsos gépekkel fordult elő) a file szerver (samba Linuxon) nem elérhető. Amikor ez a probléma van:
A gépek többsége eléri a fileszervert. A "hibás" gépeken is elérhető minden más, pl. más szerverek és az internet is. Csak a fileszerver nem. De az annyira, hogy ping sem megy.
Ezt csinálja mondjuk 5-6 gép, de nem egyszerre, tehát amikor a hiba jelentkezik, akkor sem mindnél. Az ip címekkel nincs probléma, hiszen minden mást elérnek, és a szerver is elérhető máshonnan. Az arp táblákban a mac addressek stimmelnek mintkét gépnél (szerver, windows). A szerver felől a kliens gép felé arping általában megoldja a problémát!
Az uplinkek számát már csökkentettem, amennyire lehetett. Történt egykét switch csere is, és természetesen minden újra lett már indítva. A hiba kb. 2 hete kezdődött, előtte ilyen soha nem volt, de azóta csak a gyakoriság változott (volt, hogy majdnem egész nap nem jelentkezett, de volt, hogy gyakorlatilag használhatatlan volt).
Workaround nak egy másik szerveren port átirányításokat csináltam, így most azon keresztül elérhetők a file szerver szolgáltatásai, és működnek is hibátlanul.
Szoftver frissítések a hiba jelentkezése után történtek, (hátha segít) előtte közvetlenül nem, nem tudok semmi változásról, szoftver vagy switch... A windowsok nem egyforma verziójúak, és virtuális windows is produkálja a hibát.
Valami olyasmire gyanakszok, hogy a siwtchek között veszik el a két gép közötti kapcsolat, de ezt se debugolni, se javítani nem tudom egyelőre. A hiba túl ritkán jelentkezik ahhoz, hogy értelme legyen nekiállni próbálgatni kisebb hálózattal stb...
Nagyon örülnék, ha valaki adna ötletet, esetleg látott már ilyet, és a megoldást is tudja, köszönettel!
- 7902 megtekintés
Hozzászólások
Ilyenkor az szokott segíteni ha van egy managementes switch-ed, amit beiktatsz, hogy valamit láss is.
Ha nincs más egy iptraf is jól jöhet a szerveren, hátha kiderül mi történik.
- A hozzászóláshoz be kell jelentkezni
Van managelhető switch, de őszintén szólva teljesen default minden, nem tudom mit kéne nézni benne, van webes adminja, még csak a firmware frissítést néztem (nincs újabb) :D
tcpdumpot néztem, semmi különös, amikor megy akkor látszik, amikor nem megy nem látszik semmi. Tcp szinten már nem működik semmi, ping sem, amikor a hiba jelentkezik.
- A hozzászóláshoz be kell jelentkezni
Azaz a kapcsolat egyik végén nem látsz sem tcp, sem icmp (ping) csomagokat. Mindenképp meg kéne nézni a kliens oldalon drótcápával, hogy mi történik: timeout, valamilyen más eszköz válaszol, stb, _és_ közben a switchen is nézni arp-táblát, hogy wattafakk van.
- A hozzászóláshoz be kell jelentkezni
Rendben, köszönöm! Ha sikerül megoldani, vagy van tanulság, megírom itt.
- A hozzászóláshoz be kell jelentkezni
Nem találom a switchben az arp táblát. SMCGS24C switch. A portok statisztikáját tudom nézni, vlanokat létrehozni, ilyesmi, arp meg mac addresseket amik most játszanak semmelyik menüben nem találom, lehet, hogy nem tudja?
- A hozzászóláshoz be kell jelentkezni
Hát ilyen nincs és tényleg van. Utolsó firmware sem tudja? Épp végignyaltam a kézikönyvét, és tényleg nincs benne sehol sem :(
- A hozzászóláshoz be kell jelentkezni
http://www.smc-asia.com/microsite/smart_switch_web/images/manual/SMCGS1…
248-249. oldal
Igaz, ez SMCGS26C-re igaz, de 24C-t nem találtam.
Remélem segített.
--------------------------------
...except the gyevi bíró
- A hozzászóláshoz be kell jelentkezni
Lehet hogy érdemes lenne egy Wireshark-al megnézni a forgalmat amikor a hiba előjön. Abból elég sok minden kiderül.
semper fidelis
- A hozzászóláshoz be kell jelentkezni
Tcpdumpot néztem eddig, de meg fogom nézni a wiresharkot is, talán holnap.
- A hozzászóláshoz be kell jelentkezni
ugyanarra a switchre vannak kötve a gépek amin a hiba előfordul?
--
Kristof
- A hozzászóláshoz be kell jelentkezni
Nem. Van ami 1 switch távolságra van, van ami több. A legközelebbi gépek közötti switchek már le lettek cserélve (másikra, és egymással is), nem változott a helyzet.
- A hozzászóláshoz be kell jelentkezni
Az első gyanúm az lenne, hogy valami kalóz eszköz a szerver IP-jével garázdálkodik.
Ezt a gyanút megerősíti, hogy az arping a kliens felé orvosolja a problémát.
A gyakoriság változását ebben az esetben magyarázhatjuk azzal, hogy az eszköz mikor működik, mikor nem.
Ami ellene szól, hogy az arp táblákban a mac addressek stimmelnek.
- A hozzászóláshoz be kell jelentkezni
Igen, a windowsok miatt gondoltam már vírusra is, bár szinte kizárt, hogy az összes winen fent legyen ez a vírus, van akinek saját laptopja, saját víruskeresővel, stb. Ilyen arp hamisítás már eszembe jutott, de akkor ugye más mac látszana a szerver felől. Vagy a gép felől. De valami ilyesmi lesz egyébként, de hogy tudom megtalálni a forrását, még ha egy vírusos gép is az?
- A hozzászóláshoz be kell jelentkezni
Az arpwatch-ot felteheted a szerverre.
- A hozzászóláshoz be kell jelentkezni
Egyelőre csak az új felderítésekről logol (és küld emailt), de ebben semmi különös nincs. A hiba közben már jelentkezett és nem volt másfajta bejegyzés, semmi meglepő (a hibás gép újra észleléséről sem szólt, mivel nem is törlődött az arp táblából)
- A hozzászóláshoz be kell jelentkezni
Igen fura helyzet. Van egy olyan érzésem hogy ezt távolról nehéz lesz megoldani.
- A hozzászóláshoz be kell jelentkezni