Így keresd a hibát 2010/02/09
Ha minden hálózat tökéletes lenne, sosem lenne benne hiba, avállalatok nem tartanának informatikusat, csak a hálózat létesítésének ideléjére. Ebben a bejegyzésben azt nézzük át röviden, milyen eleveket érdemes szem előtt tartani, mikor hibát kell keresnünk, és megnézünk pár példát is.
Az én tapasztalatom az, hogy a legjobb előre eltervezett folyamatábra, workflow szerint végigmenni egy adott problémán. Tipikus probléma lenne, ha egy hibás számítógép esetét vizsgálnák meg, ezért inkább egy működésképtelen IP telefonét vegyük át, mint példa. Tehát kapok egy belsős e-mail értesítést, hogy a 4. emeleten a 245-ös mellék nem működik. Hogyan állok ehhez a problémához:
- Az üzenet most kaptam nemrég, tehát a hiba “friss”. Átgondolom volt -e valami módosítás, programozás azon a melléken a közelmúltan.
- Megfontolom, hogy a többi telefon működik -e. Én fel tudom hívni magamat az asztali készülékről, tehát a hiba valószínűleg nem a telefonközpontban lesz.
- Ha már a saját telefonomat nyomkodom, megvizsgálom mi történik, ha felhívom a 245-ös melléket. Semmi, elbont a hívás, tehát tényleg rossz a mellék.
- Mivel IP alapú a telefonközpont, és én úgyis itt ülök a gépem előtt, sőt, még az IP telefóniához is értek, megnézem, hogy a központban nem lett -e semmi elállítva arra a mellékre specifikusan.
- A szerverszoba ott van mellettem, már azon gondolkozom, hogy megnézzem a switchen, hogy linkel -e az a végpont rendesen, majd hamar lebeszélem magam: ha nem linkelne, akkor a telefonra felfűzött PC-ről sem tudott volna nekem e-mailt küldeni, másrészt ezt megnézhetném a menedzselhető switch felületén, harmadrészt, még ha nem is linkelne, a szerverszoba itt van mellettem, és ott nem járt senki azóta, tehát a hiba a zsínór másik végén van.
Lusta informatikus vagyok, de nincs mit tenni, nem jellemző, hogy a készülékek megjavulnak magától, ezért kikászálódom kényelmes bőrfotelemből, és felmászok a negyedikre. Fontos, hogy megnyugtassam a kollegát, és lássa, hogy törődöm a problémájával. De azért magam is ellenőrzöm, hogy tényleg nem lehet telefonálni, vagy csak szegény user szeretne valamit úgy csinálni, ahogy nem lehet.
Érdemes ettől a ponttól kezdve, most hogy a logikus g ondolkodás megvolt, egy betanult módszert követni: a más sokszor említett OSI modell rétegeit aqlulról felfelé vizsgálni, működés szempontjából:
- A hardveres kapcsolat megfelelő -e. A vezeték nem törött (remek kábelteszterek vannak). A link LED-ek világítanak -e. Egyáltalán van -e tápellátás.
- A switchek működnek -e. Ha klasszikus switchről beszélünk, akkor más eszközök mennek -e rajta, ha menedzselhetőről, akkor megfelelő -e a portkonfiguráció (a másikportot kipróbálni itt sem árt, sőt, egyszerűbb is lehet, de hibaelhárírás tekintetében mindenképp éredemes a konfigurációt is megvizsgálni).
- A router működik -e. Kap -e az eszköz IP címet, ha statikus, akkor megfelelő hálózatból van -e, és nincs -e ütközés. Tesztelés céljára a ping parancs való.
- Szállítási layer, itt is a routerek illetve tűzfalak és átjárók konfigurációjában lehet hiba. A VoIP rengeteg UDP portot igényel a felsőbb tartományból, az 5060 vagy 2000-es TCP-n, és esetleg 69-es TFTP-n kívül.
- Ide általában én a SIP/SCCP regisztrációt/híváskezdeményezést szoktam sorolni. A hálózahoz ennek már sok köze nincsen, csak a két végponthoz, a központhoz, és a telefonhoz.
- Adattitkosítás. Itt esetleg a VPN át dolgozó távoli munkatársak jöhetnek szóba.
- Azonosítás. A SIP regisztrációhoz megfelelő a jelszó? A hívott számnak kéne egyáltalán működnie? Megjelenés. Mit ír ki a készülék kijelzője, és mit nem.
Jellemzően én azt vallom, hogyha az első, logikus felépítésű részben nem sikerül az embernek megoldani VoIP témában a gondot, de legalábbis azonosítania azt, de meggyőződött a hiba létezéséről, akkor érdemes szakembert, például minket értesítenie. Ekkor rendelkezik már elegendő információval a szakember számára a hiba részleteivel kapcsolatban.
Válasz hagyása