Emeltszintű érettségire felkészítés informatikából; ISP szolgáltatások

Az ISP szolgáltatások bevezetése
7.1.1 Felhasználói követelmények
Miután sikerült az ISP-vel kapcsolatba lépni, az egyéni felhasználónak vagy a vállalatnak el kell döntenie, milyen szolgáltatásokat igényelnek a szolgáltatótól.
Az internetszolgáltatók számos piacot szolgálnak. Az otthoni felhasználók alkotják a felhasználói piacot. Hatalmas multinacionális vállalatok képezik a vállalati piacot. Ezeken felül léteznek még olyan kisebb piacok, mint a kis- és középvállalatok, vagy nagyobb nonprofit szervezetek. Mindegyik, más és más szolgáltatás igényekkel rendelkezik.
A felhasználók növekvő igényei és az erősödő piaci verseny hatására az internetszolgáltatóknak újabb és újabb szolgáltatásokat kell nyújtani, amelyek lehetővé teszik, hogy bevételüket növelve megkülönböztethessék magukat versenytársaiktól.
Az elektronikus levelezés, a weboldalak tárolása, az adatfolyamok továbbítása, az IP telefónia és a fájlátvitel mind olyan fontos szolgáltatás, amit a szolgáltatók minden felhasználónak rendelkezésére bocsátanak. Ezek a szolgáltatások elengedhetetlenek az ISP felhasználói, valamint az olyan kis- és középvállalatok számára, amelyek nem rendelkeznek saját szakemberekkel e feladatok biztosítására.

Nagyon sok szervezet, kis és nagyvállalat, túl drágának tartja a legújabb technológiák beszerzését, vagy egyszerűen csak saját üzleti tevékenységi körükre szeretnék erőforrásaikat fordítani. Az ISP-k az ilyen szervezeteknek felügyelt szolgáltatásokat nyújtanak, amelyekkel a legújabb technológiákat és alkalmazásokat anélkül használhatják, hogy nagyobb összegeket fektetnének be akár a felszerelésbe, akár a szakértői támogatásba.

Amikor egy vállalat egy ilyen felügyelt szolgáltatásra előfizet, akkor a szolgáltató biztosítja az eszközöket és az alkalmazást a szolgáltatói szerződésnek (SLA - Service Level Agreement) megfelelően. Bizonyos felügyelt szolgáltatások esetén az alkalmazást magát is a szolgáltatói oldalon, nem pedig a felhasználói berendezéseken tárolják.
A következő három eset különböző felhasználói kapcsolatokat mutat:
1. eset - A felhasználó tulajdonában van és ő felügyeli a saját hálózati eszközeit és a szolgáltatásokat. Ezek a felhasználók csak a megbízható internet kapcsolatot várják az internetszolgáltatótól.
2. eset - Az ISP szolgáltatja az internet kapcsolatot, és tartja karban a felhasználói oldalon telepített hálózati eszközöket. Az ISP felelőssége kiterjed a telepítésre, az eszközök karbantartására és adminisztrációjára. A felhasználó kötelessége a hálózat és az alkalmazások állapotának megfigyelése, és fogadni a hálózat teljesítményére vonatkozó rendszeres jelentéseket.
3. eset - A felhasználó tulajdonában vannak a hálózati eszközök, de a kiszolgálók, melyeken az alkalmazások futnak az internetszolgáltónál találhatók meg. A kiszolgálók lehetnek akár a felhasználó, akár az ISP tulajdonában, de mindkét esetben az ISP tartja karban a kiszolgálókat és az alkalmazásokat is. A kiszolgálókat általában a kiszolgálófarmon, az ISP hálózat üzemeltető központjában (NOC - Network Operations Center) helyezik el.
ISP
Levelező kiszolgáló farm
Webkiszolgalo farm
Internet
Az ISP-nél kihelyezett kiszolgálókat tart karban és az ISP-re támaszkodik nagysebességű internetkapcsolat elérésében.
7.1.2 Megbízhatóság és elérhetőség
Egy új szolgáltatás bevezetése kihívást jelenthet. Egyrészt az internetszolgáltatóknak meg kell érteniük a felhasználói igényeket, másrészt rendelkezniük kell az adott szolgáltatásnak megfelelő erőforrásokkal és képességekkel. Mióta az internet alkalmazások egyre összetettebbek, egyre többen hagyatkoznak az ISP által felügyelt szolgáltatásokra.
Az ISP-k bizonyos díj ellenében a szolgáltatói szerződésben (SLA) meghatározott szintű szolgáltatást nyújtanak. A felhasználó követleményeinek megfelelően a biztosított szolgáltatásnak elérhetőnek és megbízhatónak kell lennie. 
Megbízhatóság
A megbízhatóságnak két mértéke van: a meghibásodások közötti átlagos idő (MTBF - mean time between failure) és a működőképesség helyreállításhoz szükséges átlagos idő (MTTR - mean time to repair). Az eszközök gyártói a gyártás során végzett tesztelések alapján megadják a várható meghibásodási időt (MTBF). Egy eszköz robosztusságának mértékét a hibatűrő képessége adja meg. Minél hosszabb a várható meghibásodási idő (MTBF), annál nagyobb a hibatűrése. A helyreállításhoz szükséges időt a garancia vagy szolgáltatói egyezmény szabja meg.
Egy eszköz meghibásodása miatt bekövetkező hálózat- vagy szolgáltatáskiesés befolyásolhatja az internetszolgáltatót a szolgáltatói szerződésben (SLA) foglaltak betartásában. Ennek megelőzésére az ISP a kritikus hardverelemekre költséges szolgáltatói egyezményeket köthet a gyártókkal vagy az eladókkal a gyors hibaelhárításra. Az ISP választhatja azt a megoldást is, hogy tartalék hardverelemeket vásárol és saját telephelyén tárolja.
Elérhetőség
Az elérhetőséget általában az erőforrás üzemidejének és rendelkezésre állásának időarányaként adjuk meg százalékos formában. A tökéletes elérhetőséget a 100% jelenti, amikor a rendszer mindig működik és elérhető. A hagyományoknak megfelelően a telefonszolgáltatásoknál 99.999%-os elérhetőség az elvárás. Ez az ún. "5 kilences elérhetőség". Ilyenkor csak az üzemidő nagyon kis százalékában (0,001%) lehet a hálózat elérhetetlen. Mivel az internetszolgáltatók kritikus üzleti szolgáltatásokat is támogatnak, mint például az IP telefónia vagy nagy mennyiségű kereskedői tranzakció, így felhasználóik magasabb szintű elvárásainak is meg kell felelniük. Az internetszolgáltatók az elérhetőséget a hálózati eszközök és kiszolgálók megduplázásával, valamint nagy rendelkezésre állást biztosító technológiák alkalmazásával érik el. Redundáns konfiguráció esetén, ha egy eszköz kiesik, akkor a másik automatikusan átveheti a szerepét.
Webkiszolgáló
Tartalék alkatrészek
Nagy elérhetőségű konfiguráció
Internet

7.2 Az ISP szolgáltatásokat támogató protokollok
7.2.1 A TCP/IP protokollkészlet áttekintése
Ma az ISP-k ügyfelei mobiltelefonon néznek tv-t, PC-n telefonálnak és televízión játszanak interaktív játékokat. A hálózati szolgáltatások egyre fejlettebbé válásával az internetszolgáltatóknak lépést kell tartani, hogy kielégíthessék felhasználóik igényeit. Az ún. "konvergált IP hálózatok" kifejlesztése teszi lehetővé, hogy az összes szolgáltatás egyetlen közös hálózaton legyen elérhető.
Több TCP/IP-n alapuló végfelhasználói alkalmazás támogatásához az internetszolgáltatók ügyfélszolgálatát ellátó személyzetnek is tisztában kell lennie e protokollkészlet működésével.
Az ISP szervereinek számtalan alkalmazást kell szolgáltatniuk a különböző előfizetői igények kielégítésére. Ehhez szükség van a TCP/IP két szállítási rétegbeli protokolljának, a TCP-nek és az UDP- nek szolgáltatásaira. A szolgáltatók által biztosított közismert alkalmazások, mint például: webkiszolgálók és levelezői fiókok szintén a TCP/IP protokolljaira támaszkodva biztosítják a megbízható kézbesítést. Ezen felül minden IP szolgáltatás az ISP tartománynév kiszolgálóján alapszik, amely az IP-címzési rendszer és a felhasználók által használt URL-ek közötti kapcsolatot biztosítja.
Az ügyfelek és a kiszolgálók meghatározott protokollokat használnak az információcserére. A TCP/IP protokolljai egy négyrétegű modell segítségével reprezentálhatók. Nagyon sok ISP nyújtotta szolgáltatás a TCP/IP rétegmodell alkalmazási és szállítási rétegének protokolljaira támaszkodik.
Alkalmazási rétegbeli protokollok
Alkalmazási réteg protokolljai határozzák meg a formátumot és szabályozzák a legismertebb internetes kommunikációs folyamatokhoz szükséges információt. Ilyen protokollok:
• Tartománynév rendszer (DNS - Domain Name System) - internet neveket feloldja IP címekre.
• Hiperszöveg átviteli protokoll (HTTP - HyperText Transfer Protocol) - A világháló weboldalait képező fájlok átvitelét valósítja meg.
• Egyszerű levéltovábbító protokoll (SMTP - Simple Mail Transfer Protocol) - E-mailek és csatolt állományainak átvitelére szolgál.
• Telnet - Terminál-emulációs protokoll, mely hálózati eszközök és kiszolgálók távoli elérését biztosítja.
• Fájlátviteli protokoll (FTP- File Transfer Protocol) - rendszerek közötti interaktív fájlátvitelt valósít meg.
Szállítási rétegbeli protokollok
Különböző típusú adatoknak egyedi követelményeik lehetnek. Bizonyos alkalmazások esetén a kommunikációs adatszegmenseknek meghatározott sorrendben kell megérkezniük a megfelelő feldolgozás érdekében. Más esetben az összes adatnak meg kell érkeznie a felhasználás előtt. Az is előfordul, hogy az alkalmazás kis mennyiségű adatvesztésre nem reagál érzékenyen.
A modern konvergált hálózatokon a különböző alkalmazások jelentősen eltérő szállítási igényeik ellenére ugyanazon a hálózaton kommunikálhatnak. A különböző szállítási rétegbeli protokollok különböző szabályokat használva biztosítják az eltérő követelményeket támasztó adatátviteli igények kielégítését.
Általában az alsóbb rétegek nem veszik észre, hogy több alkalmazás adatait küldik a hálózaton. Az ő felelősségük csak az, hogy az adatot eljuttassák az eszközhöz. A szállítási réteg feladata, hogy az adatot a megfelelő alkalmazáshoz juttassa.
A két legfőbb szállítási rétegbeli protokoll a TCP és az UDP.

A TCP/IP rétegmodell és az OSI modell hasonlóságokat és különbségeket is mutat.
Hasonlóságok
• Mindkettő rétegek segítségével szemlélteti a protokollok és szolgáltatások együttműködését.
• A szállítási és hálózati rétegek megfeleltethetők egymásnak az egyes modellekben.
• Mindkettőt a hálózatok témakörében használják a protokollok együttműködésének bemutatására.
Különbségek
• Az OSI modell a TCP/IP modell alkalmazási rétegét három külön rétegre osztja. Ez a három legfelső réteg ugyanazt a feladatot látja el, mint a TCP/IP modell alkalmazási rétege.
• A TCP/IP nem határoz meg külön protokollokat a fizikai összekapcsolódáshoz. Az OSI modell két alsó rétege a fizikai hálózat elérésével és a helyi hálózatok állomásai közötti bitek küldésével foglalkozik.
A TCP/IP modell a ténylegesen kidolgozott protokollokra és szabványokra épül, míg az OSI modell
inkább egy elméleti útmutató a protokollok együttműködéséhez

 
7.2.2 Szállítás réteg protokollok
Különböző alkalmazásoknak különböző szállítási igényeik vannak. Két szállítási rétegbeli protokoll létezik: TCP és UDP
TCP
A TCP egy megbízható, garantált átvitelt biztosító protokoll. A TCP meghatározza az állomások által használt csomagnyugtázási módszert, és arra készteti a forrás állomást, hogy újraküldje a nem nyugtázott csomagokat. Irányítja az üzenetek cseréjét a forrás és célállomás között, amellyel kommunikációs viszonyt alakít ki köztük. A TCP-t gyakran egy csőhöz, vagy állandó kapcsolathoz hasonlítják, ezért is nevezik összeköttetés alapú protokollnak.
A TCP többletterheléssel jár, mind a sávszélesség, mind a feldolgozási idő tekintetében az egyes viszonyok nyomonkövetése, valamint a forrás és célállomás közötti nyugtázási és újraküldési mechanizmusok megvalósítása miatt. Bizonyos esetekben e többletterhelés okozta késleltetés már nem elfogadható az alkalmazások számára. Az ilyen alkalmazások számára az UDP jobb megoldást jelent.
UDP
Az UDP egy nagyon egyszerű összeköttetésmentes protokoll, mely kevés többletterhelést biztosító adatküldést nyújt. Az UDP-t „legjobb szándékú" szállítási rétegbeli protokollnak tartják, mert nem biztosít hibaellenőrzést, garantált adatkézbesítést, vagy adatfolyam-vezérlést. Mivel az UDP egy legjobb szándékú protokoll, így az UDP adategységek elveszhetnek az út folyamán vagy esetleg nem a megfelelő sorrendben érkeznek meg a célállomáshoz. Azok az alkalmazások, melyek UDP-t használnak, a kis mennyiségű adatvesztésre nem reagálnak érzékenyen. Ilyen alkalmazás például az internet rádió. Ha egy adategység nem érkezik meg, annak csak kisebb hatása van a üzenetszórás minőségére.
Internet 
Az olyan alkalmazások, mint az adatbázisok, weboldalak és az elektronikus levelezés minden adat eredeti sorrendben történő, hibátlan megérkezését igénylik. Minden hiányzó adat az üzenet feldolgozhatatlanságát eredményezheti, ezért ezek az alkalmazások megbízható szállítási rétegbeli protokollt használnak. Az a hálózati többletterhelés, amely ezt a megbízhatóságot lehetővé teszi, elfogadható árat jelent egy sikeres kommunikációért.
A szállítási rétegbeli protokollt az alkalmazás adattípusa határozza meg. Például egy elektronikus levél nyugtázott adatküldést igényel, így TCP-t használ. Egy levelező ügyfél, mely SMTP-t használ, az elektronikus üzenetet bájtfolyamként továbbítja a szállítási rétegnek. A szállítási rétegben a TCP feladata a folyam szegmensekre osztása.
Minden szegmensen belül a TCP minden egyes bájtot vagy oktetet egy sorszámmal azonosít. Az így kapott szegmenseket az internet réteg kapja meg, mely csomagba helyezi őket az adatküldéshez. Ez a folyamat a beágyazás. A célállomásnál ez a folyamat megfordul és a csomagot kicsomagolják. A beágyazott szegmensek a TCP folyamaton mennek keresztül, amely visszaalakítja a szegmenseket bájtfolyammá, és azt a levelező kiszolgálónak kézbesíti.
Egy TCP viszony használata előtt az összeköttetés felépítéséhez a forrás és célállomás üzenetet váltanak egymással. Ehhez egy háromlépéses folyamatot használnak.
Az első lépésben a forrásállomás küld egy szinkronizációs üzenetet (SYN - Synchronization Message) a TCP viszony felépítéséhez. Az üzenet két célt szolgál:
• Jelzi a forrásállomás szándékát a célállomással történő kapcsolat felépítéséről.
• Szinkronizálja a TCP sorszámokat a két állomás között, hogy a beszélgetés folyamán mindkét fél nyomonkövethesse az elküldött és megérkezett szegmenseket.
A második lépésben a célállomás válaszol a SYN üzenetre egy szinkronizációs nyugtával (SYN-ACK).
Az utolsó lépésben a küldő állomás megkapja a SYN-ACK üzenetet és egy ACK üzenetet küld vissza a kapcsolatfelépítés befejezéséhez. Az adatok küldése most már megbízható módon történik.
Ezt a TCP folyamatok közötti háromlépéses metódust háromfázisú kézfogásnak nevezik.
Amikor egy állomás TCP protokollt használva küld egy üzenetszegmenst, akkor a TCP folyamat elindít egy időzítőt. Az időzítő elég időt hagy az üzenet kézbesítésére, valamint a nyugta visszaérkezésére. Ha a forrásállomás nem kapja meg a nyugtát a célállomástól az időzítő lejárta előtt, akkor a forrás az üzenetet elveszettnek tekinti. Az üzenet nem nyugtázott részeit újraküldi a forrás.
A nyugtázás és újraküldés mechanizmusa mellett a TCP azt is meghatározza, hogyan történik az üzenet összeállítása a célállomásnál. Minden TCP szegmens tartalmaz egy sorszámot. A célállomásnál a TCP folyamat egy ideiglenes tárolóba rakja a megérkezett szegmenseket. A szegmensek sorszámának kiértékelése lehetőséget nyújt a TCP folyamat számára a hiányzó szegmensek meghatározására. Ha az adatok nem sorrendben érkeznek, a TCP újra tudja sorrendezni őket.

7.2.3 Különbségek a TCP és UDP között
Az UDP egy nagyon egyszerű protokoll. Mivel ez nem összeköttetés-alapú és nem használja a TCP kifinomult sorszámozási, újraküldési és adatfolyam szabályozási mechanizmusait, sokkal kisebb többletterheléssel jár.
Az UDP-re gyakran úgy hivatkoznak, mint nem megbízható szállítási protokoll, hiszen nincsen semmi garancia az üzenet megérkezésére. Ez persze nem jelenti azt, hogy az UDP-t használó alkalmazások megbízhatatlanok. Csak annyit jelent, hogy ezeket a funkciókat nem a szállítási réteg biztosítja, hanem szükség esetén valahol máshol kell implementálni.
Bár egy tipikus hálózat összes UDP forgalma relatív kicsi a többihez képest, a következő alkalmazási rétegbeli protokollok mind az UDP-t használják:
• Tartománynév rendszer (DNS - Domain Name System)
• Egyszerű hálózatfelügyeleti protokoll (SNMP - Simple Network Management Protocol)
• Dinamikus állomáskonfigurálási protokoll (DHCP - Dynamic Host Configuration Protocol)
• RIP irányító protokoll
• Triviális fájlátviteli protokoll (TFTP - Trivial File Transfer Protocol)
• On-line játékok
A TCP és UDP közti fő különbség a protokollok által megvalósított funkciókban és az ezzel együttjáró többletterhelésben van. A két protokoll fejrészének tanulmányozásával jól látható ez a különbség.
Minden TCP szegmens fejrészében 20 bájtnyi extra adat található az alkalmazási réteg adatai mellett. Ez az extra adat a hibaellenörző mechanizmus eredeménye.
Az UDP adategységeit datagramnak nevezik. Ezeket a datagramokat „legjobb szándékkal" továbbítják, összesen 8 bájtnyi extra információval kiegészítve.
TCP-szegmens
I Fiit cm ai« MD:» /1 G\ Fiit \
■ öli □ II \ Dll y 1 öli I /
Forrásport (16) Célport (16)
Sorszám (32)
Nyugta sorszám (32)
Fejrész hossza (4) Foglalt (6) Kódolási bitek (6) Ellenőrző összeg (16)
Opciók (0 vagy 32, ha van)
Alkalmazási rétegbeli adat (méret változó)

20 bájt
1
Bit (0) Bit (15) Bit (16) Bit (31)
Forrásport (16) Célport (16)
Hossz (16) Ellenőrző összeg (16)
Alkalmazási rétegbeli adat (méret változó)
UDP datagram
A
8 bájt

7.2.4 Több szolgáltatás támogatása
Több egyidejű kommunikációs folyamat kezelése a szállítási rétegben történik. A TCP és UDP szolgáltatások nyomonkövetik a különböző, hálózaton kommunikáló alkalmazásokat. Az alkalmazások adategységeinek a megkülönböztetésére, mind a TCP, mind az UDP fejrészében találhatók olyan mezők, melyek azonosítják az alkalmazást.
A forrásport és célport minden szegmens vagy datagram fejrészében jelen van. Portszámokat nagyon sokféleképp lehet alkalmazásokhoz rendelni, például attól függően is, hogy kérésről vagy válaszról van-e szó. Ha egy ügyfél állomás kérést küld egy kiszolgálónak, akkor a fejrészben megtalálható célport a kiszolgálón az alkalmazáshoz rendelt portszám. Például, ha egy webböngésző kérést küld egy webkiszolgálónak, a kommunikáció TCP-vel történik a 80-as porton. Ez az alapértelmezett port webes alkalmazások esetén. Számos közismert alkalmazásnak vannak alapértelmezett port hozzárendelései. SMTP-t használó levelező kiszolgálók a TCP 25-ös portját használják.
Az alkalmazás-specifikus portokra érkező szegmenseket a TCP és az UDP is a megfelelő várakozási sorba rakja. Például, HTTP kérés esetén a webkiszolgálón a TCP folyamat a beérkező csomagokat a webkiszolgáló várósorába rakja. Ezek a szegmensek aztán, amilyen gyorsan csak lehet, a HTTP alkalmazáshoz kerülnek.
25-ös portot megjelölő szegmensek egy külön sorba, a levelező szolgáltatások sorába kerülnek. Így támogatják a szállítási rétegbeli protokollok az ISP kiszolgálókat több különböző alkalmazás és szolgáltatás egyidejű biztosításában.
Alkalmazási rétég
megfelelő várakozási
sorokba rakja a
szegmenseket
Bejovo keretek
Minden internetes alkalmazás esetén létezik egy forrásállomás és egy célállomás, általában egy ügyfél és egy kiszolgáló. A TCP folyamatok a küldő és fogadó állomáson némiképp különböznek. Az ügyfelek aktívak és kapcsolatot kérnek, míg a kiszolgálók passzívan viselkednek, figyelik és elfogadják a kapcsolatkéréseket.
Kiszolgáló folyamatokhoz általában statikusan a jól ismert portokat rendelik 0-tól 1023-ig. A jól ismert portok segítik az ügyfél alkalmazásokat a helyes célport hozzárendelésében egy szolgáltatáskérés létrehozásakor. 
Az ügyfeleknek a kérést indító ügyfél alkalmazás azonosításához is szükségük van egy portszámra. A forrásportok hozzárendelése dinamikusan történik az 1024-től 65535-ig terjedő tartományból. Ez a porthozzárendelés a kérést indító alkalmazás címének felel meg. A szállítási rétegbeli protokollok nyomonkövetik a forrásportot és a kérést kezdeményező alkalmazást, így a válasz a megfelelő alkalmazásnak továbbítható.

A szállítási réteg portszámából és a hálózati réteg IP-címéből álló páros egy adott állomáson futó alkalmazás azonosít. A portszám - IP-cím együttest socket-nek nevezik. Egy forrás- és cél-oldali socket pár két állomás közötti párbeszéd egyedi azonosítójaként használható.
Egy ügyfél socket, 7151-es portszámmal például a következőképpen nézhet ki:
192.168.1.1:7151
Egy socket egy webkiszolgálón például:
10.10.10.101:80
Ezek együttesen egy socket párt alkotnak:
192.168.1.1:7151, 10.10.10.101:80
A socketek segítségével a kommunikációs végpontok ismertek, így az adatok eljuthatnak az egyik állomás alkalmazásától egy másik állomás alkalmazásáig. Ez teszi lehetővé egy ügyfél állomáson futó több alkalmazás, valamint egy kiszolgáló több kapcsolatának megkülönböztetését.
7.3 Tartománynév rendszer (DNS)
7.3.1 TCP/IP állomás név
A forrás és célállomás közti internetes kommunikációhoz mindkét állomásnak érvényes IP címre van szüksége. Az IP-címek, sőt az IP-címek ezrei azonban az emberek számára nehezen megjegyezhetők.
Az olyan könnyen olvasható tartománynevek, mint cisco.com az emberek számára sokkal használhatóbbak. A hálózati névfeloldó-rendszerek ezeknek a könnyen megjegyezhető neveknek a gépek számára feldolgozható, hálózati kommunikációhoz szükséges IP-címekre történő fordítását végzik.
Webböngészés, vagy elektronikus levelezés közben nap mint nap használjuk a névfeloldó rendszereket, anélkül, hogy tudnánk róla. A névfeloldó rendszerek rejtett, de szerves részét alkotják a hálózati kommunikációnak. Például a Cisco Systems weboldalának megtekintéséhez a böngésző címmezőjébe a http://www.cisco.com címet kell beírni. A www.cisco.com egy hálózati név, mely egy meghatározott IP-címhez van rendelve. Ha a kiszolgáló IP címét írnánk a böngésző címmezőjébe, akkor ugyanazt a weboldalat látnánk.
A hálózati névfeloldó-rendszerek az emberek számára fontos eszközök, melyek segítenek abban, hogy összetett IP-címek megjegyzése nélkül is elérhessük ugyanazokat az erőforrásokat.
Az internet első napjaiban az IP-címek és állomásnevek egy adminisztrációs kiszolgálón központilag tárolt HOSTS nevű állományban voltak megtalálhatók.
Ez a központi HOSTS állomány tartalmazta a korai internetre csatlakozott összes állomás nevének és IP-címének összerendelését. Mindenhonnan elérhető volt az állomásnevek feloldása céljából. Az állomásnév megadása után a küldő állomás a letöltött HOSTS állományból kikereshette a célállomás IP-címét.
Eleinte a HOSTS állomány megfelelő volt az internet korlátozott számú számítógépei számára, azonban a hálózat növekedésével, a név-IP-cím hozzárendelést igénylő állomások száma nagyon megnőtt, ezáltal lehetetlenné vált a HOSTS frissítése. Új névfeloldó-rendszert kellett kifejleszteni. Ez a DNS, amely tartomány-nevek IP-címekre történő fordítására szolgál. A DNS kiszolgálók elosztott működéssel végzik a névfeloldást, központilag karbantartott HOSTS állományra már nincs szükség.
Ennek ellenére, ugyan csak virtuálisan, de minden állomás karbantart egy HOSTS állományt, amit a TCP/IP elindulásakor hoznak létre. A névfeloldási folyamat részeként a DNS szolgáltatás kérés előtt a helyi HOSTS fájl átvizsgálása történik. Ez a fájl használható hibakereséskor, vagy a DNS kiszolgálón található bejegyzések törlésekor.
7.3.2 DNS hierarchia
A DNS a HOSTS fájlon alapuló névfeloldás hiányosságait pótolja, felépítése hierarchikus és az egész világra kiterjedően elosztott adatbázist használ az állomásnév - IP-cím összerendelésekhez. Ezzel ellentétben a HOSTS fájlt egyetlen kiszolgálón tárolták.
A DNS tartományneveket használ a hierarchiához, amely kisebb, könnyen kezelhető zónákra van osztva. Minden DNS kiszolgáló egy meghatározott adatbázist kezel és csak a DNS struktúra kis részének név - IP-cím hozzárendeléséért felelős. Amikor egy DNS kiszolgáló egy olyan névre kap feloldási kérést, mely nem található meg saját zónájában, akkor egy másik, a megfelelő zónát kezelő DNS kiszolgálónak továbbítja a kérést.
A DNS egy jól bővíthető szolgáltatás, mivel a névfeloldás több kiszolgálóra támaszkodik.

A szolgáltatásnak három összetevője van.
Erőforrás bejegyzések és domainnév-tartomány
Az erőforrás bejegyzés egy adatbejegyzés a DNS zóna adatbázis állományában. Az állomás típusának, IP-címének vagy a DNS adatbázis paraméterének azonosítására szolgál.
A domainnév-tartomány az erőforrások rendszerezésének hierarchikus névstruktúrájára utal. Több tartományból vagy csoportból és a csoportokon belüli erőforrás bejegyzésekből áll.
Tartománynév-kezelő rendszer kiszolgálói
A tartománynév-kezelő rendszer kiszolgálói tartják karban az erőforrás bejegyzéseket és a domainnév-tartomány információit tároló adatbázist. A DNS kiszolgálók megpróbálják a saját zónájuk adatbázis állományában tárolt információk alapján feloldani az ügyfelek kéréseit. Ha a kiszolgáló nem rendelkezik a kért információval, akkor további, előre meghatározott névkiszolgálók segítségével oldja meg a kérést.

Névfeloldó (resolver)
A névfeloldók olyan alkalmazások vagy operációs rendszerfunkciók, melyek a DNS ügyfeleken és kiszolgálókon egyaránt futnak. Amikor egy tartománynév használatban van, a névfeloldó a DNS ügyfélen betöltődik, és létrehoz egy DNS kérést a kiszolgáló felé. Ha a kiszolgáló nem rendelkezik a kért név - IP-cím hozzárendeléssel, akkor a névfeloldó segítségével továbbítja a kérést egy másik DNS kiszolgáló felé.
A DNS egy hierachikus rendszer segítségével biztosítja a névfeloldást. Ez a hierarchia egy fordított fához hasonlít, melynek a gyökere van felül és az ágak alul.
A hierarchia csúcsán a gyökér (root) kiszolgálók tartják karban a legmagasabb szintű (top-level) kiszolgálók eléréséről tárolt információt, melyek visszamutatnak a második szintű (second level) tartomány kiszolgálókra.
A különböző legmagasabb szintű tartományok a szervezetek típusát vagy a származó országot reprezentálják. Példák a legmagasabb szintű tartományokra:
• .au - Ausztrália
• .co - Kolumbia
• .com - ipari vagy üzleti vállalat
• .jp - Japán
• .org - nonprofit szervezet
A legmagasabb szintű tartományok alatt a második szintű tartományok helyezkednek el, melyek alatt további, alacsonyabb szintű tartományok találhatók.
Regisztrációs hatosag (Registration Authority) áltál karbantartott.
int/net/org/edu
A gyökérben található (root) DNS kiszolgáló nem feltétlenül tudja pontosan merre található a H1.cisco.com, de van egy bejegyzése a .com legmagasabb szintű tartományról. Hasonlóan a .com tartományba tartozó kiszolgálók nem feltétlenül tudják merre van a H1.cisco.com, de van bejegyzése a cisco.com tartományról. A cisco.com tartománynak van bejegyzése a Hl.cisco.com-ról és fel tudja oldani az IP-címet.
A DNS szolgáltatás nem centralizált kiszolgáló hierarchián alapszik. Az erőforrás bejegyzések tartalmaznak tartományneveket, melyeket a kiszolgálók feloldanak és ezt más kiszolgálók szintén lekérdezhetik.
A H1.cisco.com egy teljesen minősített tartománynév (FQDN - Fully Qualified Domain Name), mivel megadja a számítógép pontos helyét a hierarchikus DNS névtartományban.
Regisztrációs hatóság (Registration Authority) által
karbantartott.
int/net/org/edu
Cisco áltál karbantartott
7.3.3 DNS névfeloldás
Amikor egy állomásnak DNS névfeloldásra van szüksége, akkor a névfeloldó segítségével lép kapcsolatba a tartományán belüli DNS kiszolgálóval. A resolver ismeri a DNS kiszolgáló IP-címét, mert ez része az állomás IP-cím konfigurálásnak.
Amikor a DNS kiszolgáló kérést kap egy ügyfél névfeloldójától, akkor az először ellenőrzi a helyi DNS bejegyzések cache tárolóját. Ha ott nem oldható fel az IP cím, akkor a kiszolgáló névfeloldója közvetíti a kérést egy másik DNS kiszolgáló felé. Ez a folyamat addig folytatódik amíg az IP-cím nincs feloldva. A névfeloldási információ visszakerül az eredeti kiszolgálóhoz, mely az információt felhasználva válaszol a kérésre.
A DNS név feloldási folyamata alatt minden DNS kiszolgáló eltárolja a kérésre válaszul érkezett információt egy gyorsítótárban (cache). A cache-ben tárolt információ segítségével a DNS kiszolgáló sokkal gyorsabban tud válaszolni az egymást követő feloldási kérésekre, mert a kiszolgáló először a gyorsítótárban lévő információt ellenőrzi.
A DNS kiszolgálók csak egy meghatározott időre tárolják az információt a cache-ben. Nem tárolhatja hosszú ideig az információt, mert az állomásnév bejegyzések időről időre változnak, és egy régebbi bejegyzéssel esetleg rossz IP-címet adna meg.

A DNS korai megvalósításaiban az erőforrás bejegyzések hozzáadása és frissítése manuálisan történt. A hálózat és a számon tartott állomások számának növekedésével már nem lehetett tovább hatékonyan megoldani a manuális karbantartást. Továbbá a DHCP használatával az egy DNS zónán belüli erőforrás bejegyzéseket sokkal gyakrabban kellett frissíteni. A DNS zónák karbantartásának könnyítésére, a DNS protokollt megváltoztatták úgy, hogy a számítógép a saját bejegyzéseit dinamikusan frissíthesse.
Dinamikus frissítéssel a DNS ügyfélszámítógép bármilyen változás esetén azonnal regisztrálhatja és frissítheti saját bejegyzéseit. A dinamikus frissítéshez a DNS kiszolglónak, a DNS ügyfélnek és a DHCP kiszolgálónak egyaránt támogatnia kell a dinamikus frissítéseket. z alapértelmezetten tiltva van, így engedélyezni kell. A legtöbb, napjainkban használatos operációs rendszer már támogatja a dinamikus frissítést.


Némely régebbi operációs rendszer nem támogatja a dinamikus DNS frissítést. Ilyen esetben a DHCP kiszolgálót kell úgy
konfigurálni, hogy dinamikusan frissítse a DNS-t az ügyfél nevében. DNS frissítése DHCP használatával a
következőképpen történik:
1. . Az ügyfél kér egy címet a DHCP kiszolgálótól
2. A DHCP kiszolgáló az ügyfélhez rendel egy IP-címet.
3. A DHCP kiszolgáló regisztrálja a DNS állomás bejegyzést az előre konfigurált kiszolgálónál az ügyfél nevében.
4. A DHCP kiszolgáló regisztrálja az állomás mutató (PTR) nevét.
A DNS kizsolgálók a teljes DNS hierarchia egy meghatározott részének zóna adatbázisát tartják karban. Az erőforrás bejegyzéseket a DNS zónában tárolják.
A DNS zónák címkeresési (forward lookup) vagy névkeresési (reverse lookup) zónák lehetnek. Ezen belül elsődleges vagy másodlagos címkeresési, illetve névkeresési zóna lehet. Minden zóna típusnak speciális szerepe van az egész DNS infrastruktúrában.


Címkeresési zóna
A címkeresési zóna egy hagyományos DNS zóna, mely egy teljesen meghatározott tartománynevet egy IP-címre old fel. Az internet böngészése közben ezzel a típussal lehet leggyakrabban találkozni. Egy weboldal címének, mint például www.cisco.com begépelése után egy rekurzív kérés érkezik a helyi DNS kiszolgálóhoz a név feloldására.
Névkeresési zóna
A névkeresési zóna egy speciális zóna típus, mely IP címeket old fel teljesen meghatározott tartománynevekre. Bizonyos alkalmazások névkeresést használnak a velük kommunikáló számítógép rendszer azonosítására. Az interneten megtalálható egy teljes névkeresési DNS hierarchia, melynek segítségével bármely nyilvánosan regisztrált IP cím feloldható. Sok magánhálózat saját maga implementálja a helyi névkeresési zónáját a hálózat számítógéprendszerének azonosítására. Névkeresést használ a ping -a[ Ip-cím] parancs is.
Elsődleges zónák
Az elsődleges DNS zóna módosítható. Ha egy új erőforrás bejegyzést hozzá kell adni vagy egy létező bejegyzést frissíteni, törölni kell, akkor a módosítást az elsődleges zónában végzik. Ha egy elsődleges zóna található a DNS kiszolgálón, akkor a kiszolgáló a felelős azért a zónáért, ő rendelkezik a zóna bejegyzéseit érintő kérésekre adható válaszokkal. Minden DNS tartományban egyetlen elsődleges zóna lehet, illetve egy elsődleges címkeresési és egy elsődleges névkeresési zóna.
Másodlagos zónák
A másodlagos zóna egy olvasható tartalék (backup) zóna, melyet az elsődleges zónától külön kiszolgálón kell tárolni. Ez tulajdonképpen az elsődleges zóna másolata és az elsődleges zónától kapja a frissítéseket. Mivel a másodlagos zóna csak egy olvasható backup zóna, így minden bejegyzés frissítést a megfelelő elsődleges zónán kell elvégezni. Másodlagos zónából is lehet címkeresési és névkeresési zóna is. A DNS zóna elérhetőségi követelményeitől függően több másodlagos zóna is lehet szétszórva.

7.3.4 DNS implementálása
Több módja is létezik a DNS implementálásának.
ISP DNS kiszolgálók
Az internetszolgáltatók általában gyorsítótáras (caching-only) DNS kiszolgálókat tartanak karban. Ezeket a kiszolgálókat úgy konfigurálják, hogy minden feloldási kérést az interneten a root kiszolgálóknak továbbítsanak. Az eredményeket a cache-ben tárolják és későbbi kérésekhez használják. Mivel a szolgáltatóknak általában sok felhasználójuk van, így az eltárolt DNS bejegyzések száma igen nagy. A hatalmas gyorsítótár csökkenti a hálózati sávszélesség igénybevételét a gyökér kiszolgálóknak továbbított DNS kérések gyakoriságának csökkentésével. A caching-only kiszolgálók nem tartanak kézben semmilyen hiteles (authoritative) zóna információt, azaz nem tárolnak egyetlen név - IP-cím hozzárendelést sem az adatbázisukban.
Helyi DNS kiszolgálók
Egy vállalat saját maga is üzemeltetheti a DNS kiszolgálóját. Ilyenkor a hálózaton lévő ügyfélszámítógépeket úgy konfigurálják, hogy a helyi és nem az ISP DNS kiszolgálójára mutasson. A helyi DNS kiszolgáló tartalmazhat hiteles zónabejegyzéseket a szóbanforgó zónára, azaz név - IP-cím hozzárendeléseket a zónáján belüli összes állomásra. Ha a DNS kiszolgáló olyan kérést kap, amit nem tud feloldani, akkor továbbítja. A helyi DNS kiszolgáló gyorsítótára viszonylag kicsi az ISP DNS kiszolgálójáéhoz képest, mivel a feloldási kérések száma jóval kevesebb.
A helyi DNS kiszolgálót úgy is lehet konfigurálni, hogy a kéréseket közvetlenül a root DNS kiszolgálónak továbbítsa. Sok rendszergazda a DNS kiszolgálót mégis úgy konfigurálja, hogy a kéréseket a hierarchián eggyel magasabb szinten álló kiszolgálónak, például az ISP DNS kiszolgálójának továbbítsa. Ilyenkor a helyi DNS kiszolgáló előnyt élvez az ISP DNS kiszolgálójának gyorsítótárában eltárolt nagyszámú bejegyzésből, és így nem kell a root kiszolgálótól kezdődő egész keresési folyamaton végigmenni. 
ISP DNS kiszolgáló
Jellemzően caching-only kiszolgáló
Mindert nevfeloldasi kérést a root kiszolgálónak továbbit
Tűzfal
Helyi DNS kiszolgáló
- A szervezet által karbantartott • A helyi DNS kiszolgáló minden belső eszköz név - IP-cím hozzárendeléséért felelős.
■ Minden külső névfeloldási kérést vagy az ISP DNS kiszolgálónak vagy a root kiszolgálónak továbbít.
A DNS kiszolgáló elérhetőségének elvesztése veszélyeztetheti a nyilvános erőforrások láthatóságát. Ha a felhasználók olyan tartománynevet gépelnek be, melyet nem lehet feloldani, akkor nem tudják elérni az erőforrást. Ezért amikor egy szervezet regisztrál egy tartománynevet az interneten, akkor legalább két DNS kiszolgálónak el kell küldeni a regisztrációt. Ezek a kiszolgálók tárolják a DNS zóna adatbázist. Tartalék DNS kiszolgálók biztosítják, hogy az egyik kiesése esetén a másik elérhető legyen névfeloldásra. Ez adja a rendszer hibatűrő képességét. Ha a hardver erőforrások lehetővé teszik egy zónán belül két vagy több DNS kiszolgáló elhelyezését, akkor nagyobb védelmet és szervezettséget lehet elérni.
Szintén hasznos, ha a zóna információt tároló DNS kiszolgálói fizikailag külön hálózaton vannak. Például az elsődleges DNS zónainformáció tárolható a vállalat helyi DNS kiszolgálóján. Általában az ISP-nél tárolható egy másodlagos DNS kiszolgáló a kiesés elkerülésére.
A DNS kritikus hálózati szolgáltatás, ezért tűzfalakkal és más biztonsági módszerekkel kell védeni. Kiesése esetén a webszolgáltatások elérhetetlenek lesznek. 
7.4 Szolgáltatások és protokollok
7.4.1 Szolgáltatások
Az internetkapcsolat és DNS szolgáltatás mellett az internetszolgáltatók nagyon sok üzleti-célú szolgáltatást biztosítanak a felhasználóiknak. Ezek a szolgáltatások a kiszolgálón található programmal engedélyezhetők. Az ISP által nyújtott szolgáltatásokhoz tartozik:
• e-mail tárolás
• weboldalak tárolása
• elektronikus kereskedelmi oldalak
• fájltárolás és átvitel
• üzenőfalak és blog-ok
• video - és audiofolyam szolgáltatások
A TCP/IP alkalmazás rétegbeli protokollok ezen ISP szolgáltatások és alkalmazások többségét lehetővé is teszik. A legismertebb TCP/IP alkalmazási rétegbeli protokollok a HTTP, FTP, SMTP, POP3 és IMAP4.
Sok felhasználó biztonsággal szembeni elvárásai nagyobbak, ezért az alkalmazási rétegbeli protokollok biztonságos verziói is rendelkezésre állnak, mint például az FTPS és a HTTPS.
7.4.2 HTTP és HTTPS
A HTTP-t, a TCP/IP modell egyik protokollját eredetileg HTML formájú weboldalak lehívására tervezték. Ma már elosztott, együttműködéssel létrehozott információ megosztásra használják. A HTTP-nek sok verziója létezik. A legtöbb ISP a HTTP 1.1-es verzióját használja web-hosting szolgáltatások biztosítására. A korábbi verzióktól eltérően az 1.1-es verzió lehetővé teszi a webkiszolgáló számára több weboldal tárolását is. Megengedi az állandó kapcsolatokat, így több kérés- és válaszüzenet használhatja ugyanazt a kapcsolatot, csökkentve ezáltal új TCP viszonyok létesítésének idejét.
A HTTP egy kérés/válasz alapú protokoll. Amikor egy ügyfél, általában egy webböngésző kérést küld a webkiszolgálónak, akkor a HTTP meghatározza az ügyfél által küldött kérés, valamint a kiszolgáló által küldött válasz üzenettípusát.
A HTTP rugalmassága ellenére nem biztonságos protokoll. A kérésüzenetek és a kiszolgálóválaszok titkosítás nélküli információt szállítanak, amely könnyen elfogható és olvasható mások számára is.
Az internet feletti biztonságos kommunikációra, a webkiszolgáló elérésére a biztonságos HTTP-t (HTTPS - Secure HTTP) használják. A HTTPS hitelesítést és titkosítást is használhat az adatok biztonságos átviteléhez az ügyfél és a kiszolgáló között. További szabályokat is meghatároz az alkalmazási és szállítási réteg közötti adatáramlás szabályzására.
80-as port
figyelése
TCP kapcsolat 
Ha kapcsolatba lépünk egy HTTP kiszolgálóval egy weboldal letöltése céljából, az egységes erőforrás azonosító (URL - uniform resource locator) segítségével történik a kiszolgáló és a meghatározott erőforrás helyének meghatározása. Az URL meghatározza:
• A használt protokollt
• Az elérni kívánt kiszolgáló tartománynevét
• A kiszolgálón található erőforrás helyét, mint például http://example.com/example1/index.htm
Sok webkiszolgáló alkalmazás megengedi a rövid URL-ket. A rövid URL-ek azért is népszerűek, mert könnyű megjegyezni, leírni vagy továbbadni őket. Egy rövid URL-lel az erőforrás alapértelmezett oldala jeleníthető meg. Amikor a felhasználó begépel egy rövidített URL-t, mint például: http://example.com, akkor az alapértelmezett oldalt kapja meg, ami tulajdonképpen a http://example.com/example1/index.htm weboldal.
A HTTP proxy szolgáltatásokat is támogat. A proxy kiszolgáló lehetővé teszi az ügyfelek számára, hogy közvetett hálózati kapcsolatokat alakítsanak ki más hálózati szolgáltatásokkal. A kommunikációs folyam közbülső eszköze, mely az ügyfél felé úgy viselkedik, mint egy kiszolgáló, a kiszolgáló felé pedig, mint egy ügyfél.
Az ügyfél kapcsolódik a proxy kiszolgálóhoz és kér egy másik kiszolgálón található erőforrást a proxy- tól. A proxy kapcsolódik a meghatározott kiszolgálóhoz és lehívja a kért erőforrást, majd továbbítja az ügyfél felé.
TCP kapcsolat
• Biztonság - A proxy kiszolgálók felhasználhatók számítógépes vírusok és más rosszindulatú programok felfogására és az ügyfeleknek való továbbítás megakadályozására.
• Szűrés - A proxy kiszolgálók látják a bejövő HTTP üzeneteket és szűrik a nem megfelelő vagy támadó tartalmú weboldalakat.
A HTTP titkosítatlan szöveget küld az ügyfél és a kiszolgáló között. Ezek az üzenetek könnyen elfoghatók és olvashatók jogosulatlan felhasználók számára. Az adatok, főleg a bizalmas információ védelmére, sok ISP nyújt biztonságos webszolgáltatást HTTPS segítségével. A HTTPS tulajdonképpen
HTTP, egy biztonságos csatoló réteg (SSL - secure socket layer) felett. A HTTPS ugyanazt az ügyfélkérés - kiszolgálóválasz üzeneteket használja mint a HTTP, de az adatokat a hálózaton történő átvitel előtt SSL használatával titkosítja.
Amikor a HTTP adatfolyam megérkezik a kiszolgálóhoz, akkor a TCP réteg átadja a kiszolgáló alkalmazási rétegében lévő SSL-nek dekódolásra.
A HTTPS kiszolgáló kevesebb egyidejű kapcsolatot tud ellátni, mint a HTTP kiszolgáló. A HTTPS többletterhelést ró a kiszolgálóra az adatforgalom titkosítása és dekódolása érdekében. A kiszolgáló teljesítményének javítására a HTTPS-t csak indokolt esetben érdemes használni, például bizalmas adatok küldése esetén.
443-as port
figyelése
TCP kapcsolat
7.4.3 FTP
Az FTP egy összeköttetés-alapú protokoll, mely TCP-t használ az ügyfél folyamat és a kiszolgáló folyamat közötti kommunikáció lebonyolítására. Az FTP implementációk a protokoll értelmező (PI - Protocol Interpreter) és az adatátviteli folyamat (DTP - data transfer process) funkciókat is tartalmazzák. A PI és a DTP két külön folyamatot határoznak meg, melyek együtt dolgoznak a fájlátvitelben. Ennek eredményeképpen az FTP két kapcsolat meglétét igényli az ügyfél és a kiszolgáló között. Egyet a vezérlő információk és parancsok küldéséhez, egyet pedig az aktuális adatátvitelhez.
Protokoll értelmező (PI - Protocol Interpreter)
A PI a fő vezérlő kapcsolat az FTP ügyfél és az FTP kiszolgáló között. Létrehozza a TCP kapcsolatot és továbbítja a vezérlő információt a kiszolgálónak, amely a fájl hierarchián történő navigáláshoz, átnevezéshez vagy fájlmozgatáshoz szükséges parancsokat is magába foglalja. A vezérlő kapcsolat vagy vezérlő folyam addig nyitva marad, míg a felhasználó be nem zárja. Amikor egy felhasználó kapcsolódni akar egy FTP kiszolgálóhoz, akkor ez öt lépésben történik:
1. lépés: A felhasználó PI kapcsolat felépítés kérést küld a kiszolgáló PI-nek a 21-es porton.
2. lépés: A kiszolgáló PI válaszol és a kapcsolat felépült.
3. lépés: Miután a TCP vezérlő kapcsolat megnyílt, a kiszolgáló PI megkezdi a bejelentkezési folyamatot.
4. lépés: A felhasználó a felhasználói interfészen keresztül megadja a személyi adatait, és elvégzi a hitelesítést.
5. lépés: Megkezdődik az adatátvitel. 
Adatátviteli folyamat (DTP - Data Transfer Process)
A DTP egy különálló adatátviteli funkció. Ez a funkció csak akkor engedélyezett, ha a felhasználó akar ténylegesen állományokat le - vagy feltölteni az FTP kiszolgálóra. A PI kapcsolattól eltérően, mely nyitva marad, a DTP kapcsolat automatikusan bezárul a fájlátvitel befejezése után.
Az FTP által támogatott kétfajta adatkapcsolat az aktív és a passzív kapcsolat.
Aktív adatkapcsolatok
Aktív adatkapcsolat esetén az ügyfél kezdeményezi a kérést a kiszolgáló felé és megnyit egy portot a várt adatnak. A kiszolgáló aztán kapcsolódik az ügyfélhez a megadott porton és megkezdődik a fájlátvitel.
Passzív adatkapcsolatok
Passzív adatkapcsolat esetén az FTP kiszolgáló nyit meg egy véletlenszerűen kiválasztott portot (nagyobb, mint 1023). A kiszolgáló elküldi az FTP ügyfélnek az IP címét és a megnyitott port számát egy vezérlő folyamon. A kiszolgáló várja az FTP ügyfél kapcsolódását és a fájlátvitel megkezdését.
Az ISP-k az FTP kiszolgálóknak általában passzív adatkapcsolatokat szolgáltatnak. A tűzfalak gyakran nem engedélyezik az aktív FTP kapcsolatokat a belső hálózaton lévő állomások számára.


7.4.4 SMTP, POP3 és IMAP4
Az ISP által támogatott elsődleges szolgáltatások egyike az email-hosting (e-mail szolgáltatás). Az elektronikus levelezés szolgáltatás a tárol és továbbít módszert alkalmazza az üzenetek hálózaton történő küldésére, tárolására és elérésére. Az elektronikus leveleket a levelezőkiszolgálók adatbázisokban tárolják. Az internetszolgáltatók gyakran alkalmaznak olyan levelezőkiszolgálókat, melyek több különböző felhasználói fiókot is támogatnak.
A levelező ügyfelek a kiszolgálóknak küldik és tőlük kapják a leveleket. Levelezőkiszolgálók más kiszolgálókkal is kommunikálnak, hogy egyik tartományból a másikba küldjék az üzeneteket. Levélküldés esetén az ügyfelek nem kommunikálnak egymással közvetlenül, helyettük a kiszolgálók végzik az üzenettovábbítást még akkor is, ha a küldő és fogadó állomás ugyanabban a tartományban van.
A levelező ügyfelek a kiszolgálónak az alkalmazás beállításainak megfelelően küldik az üzeneteket. Amikor a kiszolgáló megkapja az üzenetet, akkor először ellenőrzi, hogy a címzett a helyi adatbázisában van-e. Ha nem, akkor egy DNS kérést küld a célállomás tartományában megtalálható levelezőkiszolgáló meghatározására. Ha a célállomás levelezőkiszolgálójának IP-címe már ismert akkor a levelet továbbítja ennek a kiszolgálónak.
Az elektronikus levelezés három különböző protokollt támogat: SMTP, POP3 és IMAP4. Az az alkalmazási rétegbeli folyamat, amely az ügyféltől a kiszolgálóig, vagy két kiszolgáló között továbbítja a leveleket, az SMTP protokollra épül. Az ügyfél pedig a POP3 vagy IMAP4 alkalmazási rétegbeli protokoll valamelyikével hívja le az e-maileket.
"A" ISP "B" ISP
Levelezőkiszolgáló Levelezőkiszolgáló

Küldő Címzett

Az SMTP megbízhatóan és hatékonyan továbbítja a leveleket. Az SMTP alkalmazások megfelelő működéséhez az üzenetnek megfelelő formájúnak kell lennie, és az SMTP folyamatoknak mind az ügyfél, mind a kiszolgáló állomáson futnia kell.
Az SMTP üzenetnek van egy fejrésze és adatrésze. Míg az üzenet adatrésze tetszőleges mennyiségű szöveges információt tartalmazhat, addig a fejrésznek megfelelő formátumú címzett és feladó címet kell tartalmaznia. A többi fejrész információ nem kötelező.
Amikor az ügyfél e-mailt küld, akkor az SMTP folyamata kapcsolódik a kiszolgáló SMTP folyamatához a jól ismert 25-ös porton. A kapcsolat felépítése után az ügyfél megkísérli a kapcsolaton keresztül az e-mail küldését. Ha a kiszolgáló megkapja az üzenetet, akkor vagy elhelyezi egy helyi levelzőfiókban vagy továbbítja egy másik kiszolgálónak ugyanazon az SMTP folyamaton keresztül.
A célállomás e-mail kiszolgálója lehet, hogy nem elérhető az üzenetküldés idejében, ezért az SMTP eltárolja az üzeneteket egy sorban a későbbi küldéshez. A kiszolgáló periódikus időközönként ellenőrzi az üzenetsort és újra megpróbálja elküldeni. Ha az üzenetet nem sikerült egy előre meghatározott lejárati időn belül kézbesíteni, akkor visszakerül a feladóhoz kézbesítetlenül.
Az e-mail üzenet fejrészének egyik szükséges mezője a címzett e-mail címe. Az e-mail cím felépítésében megtalálható az e-mail fiók neve vagy egy fedőnév a levelező kiszolgáló tartomány neve mellett. Példa az e-mail címre:
dmzett@cisco.com
A @ szimbólum a kiszolgáló tartomány nevét és a levelező fiók nevét választja el egymástól. Ha a DNS kiszolgáló egy olyan kérést kap, amiben megtalálható a @ szimbólum, akkor tudja, hogy egy levelező kiszolgáló IP-címét kell keresnie.
Ha az üzenet a címzett@cisco.com-nak szól, akkor a tartománynevet elküldik a DNS kiszolgálónak, hogy a tartomány levelező kiszolgálójának IP-címét megszerezzék. A tevelező kiszolgálókat a DNS-en belül egy MX bejegyzés jellel különböztetik meg. Az MX egy erőforrás bejegyzés típus, mely a DNS kiszolgálókon megtalálható. Ha a célállomás levelező kiszolgálója megkapja az üzenetet, akkor eltárolja a megfelelő levelesládában. A levelesláda helye az e-mail cím első részében meghatározott előfizetői fiókon alapszik, jelen esetben ez a "címzett" előfizetői fiók. Az üzenet addig a levelesládában marad, amíg a címzett nem kapcsolódik a kiszolgálóhoz és le nem tölti az e-mailt.
Ha a levelező kiszolgáló kap egy e-mail üzenetet, ami egy ismeretlen előfizetői fióknak szól, az e-mailt kézbesítetlenül visszaküldi a feladónak.
Postafiók protokoll - 3-as verzió (POP3 - Post Office Protocol) lehetővé teszi egy munkaállomás számára az e-mailek levelező kiszolgálóról történő lehívását. POP3 esetén az e-mailek letöltés után törlődnek a kiszolgálóról.
A kiszolgáló a POP3 szolgáltatást a 110-es TCP port passzív figyelésével teszi elérhetővé az ügyfélek számára. Ha az ügyfélnek szüksége van a szolgáltatásra, akkor kérést küld a TCP kapcsolat felépítésére. A kapcsolat felépítése után a POP3 kiszolgáló egy üdvözlő üzenetet küld. Az ügyfél és a POP3 kiszolgáló utasításokat és válaszokat váltanak egymással, addig amíg a kapcsolat nem zárul vagy meg nem szakad.
Mivel az e-mail üzeneteket az ügyfelek letöltik és aztán a kiszolgálóról törlődnek, így az üzenetek nincsenek egyetlen központi helyen tárolva. Mivel a POP3 nem tárolja az üzeneteket, ezért kis vállalatok számára nem ajánlott, mert központosított mentési megoldást igényelnek.
POP3 az ISP-k számára megfelelő választás, mivel nem szükséges a levelezőkiszolgálókon nagyméretű tárolóterület fenntartása és karbantartása.
Internetes üzenetelérési protokoll (IMAP4 - Internet Message Access Protocol) egy másik e-mail hozzáférési módszert definiál. A POP3-tól eltérően azonban, amikor a felhasználó az IMAP kiszolgálóhoz kapcsolódik, az ügyfél alkalmazás az e-mail üzeneteknek csak egy másolatát tölti le. Az eredeti üzenetek kezelői törlésig a kiszolgálón maradnak. A felhasználók a levelező ügyfélprogram segítségével tekinthetik meg az üzenetek másolatát.
Az ügyfelek a kiszolgálón fájlhierarchiát hozhatnak létre a levelek tárolására és rendszerezésére. A fájlhierarchia másolata az e-mail ügyfélen is megtalálható. Ha az ügyfél töröl egy üzenetet, akkor a kiszolgáló szinkronizálja a műveletet és törli az üzenetet a kiszolgálóról.
Kis- és középvállalatok szempontjából sok előnye van az IMAP szolgáltatásnak. Az IMAP hosszútávú e-mail tárolást, és központosított mentést tesz lehetővé. Az alkalmazottak számára az e-mailek több helyszínről, különböző eszközökkel és ügyfélprogrammal történő elérését is támogatja. A levelesláda könyvtárszerkezetének megtekintése független a levelesláda elérési módjától.
Egy ISP számára az IMAP nem megfelelő választás. Nagyon költséges lenne az e-mailek tárolásához szükséges tárkapacitás megvásárlása és karbantartása. Ezen felül az ügyfelek postafiókjainak rendszeres mentése tovább növelné az ISP költségeit.
7.5 A fejezet összefoglalása
• A TCP egy összeköttetés alapú protokoll. Nyugtázott, garantált kézbesítést igénylő alkalmazások használnak TCP-t.
• Az UDP egy összeköttetés-mentes protokoll. Nem garantált kézbesítést igénylő alkalmazások UDP-t használnak.
• A TCP és UDP protokollok portszámokat használnak egy meghatározott alkalmazás adatainak, vagy a kiszolgálón futó folyamat azonosítására.
• A TCP és UDP portok teszik lehetővé, hogy a hálózati kiszolgálók egyidejűleg több különböző alkalmazás által kezdeményezett adatátviteli kérésre gyorsan és megbizhatóan válaszoljanak.
• Az eredeti TCP/IP névrendszer a HOSTS állományon alapult, mely tartalmazta az ismert állomások nevét és IP címét.
• A DNS egy névfeloldási rendszer, mely a HOSTS állomány hiányosságait hivatott pótolni.
• A DNS hierarchikus felépítésű és a DNS adatbázis fel van osztva a root, a legfelsőbb szintű, a második szintű és az altartományok között.
• Dimamikus frissítések segítségével a DNS ügyfelek regisztrálhatják magukat a kiszolgálónál és változás esetén frissíthetik az erőforrás bejegyzéseiket.
• A DNS zónák lehetnek címkeresési (Forward lookup) és névkeresési (reverse lookup) zónák. Ezen felül lehetnek elsődleges vagy másodlagos zónák.
• Sok ISP nyújt gyorsítótáras (caching-only) DNS szolgáltatást.
’ Egy szervezet úgy is futtathatja a DNS kiszolgálóját, hogy vagy a caching-only kiszolgálóra vagy rögtön a root kiszolgálóra mutasson. 
• Az interneten nyújtott leggyakoribb szolgáltatások az FTP, FTPS, SMTP, POP3, IMAP4, HTTP és HTTPS.
• A HTTP és a HTTPS webkiszolgáló szolgáltatások. A HTTPS a biztonságos változata a HTTP-nek, mely SSL-t használ.
• Az ISP a HTTPS támogatásához nagyteljesítményű webkiszolgálőkat használ, hogy ellássa a titkosítási és visszafejtési feladatokat.
• Az FTP-t fájlátviteli szolgáltatásokra használják. Az ISP támogatja az aktív és passzív FTP kapcsolatokat is. Aktív kapcsolat esetén a kiszolgáló kezdeményezi a összeköttetést. Passzív kapcsolat esetén az állomás kezdeményezi az összeköttetést.
• Az elektronikus levelezés három különböző protokollt használ. Email küldése SMTP-vel történik. Email letöltésére a POP3 és IMAP protokollok szolgálnak.

8. ISP felelősség
8.1 ISP biztonsági megfontolások
8.1.1 ISP biztonsági szolgáltatások
Bármilyen internet kapcsolat esetén a számítógép rosszindulatú támadások célpontjává válhat. A károkozó vagy rosszindulatú programok, mint a számítógépes vírusok, férgek vagy kémprogramok levélben, illetve weboldalak letöltésével érkezhetnek. Az általuk keletkezett, változó mértékű hibák, gyakran az ISP hálózatának nem biztonságos előfizetői asztali gépeiről származnak.
Ha az ISP webhelyek és e-kereskedelmi oldalak tárolásával is foglalkozik, bizalmas kereskedelmi és bankszámlákkal kapcsolatos adatokat is tárolhat, minek következtében az előfizetők adatainak biztonságos tárolása elengedhetetlen követelmény.
Az internetszolgáltatók fontos szerepet játszanak az otthoni és üzleti felhasználók védelmében, továbbá biztonsági szolgáltatásaikkal védik a náluk elhelyezett kiszolgálókat is. A felhasználók gyakran kérik segítségüket hálózataik és munkaállomásaik védelme érdekében a veszély kockázatának csökkentésére.
Számos lehetőség áll rendelkezésre mind a helyi, mind a szolgáltatói oldalon az operációs rendszer, a benne tárolt és a rendszerek között szállított adatok védelmére.
Ha egy internetszolgáltató tárhely és levelező szolgáltatást nyújt, fontos feladata az adatok védelme a rosszindulatú támadásokkal szemben. A védelem megteremtése bonyolult lehet, mert az egyetlen vagy néhány kiszolgálón tárolt adatok több felhasználóhoz tartozhatnak.
A sebezhető felületek elleni támadások megelőzésére a szolgáltatók könnyen kezelhető, asztali lehetőségeket nyújtanak. A helyszíni telepítő munkájának fontos részét képezi az alapvető biztonsági lehetőségek telepítése és beállítása az ügyfél számítógépén, melyek az alábbiak lehetnek: 
Szintén javasolt a jelszó rendszeres megváltoztatása. Léteznek programok, amelyek lehetővé teszik a támadóknak a jelszavak feltörését a betűk, számok és szimbólumok összes lehetséges kombinációjának probálgatásával.
A jelszó változtatgatásával a "nyers erő" szerinti jelszófeltörés valószínűsége eltörpül, mivel a próbálgatás rengeteg időt vesz igénybe, miközben a jelszó folyton módosul.
Felesleges szolgáltatások
A számítógéprendszer veszélyeztetésének egyik legáltalánosabb módszere a nem, vagy rosszul konfigurált szolgáltatások kiaknázása. A szolgáltatás természetéből adódóan figyeli a külső számítógépes rendszerekból érkező kéréseket. Ha a szolgáltatásnak kiismerhető és jól kiaknázható forgalma van a rossz konfiguráció eredményeként, a támadó vagy egy féreg veszélyeztetheti, és hozzáférést szerezhet a szolgáltatást futtató számítógéphez.
Bevált módszerként az összes nem használt szolgáltatás eltávolítása vagy kikapcsolása javasolt. A szükséges vagy nem eltávolítható szolgáltatások esetén meg kell győződni a helyes konfigurációról.
Javítások kezelése
Szinte naponta, folyamatosan azonosítanak új, kiaknázható biztonsági hézagokat az operációs rendszerekben. Egyszerű böngészéssel ezek megkereshetők, bárki rátalálhat a napjainkban használt összes operációs rendszer kiaknázható felületeinek listáját tartalmazó oldalakra.
A programfejlesztők rendszeresen hoznak forgalomba frissítéseket - bizonyos esetekben naponta. Az operációs rendszerek frissítéseinek rendszeres figyelemmel kisérése és telepítése elengedhetetlen. A legtöbb támadás, ami egy hekkertől, vagy egy vírus vagy féreg által okozott fertőzéstől indul ki, az oprációs rendszer folyamatos javításával megakadályozható.

Felhasználó jogosultságok
Egy korszerű operációs rendszerben több hozzáférési szint létezik. Ha a felhasználóknak rendszergazdai, azaz korlátlan hozzáférésük van a rendszerhez, a károkozók könnyebben árthatnak a számítógépnek.
A normál felhasználói azonosító nem jogosítja fel tulajdonosát új alkalmazások telepítésére, mivel nincs hozzáférése sem a legtöbb alkalmazás telepítéséhez szükséges állományrendszerhez, sem a
rendszer állományokhoz. Ennek eredményeként a normál felhasználó nem annyira érzékeny rosszindulatú fertőzésekre, melyek az állományrendszer bizonyos részeihez próbálnak hozzáférni vagy telepíteni rá valamit.
Legjobb megoldásként a felhasználóknak csak azt a hozzáférési szintet szabad engedélyezni, amely a mindennapi munkájukhoz elengedhetetlen. Rendszergazdai hozzáférés csak abban az esetben alkalmazható, amikor olyan műveletek elvégzésére van szükség, melyek a normál felhasználók számára nem megengedettek.
Tipp
A Microsoft szabadon letölthető segédeszköze a Microsoft Baseline Security Analyzer (MBSA) (Microsoft alap biztonsági elemző) program, amely megvizsgál minden, normál felhasználói hozzáféréssel telepített Windows szolgáltatást, és még az operációs rendszer jelenlegi javítási szintjét is ellenőrzi.
Másik népszerű átvizsgáló segédprogram a Nessus Vulnerability Scanner, amely nem csak Windows- on, hanem más, különböző platformon is fut. Számos további eszköz érhető el interneten. Rendszerint a legjobb megoldást az adja, ha legalább egy (de inkább több) program vizsgálja át a rendszer biztonságát.
8.1.2 Biztonsági intézkedések
Az felhasználók adatainak védelmében tett szolgáltató oldali intézkedések elengedhetetlenek a rosszindulatú támadásokkal szemben. A leggyakrabban alkalmazott lehetőségek és eljárások a következők:
• A kiszolgáló merevlemezén tárolt adatok titkosítása.
• Jogosultságok alkalmazása állományok és könyvtárak elérése esetén.
• Felhasználói azonosító vagy csoporttagság alapján történő hozzáférés engedélyezése illetve megtagadása.
• Többszintű hozzáférési jogosultságok használata felhasználói azonosító vagy csoporttagság alapján.
Állományok és könyvtárak jogosultságainak beállításakor a "lehető legkevesebb előjog elve" alapján érhető el a legnagyobb biztonság. Ez annyit jelent, hogy a felhasználóknak csak annyi jogosultságot szabad adni az erőforrások eléréséhez, amennyi a munkájuk elvégzéséhez elengedhetetlenül szükséges. Azaz a megfelelő jogosultsági szintet kell hozzájuk rendelni, például hozzáférés csak olvasásra vagy írásra.
Hitelesítés, Jogosultság ellenőrzés és Naplózás (AAA - Authentication, Authorization, Accounting) a rendszergazdák által használt három lépéses eljárás, amely megnehezíti a támadók hálózathoz történő hozzáférését.
A hitelesítés során a felhasználónak azonosítania kell magát
egy felhasználónévvel és egy jelszóval. A hitelesítési adatbázisokat általában RADIUS vagy TACACS protokollt használó kiszolgálókon tárolják.
A jogosultságok kezelésével a felhasználók megfelelő jogokat kapnak az erőforrások eléréséhez és bizonyos feladatok elvégzéséhez.
Naplózással nyomonkövethetők a felhasználók által használt alkalmazások és használati idejük.
Például a hitelesítési folyamat része a "tanuló " nevű felhasználó felismerése és a rendszerbe történő bejelentkezésének engedélyezése. Az jogosultság ellenőrzés meghatározza a "tanuló" felhasználó jogait az XYZ kiszolgáló eléréséhez Telnet segítségével. A naplózás nyomonköveti a "tanuló" felhasználó hozzáférését az XYZ kiszolgálóhoz és a Telnet használatát egy bizonyos napon 15 percen keresztül.
Az AAA különböző hálózati kapcsolatokban használható. Adatbázis alkalmazásával tartja nyilván a felhasználói azonosítókat, jogosultságokat és hozzáférési statisztikákat. A helyi hitelesítés a legegyszerűbb megoldás, ebben az esetben a helyi adatbázist az átjáró forgalomirányítón lehet elhelyezni. Ha egy szervezetnek több tucat felhasználót kell hitelesítenie az AAA segítségével, külön kiszolgálón kell az adatbázist fenntartania.
8.1.3 Adattitkosítás
Az internetszolgáltatóknak a kiszolgálók közötti adatforgalom védelmét is biztosítaniuk kell. A hálózatok alapértelmezett adattovábbítása nem biztonságos, nyílt szövegben történik, amelyet illetéktelen felhasználók lehallgathatnak. Az átmenő forgalom adatainak elfogása során az összes, az adatokon beállított állományrendszerbeli védelmet elkerülik. Vannak módszerek a biztonsági problémák elleni védelemre.
Titkosítás
A digitális titkosítás az ügyfél és a kiszolgáló közötti forgalom titkosítását teszi lehetővé. Számos protokoll, amelynek biztonságos változatát használják az adattovábbításhoz, digitális titkosítást alkalmaz. Legjobb minden esetben a protokoll biztonságos változatát használni, valahányszor bizalmas adatokat kell továbbítani állomások között.
Például, amikor egy felhasználó a bejelentkezése során megerősíti a felhasználónevét és jelszavát egy e-kereskedelemmel foglalkozó oldalon, biztonságos protokoll szükséges az adatok védelme érdekében. Szintén elengedhetetlen a biztonságos protokollok használata a hitelkártyával és bankszámlával kapcsolatos adatok használatánál.
Az internet böngészése és nyilvános honlapok nézegetése közben az adatok biztonságos továbbítása nem szükséges, sőt, felesleges számítási többletet és lassabb válaszidőt eredményezhet.

Az alkalmazások számos hálózati protokollt használnak, melyek közül némelyiknek van biztonságos változata, némelyiknek azonban nincs:
• Web kiszolgálók - A Web kiszolgálók HTTP protokollt használnak, amely nem biztonságos. A HTTPS, Biztonságos átviteli protokoll (SSL - Secure Socket Layer) alkalmazásával azonban lehetővé válik a biztonságos adattovábbítás.
• Levelező kiszolgálók - Különböző protokollokat használnak, például SMTP, POP3 és IMAP4. A felhasználó bejelentkezése során a POP3 és az IMAP4 felhasználónevet és jelszót kér a hitelesítéshez, amelyeket nem biztonságos módon küldenek. A POP3 SSL segítségével biztonságossá tehető. Az SMTP és az IMAP4 SSL-t és Szállítási rétegbeli biztonság (TLS - Transport Layer Security) protokollt is használhat a védelem érdekében.
• Telnet kiszolgálók - Cisco forgalomirányítóra vagy kapcsolóra történő Telnet bejelentkezés esetén a kapcsolat nem biztonságos. A Telnet program a hitelesítő adatokat és a parancsokat nyílt szövegként küldi a hálózaton keresztül, de a Biztonságos Parancshéj (SSH - Secure Shell) protokoll használatával a hitelesítés és a munka biztonságos módon történik.
• FTP kiszolgálók - Az FTP szintén nem biztonságos protokoll, a bejelentkezéshez és a hitelesítéshez kért adatokat nyílt szövegként továbbítja. SSL használatával a biztonságos adatküldés megvalósítható, és némely verzió SSH alkalmazására is képes.
• Állománykiszolgálók - A számítógép operációs rendszerétől függően több különböző protokollt is használhatnak adattovábbításra, de az esetek többségében ezek nem biztonságosak.
Az IP Biztonság (IPSec - IP Security) egy hálózati rétegbeli protokoll, amellyel bármely alkalmazás rétegbeli protokoll használata biztonságos kommunikációt eredményez. Ez magában foglal állománykiszolgáló protokollokat, amelyeket semmilyen más biztonsági protokollverzió nem kínál.

8.2 Biztonsági eszközök
8.2.1 Hozzáférési listák és portszűrés
Még az AAA és a titkosítás használata esetén is, sok különböző típusú támadás ellen kell az ISP-nek védekeznie. Különösen sebezhetők a Szolgáltatásmegtagadási támadásokkal (DoS - denial-of-service) szemben, mivel számos különböző, regisztrált tartománynévvel rendelkező oldalt tárolhatnak, amelyek némelyike igényel hitelesítést, más részük viszont nem. Jelenleg három kulcsfontosságú DoS támadás létezik:
DoS
A DoS támadások alapformája a kiszolgáló vagy szolgáltatás elleni támadás a jogos felhasználók hozzáférésének megakadályozására. Ilyen például a SYN elárasztás, ping elárasztás, Land támadás, sávszélességet leterhelő támadás és buffer túlcsordulási támadás.
DDoS
Az elosztott szolgáltatásmegtagadási támadás(DDoS - distributed denial-of-service) esetén több számítógép egyszerre lép fel egy meghatározott célpont ellen. A támadó sok feltört számítógéphez fér hozzá, általában interneten keresztül, íly módon távolról indíthatja a támadást. A DDoS támadások az alap Dos támadásokhoz hasonlítanak, leszámítva, hogy egyszerre több számítógépről, párhuzamosan indulnak.
DRDoS
Az elosztott reflektált szolgáltatásmegtagadási támadás (DRDoS - distributed reflected denial-of- service) alkalmával a támadó ál- vagy látszatüzenetkérést küld egyszerre több számítógépnek az interneten keresztül, módosítva a forrás címet a célpont számítógép címére. Azok a számítógépek, amelyek a kérést megkapják, mind válaszolnak a célpont számítógép címére. Mivel a támadás reflektált, a támadó kezdeményezőjét nagyon nehéz meghatározni. 
Az internetszolgáltatóknak képesnek kell lenniük az olyan hálózati forgalom kiszűrésére, mint például a DoS támadás, amely veszélyezteti a hálózatuk vagy a kiszolgálók működését. A Portszűrés (Port filtering) és a hozzáférési lista (ACL - access control list) segítségével a kiszolgáló és más hálózati eszközök felé menő adatforgalom szabályozható.
Portszűrés
Meghatározott TCP vagy UDP portok alapján ellenőrzi az adatforgalmat. Számos kiszolgáló operációs rendszerében van lehetőség a hozzáférések korlátozására portszűrés segítségével. Hálózati forgalomirányítókon és kapcsolókon is gyakran használják a forgalom ellenőrzésére és az eszközökhöz való biztonságos hozzáféréshez.

Hozzáférési listák
A hozzáférési listákkal definiálható a tiltott vagy engedélyezett hálózati forgalom a forrás és cél IP- címek alapján, valamint a használt protokoll forrás- és célportjai alapján. Továbbá az ICMP üzenetek és a forgalomirányító protokollok frissítései is ellenőrizhetők. A rendszergazda ACL-eket hoz létre olyan hálózati eszközökön, mint például a forgalomirányító, annak eldöntésére, vajon a forgalom átengedhető-e vagy sem.
Az ACL-ek a védelemnek csak az első lépései, önmagukban nem elégségesek a hálózat biztonságához. Csupán megelőzik a hálózathoz történő hozzáférést, de nem védik meg a rosszindulatú támadások minden fajtájától.

8.2.2 Tűzfalak
A tűzfal olyan hálózati hardver vagy szoftver, amely meghatározza, melyik forgalom jöhet be vagy távozhat a hálózat bizonyos részeiből, illetve hogyan kell az adatokat kezelni.
Az ACL mechanizmus egy a tűzfalak által használt eszközök közül, amelyek szabályozzák, mely forgalom haladjon át a tűzfalon. Az engedélyezett forgalom iránya is szabályozható. Egy közepes méretű hálózatban az ellenőrizni kívánt forgalom, illetve a szabályozandó hálózati protokollok mennyisége igen nagy lehet, így a tűzfalon elhelyezett ACL-ek túl bonyolulttá válhatnak.
A tűzfalak hozzáférési listákat használnak az átengedhető és a letiltandó forgalom ellenőrzésére. Állandóan fejlődnek, ahogy új képességeket fejlesztenek ki, és új fenyegetéseket fedeznek fel.
A különböző tűzfalak különböző jellemzőkkel rendelkeznek. Az állapotalapú tűzfalként is ismert dinamikus csomagszűrő tűzfalak állapottábla alkalmazásával képesek a forrás- és céleszközök közötti kommunikáció követésére. Ezek adott adatfolyamok engedélyezését követően csak az azokhoz tartozó forgalom áthaladását engedik a tűzfalon. A Cisco IOS-be ágyazott Cisco IOS tűzfal használatával a forgalomirányítók hálózati rétegbeli dinamikus, állapotalapú csomagszűrű tűzfalként is használhatók.
A tűzfalak állandóan fejlődnek, ahogy új képességeket fejlesztenek ki, és új fenyegetéseket fedeznek fel. Minél több beágyazott funkcióval rendelkeznek, annál több időt vesz igénybe a csomagok feldolgozása.
A tűzfalak a hálózat egész területének határbiztonságát és a belső, helyi szegmensek, például kiszolgáló-farmok, védelmére is jól használhatók.
Egy ISP hálózaton belül vagy egy közepes méretű vállalat hálózatában a tűzfalakat általában több rétegben valósítják meg. A nem megbízható hálózatból bejövő forgalom először egy határforgalomirányító csomagszűrőjén halad át, amelynek belső tűzfala az engedélyezett csomagokat egy demilitarizált zóna felé (DMZ - demilitarized zone) irányítja. A DMZ az internet felől érkező felhasználók számára hozzáférhető kiszolgálókat tárolja és kizárólag az a forgalom érkezhet ide, amelyiknek engedélyezett ezekhez a kiszolgálókhoz történő hozzáférése. A tűzfalak a védett, belső hálózatba érkező forgalom típusát is ellenőrzik. Általában a belső eszközök meghatározott kéréseire érkező válaszok engedhetők be a belső hálózatba. Például, ha egy belső eszköz egy külső kiszolgálótól kér egy weboldalt, a tűzfal beengedi.
Némely szervezet belső tűzfalat alkalmaz az érzékeny területek védelmére. Ezek a tűzfalak a fokozott védelmet igénylő területek elérésének korlátozására használhatók. Elkülönítik és védik a kiszolgálókon elhelyezett vállalati erőforrásokat a szervezeten kívüli felhasználóktól, megakadályozzák a külső és belső véletlenszerű vagy akár rosszindulatú a támadásoktól.

 
8.2.3 IDS és IPS
Szintén az internetszolgáltató kötelezettsége, hogy amennyire lehetséges akadályozza meg a saját, és az olyan előfizetők hálózatába történő behatolást, akik fizetnek a szervezett szolgáltatásokért. Ennek érdekében két, gyakran használt megoldás közül választhatnak a szolgáltatók.
Behatolásérzékelő rendszer (IDS - Intrusion Detection System)
Az IDS a hálózati forgalmat passzívan figyelő szoftver- vagy hardver alapú megoldás. Az IDS eszköz a hálózati interfészeken áthaladó forgalmat figyeli, amely az IDS-en nem halad át. Amint rosszindulatú forgalmat észlel, vészüzenetet küld egy előre konfigurált felügyelő állomásnak.
Behatolás megelőző rendszer (IPS - Intrusion Prevention System)
Az IPS aktív fizikai eszköz vagy szoftver. A forgalom az IPS egyik interfészén megy be és a másikon megy ki. Az IPS megvizsgálja a hálózati forgalomban résztvevő aktuális adatcsomagokat, és valós időben működve engedi vagy tíltja a hálózatot elérni kívánó csomagokat.
Az IDS és IPS technológia szenzorokon alapul, amelyek az alábbiak lehetnek:
• Cisco IOS IPS-sel ellátott verziójával konfigurált forgalomirányító.
• IDS vagy IPS szolgáltatásra tervezett speciális (hardver) berendezés.
• Adaptív biztonsági berendezésbe (ASA - adaptive security appliance), forgalomirányítóba vagy kapcsolóba épített hálózati modul.
Az IDS és IPS szenzorok különböző módon válaszolnak a hálózatban észlelt, nem megszokott eseményekre, de mindegyiknek saját szerepe van a hálózatban.

Behatoiásérzékelő rendszer
Behatolásvédelmi rendszer
Vállalati hálózat Vállalati hálózat

Az IDS megoldások reaktívak, a behatolás észlelésekor riasztanak. A behatolást a jellemző hálózati forgalom vagy a számítógép jellemző tevékenységének ismeretében, az attól való eltérés alapján
detektálják. A kezdeti forgalmat nem tudják leállítani a célpont elérése előtt, csak reagálnak a detektált eseményre.
A rosszindulatú forgalom észlelését követően egy helyesen konfigurált IDS meg tudja akadályozni a következő támadásokat az olyan hálózati eszközök újrakonfigurálásával, mint a biztonsági berendezések vagy a forgalomirányítók. Megjegyzendő, hogy a kezdeti támadás keresztülhalad a hálózaton az érintett célpont felé, leállítani nem lehet, csak a további rosszindulatú forgalom akadályozható meg. Ebben a tekintetben, az IDS nem tudja teljes mértékben megakadályozni a sikeres támadást.
Gyakran a hálózatok nem megbízható határvonalában alkalmazzák, a tűzfalon kívül. Itt az IDS tudja elemezni a tűzfal felé haladó forgalom típusokat és meghatározza milyen a végrehajtott támadás. A tűzfallal blokkolható a legtöbb rosszindulatú forgalom. IDS a tűzfalon belül is elhelyezhető a tűzfal félrekonfigurálásának felismerésére. Amikor az IDS itt van elhelyezve, bármely felbukkanó vészjel azt mutatja, hogy rosszindulatú forgalom lett átengedve a tűzfalon. Ezek a vészjelek a tűzfal helytelen konfigurációját jelzik.
IPS
Az IDS megoldásaival ellentétben, melyek reaktívak, az IPS megoldásai proaktívak. Minden gyanús eseményt azonnal blokkolnak. Az IPS majdnem a teljes adatcsomagot képes megvizsgálni az OSI modell második rétegétől a hetedikig. Amikor rosszindulatú forgalmat észlel, azonnal blokkolja, majd vészjelet küld a felügyelő állomásnak a behatolásról. A kiinduló és a rákövetkező támadásokat egyaránt megakadályozza.
Megjegyzendő, hogy az IPS egy behatolás detektáló berendezés, nem pedig egy program. Általában a tűzfalon belül helyezik el, ezért tudja megvizsgálni a teljes adatcsomagot és megvédeni a kiszolgáló alkalmazásokat támadás esetén. A tűzfal általában nem vizsgálja meg a teljes csomagot, mint az IPS, hanem a legtöbb nem engedélyezett csomagokat eldobja, de még így is átengedhet rosszindulatú csomagokat. Mivel az IPS-nek kevesebb számú adatcsomagot kell megvizsgálnia, ellenőrizheti az egész csomagot, így azonnal blokkolhatja az újabb támadásokat, amelyek a tűzfal eredeti konfigurációjában még nem voltak tiltva. Az IPS olyan támadásokat is képes megállítani, amelyeket a tűzfal, saját korlátaiból kifolyólag, nem tud.
4.2.4 Vezeték nélküli hálózatok biztonséga
Némely ISP lehetőséget ad vezetéknélküli hozzáférési pontok (hot spot) létesítésére, amelyeken az előfizetők elérhetik a vezetéknélküli helyi hálózatokat (WLAN - wireless local-area network). WLAN- okat könnyű implementálni, ám könnyen is sebezhetők rossz konfiguráció esetén. Mivel a vezetéknélküli jelek áthaladnak a falakon, a vállalat területén kívülről is elérhetők. Az alapértelmezett beállítások megváltoztatásával, hitelesítés vagy MAC-cím szűrés beállításával a vezetéknélküli hálózatok védhetők.
Az alapértelmezett beállítások megváltoztatása.
Az SSID, a felhasználónév és a jelszó alapértelmezett beállításait ajánlott megváltoztatni, illetve az SSID üzenetszórását kikapcsolni.

A hitelesítés beállítása
A hitelesítés az a folyamat, mely során hitelesítő információk alapján dől el a belépés engedélyezése. A kapcsolódni kívánó eszközök megbízhatóságának eldöntésére használják. Három hitelesítési módszer használható:
• Nyílt hitelesítés - Személytől függetlenül, bármely felhasználó kaphat hozzáférést. Általában nyilvános vezetéknélküli hálózatokban használják.
• Előre megosztott kulcs (PSK - Pre-shared key) - A kiszolgálónak és az ügyfélnek egyaránt, egy megegyező, előre konfigurált kulcsra van szüksége. Kapcsolódás esetén, a hozzáférési pont egy véletlen bájtsorozatot küld a felhasználónak, amelyet az titkosít (vagy összekever) a kulcs alapján, majd visszaküld. A hozzáférési pont a titkosított karaktersorozatot a kulcs segítségével visszafejti (vagy visszakeveri). Egyezés esetén a hitelesítés sikeres.
• Kiterjeszthető hitelesítő protokoll. (EAP - Extensible Authentication Protocol) - Kölcsönös vagy két-utas hitelesítést és felhasználóhitelesítést tesz lehetővé. Ha EAP-ot használó programot telepítettek egy állomásra, az ügyfél egy kiszolgáló oldali hitelesítő szerverrel kommunikál, mint például a RADIUS.
MAC-cím szűrés beállítása
A MAC-cím szűrés megakadályozza az illetéktelen számítógép hálózatra csatlakozását a MAC-címek korlátozásával. Bár a módszer működik, mégis, mivel a MAC-cím lemásolható, más biztonsági megoldásokkal együtt alkalmazandó!
A legfontosabb a vezetéknélküli hálózaton keresztül küldött adatok titkosítása. WLAN-ok esetén három fontos titkosítási eljárás létezik:
• Vezetékessel egyenértékű titkosítás (WEP - Wired Equivalent Privacy) - Vezetéknélküli csomópontok között küldött adatok titkosítására szolgál. 64, 128, vagy 256 bites, előre kiosztott kulcsokat alkalmaz. Legnagyobb hibája a kulcsok állandóságából adódik, azaz minden eszköznél ugyanazt a kulcsot használja az adatok titkosítására. Számos WEP feltörő eszköz érhető el az Interneten, ezért csak régebbi eszközökön használható, amelyek nem támogatják az újabb biztonsági protokollokat.
• WiFi védett hozzáférés (WPA - Wi-Fi Protected Access) - egy új vezetéknélküli titkosítási protokoll, amely egy továbbfejlesztett titkosítási algoritmust, az Átmeneti kulcsintegritás protokollt (TKIP - Temporal Key Integrity Protocol) használja. A TKIP egyedi kulcsot generál minden ügyfél számára, amelyeket egy konfigurálható intervallumon belül forgat. Kölcsönös hitelesítési eljárást nyújt, mivel a felhasználó és a hozzáférési pont egyaránt rendelkezik a kulccsal, amelyet sohasem küldenek át a hálózaton.
• WPA2 - A WPA egy új, továbbfejlesztett változata. A WPA2 a biztonságosabb Fejlett titkosítási szabványt (AES - Advanced Encryption Standard) használja.
8.2.5 A munkaállomások biztonsága
Függetlenül a hálózat védekezési rendszerében megvalósított rétegektől, minden kiszolgáló ki van téve támadásoknak a nem megfelelő biztonsági intézkedések esetén. Az ISP kiszolgálók különösen sebezhetők, mert általában az internetről elérhetőek. A kiszolgálóknak minden nap újabb és újabb sebezhetőségeit fedezik fel, így egy ISP számára kritikus, hogy szervereit védje az ismert és
ismeretlen sebezhetőségeikkel szemben, amikor csak lehetséges. Egy lehetséges megoldást jelentenek az állomásalapú tűzfalak.
Az állomásalapú tűzfal közvetlenül a munkaállomás operációs rendszerén futó program. Megvédi a számítógépet az olyan rosszindulatú támadástól, amelyik a védelem összes többi rétegén keresztüljutott. A hálózaton belüli és kívüli forgalmat egyaránt ellenőrzi. Lehetővé teszi a számítógép címe és portja szerinti szűrést, mely további védekezési lehetőséget ad a hagyományos portszűrésen túl.
Az állomásalapú tűzfalak általában előre meghatározott szabályokkal kaphatók, amelyek blokkolják az összes beérkező forgalmat. A szabályokhoz kivételeket hozzáadva válik engedélyezetté a bejövő és a kimenő forgalom megfelelő aránya. Az állomásalapú tűzfal alkalmazásakor fontos megtartani az egyensúlyt a feladatok elvégzéséhez szükséges erőforások hozzáférhetősége, és a rosszindulatú támadások célpontjait jelentő alkalmazások megelőzése között. Számos kiszolgáló operációs rendszerében egy korlátozott lehetőségű, egyszerű állomásalapú tűzfal található. Fejlettebb, külső gyártók által forgalmazott csomagok szintén elérhetők.
Az ISP-k állomásalapú tűzfalakat használnak arra, hogy korlátozzák egy kiszolgáló által ajánlott specifikus szolgáltatásokhoz való hozzáférést. Egy állomásalapú tűzfal használatával az ISP megvédi a szervereiket és az előfizetőik adatait, a meglévő, de felesleges portjai elérésének blokkolásával.

Az állomásalapú tűzfalakat alkalmazó ISP kiszolgálók védettek a támadások és sebezhetőségek különböző fajtáival szemben.
Ismert támadások
Az állomásalapú tűzfalak frissíthető aláírásoknak is nevezett jellemző aktivitásminták alapján ismerik fel a rosszindulatú tevékenységet, majd blokkolják a forgalmat a támadás által használt porton.
A kihasználható szolgáltatások
Az állomásalapú tűzfalak védik a kihasználható szolgáltatásokat nyújtó kiszolgálókat a szolgáltatás portjain történő elérés megakadályozásával. Némelyek a csomag tartalmát is képesek ellenőrizni a rosszindulatú kódok felismerése érdekében. A web és levelező kiszolgálók népszerű célpontjai a

szolgáltatás támadásoknak, de csomagvizsgálatra alkalmas állomásalapú tűzfalak alkalmazásával megvédhetők.
Férgek és vírusok
Férgek és vírusok a szolgáltatások sebezhetőségének kiaknázásával és az operációs rendszerek más gyengeségeivel terjednek. Az állomásalapú tűzfalak megakadályozzák az ilyen rosszindulatú programok hozzáférését a kiszolgálókhoz. Megakadályozhatják a férgek és vírusok terjedését is a kiszolgálótól származó kimenő forgalom ellenőrzésével.
Back Doors és Trójai falovak
A Back door-ok (hátsó ajtó) és Trójai falovak lehetővé teszik a hekkerek távoli hozzáférését a hálózat kiszolgálóihoz. A program általában üzenetet küld a hekkernek, tudatva vele a behatolás sikerességét, majd lehetőséget ad a rendszerhez való hozzáféréséhez. Az állomásalapú tűzfal a kimenőforgalom korlátozásával megakadályozhatja a trójai faló üzenetküldését és a támadó bármely szolgáltatáshoz való kapcsolódását.

Az anti_X program telepítésével még átfogóbb biztonsági szint érhető el. Az anti_X segít a számítógép védelmében a vírusok, férgek, kémprogramok, rosszindulató programok, adathalászat és még a spam támadásokkal szemben is. Több internetszolgáltató nyújt anti_X programot a teljeskörű biztonsági szolgáltatásaik részeként. Nem minden anti-X szoftver véd meg ugyanazokkal a fenyegetésekkel szemben. Az ISP-nek állandóan szemmel kell tartania, hogy az anti-X szoftver valójában mely veszélyek ellen véd, és a veszélyek elemzése alapján kell javaslatokat tennie.
Számos anti_X programcsomag tesz lehetővé távoli felügyeletet, azaz tartalmaz megfigyelő rendszert, amely elektronikus levélben vagy személyi hívón figyelmezteti az adminisztrátort vagy műszaki szakembert az illetéktelen behatolásról. A megfelelő személy azonnali tájékoztatása jelentősen csökkenti a támadások következményeit. Anti_X használatával a rosszindulatú események száma nem csökkenthető, viszont a fertőzések kockázata igen.
Alkalmanként a fertőzések és támadások erősen romboló hatásúak lehetnek, ezért fontos az esetek felügyelete és a megfelelő megoldások nyomonkövetése a fertőzések újból való bekövetkezésének elkerülése érdekében. Az eseményfelügyelethez a felhasználók adait nyilván kell tartani, mert az internetszolgáltató az előfizetői felé kötelezi magát a védelem és az adatok sértetlenségének biztosítására. Például, ha egy hekker a támadásával hitelkártyaszámok százait lopta el a szolgáltató által felügyelt adatbázisból, értesítenie kell előfizetőit, hogy azok értesíthessék a kártyatulajdonosokat.

8.3 Az ISP megfigyelése és felügyelete
8.3.1 Szolgáltatói szerződés
Az intemetszolgáltató és az előfizető között rendszerint szolgáltatói szerződés (SLA - Service Level Agreement) jön létre, mely meghatározza a felek elvárásait és kötelességeit. Általában az alábbi részeket tartalmazza:
• Szolgáltatásleírás
• Költségek
• Megfigyelés és tájékoztatás
• Problémakezelés
• Biztonság (Security)
• Végződtetés
• Kártérítés szolgáltatáskimaradás esetén
• Rendelkezésre állás, teljesítmény és megbízhatóság
Az SLA fontos dokumentum, mely egyértelműen vázolja a hálózat felügyeletét, megfigyelését és fenntartását.
Rendelkezésre állás, teljesítmény és megbízhatóság
A szolgáltatás befejezése

8.3.2 A hálózati összeköttetések teljesítményének megfigyelése
Az intrenetszolgáltató köteles figyelemmel kísérni és ellenőrizni az eszközök közötti kapcsolatot. A felelősség magában foglalja az ISP-hez tartozó bármely berendezést, és a felhasználói oldalon lévő azon felszereléseket, amelyeknek az ISP az SLA-ban elvállalta a megfigyelését. A felügyelet és a beállítások történhetnek sávon kívül, közvetlen konzol kapcsolaton keresztül, vagy sávon belül, hálózati kapcsolaton keresztül.
A sávon kívüli felügyelet a kezdeti konfigurációnál hasznos, amikor az eszköz még nem érhető el hálózaton keresztül, vagy ha az eszköz helyszíni megtekintést igényel.
A legtöbb szolgáltatónak nem áll módjában fizikai kapcsolatot teremteni minden eszközzel vagy megtekinteni azokat. A sávon belüli felügyeleti eszközök könnyebb adminisztrációra adnak módot, mert a szakembernek nincs szüksége fizikai kapcsolatra. Emiatt azon felügyeleti kiszolgálók és hálózati eszközök számára, amelyek a hálózatról elérhetőek, a sávon belüli felügyeletet részesítik előnybe a sávon kívülivel szemben. Ráadásul a sávon belüli eszközök hagyományosan több felügyeleti funkciót tesznek lehetővé, mint amelyek a sávon kivüli felügyeletettel megvalósíthatók, például egy hálózati eszköz teljes vizsgálatára is mód van. Hagyományos sávon belüli felügyeleti protokollok a Telnet, SSH, HTTP, és az Egyszerű hálózatfelügyeleti protokoll (SNMP - Simple Network Management Protocol).
Számos, ezeket a felügyeleti protokollokat használó beágyazott, kereskedelmi és ingyenes eszköz érhető el, például a web böngésző a HTTP eléréséhez. Néhány alkalmazás, mint a Cisco SDM is, sávon belüli felügyeletre használja e protokollokat.
8.3.3 Eszközfelügyelet sávon belüli eszközökkel
Előfizetői oldalon történő új hálózati eszköz telepítését követően, egy távoli ISP helyről kell a berendezést figyelemme kisérni. Néha csak a kisebb beállítási változtatásokra van szükség a szakember fizikai jelenléte nélkül.
IP hálózatok esetén Telnet ügyfélprogrammal, sávon belül lehet az eszközhöz kapcsolódni a felügyeleti és adminisztrációs teendők elvégzése érdekében. A Telnet által használt kapcsolatot Virtuális treminál (VTY) kapcsolatnak hívják. A Telnet egy kiszolgáló/ügyfél protokoll. A kapcsolódó eszköz futtatja a Telnet ügyfélprogramot. Telnet ügyfélkapcsolat létesítéséhez a csatlakoztatott eszköznek vagy kiszolgálónak a Telnet démon nevű szolgáltatást kell futtatnia.
A legtöbb operációs rendszer tartalmaz alkalmazás rétegbeli Telnet ügyfélprogramot. A Microsoft Windowst használó számítógépeken a Telnet, parancssorból inditható. Más, közismert Telnet ügyfelet futtató terminál-emulátor alkalmazások, a HyperTerminal, Minicom, és TeraTerm. A hálózati
eszközök, mint például a forgalomirányítók, a Telnet-démon és a Telnet-ügyfélprogramot egyaránt támogatják,ezért akár ügyfélként, akár kiszolgálóként használhatók.
Egy Telnet kapcsolat felépülését követően a felhasználók bármilyen engedélyezett műveletet végrehajthatnak a kiszolgálón, úgy, mintha magán a kiszolgálón használnák a parancssort. Megfelelő jogosultság esetén a felhasználó elindíthat és leállíthat folyamatokat, konfigurálhatja az eszközt, vagy akár a rendszert is leállíthatja.
Telnet kapcsolatot a forgalomirányító parancssorából a telnet parancs és azt követően egy IP-cím vagy egy domain név segítségével lehet kezdeményezni, egyszerre akár több kiszolgálóval is. Cisco forgalomirányítón a Ctrl-Shift-6 X billentyűkombinációval lehet a Telnet kapcsolatok között választani. Ráadásul egy Telnet kiszolgáló képes egyszerre több ügyféllel kommunikálni. Egy kiszolgálóként működő forgalomirányítón a showsessions paranccsal megjeleníthetők az ügyfélkapcsolatok.
Bár a telnet a felhasználók hitelesítését támogatja, a hálózaton átküldött adatok titkosítását nem. A telnetkapcsolat teljes adatforgalma nyílt szövegként továbbítódik, az üzenetek a felhasználónévvel és jelszóval együtt könnyen lehallgathatók.
Amennyiben a biztonság is fontos szerepet játszik, a Secure Shell (SSH) protokoll teremt alternatív megoldást a kiszolgáló biztonságos eléréséhez. Az SSH biztonságos távoli bejelentkezést és más hálózati szolgáltatásokat nyújt, valamint a Telnetnél erősebb hitelesítési módszert és titkosított adatszállítást. A hálózati szakembereknek minden lehetséges esetben az SSH használata ajánlott Telnet helyett.
Az SSH kiszolgáló alkalmazásnak két változata létezik, a választás az eszközre betöltött Cisco IOS verziójától függ. Asztali gépenn futtatható SSH ügyfél esetén több különböző programcsomag érhető el. Az SSH ügyfélnek támogatnia kell a kiszolgálón konfigurált változatot.
8.3.4 SNMP és Syslog használata
Az SNMP hálózatfelügyeleti protokoll, amely a rendszergazda számára lehetővé teszi hálózati és más eszközökről az adatok összegyűjtését. Az SNMP felügyeleti rendszerprogram elérhető olyan eszközökből, mint a CiscoWorks, melynek ingyenes változata letölthető az internetről. Az SNMP felügyeleti ügynök programokat gyakran a kiszolgálók, forgalomirányítók és kapcsolók operációs rendszerébe ágyazzák be.
Az SNMP négy fő összetevőből áll:
• Felügyeleti állomás - A rendszergazda által, a hálózat megfigyelésre és konfigurálására használt állomás, melyen SNMP felügyeleti alkalmazás fut.
• Felügyeleti ügynök (Management agent) - Az SNMP által felügyelt eszközön telepített program.
• Felügyeleti információs adatbázis (MIB - Management Information Base) - Adatbázis, amelyet az eszközök maguk vezetnek a hálózati teljesítmény paramétereiről.
• Hálózatfelügyeleti protokoll - A felügyeleti állomás és az ügynökök között használt kommunikációs protokoll.
A felügyelő állomás futtatja a rendszergazda által a hálózati eszközök konfigurálására használt SNMP alkalmazást. Itt tárolódnak az adatok ezekről az eszközökről. A felügyeleti állomás az eszközök lekérdezésével gyűjti az adatokat. Lekérdezés akkor következik be, amikor a felügyelő állomás meghatározott információkat kér egy ügynöktől.
Az ügynök tájéloztatást ad, válaszolva a lekérdezésre. Amikor a felügyelő állomás lekérdez egy ügynököt, az ügynök előveszi a MIB-ben összegyűjtött statisztikát.
Az SNMP ügynökök nem csak lekérdezhetők, trap-nek nevezett önálló riasztóüzenet elküldésére is konfigurálhatók. A trap egy eseményvezérelt jelzés. Bizonyos területeken az ügynökökön egy küszöb-vagy maximumértéket konfigurálnak, amely például egy meghatározott porton áthaladó adatforgalom mennyiségére vonatkozik. Ha a forgalom mennyisége a küszöböt eléri, az ügynök riasztóüzenetet küld a felügyelő állomásnak. A riasztóüzenetek megkímélik a felügyelő állomásokat a hálózati eszközök folyamatos lekérdezésétől.
A felügyelő állomások és a felügyelt eszközök hitelesítése egy közösségi azonosítónak nevezett karakterlánc alapján történik. Az SNMP ügynök és az SNMP állomás közösségi karakterláncának meg kell egyeznie. Amikor az ügynök egy lekérdezés vagy egy riasztóüzenetet generáló esemény hatására információt küld a felügyelő állomásnak, mindketten először a karakterláncot egyeztetik.
A hálózat megfigyelésének fontos része a device log (eszköz napló) tárolása és rendszeres időközönkénti felülvizsgálata. A Syslog a rendszeresemények naplózására kidolgozott szabvány. Az SNMP-hez hasonlóan egy alkalmazás-rétegbeli protokoll, amely lehetővé teszi az eszközök információküldését a felügyeleti állomáson telepített és futtatott syslog démon számára.
A Syslog rendszer egy kiszolgálóból és egy ügyfélből áll. Az előbbiek fogadják és feldolgozzák az ügyfelek naplózási üzeneteit, az utóbbiak az eszközök megfigyelését végzik, amiről tájékoztatják a Syslog kiszolgálót.
A naplózási üzenetek általában egy azonosítóból, az üzenet típusából, az elküldés időpontját jelölő időbélyegből (dátum, idő) és az üzenet szövegéből állnak. A küldő hálózati eszköztől függően, a felsoroltaknál több elemet is tartalmazhatnak. 
8.4 Biztonsági mentések és katasztrófahelyzet helyreállítás
8.4.1 Archiválási hordozók
A hálózatfelügyeleti és megfigyelési programok segítenek az internetszolgáltatóknak és a vállalatoknak azonosítani és kijavítani a hálózatban előforduló problémákat. A olyan hálózati hibák helyreállításában szintén fontos szerepük van, mint a kártékony és rosszindulatú tevékenység, elromlott eszközök, vagy hibás működés okozta problémák.
A hiba okától függetlenül a felhasználók weboldalait és leveleit tároló ISP kötelessége biztosítani az adatvesztés elleni védelmet. A weboldalakon tárolt adatok elvesztése utáni helyreállítás több száz, vagy akár több ezer órát is igénybe vehet, nem beszélve a tartalom elvesztése és újratöltése közti üzleti forgalom kieséséről.
Az ISP levelező kiszolgálóján tárolt üzenetek adatainak elvesztése a vállalatok számára kritikus lehet. Némely vállalkozás számára törvény írja elő a levelezések adatainak megtartását, minek következtében azok megsemmisülése megengedhetetlen.
Az adatok mentése elengedhetetlen. Egy informatikai szakember munkaköréhez tartozik az adatvesztés kockázatának csökkentése, és egy esetleges helyreállítási eljárás megtervezése.
Hardver meghibásodás
Felhasználói hiba
Adatlopás
Rosszindulatú tevékenység
Operációs rendszer meghibásodás 
Amikor az ISP-nek adatai mentésére vagy archiválására van szüksége, a lehetőségek költségének és hatékonyságának egyensúlyban kell lennie. Az archiválási hordozók kiválasztása a számos befolyásoló tényező következtében összetett feladat.
Néhány tényező az alábbi lehet:
• Adat mennyisége
• Tárolóhely költsége
• Tárolóhely teljesítménye
• Tárolóhely megbízhatósága
• A külső tárolás egyszerűsége
Többféle archiválási hordozó létezik, például szalagok, optikai lemezek és félvezető alapú háttértárak.
A szalag máig a legközismertebb külső tárolók egyike, nagy kapacitású, és máig a piac leginkább költséghatékony tárolója. Ha az adatmennyiség meghaladja egyetlen szalag tárolóképességét, a mentési folyamat alatt az automatikus betöltők és könyvtárak cserélgethetik a szalagokat, lehetővé téve annyi adat eltárolását, amennyire szükség van. Az automatikus betöltők és könyvtárak igen költségesek lehetnek, amivel a kis- és középvállalatok általában nem is rendelkeznek, mindamellett nagyobb adatmennyiség esetén, lehetséges, hogy nincs más választásuk.
A szalag hibaérzékenysége nagy, a vezérlőeszközt rendszeresen tisztítani kell a hibátlan működés érdekében. Könnyen elkopik, ezért csak meghatározott ideig használható. A szalagoknak különböző fajtái léteznek: 

Merevlemezek
A merevlemez alapú mentési rendszerek egyre közkedveltebbé válnak alacsony költségük és nagy tárolási kapacitásuk következtében. Mindamellett a merevlemezek másik helyen történő tárolása nehézkes. A hatalmas lemeztömbök, mint a közvetlenül csatlakoztatott tároló (DAS - direct attached storage), hálózathoz kapcsolt tároló (NAS - network attached storage) és a tároló hálózatok (SAN - storage area network) nem hordozhatók.
A merevlemez alapú mentési rendszerek különböző megvalósításai a szalagos mentési rendszerekkel együttműködnek a külső helyen történő tárolásban. Többszintű biztonsági mentés esetén a merevlemezes és a szalagos lehetőségek egyaránt gyors helyreállítási időt tesznek lehetővé a merevlemezen helyileg elérhető adatok és a hosszútávú archiválási megoldások kombinálásával.
Félvezető alapú tároló rendszerek
A félvezető alapú tároló rendszerekközé sorolandó az összes nemfelejtő tárolóeszköz, amelyben nincsenek mozgó részek. A pédák széles skálája az 1 GB tárolására képes, kicsi postai bélyeg méretű eszköztől az 1000 GB (1 TB) adat tárolására képes forgalomirányítónak megfelelő méretű eszközökig terjed.
Az adatok gyors tárolási és visszakereshetőségi igénye esetén kitűnő. A félvezető alapú tároló rendszerek alkalmazásai közé sorolhatók az adatbázisgyorsítók, a HD videó letöltők és szerkesztők, az informaciószolgáltatók és a tárolóhálózatok (Storage Area Network- SAN) A nagy tejesítményű, félvezető alapú tároló rendszerek kirívóan drágák lehetnek, de a technikai fejlődés természetéből fakadóan az árak folyamatosan csökkennek.

8.4.2 Az allomanymentes módszerei
Az archiválási közeg kiválasztása után a mentési módszer kiválasztása következik.
Normál
A normál vagy teljes biztonsági mentés során az összes kijelölt állományról másolat készül, teljes egészében. Utána mindegyik állomány kap egy "másolva" jelet. Normál mentések esetén elegendő mindig a legutolsó mentést megtartani, ami meggyorsítja és egyszerűsíti a helyreállítási folyamatot. Mindamellett, mivel mindig a teljes adatállomány mentésére kerül, ez a legidőigényesebb mentési módszer.

Különbségi
A különbségi mentés esetén, mindig csak a legutolsó teljes mentés óta keletkezett vagy változott állományokról készül másolat. Ennél a módszernél a mentési ciklus első napján teljes mentés szükséges, azt követően pedig mindig csak az ahhoz képest történt változásoké, egészen a ciklus végét jelentő legközelebbi teljes mentésig. Ezáltal a folyamat kevesebb időt vesz igénybe. Az adatok helyreállításához az utolsó teljes és az utolsó különbségi mentés szükséges.
Növekményes
A növekményes mentés egyetlen lényeges pontban tér el a különbségitől. Amíg a különbségi mentés során az utolsó teljes mentés után történt változásokról készül másolat, addig a növekményes esetben az utolsó növekményes mentés óta bekövetkezett változásokat kell elmenteni. Ha minden nap növekményes mentési eljárás történik, az archiválási közegen mindig csak az aznapi változások tárolódnak. A növekményes mentési módszer a leggyorsabb, viszont a helyreállítási folyamata a legidőigényesebb, mivel az utolsó normál és az utána következő összes növekményes mentés szükséges hozzá.

A mentési rendszerek a helyes működés érdekében rendszeres karbantartást igényelnek. Léteznek a mentések sikerességét segítő eljárások:
• Az adathordozók cseréje - számos mentési módszer igényli az adathordozók napi cseréjét, az elmentett adatok előzményeinek fenntartására. Ha a szalagot vagy lemezt nem cserélik napi rendszerességgel, adatvesztés léphet fel. Mivel a szalagok cseréje kézzel végezhető feladat, ki van téve a hiba bekövetkezésének. A felhasználónak szükségük van egy feljegyzési módszerre, mint a naptár vagy határidőnapló.
• A mentési naplózások áttekintése - Jóformán az összes mentésre szolgáló program létrehoz naplózási állományokat. Ezek az állományok tájékoztatnak a művelet sikerességéről, vagy meghatározzák a hiba helyét. A mentési naplózások rendszeres felügyelete lehetővé teszi bármely olyan mentési probléma gyors azonosítását, amely megköveteli a figyelmet.
• Helyreállítási folyamatok kipróbálása - Mégha a naplók szerint a mentés sikeres is volt, felmerülhetnek a naplókban nem jelzett, más problémák. Az adatok rendszeres próbahelyreállításával ellenőrizhető az elmentett adatok használhatósága és a mentési eljárás megfelelő működése.
• Az eszközvezérlő karbantartása - Sok archiválási rendszer speciális hardvereket igényel az eljárás végrehajtásához. A szalagos mentési rendszer a szalag olvasásához és írásához mágnesszalagos egységet használ, amely a használat során piszkolódik, és később mechanikai hibához vezethet. Ezért megfelelő tisztító szalagok segítségével rendszeres tisztítást kell rajta végezni. A merevlemez alapú archiváló rendszereken alkalmanként töredezettség-mentesítés ajánlott a teljesítmény növelése érdekében.
8.4.3 Cisco IOS mentése és helyreállítása
Az ISP számára a kiszolgálók állományainak mentésén túl a hálózati eszközeiken használt, az ISP tulajdonában lévő Cisco IOS és konfigurációs állományok védelmét is biztosítania kell. Ezekről az állományokról is készülhet másolat egy hálózati TFTP kiszolgálón a megfelelő copy parancs segítségével. Az IOS és a konfigurációs állományok mentése hasonló parancsal történik.
A Cisco IOS kód biztonsági mentése három alapvető lépésből áll:
1. lépés: A ping parancs segítségével az állomány tárolására szolgáló TFTP kiszolgálóval fenntartott kapcsolat ellenőrzése.
2. lépés: A forgalomirányító flash memóriájában tárolt IOS kód ellenőrzése. Az állomány nevének és méretének megtekintése a show flash parancs használatával. Fontos megbizonyosodni a kiszolgálón található szabad hely megfelelő méretéről.
3. lépés: Az IOS rendszerkód TFTP kiszolgálóra történő másolása az alábbi parancs segítségével. Router# copy flash tftp
A copy parancs alkalmazásánál a forgalomirányító kéri a felhasználótól a forrás állománynevet, a TFTP kiszolgáló IP-címét és a cél állománynevet.
A TFTP kiszolgálón tárolt rendszerkód állományok segítségével a hálózat forgalomirányítóinak és kapcsolóinak Cisco IOS szoftvere helyreállítható vagy frissíthető.
A forgalomirányítók IOS rendszerkód frissítésének és a rendszerkód TFTP szerverre való mentésének a lépései hasonlóak. Használja a show flash parancsot a flashben lévő bájtok számának megállapítására, és bizonyosodjék meg arról, hogy az IOS számára van elegendő szabad hely, mielőtt elkezdi a frissítést vagy a visszaállítást.
A Cisco IOS frissítésére a következő parancs szolgál:
copy tftp: flash:
Frissítés során a forgalomirányító kéri a felhasználótól a TFTP kiszolgáló IP-címét, majd a kiszolgálóról letölteni kívánt rendszerkód nevét. Ha nincs elegendő hely mind a régi, mind az új kód tárolására, a forgalomirányító kérheti a felhasználót a flash törlésére. A kód flash memóriából történő eltávolítása alatt a folyamatot jelző "e" betűk sora jelenik meg. A letöltés befejeztével az ellenőrzésre is sor kerül, és ezzel a hálózati eszköz kész az újraindulásra az új Cisco IOS rendszerkóddal.
Ha az IOS kód elveszett és helyre kell állítani, egy külön eljárás szükséges ROMmon mód használatával.
Rltcopy flash: tftp:
Source filename []? cl841-ipbase-mz.l23-14.T7.bin
Address or name of remote hőst []? 192.168.20.254 Destination filename [cl841-ipbase-mz.l23-14.T7.bin]? <CR> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!<output omitted>
13832032 bytes copied in 113.061 secs (122341 bytes/sec)
RÍ#
Ha a beállítások alapján a forgalomirányító flashből indul, de onnan a Cisco IOS rendszerkódot kitörölték, megsérült vagy helyhiány következtében nem elérhető, azt helyre kell állítani. Ennek leggyorsabb módja a TFTP használata ROM monitor (ROMmon) módból.
A ROMmon TFTP átvitel egy meghatározott LAN interfészen keresztül történik, amely alapértelmezésben az első elérhető LAN interfész. A művelet végrehajtásához a felhasználónak először be kell állítania néhány környezeti változót, beleértve az IP-címet, majd a tftpdnld parancs segítségével helyreállítani a képfájlt.


A ROMmon környezeti változóinak beállításához be kell gépelni a változó nevét, majd az egyenlőség (=) jelet, és végül a változó értékét. Például az IP-cím 10.0.0.1-re történő beállításához be kell gépelni az IP_ADDRESS=10.0.0.1. parancsot.
A szükséges környezeti változók a következők:
• IP_ADDRESS - a LAN interfész IP-címe
• IP_SUBNET_MASK - a LAN interfész alhálózati maszkja
• DEFAULT_GATEWAY - a LAN interfész alapértelmezett átjárója
• TFTP_SERVER - a TFTP kiszolgáló IP-címe
• TFTP_FILE - a Cisco IOS állományneve a kiszolgálón
A set parancs használatával a ROMmon környezeti változói megnézhetők és ellenőrizhetők.
A változók beállítása után a tftpdnld parancsot kell használni. Az Cisco IOS állomány összes adatcsomagjának megérkezése után egy felkiáltó jel (!) jelenik meg. Amint az IOS másolata elkészül, a Flash memória meglévő tartalma kitörlődik, melybe nem csak az aktuális IOS fájl, hanem az összes itt tárolt állomány is beletartozik. Ezért ezek megóvása és szükség esetén helyreállítása érdekében a másolatok TFTP kiszolgálón történő ideiglenes tárolása elengedhetetlen.
A ROMmon parancssorának (rommon1>) megjelenésekor a forgalomirányító a reset parancs, vagy az i begépelésével újraindítható. A forgalomirányító most a flash memóriában tárolt új Cisco IOS rendszerkód alapján fog indulni.
romínon 1> IP_ADDRESS=192.168.1.2 rommon2> IP_SUBNET_MASK=255.255.255.0 rommon3> DEFAULT_GATEWAY=192.168.1.1 rommon4> TFTP_SERVER=192.168.1.1
rommon5> TFTP_FILE=cl841-ipbase-mz.123-14.T7.bin
romínon 7 > tftpdnld
:P ADDKKS3: 192.168.1.2 IP_SÜBNET_MASK: 2 55.2 5 5   255 .Jj DEFA0IiT_GATEWAY; 192.1:6 8.. 1.1 TFTP_SÉRVÉR: 192.168.1.1
TFTP_FILE: cl8 41-ipbase-mz.123-14.T7.bin Invoke this command fór diaaater reeovery only.
WARNING: all existing data in all partitions on flash will be lost!
Do you wish tO continue? y/n: [n]:
Do you wish to continue? y/n: [ni: y <CR>
Receiving cl841-ipbase-mz.l23-14.T7.bin from 192.168.1.1 1 ! ! ! ! I ! ! ! (output omitted) !!!!!!!
Fiié reception completed.
Copying fiié cl841-ipbase-mz.l23-14.T7.bin to flash.
Erasing flash at Qx607c0000 program flash location 0x605a0000
8.4.4 Katasztrófa-helyreállítási terv
A katasztrófahelyzet helyreállítási tervének fontos része az adatok biztonsági mentése. A katasztrófahelyzet helyreállítási terv egy mindent átfogó dokumentum a gyors tárolási folyamatokról, és a vállalat katasztrófa alatti és utáni folyamatos működésének fenntartási feltételeiről. Célja a
vállalat katasztrófa okozta fizikai és szociális változásokhoz történő alkalmazkodásának biztosítása. Katasztrófa lehet, a hálózat szerkezetét érintő természeti csapásoktól kezdve a hálózatot ért rosszindulatú támadásokig, bármi.
A katasztrófahelyzet-helyreállítási terv információkat tartalmazhat más telephelyekről, ahova a szolgáltatások áttehetők, a hálózati eszközök és kiszolgálók kikapcsolásáról, valamint a tartalék csatlakozási lehetőségekről. A terv elkészítése során elengedhetetlen a működés fenntartásához szükséges kritikus szolgáltatások teljes megértése. Katasztrófahelyzet esetén is elérhetőnek kell lennie az alábbi szolgáltatásoknak:
• Adatbázisok
• Alkalmazáskiszolgálók
• Rendszerfelügyeleti kiszolgálók
• Web
• Adattárolók
• Címtár

A katasztrófahelyzet-helyreállítási terv készítésénél fontos megérteni a szervezet igényeit és elnyerni a támogatását. Sok lépés kell egy hatékony helyreállítási terv elkészítéséhez. •
mértékű katasztrófa esetén is fontos, hogy mindenki tisztában legyen a feladataival és kötelezettségeivel.
• Elsőbbségi sorrend felállítása - Prioritást kell rendelni minden, a vállalat hálózatát, alkalmazásait és rendszereit érintő lehetséges katasztrófahelyzethez, úgymint kritikus, fontos vagy kevésbé fontos.
A tervhez először a vezetőséget kell megnyerni, majd végül mindenkit, aki a kritikus vállalati folyamatokban dolgozik. A siker érdekében mindenkinek részt kell vennie benne, és támogatnia kell a tervet.
A vállalkozás számára legfontosabb alkalmazások és szolgáltatások meghatározását követően, a gyűjtött információk alapján el kell készíteni a katasztrófahelyzet-helyreállítási tervet. Öt fő lépés szükséges a terv megvalósításához:
1. lépés - HálózathelyreáNító stratégia
A hálózat tervének elemzése. A hálózat tervénél figyelembe vett katasztrófahelyreállítási szempontok a következők:
• Vajon a tervezett hálózat túlélne-e egy nagyobb katasztrófát? Léteznek-e tartalék kapcsolatok és redundanciák a hálózatban?
• Azok a nem helyszínen tárolt kiszolgálók, melyek olyan alkalmazásokat támogatnak, mint a levelezés vagy adatbázis-kezelés, elérhetők maradnak-e?
• Megszakadna-e a tartalék forgalomirányítók, kapcsolók és más hálózati eszközök elérhetősége?
• A hálózat számára szükséges erőforrások és szolgáltatások elhelyezkedése nagy földrajzi területre terjed-e ki?
2. lépés - Leltár és dokumentáció
Leltár készítése az összes helyről, az összes eszközről, gyártóról, a felhasznált szolgáltatásokról és a kapcsolatok neveiről! A kockázatfelmérési lépésben megbecsült költség ellenőrzése.
3. lépés - Ellenőrzés
Olyan tesztfolyamat létrehozása, melynek segítségével ellenőrizhatő a katasztrófahelyreállítási stratégia működőképessége. Bevált katasztrófahelyzet-helyreállítási gyakorlat a terv korszerűségének és hatékonyságának biztosítására.
4. fázis - Jóváhagyás és megvalósítás
A felsővezetők jóváhagyásának elnyerése, és a terv megvalósítási költségvetésének elkészítése.
5. fázis - Felülvizsgálat
A katasztrófahelyreállítási tervezet megvalósítását követő első évben a terv felülvizsgálata. 
8.5 A fejezet összefoglalása
• Előfizetők számára elérhető asztali szolgáltatások: biztonságos jelszó, biztonsági alkalmazások javításokkal és frissítésekkel, a nem használt alkalmazások eltávolítása, biztonsági vizsgálatok végzése és a megfelelő hozzáférési jogosultságok beállítása.
• Állományok és könyvtárak jogosultságainak beállításakor a "lehető legkevesebb előjog elve" alapján érhető el a legjobb biztonság.
• Hitelesítés, Jogosultságellenőrzés és Azonosítás (AAA) egy három lépéses eljárás a hálózati hozzáférések figyelemmel kisérésére és ellenőrzésére. Adatbázis alkalmazásával tartja nyilván a felhasználói jelszavakat, jogosultságokat és azonosító statisztikákat.
■ A digitális titkosítás a kiszolgálók és ügyfelek közötti forgalom titkosítását teszi lehetővé. Számos protokollnak létezik biztonságos változata.
• Legjobb minden esetben a protokoll biztonságos változatát használni, valahányszor bizalmas adatokat kell továbbítani hálózaton keresztül.
• Számos biztonsági fenyegetés létezik, mint DoS, DDoS és DRDoS támadások.
■ A portszűrés és hozzáférési listák használata védelmet nyújt az ilyen veszélyek ellen.
■ A portszűrés alkalmazásával TCP és UDP port alapján a forgalom korlátozható vagy átengedhető.
• A hozzáférési listákkal IP-címek, vagy akár UDP és TCP portok alapján definiálható a tiltott vagy az engedélyezett forgalom.
• A tűzfal olyan hálózati hardver vagy szoftver, amely meghatározza melyik forgalom jöhet be vagy távozhat a hálózat bizonyos részeiből.
• Az IDS a hálózati forgalmat passzívan figyelő szoftver- vagy hardveralapú megoldás. Nem akadályozza meg a kezdeti támadó forgalom hálózaton történő áthaladását és a cél elérését.
• Az IPS aktív fizikai eszköz vagy szoftver. A forgalom ténylegesen áthalad az IPS interfészeken és az IPS képes valós időben blokkolni az összes gyanús forgalmat.   
• A szolgáltatói szerződés (SLA) az internetszolgáltató és a fehasználó között létrejött szerződés, mely világosan dokumentálja a felek elvárásait és kötelességeit.
■ Az ISP-k figyelemmel kísérik és ellenőrzik az eszközök közötti kapcsolatot. Ezt sávon belüli és sávon kívüli kezeléssel hajtják végre. Sávon belüli felügyelet kedvezőbb a hálózaton keresztül elérhető kiszolgálók elérése esetén.
• Biztonsági mentések elvégzésére több megoldás kínálkozik, például szalag, optikai lemez vagy félvezető alapú tároló.
• Három módszer létezik az adatok mentésére: teljes mentés, különbségi mentés és növekményes mentés. Általában a három módszer kombinált használata ajánlott.
• A katasztrófahelyzet-helyreállítási terv egy mindent átfogó dokumentum a gyors helyreállítási folyamatokról és egy vállalat katasztrófa alatti és utáni folyamatos működését lehetővé tevő feltételekről.
• Elkészítéséhez a sebezhetőségek és kockázatok felbecsülése, vezetői tudatosság, tervezési csoport felállítása és a prioritások meghatározása szükséges.

9. Hibaelhárítás
9.1 Hibaelhárítási módszerek és eszközök
A hálózati szakemberek egyik legfontosabb képessége a hálózati problémák megoldásának képessége. A jó problémamegoldó képességgel rendelkező hálózati szakemberek mindig keresettek. Éppen ezért a Cisco képesítések vizsgái a hálózati hibák felismerésére és megoldására helyezik a hangsúlyt.
A hálózati hibaelhárítás során a szakemberek általában az OSI referenciamodell vagy a TCP/IP hálózati modell segítségével határolják be a hiba lehetséges okát. A logikai hálózati modellek rétegekre bontják a hálózati működést. Az OSI és a TCP/IP modell rétegei jól meghatározott feladatokat látnak el adott protokollokkal. A hibaelhárítás során nagyban megkönnyíti a szakember munkáját, ha tisztában van az egyes rétegek feladataival, jellemzőivel, az azokhoz tartozó eszközökkel, illetve az adott réteg többi réteghez való viszonyával.
A fejezet során az OSI és a TCP/IP modell mentén épül fel a hálózati hibaelhárítás szerkezete. A fejezet elkezdése előtt érdemes átismételni a CCNA Discovery: Otthoni és kisvállalati hálózatok és CCNA Discovery: Hálózati feladatok kis- és középvállalatoknál vagy internetszolgáltatóknál tananyag OSI és TCP/IP modellre vonatkozó részeit!
Az OSI referenciamodell mint hibaelhárítási segédeszköz
Az OSI referenciamodell a hálózati technikusok és fejlesztőmérnökök közös nyelve. Fontos megérteni az OSI modell egyes rétegeiben felmerülő feladatokat, és megismerni e feladatok végrehajtását szolgáló hálózati eszközöket.
Az OSI modell felsőbb (5-7) rétegei jellemzően speciális alkalmazási funkciót látnak el, többnyire szoftveresen valósítják meg őket. A problémák gyökere általában az ügyfél vagy a kiszolgálói oldalon futó végfelhasználói szoftverek beállításaiban keresendő.
Az OSI modell alsóbb (1-4) rétegei elsősorban az adattovábbítási kérdésekért felelősek.
A 3. (hálózati) és 4. (szállítási) réteget általában teljesen szoftveresen valósítják meg. Egyúttal a végrendszerek szoftveres hibáit, és a forgalomirányítók és tűzfalak konfigurációs hibáit tartják felelősnek e két rétegben előforduló problémák töbségéért. Az IP-címzési és a forgalomirányítási hibák a 3. rétegre jellemzőek.
Az 1. (fizikai) és a 2. (adatkapcsolati) réteg szoftveres és hardveres összetevőkből épül fel. A fizikai réteg az átviteli közeghez (mint például a kábelezés) áll legközelebb, és ez a réteg a felelős az adatok átviteli közegre juttatásáért. Az 1. és a 2. rétegben előforduló hibák zöméért hardveres vagy kompatibilitási problémák okolhatók.
9.1.2 Hibaelhárítási módszerek
A hálózati modellekkel végzett munka során három fő hibaelhárítási megközelítés alkalmazható:
• Fentről lefelé
• Alulról felfelé
• Oszd meg és uralkodj
Mindhárom megközelítés alapja a hálózati működés rétegekre bontása. Elsődleges céljuk, hogy a hibaelhárítást végző személy könnyen tudja az egyes rétegek működési funkcióit ellenőrizni, illetve a hibát egy adott rétegre behatárolni.
Fentről lefelé - Az alkalmazási réteggel kezd és rétegenként halad lefelé. A problémát a felhasználó és az alkalmazás szemszögéből nézi. Csak egy alkalmazás nem működik vagy egyik sem? A felhasználó például eléri a különböző weblapokat az interneten, de az elektronikus levelezést nem? A többi állomáson is tapasztalhatók hasonló problémák?
Alulról felfelé - A fizikai réteggel kezd és rétegenként halad felfelé. A fizikai réteg a kábelezésre és a fizikai összetevőkre koncentrál. Nem lazult meg egyik kábel sem? Amennyiben vannak kijelző fények az eszközön, azok világítanak vagy sem?
Oszd meg és uralkodj - Valamelyik közbülső réteggel kezd és onnan halad rétegenként felfelé vagy lefelé. A hibaelhárítást végző szakember kezdheti például az IP-címzési beállítások ellenőrzésével.
Ezek a hibaelhárítási módszerek tökéletesek lehetnek kezdő hibaelhárító személyeknek. A tapasztaltabbak gyakran mellőzik ezeket a strukturált módszereket és ösztöneikben, illetve tapasztalataikban bíznak.

9.1.3 Hibaelhárítási eszközök
A hálózati kapcsolatok hibaelhárítását nagyban megnehezíti, ha nem áll rendelkezésre az IP-címeket, útvonalakat és eszközöket (tűzfalak, kapcsolók) pontosan feltüntető hálózati rajz. A hibaelhárítás során felbecsülhetetlen értéket képviselnek a pontos fizikai és logikai topológiarajzok.
Fizikai topológiák
A fizikai topológia mutatja meg a hálózatba kötött eszközök tényleges, fizikai kapcsolódásait, melyek ismerete nélkülözhetetlen a fizikai réteg hibáinak - például a kábelezési és hardveres hibák - feltárása során. A rajz általában az alábbi részleteket tartalmazza:   
Logikai topológiák
A logikai topológia mutatja meg, hogyan áramlanak az adatok a hálózatban. Az egyes hálózati eszközök (forgalomirányítók, kiszolgálók, hubok, állomások és biztonsági berendezések) külön jelölést kapnak. A rajz általában az alábbi részleteket tartalmazza:
• Eszköz azonosító
• IP-cím és alhálózati maszk
• Interfész azonosító
• Irányító protokollok
• Statikus és alapértelmezett útvonalak
• Adatkapcsolati rétegbeli protokollok
• WAN-technológiák
A hálózati diagram mellett számos további eszköz segítheti a hatékony hibaelhárítást a hálózati teljesítmény javítása és a rendszerhibák feltárása során.
Hálózati dokumentációs és alapszint-ellenőrző eszközök
Ilyen eszközök szép számban állnak rendelkezésre Windows, Linux és UNIX operációs rendszerekhez is. A CiscoWorks nevű szoftver kiválóan alkalmas a hálózati diagramok megrajzolására, a szoftver- és hardverdokumentáció naprakészen tartására, valamint a jellemző hálózati sávszélességigény költséghatékony felmérésére. A hálózati működés alapszintjének meghatározásához ezek a szoftverek általában monitorozó és jelentéskészítő eszközöket biztosítanak.
Hálózatfelügyeleti rendszereszközök
A hálózatfelügyeleti rendszereszközök (NMS - Network Management System tools) elsődleges feladata a hálózat teljesítményének követése. A hálózati eszközök fizikai elrendezését jelenítik meg grafikusan. Meghibásodás esetén ezekkel az eszközökkel meghatározható a hiba forrása, továbbá kideríthető, hogy rosszindulatú program, betörési kísérlet vagy egy eszköz meghibásodása okozta a hibát. A gyakran használt hálózatfelügyeleti eszközök közé tartozik a CiscoView, a HP Openview, a SolarWinds és WhatUp Gold.
Tudásbázis
Mára az egyes gyártók által gondozott tudásbázisok nélkülözhetetlen információforrásokká nőtték ki magukat. Az on-line tudásbázisok internetes keresőkkel történő kombinálása hatalmas mennyiségű tapasztalati alapokon nyugvó ismeret hozzáférését teszik lehetővé.
Protokollelemzők
A protokollelemzők a kereteket képesek hálózati rétegekre tagoltan dekódolni és viszonylag könnyen értelmezhető alakban megjeleníteni, és ezáltal a hálózati forgalmat további elemzés céljából rögzíteni. Az így rögzített kimenet különböző igények és kritériumok szerint szűrhető: megjeleníthető például csak egy adott eszközről indított és annak címzett forgalom. A Wireshark és a hasonló protokollelemző alkalmazások a hálózaton forgalmazott adatokról nyújtanak részletes hibaelhárítási információt. Jó példa a protokollelemzőkkel feltárható információra a két állomás között zajló TCP viszony felépítése és lezárása.
Kábelteszterek
A kábelteszterek olyan kisméretű célműszerek, melyeket különböző kommunikációs kábelek ellenőrzésére terveztek. Alkalmazásukkal feltárhatók a törött kábelek, a hibás bekötések, a rövidzárlatok és a felcserélt kábelek. A fejlettebb eszközök, mint például a TDR kábelteszter (time¬domain reflectometer - időtartományi reflektométer) képesek a kábelben a szakadás helyét is meghatározni. Kábelteszterrel meghatározható a kábel hossza is. 
Digitális multiméterek
A digitális multiméterek olyan mérőműszerek, melyekkel közvetlenül mérhetünk bizonyos elektromos jellemzőket: feszültséget, áramerősséget és ellenállást. A hálózati hibaelhárításban a multiméter elsősorban az egyes áramforrások feszültségszintjeinek és az adott hálózati készülékek áramellátásának ellenőrzésekor hasznos.
Hordozható hálózatanalizátorok
A hálózat tetszőleges pontján egy hálózatanalizátor kapcsolóhoz csatlakoztatásával rögtön láthatóvá válik az adott szegmens átlagos és csúcskihasználtsága. Analizátorral az is könnyen kideríthető, hogy melyik eszköz generálja a legnagyobb hálózati forgalmat, de elemezhető vele a forgalom is protokollok szerint, vagy akár részletesen vizsgálhatók az egyes interfészek. A hálózatanalizátorok különösen jól használhatók rosszindulatú programok, vagy szolgáltatásmegtagadási támadás okozta problémák felderítésekor.
9.2. 1. és 2. rétegbeli problémák hibaelhárítása
A fizikai és az adatkapcsolati réteg hardveres és szoftveres megvalósításokat is tartalmaz. Minden hálózati kommunikáció ebben a két rétegben alkalmazott technológiákon nyugszik. Éppen ezért roppant fontos, hogy a hálózati szakember gyorsan felismerje és javítani tudja az itt előforduló hibákat.
A fizikai réteg felelős az egyik állomásról a másik állomásra küldött bitek fizikai és elektromos jellemzőinek a definiálásáért függetlenül attól, hogy vezetékes vagy vezeték nélküli átviteli közeget alkalmaznak. Az 1. rétegben előforduló hibák a kapcsolat elvesztésével, vagy - egyszerűbb esetben - teljesítménycsökkenéssel járhatnak.
Az 1. rétegben előforduló hibák szorosan kapcsolódnak az alkalmazott technológiához. Az Ethernet például többszörös hozzáférésű technológia. Az Ethernet protokollban alkalmazott algoritmus alapja, hogy az egyes állomások érzékelik, hogy szabad-e a csatorna mielőtt adni kezdenek. Ennek ellenére előfordul, hogy két állomás ugyanabban az időpillanatban kezd adni, ezzel ütközés keletkezik. Minden ütközésnél az összes érintett eszköz abbahagyja a továbbítást, és véletlen ideig vár az újrakezdés előtt. Mivel az Ethernet észleli az ütközést és képes reagálni rá, ezért gyakran Vivőjel- figyeléses többszörös hozzáférésű ütközésérzékeléses (CSMA/CD - Carrier Sense Multiple Access with Collision Detection) technológiának nevezik.
Ugyanakkor a túl gyakori ütközések erősen ronthatják a hálózat teljesítményét. Osztott közegen, amilyen a hubokkal kialakított hálózat, az ütközések sokkal komolyabb problémát jelentenek, mint a kapcsolt hálózatokban.
7. Alkalmazási
6. Megjelenítési
5. Viszony
2. Adatkapcsolati 
Küszöbérték alatti átvitel
Magas ütközésszám
Túlzott CPU igénybevétel
Az adatkapcsolati réteg (azaz a 2. réteg) definiálja az adott közegen történő továbbításra előkészített adatok formátumát. Ebben a rétegben kerül szabályozásra a közeghozzáférés is. A 2. réteg teremti meg a kapcsolatot a hálózati réteg szoftveres megvalósítása és az 1. réteg hardveres LAN és WAN technológiái között. Az 1. és 2. rétegben előforduló hibák hatékony kezeléséhez elengedhetetlen a kábelezési szabványok, a beágyazási folyamat és a keretformátumok ismerete.
Az 1. réteg működőképességének ellenőrzése után meg kell állapítani, hogy a hiba a 2. rétegben jelentkezik-e, vagy valamelyik felsőbb rétegben. Például, ha az állomás meg tudja pingelni a visszacsatolási hurok címét (127.0.0.1), de nem éri el a hálózati szolgáltatásokat, akkor a hiba jó eséllyel a 2. rétegbeli keretezésben, vagy a hálózati csatoló hibás beállításában keresendő. A hálózati analizátorok és más, hasonló on-line eszközök segítségével behatárolható a 2. rétegbeli hiba helye. Egyes esetekben az eszközök felismerhetik a 2. rétegben jelentkező hibát, melyről akár hibaüzenetet is küldhetnek a konzolra. 
A hálózat a küszöbérték alatti szinten működik
9.2.2 Hardware-s eszközhibák és rendszerindítási problémák hibaelhárítása
A hálózati problémák gyakran egy eszköz újraindítását követően jelentkeznek. A rendszer újraindítása lehet szándékos (például egy eszközfrissítést követően), vagy váratlan (például áramkimaradás után). A hardveres eszközhibák és a rendszerindítási problémák kezelése megköveteli a Cisco IOS rendszerindítási folyamatának ismeretét. A rendszerindítási folyamat három szakaszból áll:
1. Az önellenőrzés (POST) és a rendszerbetöltő program (bootstrap) futtatása.
2. A Cisco IOS megkeresése és betöltése.
3. Az indítási konfigurációkat tartalmazó állomány megkeresése és betöltése, vagy beállítási módba váltás.
Tetszőleges Cisco hálózati eszköz elindításakor hasznos a rendszerindítás során megjelenő konzolüzenetek tanulmányozása. A Cisco IOS betöltődése után néhány paranccsal ellenőrizhető, hogy a hardver- és szoftverösszetevők valóban megfelelően működnek-e.
A show version parancs kimenetéből megállapítható a használatban levő operációs rendszer verziószáma, valamint megtudható, hogy a rendszer rendben felismerte-e a hardver interfészeket.
A show flash parancs a flash memória tartalmát listázza ki, beleértve az Cisco IOS fájlnevét is. A kimenetéből megállapítható a használatban levő és a szabad flash memória mérete.
A show ip interfaces brief parancs kimenetében az egyes fizikai interfészek állapota és a hozzájuk rendelt IP-címek láthatók.
A show running-configuration és a show startup-configuration parancsok kimenetéből megállapítható, hogy minden utasítást felismert-e a rendszer az indítási folyamat során.
Amikor egy eszköz nem indul el megfelelően, és ezzel hálózatleállást okoz, az eszközt ki kell cserélni egy ellenőrzötten működőképes készülékre a szolgáltatás helyreállítása érdekében. A szolgáltatás helyreállítását követően elegendő időt kell szánni a meghibásodott eszköz diagnosztizálására és javítására.
Ha a forgalomirányító rendben elindult, kigyulladnak a zöld jelzőfények. Ha hibát észlelnek a rendszerindítási folyamat során, a Cisco eszközök alapértelmezett műveletek segítségével (például ROMmon módba lépve) megpróbálnak helyreállni. A következőkben 5 gyakori rendszerindítási hiba hibaelhárítási stratégiáját tárgyaljuk meg.
Az eszköz nem jut át az önellenőrzésen
Ha az önellenőrzés sikertelen, nem jelennek meg üzenetek a konzolképernyőn. Az eszköz típusától függően a rendszer LED vagy villog, vagy más színre vált. A kijelző fények jelentése az eszköz leírásában megtalálható. Ha az önellenőrzés sikertelen, az eszközt ki kell kapcsolni, a hálózati áramforrásból ki kell húzni és el kell távolítani az összes interfészmodult. Ezek után az eszköz újraindítható. Ha az önellenőrzés még mindig sikertelen, az eszköz javításra szorul. Ha az interfészmodulok nélkül sikeres lesz az önellenőrzés, akkor valószínűsíthető, hogy az egyik modul okozta a hibát. Áramtalanítás után egyenként vissza kell szerelni az interfészmodulokat, és újraindítani a rendszert, hogy a hibás modul kiszűrhető legyen. A hibás modult egy ellenőrzötten működőképes modulra ki kell cserélni, majd újra kell indítani a készüléket.
Sérült Cisco IOS rendszerkód a flash memóriában
Ha a flash memóriában tárolt rendszerkód megsérült, vagy hiányzik, a rendszerindító program nem talál érvényes, betölthető operációs rendszert. Egyes Cisco eszközökön van egy korlátozott képességű operációs rendszer is, melyet az eszköz betölt, ha nem talál operációs rendszert a flash memóriában vagy más meghatározott helyen. Ezt a limitált rendszerkódot nevezzük betöltéssegítőnek (Boothelper). A betöltéssegítők sokszor nem rendelkeznek olyan szolgáltatáskészlettel, hogy sikeresen lehessen konfigurációs parancsokat futtatni, és ezáltal helyreállítani az eszköz helyes működését. Betöltéssegítő hiányában az eszköz általában ROMmon módba lép. A ROMmon mód parancsaival TFTP kiszolgálóról betölthető egy működőképes Cisco IOS fájl.
A rendszer nem ismeri fel a memóriát, vagy memóriahibát jelez
Előfordulhat, hogy nem áll rendelkezésre kellő méretű memória az operációs rendszer kicsomagolásához és betöltéséhez. Ilyenkor hibaüzenetek peregnek a konzolképernyőn, vagy a rendszer folyton újraindul. Lehet, hogy ROMmon módban elindítható ilyenkor is az eszköz. Ehhez a CTRL+Break billentyűkombinációt kell leütni rendszerindítás közben. ROMmon módban, a megfelelő parancs használatával megállapítható a memória állapota. A rendes működés helyreállításához elképzelhető, hogy ki kell cserélni, vagy ki kell bővíteni a memóriát.
A rendszer nem ismeri fel az interfészmodulokat
A hibás vagy helytelenül telepített interfészmodulokat a rendszer nem ismeri fel az önellenőrzés vagy az IOS betöltése során. Ilyenkor a show version parancs kimenetében listázott és használható interfészek nem egyeznek meg a fizikailag telepített interfészekkel. Új interfészmodulokat mindig ellenőrizni kell, hogy a készüléken futó IOS támogatja-e, illetve van-e elég memória a működéséhez. A hardver hiba biztonságos felismeréséhez a készülék áramtalanítása és a tápcsatlakozó kihúzása után az interfészmodult újra be kell szerelni a készülékbe. Ha újratelepítés után sem ismeri fel a rendszer a modult, ki kell cserélni egy ellenőrzötten jól működőre.
Hibás vagy hiányzó konfigurációs állomány
Egyes Cisco készülékek beépített automatikus telepítési segédprogramot futtatnak, ha nem találnak érvényes konfigurációs állományt. Ez a segédprogram szórásos TFTP kérést küld ki, hogy konfigurációs állományt szerezzen. Más eszközök azonnal a kezdeti konfigurációs párbeszédbe lépnek, amit beállítási segédprogramnak vagy beállítási módnak is nevezünk. Az automatikus telepítési segédprogramot futtató készülékek is beállítási módba lépnek, ha 5 kérés után egyetlen TFTP kiszolgáló sem válaszol. A konfiguráció betöltése vagy létrehozása érdekében TFTP vagy kézi beállítás is alkalmazható. Az eszközök nem továbbítanak hálózati forgalmat, amíg helyes konfigurációhoz nem jutottak.

9.2.3 Kábelezési és interfészproblémák hibaelhárítása
A forgalomirányító interfész hibák gyakran az első tünetei az 1. és 2. rétegbeli kábelezési és kapcsolati hibáknak. A hibakeresést érdemes az adott interfész show interfaces parancs kimenetén található statisztikáinak az áttekintésével, valamint a show ip interface brief parancs kimenetén látható állapot információk ellenőrzésével kezdeni!
A show ip interface brief parancs kimenete tömör összefoglalást tartalmaz az összes interfészről, beleértve az interfészek állapotát és hozzárendelt IP-címét is.
• up/up állapot - a normál működést jelzi, mind a közeg, mind a 2. rétegbeli protokoll üzemképes.
• down/down állapot - kapcsolati vagy átviteli közeg problémára utal.
• up/down állapot - azt jelzi, hogy az átviteli közeg megfelelően csatlakozik, de a 2. rétegbeli protokoll nem működik megfelelően, beállítási hibák lehetnek.
Down/down állapothoz vezető gyakori kábelezési vagy átviteli közeg hibák:
• Meglazult vagy megfeszülő kábel - akár egyetlen érintkező rossz csatlakozása az áramkör megszakadását okozhatja.
• Hibás végződtetés - ellenőrizni kell az érintkezők szabvány szerinti bekötését, és hogy az érintkezők helyesen vannak-e végződtetve a csatlakozóban.
• Sérült soros interfészcsatlakozó - a csatlakozó egyes érintkezői elgörbültek, vagy hiányoznak.
• Szakadás vagy rövidzár a vezetékben - ha hibák lépnek fel az áramkörben, az interfész nem érzékel megfelelő jeleket.
Up/down állapothoz vezető gyakori 2. rétegbeli problémák:
• Helytelen beágyazási beállítások.
• Az adott interfészen nem érkeznek ébrenléti jelek.


Időnként az átviteli közeg hibái nem vezetnek az áramkör leállásához, hanem a csak hálózati teljesítmény csökkenését okozzák. A show interfaces parancs további információkkal szolgál, melyek segítenek az átviteli közeget érintő problémák azonosításában.
A show interfaces parancs kimenetében megtalálható:
• Erős zaj - Ethernet és soros interfészen érzékelhető sok CRC hiba és kevés ütközés erős zajra utal. A CRC hibák általában az átviteli közeg vagy a kábelezés hibájára utalnak. Jellemző hibák: elektromos interferencia, meglazult vagy sérült kapcsolatok, nem megfelelő kábeltípus alkalmazása.
• Sok ütközés - az ütközések a fél-duplex kommunikációra és az osztott közegre jellemzőek. A sérült kábelek az ütközések számának megnövekedéséhez vezethetnek.
• Sok túl kicsi (runt) keret - a túl kicsi keretek számának megemelkedését általában egy hibásan működő hálózati kártya okozza, de előidézheti a sok ütközéshez vezető állapot is.
• Késői ütközés - a helyesen megtervezett és kialakított hálózatokban soha nem fordulhat elő késői ütközés. Leggyakoribb előidézői a túl hosszú kábelek. A téves duplex egyeztetés is okozhat késői ütközést.


9.2.4 LAN kapcsolati hibák elhárítása
A LAN hibaelhárítása szorosan kötődik a kapcsolók világához, mivel a LAN felhasználók többsége egy kapcsolóporton keresztül éri el a hálózatot. A Cisco kapcsolókon a hibaelhárítás során az eddig megismert show parancsok többsége használható információgyűjtésre. Ezen kívül minden egyes kapcsolóport saját LED kijelzővel rendelkezik, mely hasznos információt nyújt a hibakereséshez.
A LAN kapcsolati hibák elhárításának első lépése annak ellenőrzése, hogy a felhasználó csatlakozását biztosító kapcsolóport működik-e, és hogy a LED kijelzők világítanak-e. Ha a kapcsoló fizikailag hozzáférhető, akkor a legidőhatékonyabb megoldás rápillantani a LED kijelzőre, amiből kiderül, hogy
van-e kapcsolat (zöld fény), vagy hiba van (vörös vagy narancs fény). Az összeköttetés mindkét végén ellenőrizni kell a kapcsolat meglétét.
Ha a kapcsolatjelző nem világít, meg kell győződni a kábel helyes csatlakozásáról az összeköttetés mindkét végén, és hogy a kábel a megfelelő porthoz csatlakozik-e. Továbbá ellenőrizni kell, hogy mindkét eszköz be van-e kapcsolva, és hogy a rendszerindítási folyamat hiba nélkül befejeződött-e. A lengőkábeleket ki kell cserélni ellenőrzötten jó kábelekre, és ellenőrizni kell a csatlakozók bekötését a kívánt kapcsolattípusnak megfelelően. Ha a kapcsolatjelző fény továbbra sem gyullad ki, ellenőrzni kell, hogy a port nincs-e adminisztratív módon kikapcsolva. A portok beállításainak megtekintéséhez a show running-config interface parancs használható.
Switch# sh run interface fastEthernet 4/2
!
interface fastEthernet 4/2
shutdown
duplex full
speed 100
end


A világító kapcsolatjelző nem feltétlenül jelenti a kábel tökéletes működését. A kábel lehet sérült, ami időszakos teljesítményproblémákat okozhat. Az ilyen esetek általában feltárhatók a Cisco IOS show parancsaival: a kimenetekben nagy számú csomaghibát, és folyamatosan le-, illetve felkapcsolódó interfészeket érdemes keresni.
A kapcsolón kiadott show version és show interfaces parancsok kimenete hasonló információt szolgáltat a forgalomirányítón kiadott parancsokéhoz. A show interface portazonosító counter errors paranccsal egy adott interfész hibastatisztikái gyorsan megjeleníthetők.
A hibás duplexbeállítás sokkal jellemzőbb a kapcsolókra, mint a forgalomirányítókra. Sok eszköz automatikusan egyezteti a sebesség- és duplexbeállításokat. Könnyen ellentmondó beállításhoz, és így csomagvesztéshez és ütközéshez vezethet, ha a kapcsolat egyik végén automatikus egyeztetést, míg a másik végén kézi beállítást alkalmaznak. 
A show interface portazonosító status parancs segítségével megjeleníthető, hogy milyen duplex- és sebességbeállítások (kézi, vagy automatikus, illetve milyen konkrét érték) vannak érvényben egy adott porton.
Ha az egyeztetési hiba olyan Cisco eszközökön jelentkezik, melyeken a Cisco Discovery Protocol (CDP) engedélyezve van, mindkét eszköz konzolképernyőjén vagy a naplófájlokban hibaüzenetek jelennek meg. A CDP hasznos segítség a szomdszédos Cisco eszközök hibáinak, port- és rendszerstatisztikáinak ellenőrzéséhez.
A duplex egyeztetési hibák kijavításának legegyszerűbb módja, mindkét eszköz automatikus egyeztetésre állítása. Ha az automatikus beállítás nem hozná meg a várt eredményt, akkor kézzel kell beállítani az egyező sebesség és duplex értékeket.
Duplexitási problémára utaló hibaüzenet.
Switch# sh interfaces fas 6/1 status
Port Name Status Vlan Duplex Speed Type
FaG/1 notconnect 1 auto auto 10/100BaseTX
Show parancs klmenete, amely azt mutatja, hogy a duplexltás és a sebesség beállítása automatikus egyeztetéssel történik.


9.2.5 WAN kapcsolati hibák elhárítása
A soros WAN kapcsolatok hibaelhárítása eltér az Ethernet LAN kapcsolatokétól. A WAN kapcsolat jellemzően távközlési szolgáltató (TSP - telecommunications service provider) birtokában levő készülékek és az átviteli közeg működésétől függ. Ezért lényeges, hogy a technikus jártas legyen a felhasználói végberendezések hibaelhárításában, és az eredményeket érthetően tudja kommunikálni a szolgáltató felé.
A soros interfészek és vonali problémák többségének felismeréséhez és megoldásához elegendő a show interfaces serial parancs kimenetéből nyerhető információ. A soros összeköttetésekre általában csomaghibák, beállítási hibák, beágyazási eltérések vagy rossz időzítések jellemzők. Mivel a soros WAN összeköttetések az időzítési információt rendszerint CSU/DSU készülékektől vagy modemektől kapják, a soros vonalak hibaelhárításakor ezeket az eszközöket is érdemes számításba venni. Prototípus hálózatokban a forgalomirányítón beállítható a DCE órajel-szolgáltatás, ekkor nincs szükség CSU vagy modem használatára.
A hatékony WAN kapcsolati hibaelhárításhoz ismerni kell az alkalmazott CSU/DSU eszköz vagy modem típusát, és a visszahurkolási mód beállításának módját a teszteléshez. 
Kábelmodem
A show interfaces serial parancs kimenetén a soros vonal állapotát jelző sor hat különböző állapotot mutathat:
Serial x is down, line protocol is down (DTE mode) - amikor a forgalomirányító soros interfésze nem érzékel semmiféle jelet a vonalon, akkor mind a vonalat, mind a 2. rétegbeli protokollt leálltnak tekinti.
1. lépés: Ellenőrizze, hogy a LED-ek a
CSU/DSU-n aktlvak-e!
2. lépés: Ellenőrizze, hogy a megfelelő kábelt
és a megfelelő Interfészt használja-e!
3. lépés: Vegye fel a kapcsolatot a bérelt vonali
- vagy egyéb szolgáltatóval, és érdeklődjön, tudnak-e a hibáról!
4. lépés: Cserélje ki az Interfész modult egy
ellenőrzötten hibátlan példányra!
5. lépés: Helyettesítse a CSU/DSU-t egy
ellenőrzötten hibátlan eszközzel.
Serial x is up, line protocol is down (DTE mode) - amennyiben a soros interfészre nem érkeznek ébrenléti jelek, vagy beágyazási hiba van, akkor a 2. rétegbeli protokollt tekinti leálltnak.


Serial x is up, line protocol is down (DCE mode) - az olyan esetekben, amikor a forgalomirányító szolgáltatná az órajelet, és az interfészhez DCE kábel csatlakozik, de nincs beállítva órajel, akkor a 2. rétegbeli protokollt leálltnak tekinti.


Serial xis up, line protocol is up (looped) - bevett gyakorlat, hogy a kapcsolat teszteléséhez visszacsatolási állapotba helyezik az áramkört. Amikor a soros interfész saját jelét kapja vissza az áramkörben, akkor hurkoltnak jelzi a vonalat.


Serial x is up, line protocol is down (disabled) - a magas hibaarány arra készteti a forgalomirányítót, hogy az adott vonalat "protokoll üzemen kívül" állapotba helyezze. Az ilyen hiba általában hardveres hibára vezethető vissza.
í Lehetséges probléma: A hiba megkeresése:
• Távközlési szolgáltatói 1, lépés: Lépjen kapcsolatba a távközlési
probléma okozta magas szolgáltatóval!
hibaarányt. 2, lépés: Kösse hurok módba a CSU/DSU
• CSU/DSU hardver egységet (DTE hurok)! Ha a probléma
probléma. továbbra is fennáll, valószínűleg
■ Rossz a hardver hibával állunk szemben. Ha a
forgalomirányító probléma nem áll fenn, valószínűleg a
hardver. távközlési szolgáltató hibjával állunk szemben.
3. lépés: Szükség szerint cserélje ki a hibás hardvereszközöket (CSU, DSU, kapcsoló, helyi vagy távoli forgalomirányító)!


Serial x is administratively down, line protocol is down - egy interfész akkor van adminisztratív lezárt állapotban, ha a konfigurációjában szerepel a shutdown utasítás. A hiba kijavításához rendszerint csak az szükséges, hogy interfészkonfigurációs módban kiadjuk a no shutdown parancsot. Ha az interfész nem kapcsol fel a no shutdown parancs hatására, ellenőrizzük a konzolon, hogy nem jelent¬e meg duplikált IP-címre utaló hibaüzenet. Duplikált IP-cím esetén ki kell javítani a hibát, majd újra ki kell adni a no shutdown parancsot.


Serial x is up, line protocol is up - az interfész az elvárásoknak megfelelően működik.
9.3 3. rétegbeli működés és IP-címzés - ismétlés
1. rétegbeli hálózat akkor jön létre, ha hálózati eszközöket pusztán fizikai átviteli közeggel kapcsolnak össze. A 2. rétegbeli protokollok hardverfüggőek. Az Ethernet nem képes soros vonalon üzemelni, ahogy soros kommunikáció sem létesíthető Ethernet hálózati kártyával.
A 3. rétegben (azaz a hálózati rétegben) működő protokollok nem kötődnek egy adott átviteli közeghez, sem a 2. rétegbeli keretformátumokhoz. Ugyanaz a 3. rétegbeli protokoll működhet Ethernet, vezeték nélküli, soros vagy bármi más 2. rétegbeli megvalósítás fölött is. Egyazon 3. rétegbeli hálózat állomásait többféle 1. és 2. rétegbeli technológia is összekötheti. Az OSI modell 3. rétegének elsődleges feladata a hálózati címzés és a forgalomirányítás megvalósítása. A 3. rétegbeli hálózatokat logikai hálózatoknak nevezzük, mivel megvalósításuk tisztán szoftver segítségével történik.
A mai hálózatok többsége a TCP/IP protokollkészlet megvalósításával oldja meg az állomások közti információcserét. Éppen ezért a 3. réteg hibaelhárítása főleg az IP-címzési problémákra és az irányítóprotokollokra koncentrál.
A 3. rétegbeli hibaelhárításhoz nélkülözhetetlen az IP-címzés és a hálózatok határainak alapos megértése. A hálózati teljesítményproblémák zöme rosszul megtervezett és kialakított IP-címzési sémákra vezethető vissza.


A 3. rétegben minden csomagnak hordoznia kell a forrás- és a célrendszer címét. Az IPv4 rendszer 3. rétegbeli fejrésze tartalmazza a forrás és a cél 32-bites címét.
Az IP-cím az egyedi állomásazonosítás mellett az állomás 3. rétegű hálózatát is azonosítja, amelyen kommunikálhat. Egy egyszerű IP-hálózat kialakításához elegendő, ha közvetlenül összekapcsolunk két állomást, melyekhez ugyanabból az alhálózatból rendelünk IP-címet, és azonos alhálózati maszkot adunk.
Az állomások csak akkor képesek egymással TCP/IP alapon üzeneteket váltani, ha rendelkeznek IP- címmel. A különálló 3. rétegbeli IP-hálózatok lényegében IP-címtartományokat jelentenek. A hálózatok határait a cím hálózati előtagját alkotó bitek száma határozza meg. Az ökölszabály egyszerű: minél hosszabb a hálózati előtag a címben, annál kevesebb egyedi címet lehet állomásoknak kiosztani az adott IP-hálózatban.
A 3. rétegbeli problémák megoldásához elengedhetetlen, hogy a rendszergazda meg tudja határozni azt az állomás címtartományt, amely egy adott IP-hálózathoz tartozik. A címtartomány az állomáscímet alkotó bitek számától és pozíciójától függ. Tegyük fel például, hogy a 192.168.1.0/24 hálózatban 3 bitet kölcsönveszünk alhálózatok kialakítására. Így 5 bit marad az állomáscímzésre. 8 alhálózatot kapunk (2A3=8), mindegyikben 30 állomással (2A5 - 2 = 30).
Tekintsük a 192.168.1.96/27 hálózatot, melyben az első kiosztható állomáscím a 192.168.1.97 lesz, míg az utolsó a 192.168.1.126. Az alhálózat szórási címe a 192.168.1.127. Mindez leolvasható az utolsó oktett bináris alakjából:
(011 az alhálózat) 96 + (00001 az első állomáscím) 1 = (01100001), ami decimálisan 97 (011 az alhálózat) 96 + (11110 az utolsó állomáscím) 30 = (01111110), ami decimálisan 126
(011 az alhálózat) 96 + (11111 szórás) 31 = (01111111), ami decimálisan 127
Ez egy C osztályú címet használó példa. Ugyanez a technika alkalmazható az A és a B osztályú címek esetében is. Nem szabad elfelejteni, hogy az állomásazonosító bitek átnyúlhatnak az oktetthatáron.


[ Alhálózat Hálózatéira Álfamáscfm-tartománv Üzenetszórási cím ]

0 192.16B.1.0/27 192.168.1.1 - 192.168.1.30 192.168.1.31
1 192.1S8,1.32/27 192,168.1,33 - 192,168.1.62 192.168.1.63
2 192.1SB.1.64/27 192.168.1.65 - 192.168.1.94 192.168.1.95
3 192.16B.1.96/27 192.168.1.97 - 192.168.1.126 192.168.1.127
4 192.16B.1.128/27 192.168.1.129 - 192.168.1.158 192,168.1.159
5 192.168.1.160/27 192.168.1.161 - 192.168.1.190 192.168.1.191
6 192.168.1.192/27 192.168.1.193 - 192,168.1,222 192.168.1.223
7 192.16B.1.224/27 192.168.1.225 - 192.168.1.254 192,168.1.255


9.3.2 IP-címtér megtervezésének és beállításának kérdései
Az IP-címtér meggondolatlan kiosztása azt eredményezheti, hogy nehézkessé válik a forrás- és a célállomás helyének meghatározása. Manapság a legtöbb hálózat hierarchikus IP-címkiosztást alkalmaz. A hierarchikus IP-címzési séma számos előnyt hordoz, beleértve a kisebb irányítótáblákat és az ezzel járó kisebb számításigényt is. A hierarchikus IP-címzés egyúttal jobban strukturált környezetet teremt, amelyben a dokumentálás, a hibaelhárítás és a bővítés is könnyebben elvégezhető.
Ugyanakkor a hanyagul megtervezett hierarchikus hálózat, vagy egy rosszul dokumentált terv olyan veszélyeket rejt magában, mint az átfedő alhálózatok kialakulása, vagy a helytelenül beállított alhálózati maszkok az eszközökben. Ebből a két típushibából számos IP-címzéssel és irányítással kapcsolatos probléma származhat.
Akkor beszélünk átlapolódó alhálózatokról, ha egyes IP-címek vagy szórási címek két különálló alhálózatnak is a tagjai. Az átlapolódás oka általában a rossz tervezés, vagy a véletlenül hibásan megadott alhálózati maszk, illetve hálózati előtag. Az átlapolódó címzés nem minden esetben vezet hálózatleálláshoz. A hibásan beállított alhálózati maszk helyétől függően többnyire csak néhány állomást érint a probléma.


A Cisco IOS megengedi, hogy átlapolódó alhálózatokból rendeljünk IP-címeket a forgalomirányító két különböző interfészéhez, ilyenkor azonban nem aktiválja a második interfészt.
Például rendeljünk IP-címet és alhálózati maszkot az R1 nevű forgalomirányító FastEthernet 0/0 interfészéhez a 192.168.1.0/24 hálózatból! Ezek után, ha a FastEthernet 0/1 interfészhez a 192.168.1.0/30 hálózatból próbálunk meg IP-címet rendelni, hibaüzenet fog tájékoztatni az átlapolódó beállításokról. Ha megpróbáljuk felkapcsolni az interfészt a no shutdown paranccsal, újabb hibaüzenetet kapunk. Ezen az interfészen a forgalomirányító nem továbbít csomagokat. A show ip interface brief parancs kimenetéből is látható, hogy a másodikként a 192.168.1.0/24 hálózatba konfigurált FastEthernet 0/1 interfész leállított állapotban van.
Mindig fontos az interfészek állapotának ellenőrzése a beállításaik megváltoztatása után. Ha egy interfész adminisztratív lezárt állapotban marad a no shutdown parancs kiadása után, az többnyire IP- címzési problémára utal.


Ugyan a Cisco IOS szoftver rendelkezik beépített védelemmel az egy azon készülék különböző interfészein beállított átlapolódó IP-címek kivédésére, nem tudja megakadályozni a különböző készülékeken, illetve az állomásokon beállított átlapolódásokat.
Egyetlen rosszul beállított alhálózati maszk is okozhat néhány állomáson hálózatelérési nehézségeket. A rosszul beállított alhálózati maszkok különféle tüneteket mutathatnak, amelyek olykor nehezen azonosíthatók.

Egyes állomások el tudják érni az internet és más alhálózatok kiszolgálóit is, más állomások azonban nem.

9.3.2 IP-címtér megtervezésének és kiosztásának kérdései
A rosszul megtervezett IP-címkiosztás további bonyodalmakhoz vezethet. A rendszergazdák gyakran alábecsülik a lehetséges növekedést az alhálózatok tervezésekor. Ennek az a következménye, hogy az IP-alhálózati terv nem teszi lehetővé elegendő állomás címzését minden alhálózatban. Túl sok állomás jelenlétére utal az alhálózatban, ha egyes állomások nem kapnak IP-címet a DHCP kiszolgálótól.
Amikor egy Microsoft Windows operációs rendszert futtató számítógép nem kap IP-címet a DHCP kiszolgálótól, automatikusan választ magának egyet a 169.254.0.0 hálózatból. A tünet jelentkezésekor ellenőrizni kell a show ip dhcp binding paranccsal, hogy van-e szabad, kiosztható cím a DHCP kiszolgálón.
A túl kevés IP-cím másik jellemző tünete a duplikált IP-címre utaló hibaüzenet az állomáson. Ha a DHCP bérleti ideje akkor jár le, amikor az azt birtokló állomás ki van kapcsolva, akkor a cím visszakerül a kiosztható címek készletébe, így kioszthatóvá válik egy másik számítógép számára. Amikor a cím eredeti bérlőjét újra bekapcsolják, az először megpróbálja megújítani a korábbi IP címét. Ebben az időpillanatban mindkét Microsoft Windows rendszert futtató állomás hibaüzenetet jelenít meg a duplikált címek miatt.
RÍ#show ip dhcp binding
Bindings from all pools nőt associated with VRF:
IP address Client-ID/ Lease expiration
Hardware address/
User name
192,168,10,10 01QQ.eQ18.5bdd,35 Oct 03 2007 06:14 PM
192 * 168.10*11 0100,bQd0*d817,e6 Oct 03 2007 06:18 PM
9.3.4 DHCP és NAT problémák
A DHCP további bonyodalmakat okozhat a hibaelhárítás során. Ha egy DHCP használatára beállított állomás nem tud kapcsolódni a hálózathoz, a Windows ipconfig /all parancsával ellenőrizni kell, hogy kapott-e IP-címet. Ha nem kapott, valószínűleg a DHCP kiszolgálón kell keresni a hibát.
Függetlenül attól, hogy a DHCP szolgáltatás egy dedikált kiszolgálón, vagy a forgalomirányítón fut, a hibaelhárítás első lépése a fizikai kapcsolat ellenőrzése. Ha a szolgáltatás külön kiszolgálón fut, elsőként ellenőrizni kell, hogy a kiszolgáló fogad-e hálózati forgalomat. Ha a szolgáltatás a forgalomirányítón fut, a show interfaces paranccsal ellenőrizhető az interfész működése. A leállított állapotban levő interfészek nem továbbítanak semmilyen hálózati forgalmat, így DHCP kérésekre sem válaszolnak.
Következő lépés a DHCP kiszolgáló beállításainak ellenőrzése, különösen, hogy van-e elegendő kiosztható IP-címe. Ezek után a címütközések vizsgálat következik. Címütközés akkor is előfordulhat, ha van elegendő cím a DHCP címkészletben. Címütközés keletkezhet például, ha egy állomáson olyan cím van statikusan beállítva, mely szerepel a DHCP kiosztható címei közt is.
A show ip dhcp conflict paranccsal kilistáztatható az összes olyan címütközés, melyet a DHCP kiszolgáló regisztrált. Címütközés esetén az érintett cím kikerül a kiosztható címek halmazából, és mindaddig vissza sem kerül, amíg a rendszergazda fel nem oldja az ütközést. 
Ha mindezek nem oldották meg a problémát, érdemes megvizsgálni, hogy valóban a DHCP szolgáltatásban van-e a hiba! Állítsunk be statikus IP-címet, alhálózati maszkot és az alapértelmezett átjárót az állomáson. Ha az állomás nem fér hozzá a hálózat erőforrásaihoz, akkor minden bizonnyal nem a DHCP szolgáltatás felelős a hibáért. Ezen a ponton a hálózati kapcsolat hibaelhárítására van szükség.


A DHCP alapvetően üzenetszórást alkalmazó protokoll, ami azt jelenti, hogy a DHCP kiszolgálónak elérhetőnek kell lennie szórásos üzenetekkel. Tekintve, hogy a forgalomirányítók általában nem továbbítják a szórásos forgalmat, a DHCP kiszolgálónak vagy az állomással megegyező helyi hálózaton kell lennie, vagy a forgalomirányítón be kell állítani a szórásos üzenetek továbbítását.
A forgalomirányítók az ip helper-address parancs segítségével konfigurálhatók a szórásos üzenetek, így a DHCP kérések továbbküldésére is egy meghatározott kiszolgálóra. A parancs hatására a forgalomirányító egyedi címekre cseréli a szórásos célcímeket a csomagban:
Router(config-if)# ip helper-address x.x.x.x
A parancs kiadása után az összes szórásos üzenet (köztük a DHCP kérések is) a parancsban megadott IP-címmel rendelkező kiszolgálóhoz kerülnek.
Amikor a forgalomirányító továbbküldi a címkéréseket, DHCP közvetítő ügynökként működik. A DHCP közvetítő szolgáltatás nélkül az állomások nem jutnának IP-címhez. Amikor egyik állomás sem kap IP- címet a másik hálózaton található DHCP kiszolgálótól, ellenőrizni kell az ip helper-address beállítás helyességét a forgalomirányítón.

192.168.10.10/24 192.168.11.10/24 192.168.11.5/24
C:\WIND0WS\system32\cnid.eKe
C:\Documents and Settings\Administrator>ipconfig /release
Windows IP konfiguráció
Ethernet-adapter Helyi kapcsolat:
Kapcsolatspecifikus DNS utótag, :
IP-cim : 0.0.0.0
Alhálózat! maszk : 0.0.0.0
Alapértelmezett átjáró :
C:\Documents and Settings\Administrator>ipconfig /renew Windows IP konfiguráció
Egy hiba keletkezett az interfész helyi hálózati kapcsolatának megújítása során: nem jött létre kapcsolat a DHCP kiszolgálóval. A kérésre nem érkezett
válasz határidn belül.
RÍ# config t
Rl (config)# interface FaO/0
RÍ(config-if)# ip helper-address 192.168.11.5
Rl(config-if)4 end
192.168.10.2 /24ylTM.I» 192.168 11.2 /24 Fa0/2 Fa0/2| \ FaO/24
192.168.10.10/24 192.168.11.10/24 192.168.11.5/24
cC C:\WIND0WS\system32\cfndexe
C:\Documents and Settings\Administrator>ipconfig /release
Windows IP konfiguráció
Ethernet-adapter Helyi kapcsolat:
Kapcsolatspecifikus DNS utótag :
IP-cim : 0.0.0.0
Alhálózat! maszk : 0.0.0.0
Alapértelmezett átjáró :
C:\Documents and Settings\Administrator>ipconfig /renew
Windows IP konfiguráció
Ethernet-adapter Helyi kapcsolat:
Kapcsolatspecifikus DNS utótag :
IP-cim: 192.168.10.11
Alhálózati maszk: .... 255.255.255.0
<atíintson a gombokra a DHCP továbbítás működésének megismeréséhez!
Ha a belső hálózat állomásai privát címmel rendelkeznek, az állomások csak NAT segítségével tudnak kommunikálni a nyilvános hálózattal. A NAT problémák legjellemzőbb tünete, hogy az állomások nem érik el az internetes oldalakat. Háromféle címfordítást különböztetünk meg: statikus, dinamikus és PAT (port address translation - port alapú címfordítás) A két legjellemzőbb beállítási hiba mindhárom fajtát érinti.
A belső és külső interfészek hibás kijelölése
A NAT működése szempontjából alapvető fontosságú, hogy a megfelelő interfészek legyenek belső és külső interfészként kijelölve. A legtöbb NAT megvalósításban a belső interfész kapcsolódik a privát címteret használó helyi hálózathoz. A külső interfész kapcsolódik a nyilvános hálózathoz, ami rendszerint egy internetszolgáltató hálózata. Ezek a beállítások a show running-config interface paranccsal ellenőrizhetők.
Helytelen IP-címbeállítás az interfészen vagy rossz NAT címtartomány
A legtöbb NAT megvalósításban a NAT címtartománynak és a statikus címfordításnak ugyanabból a tartományból származó IP-címeket kell használnia, mint amibe a külső interfész IP-címe esik. Ellenkező esetben a címfordítás megtörténik, de a rendszer nem talál útvonalat a lefordított címhez. Az összes lefordított cím elérhetőségét ellenőrizni kell. Amikor a címfordítás a külső interfész címét használja PAT esetén, ellenőrizni kell, hogy az interfész címe a megfelelő hálózathoz tartozik, és helyes alhálózati maszkkal rendelkezik.
További problémát jelenthet, ha dinamikus NAT vagy PAT használata esetén a külső felhasználók nem érik el a belső erőforrásokat. Ha külső felhasználóknak el kell érniük bizonyos kiszolgálókat a belső hálózaton, akkor ezekhez statikus fordítást kell alkalmazni. 


A NAT működésének ellenőrzését akkor is el kell végezni, ha a NAT beállítások helyessége bizonyos.
A NAT működés ellenőrzésében az egyik leghasznosabb parancs a show ip nat translations. Az érvényben levő fordítások megtekintése után a lista a clear ip nat translation * paranccsal törölhető. Megjegyzendő, hogy az érvényben levő IP címfordítások törlése fennakadásokat okozhat a felhasználói szolgáltatásokban. A törlést követően újból alkalmazni kell a show ip nat translations parancsot! Ha új címfordítások jelennek meg a listában, elképzelhető, hogy valami más hiba miatt nem érhető el az internet.
Ebben az esetben ellenőrizni kell, hogy van-e érvényes útvonalbejegyzés az internet felé a lefordított címekhez! A traceroute paranccsal megjeleníthető a lefordított csomagok útvonala. Ellenőrizni kell az útvonal helyességét. Ha van rá mód, ellenőrizni kell az útvonalat az egyik lefordított címre egy külső hálózaton található távoli számítógépről. Ez segíthet kiválasztani azt az eszközt, amely a hibát okozhatja. Elképzelhető, hogy forgalomirányítási probléma van azon a forgalomirányítón, ahol az útvonalkövetés elakadt.

 
R2#show ip nat translations
Pro Inside global Inside local
top 209.165.200.225:16642 192.168.10.10:16642
top 209.165.200.225:62452 192.168.10.11:62452
R2#show ip nat translations verbose
Pro Inside global Inside local Outside local Outside global
tcp 209.165.200.225:16642 192.168.10.10:16642 209.165.200.254:80 209.165,200,254:80
create 00:01:45, use 00:01:43 timeout:86400000, left 23:58:16, Map-Id(In): 1, flags:
extended, use count: 0, entry-id: 4, lc entries: 0
tcp 209.165.200,225:62452 192.168.10.11:62452 209,165,200.254:80 209.165,200.254:80
create 00:00:37, use 00:00:35 timeout:86400000, left 23:59:24, Map-Id(In): 1, flags:
extended, use count: 0, entry-id: 5, lc entries: 0
R2#clear ip nat translation * R2#show ip nat translations
R2#
R2# ~ ~~
9.4 3. rétegbeli irányítási problémák
A 3. réteg gyakorlatilag az állomások és hálózatok címzését, valamint az ezek közti forgalomirányítást végző protokollokat definiálja.
A legtöbb hálózatban különböző típusú útvonalak vannak egyszerre jelen: statikus, dinamikus és alapértelmezett útvonalak. Az irányítási folyamat hibái hálózati leállást okozhatnak, és igen kedvezőtlenül érintik a hálózat teljesítményét. A hibák forrása sokféle lehet: rossz kézi útvonalbejegyzések, irányítóprotokollok beállítási és működési hibái, valamint az OSI alsóbb rétegeinek hibái.
A 3. rétegbeli problémák megoldása megköveteli az irányítási folyamatok, a különböző útvonaltípusok és azok működésének alapos ismeretét.
A folytatás előtt érdemes lehet átismételni a CCNA Discovery: Otthoni és kisvállalati hálózatok és CCNA Discovery: Hálózati feladatok kis- és középvállalatoknál vagy internetszolgáltatóknál tananyagok forgalomirányítással, irányítóprotokollokkal foglalkozó részeit. 
Számos tényezőnek köszönhetően a hálózat állapota gyakran változhat:
• Egy interfész meghibásodik.
• A szolgáltató megszakítja az összeköttetést.
• A rendelkezésre álló sávszélesség túlterheltté válik.
• Egy rendszergazda helytelen konfigurációt készít.
Minden egyes hálózati változásnál előfordulhat, hogy útvonalak vesznek el, vagy téves útvonalak kerülnek az irányítótáblába.
A 3. rétegbeli problémák feltárásának legfontosabb eszköze a show ip route parancs, amely kilistázza az összes olyan útvonalat, amelyet a forgalomirányító felhasznál a csomagok továbbítására. A forgalomirányító-tábla az alábbi forrásokból származó bejegyzéseket tartalmaz:
• Közvetlenül kapcsolódó hálózatok
• Statikus útvonalak
• Dinamikus forgalomirányító protokollok
Az irányítóprotokollok az irányítási mérték alapján választják ki az előnyben részesített útvonalakat. A közvetlenül kapcsolódó hálózatok mértéke 0, csakúgy mint a statikus útvonalak alapértelmezett mértéke. A dinamikus útvonalak irányítási mértéke irányítóprotokollonként változó.
Ha egy célhálózat felé több útvonal is létezik, a legkisebb adminisztratív távolságú (administrative distance - AD) útvonal kerül be az irányítótáblába.
Ha irányítási probléma gyanúja merül fel, a show ip route paranccsal ellenőrizhető, hogy a remélt útvonal szerepel-e az irányítótáblában.
Az útvonal forrása Adminisztratív távolság Alapértelmezett mérték(ek)
Csatlakoztatva 0 0
Statikus 1 0
EIGRP összevont Útvonal 5
Külső BGP 20 Rendszergazda által megadott érték
Belső EIGRP 90 Sávszélesség, késleltetés
IGRP 100 Sávszélesség, késleltetés
OSPF 110 Összeköttetés költsége (sávszélesség)
ISIS 115 Összeköttetés költsége (rendszergazda által megadott érték)
RIP 120 Ugrásszám
Külső EIGRP 170
Belső BGP 200 Rendszergazda által megadott érték

Közvetlenül kapcsolódó hálózatok problémái
A közvetlenül kapcsolódó hálózatok automatikusan bekerülnek az irányítótáblába, mihelyt az interfész IP-címet kap, és a no shutdown parancs végrehajtódik. Ha egy közvetlenül kapcsolódó hálózat nem jelenik meg az irányítótáblában, a show interfaces vagy a show ip interface brief paranccsal ellenőrizhető, hogy rendben van-e az interfész IP-címe, illetve up/up állapotban van-e.
Statikus és alapértelmezett útvonalak problémái
Szinte mindig beállítási probléma van a háttérben, ha egy statikus vagy egy alapértelmezett útvonal nem jelenik meg az irányítótáblában. Statikus és alapértelmezett útvonalak megadhatók a kimenő interfész vagy a következő ugrás IP-címének megnevezésével. A statikus útvonalak hibája gyakran abból ered, hogy a megadott következő ugrás IP-címe nem esik egyik közvetlenül kapcsolódó hálózat tartományába sem. Mindig ellenőrizni kell a konfigurációs parancsok helyességét és hogy a használt kimenő interfészek up/up állapotban vannak-e.
Dinamikus útvonalak problémái
Több, különböző probléma okozhatja, hogy a dinamikus útvonalak nem épülnek be az irányítótáblába. Mivel a dinamikus irányítóprotokollok irányítási információkat cserélnek a hálózat többi forgalomirányítójával, a célhoz vezető útvonalon lévő bármelyik forgalomirányító hibás beállítása eredményezheti egy-egy útvonal kiesését.


9.4.2 A dinamikus forgalomirányítás hibái
A forgalomirányító tábla frissítéseket általában új hálózat belépése vagy egy hálózat elérhetetlenné válása idézi elő.
Közvetlenül kapcsolódó hálózatok megjelenésekor a forgalomirányító tábla csak akkor frissül, ha a közvetlenül csatlakozó interfész állapota megváltozik. Statikus és alapértelmezett útvonalak konfigurálása esetén a forgalomirányító tábla csak akkor változik, ha új útvonalat definiálnak, vagy ha az útvonal meghatározásában szereplő kimenő interfész állapota megváltozik.
A dinamikus forgalomirányító protokollok automatikusan frissítéseket küldenek a hálózat más forgalomirányítóinak. Ha a dinamikus forgalomirányítás engedélyezve van, a forgalomirányító mindig frissíti az irányítótábláját, amikor egy szomszédos forgalomirányítótól kapott frissítésben változást észlel.
A RIP egy olyan dinamikus irányítóprotokoll, melyet kis és közepes helyi hálózatokban használnak. A RIP protokollal kapcsolatos hibák kijavításakor ellenőrizni kell a verzió beállítását és konfigurációs parancsokat.
Tanácsos a forgalomirányító protokollnak ugyanazt a verzióját használni az összes forgalomirányítón. Bár a RIPv1 és a RIPv2 kompatibilis, a RIPv1 nem tudja kezelni az osztály nélküli forgalomirányítást (CIDR) és a változó hosszúságú alhálózati maszkokat (VLSM). A RIPv1 és a RIPv2 egyidejű futtatása ugyanazon a hálózaton problémákat okozhat. Míg a RIPv2 automatikusan figyeli a RIPv1 és a RIPv2 frissítéseket is, a RIPv1 nem fogadja a RIPv2 frissítéseit.
Abból is forgalomirányítási problémák származhatnak, ha hiányoznak vagy hibásak a network utasítások. A network utasítások szerepe kettős:
• Engedélyezi, hogy az irányítóprotokoll minden olyan interfészen frissítéseket küldjön és fogadjon, melynek IP-címe a network parancs által megadott hálózatba esik.
• A kiküldött frissítéseiben feltünteti ezt a hálózatot.
A hiányzó, vagy hibás network utasítás, tehát hibás irányítási frissítéseket generálhat, illetve megakadályozhatja, hogy a forgalomirányító adott interfészén frissítéseket küldjön és fogadjon.

 A dinamikus irányítás hibáinak feltárásában sok eszköz segíthet.
A TCP/IP ping és traceroute segédprogramja használható a kapcsolat ellenőrzéséhez. A telnet segítségével egyrészt ellenőrizhető a kapcsolat, másrészt távoli eszközök is konfigurálhatók. A Cisco IOS show parancsai pillanatképet mutatnak a forgalomirányító beállításairól és az egyes összetevők állapotáról. A Cisco IOS parancskészlete számos debug parancsot is tartalmaz.
A debug parancsok dinamikus működésűek, valós idejű információt szolgáltatnak a hálózati forgalomról és a protokollok kommunikációjáról. Például a debug ip rip parancs a RIP irányítóprotokoll üzenetváltásait mutatja meg.
A debug parancsok komoly CPU erőforrásokat kötnek le, így lassíthatják, vagy akár meg is állíthatják a forgalomirányító normál működését. Éppen ezért a debug parancsokat csak a hibafeltárásban szabad használni, a forgalomirányító normál működésének monitorozására nem ajánlott.

9.5 A 4. és a felsőbb rétegek hibaelhárítása
9.5.1 4. rétegbeli forgalomszűrési hibák
A 4. (szállítási) réteget szokás átmenetnek tekinteni az OSI modell alsóbb és a felsőbb rétegei között. A 4. réteg felelős az adatcsomagok szállításáért, és definiálja az egyes alkalmazások eléréshez használatos portszámokat. A 4. rétegbeli problémák a hálózat határán lépnek fel, ahol a biztonsági technológiák ellenőrzik és módosítják a forgalmat. Számos problémát okoznak a tűzfalak, amelyeket úgy konfigurálnak, hogy a portszámok alapján tiltsák a forgalmat, amelyet egyébként továbbítniuk kellene.
A 4. réteg az UDP és a TCP forgalmat támogatja. Egyes alkalmazások kizárólag az egyiket használják, mások mindkettőt. Éppen ezért a portszámokon alapuló forgalomszűrésnél meg kell nevezni a protokollt is. Előfordul, hogy a TCP és az UDP protokollt is tiltják egy adott portszámhoz, pusztán mert bizonytalanok abban, hogy az adott alkalmazás melyiket használja. Ez a megoldás azonban olyan forgalmat is kiszűrhet, melynek kiszűrése nem volt cél.
A tűzfalakat gyakran úgy konfigurálják, hogy az explicit permit utasításokkal engedélyezett forgalom kivételével minden más forgalmat tiltsanak. Ha egy engedélyezett forgalomtípus nem szerepel a tűzfal utasításai között, vagy egy új alkalmazás jelenik meg a hálózaton anélkül, hogy a megfelelő endedélyek bekerülnének a tűzfal konfigurációjába, forgalomszűrési problémák keletkezhetnek.
A 4. rétegre jellemző hibajelenség, hogy a felhasználók bizonyos webes szolgáltatásokat (például video- és audioszolgáltatásokat) nem érnek el.
Ellenőrizni kell, hogy a tűzfalon engedélyezett ill. tiltott portok biztosítják-e az alkalmazások megfelelő működését. Az egyes alkalmazásokhoz tartozó portok jobb megértéséhez érdemes átismételni a CCNA Discovery: Otthoni és kisvállalati hálózatok és CCNA Discovery: Hálózati feladatok kis- és középvállalatoknál vagy internetszolgáltatóknál tananyag TCP és UDP portokra vonatkozó részeit.
9.5.2 Felsőbb rétegek hibáinak elhárítása
A felsőbb rétegbeli protokollok többnyire olyan felhasználói szolgáltatásokat nyújtanak, mint a hálózatfelügyelet, a fájlátvitel, az elosztott szolgáltatások, a terminálemuláció és az elektronikus levelezés. A felsőbb rétegekben működő protokollokat szokás TCP/IP alkalmazási rétegbeli
protokolloknak is nevezni, mivel a TCP/IP modell alkalmazási rétege az OSI modell felső 3 rétegét egyesíti.
Az alábbi listában láthatók a legismertebb, leggyakrabban megvalósított TCP/IP alkalmazási rétegbeli protokollok:
• Telnet - lehetővé teszi terminálkapcsolat kialakítását egy távoli állomással.
• HTTP - webes felületen történő adatcserét (szövegek, képek, hangok, videók és más multimédiás tartalmak) tesz lehetővé.
• FTP - TCP alapú, interaktív fájlátvitelt tesz lehetővé az állomások között.
• TFTP - egyszerű, de interaktív fájlátvitelt tesz lehetővé UDP fölött, jellemzően állomások és hálózati eszközök között.
• SMTP - alapvető levéltovábbítási szolgáltatást nyújt.
• POP3 - kapcsolatot teremt a levelező-kiszolgálóval és letölti a leveleket a levelezőprogramba.
• IMAP4 - lehetővé teszi, hogy a levelezőprogramok letöltsék a leveleket kiszolgálóról, és küldjenek leveleket a kiszolgálóra.
• SNMP - a felügyelt eszközökről gyűjt információt.
• NTP - pontos idő szolgáltatást nyújt a hálózati eszközöknek és állomásoknak.
• DNS - a hálózati neveket és az IP-címeket társítja.
• SSL - a HTTP tranzakciók titkosítását és biztonságát garantálja.
• SSH - kiszolgálók és hálózati eszközök biztonságos távoli elérését teszi lehetővé.
OS hivatkozási mode
4. Szállítási 3. Hálózati
2. Adatkapcsolati
1. Fizikai
A felsőbb rétegek problémáit sokszor nem könnyű behatárolni, különösen, ha az ügyfél beállításai nem utalnak semmi hibára. A felsőbb rétegek hibaelhárítását is az alapvető kapcsolati hibák kiszűrésével érdemes kezdeni.
Az "oszd meg és uralkodj" elv alapján célszerű a 3. rétegbeli kapcsolat ellenőrzésével kezdeni a hibaelhárítást.
1. lépés Ping üzenet küldése az állomás alapértelmezett átjárójához.
2. lépés A végpontól-végpontig tartó kapcsolat ellenőrzése.
3. lépés Az irányítási beállítások ellenőrzése. 
4. lépés A NAT megfelelő működésének ellenőrzése.
5. lépés A tűzfalszabályok ellenőrzése.
Ha a probléma egy távoli hálózatban jelentkezik, a végponttól-végpontig tartó kapcsolat nem ellenőrizhető, hiszen bizonyos kapcsolatok más felügyelet alá tartoznak. Ebből következően előfordulhat, hogy bár a helyi eszközökön minden rendben van, mégis problémák vannak a távoli hálózat elérésével. Ebben az esetben az internetszolgáltatóval kell ellenőriztetni, hogy a hálózati kapcsolatuk működőképes-e.
Ha mindez megtörtént, és a végponttól-végpontig tartó kapcsolat működőképes, miközben a végberendezés még mindig nem működik megfelelően, akkor a hibát a felsőbb rétegekben kell keresni.
1. lépés: Alapértelmezett átjáró pingelése
Ha a távoli hálózat, valamint az Internet szolgáltatásai nem elérhetők, akkor a NAT nem működik jól. Adja ki a show ip nat translations parancsot, a NAT fordítás ellenőrzésére! Törölje a NAT fordításokat a clear ip nat translation * paranccsal, és kísérelje meg a külső forrás újbóli elérését! Ha ez nem volt sikeres, ellenőrizze a belső és külső interfészek beállítását! A NAT beállítás ellenőrzését követően hajtsa végre ismét a 2. lépést! Ha még mindig sikertelen a ping, ellenőrizni kell a tűzfal szűrök beállítását.
2. lépés: Vógpontól-vógpontig terjedő kapcsolat ellenőrzése
5. lépés: Tűzfal szűrési szabályainak ellenőrzése
A felsőbb rétegek hibái miatt általában nem működhetnek az alkalmazói programok felé nyújtott szolgáltatások. Elérhetetlenné, vagy működésképtelenné tehetik az erőforrásokat, annak ellenére, hogy az alsóbb rétegek üzemképesek. Előfordulhat, hogy a hálózati kapcsolattal minden rendben van, az alkalmazás mégsem szolgáltat adatokat.
A felsőbb rétegek hibái sokszor csak néhány vagy csak egyetlen alkalmazást érintenek. Nem ritka, hogy olyan hívás fut be az ügyfélszolgálatra, hogy a felhasználó nem éri el a leveleit, miközben a többi hálózati szolgáltatás üzemszerűen működik.
A felsőbb rétegbeli hibákért legtöbbször a rossz ügyfélprogram-beállítások a felelősek. Az ügyfél nem jut hozzá a szükséges információhoz, ha rossz levelező- vagy az FTP kiszolgáló van megadva. Ha több alkalmazást is érintett, a felsőbb réteg hibáját a DNS szolgáltatás környékén érdemes kereseni.
A Windows nslookup segédprogramjával ellenőrizhető, hogy a DNS szolgáltatás hibátlanul működik-e, és fel tudja-e oldani a kiszolgálók IP-címeit. Ha a DNS szolgáltatás nem az elvárásoknak megfelelően működik, ellenőrizni kell az állomáson a DNS kiszolgáló címének beállítását. Ha az állomás a DNS kiszolgáló címét egy DHCP kiszolgálótól kapja, ellenőrizni kell a DHCP kiszolgálón a DNS kiszolgáló IP- címének beállítását.
Ha a DNS kiszolgáló üzemel és elérhető, ellenőrizni kell a DNS zónabeállítások hibáit. A hibát gyakran a címek és a tartománynevek elírása okozza a konfigurációs fájlokban.
4. Szállítási 3. Hálózati
2. Adatkapcsolati
1. Fizikai
A felsőbb rétegek a felelősek a titkosításért és a tömörítésért is. Alkalmazási hibákhoz vezethet, ha az ügyfél ill. a kiszolgáló nem ugyanúgy titkosítja és tömöríti az adatokat, mint ahogyan a másik fél elvárja.
Ha a probléma egyetlen állomásra korlátozódik, valószínű, hogy az adott számítógépen futó alkalmazás beállításaiban van a hiba. A böngészők különböző beépülő moduljai, mint például az Adobe Reader, gyakran felsőbb rétegbeli hálózati funkciókat is megvalósítanak. A weboldalak helyes megjelenítése érdekében ezeket a modulokat rendszeresen frissíteni kell.
Az adat lekérésekor használt nem megfelelő protokoll okozhatja, hogy a weboldal nem elérhető. Például előfordulhat, hogy az SSL-lel titkosított oldalak megtekintéséhez a https:// kezdetű címet kell a böngésző címsorába írni a szokásos http:// helyett. 
9.5.3 Felsőbb rétegbeli kapcsolat ellenőrzése Telnettel
A Telnet jól használható a felsőbb rétegbeli problémák elhárításában. Segítségével a rendszergazdák úgy kapcsolódhatnak a hálózati eszközökhöz, és adhatnak ki parancsokat, mintha helyileg csatlakoznának. Sikeres bejelentkezés egy eszközre telnettel, egyúttal az alsóbb rétegek megfelelő működését is jelzi.
Mindazonáltal, a telnet nem biztonságos protokoll, vagyis minden továbbított információ könnyedén lehallgatható és olvasható. Ha a legkisebb esélye is megvan, hogy illetéktelenek lehallgatják a hálózati kommunikációt, akkor telnet helyett a Secure Shell (SSH) protokoll használata ajánlott. Az SSH lényegesen biztonságosabb módja a távoli eszközök elérésének.
A Cisco IOS újabb változatainak többsége már tartalmaz SSH kiszolgálót. Egyes eszközökben ez a szolgáltatás már alapértelmezésként fut, másokon külön engedélyezni kell.
A Cisco IOS csomagok tartalmaznak egy SSH ügyfelet is, hogy SSH kapcsolatot tudjanak létesíteni más eszközökkel. Hasonlóan, távoli számítógépek SSH ügyfél segítségével biztonságos parancssori kapcsolatot kezdeményezhetnek. Az SSH ügyfélprogram nem minden operációs rendszernek része, ebben az esetben a rendszergazdának külön kell beszereznie, telepítenie és konfigurálnia.
Érdemes átismételni az SSH konfigurálását és használatát a CCNA Discovery: Hálózati feladatok kis- és középvállalatoknál vagy internetszolgáltatóknál tananyagban.
9.6 Felkészülés a Cisco képesítés megszerzésére
9.6.1 Tudás, készség és képesség
A CCENT (Cisco Certified Entry Networking Technician - Cisco belépő szintű hálózati technikus) minősítés igazolja, hogy a tulajdonosa rendelkezik a belépő szintű hálózat támogatási munkakörök ellátáshoz szükséges szakértelemmel, amely számos sikeres karrier kiindulópontja a számítógépes hálózatok területén. Megszerzése az első lépés a CCNA (Cisco Certified Network Associate - Cisco hálózati rendszergazda) képesítés felé vezető úton, amely a közepes méretű, bonyolultabb összekötetésekkel bíró, vállalati kirendeltségek hálózatait foglalja magába. A CCENT képesítés megszerzéséhez a jelöltnek le kell tennie az ICND1 vizsgát a hivatalos Cisco vizsgaközpontok valamelyikében.(A CCENT vizsga jelenleg magyar nyelven nem érhető el.)
Az ICND1 (640-822) vizsgán a jelöltnek azt kell bizonyítania, hogy rendelkezik a kis irodai hálózatok telepítéséhez, üzemeltetéséhez és hibaelhárításához szükséges képességekkel. A vizsga részét képezik az alábbi hálózati alapismeretek:
• Csatlakozás egy WAN-hoz
• Alapvető hálózatbiztonsági és vezeték nélküli hálózati ismeretek
• Forgalomirányítás és kapcsolás
• A TCP/IP és az OSI modell
• IP-címzés
• WAN-technológiák
• Cisco IOS operációs rendszert futtató eszközök üzemeltetése és konfigurálása
• RIPv2, statikus és alapértelmezett forgalomirányítás konfigurálása
• NAT és DHCP alkalmazása
• Egyszerű hálózatok konfigurálása
A Cisco vizsgára való felkészülés komoly kihívás. A Cisco különös figyelmet fordít a CCNA vizsgák színvonalának megtartására, ezért rendszeresen frissíti az elvárásokat. Egyes jelöltek elsőre leteszik a vizsgát, mások többször nekifutnak, és olyanok is akadnak, akiknek nem sikerül megszerezniük a képesítést. Az alapos felkészülés a legjobb módszer ahhoz, hogy az első csoportba tartozzon valaki.

 Mindig érdemes azzal kezdeni a vizsgafelkészülést, hogy az ember megérti a vizsga célját. A Cisco vizsgarendszerek célja, hogy egy adott szakterületen mérjék a jelölt tudását, szakértelmét és képességét. A vizsga többféle mérési technikát alkalmaz annak érdekében, hogy a jelölt bizonyíthassa rátermettségét, és a különböző hálózati feladatok megvalósításában szerzett jártasságát. A vizsga tartalmaz feleletválasztós feladatokat, különböző gyakorlatokat és szimulált hálózatkonfigurációs feladatokat is. Minden kérdésnek, feladatfajtának célja van. A Cisco képesítések honlapján megtalálhatók az ICND1 vizsga céljai.
9.6.1 Hálózati tudás, készség és képesség IP*
A hálózati feladatok megoldása általában megköveteli bizonyos háttérismeretek meglétét. Ez a fajta tudás legtöbbször tényeken alapul. A vizsgára készülés során mindig érdemes az adott számonkérési célhoz tartozó alapvető tényeket rendszerezni. Van, akinek segít, ha kis kártyákra felírja a tényeket, kulcsfogalmakat tanulás közben. Ugyan szerepelhet a vizsgán néhány olyan kérdés, amikor csak a lexikális tudást kell mozgósítani, de többségében a hálózati problémák feltárása és megoldása során lesz szükség ezekre az ismeretekre. 
A hálózati feladatok megoldása sokrétű szakértelmet igényel. Egyes készségek roppant egyszerűek, mint például a keresztkötésű kábel készítése. Mások jóval összetettebbek, például az IP-alhálózatok kialakítása.
A hálózattervezési feladatok elsajátítása sok gyakorlást igényel. A laborgyakorlatok és a Packet Tracer feladatok hivatottak a sokrétű tapasztalatszerzés lehetőségét biztosítani a hallgatók számára.
A Cisco vizsgák az alapján mérik a jelölt felkészültségét a számítógépes hálózatok tárgykörében, hogy miként tud a Cisco hálózati eszközökkel dolgozni. Ezért elengedhetetlenül fontos, hogy kellő tapasztalatot szerezzenek a hallgatók a Cisco IOS használatában. A vizsgafeladatok jelentős részének megoldásához szükség van a különböző IOS parancsok, elsősorban a show parancsok kimenetének értelmezésére.
Ez a mintakérdés annak ellenőrzésére szolgál, hogy a jelölt mennyire jártas az IP-címzésben és a Cisco IOS szoftver használatában.
Tanulmányozza az ábrát! Melyik Cisco IOS parancs rendeli hozzá az első felhasználható IP-címet az alhálózatban az RTA FastEthernet 0/1 interfészéhez?
A. RTA(config-if)#ip address 172.18.13.1 255.255.254.0
B. RTA(config-if)#ip address 172.18.14.1 255.255.252.0
C. RTA(config-if)#ip address 172.18.14.1 255.255.255.252
D. RTA(config-if)#ip address 172.18.16.1 255.255.252.0
E. RTA(config-if)#ip address 172.18.16.1 255.255.255.252
F. RTA(config-if)# ip address 172.18.16.229 255.255.255.252
A belépő szintű technikus számára a legfontosabb, hogy rendelkezzék a tervezés, a szervezés, a kivitelezés és a problémamegoldás képességével. Vizsgahelyzetben ezek meglétét leginkább konfigurációs és hibaelhárítási feladatokon keresztül lehet ellenőrizni. A vizsgafeladatok összeállításakor az a cél, hogy a vizsgahelyzetek minél jobban közelítsék a valós élethelyzetekben előforduló szituációkat. Ezek a körülmények szimulációkkal és esetleírásokkal közelíthetők legjobban.
Az esetleíráson alapuló és a szimulációs feladatokra nehezebb felkészülni, mint néhány adatot megjegyezni, vagy egy adott képességet begyakorolni. A kitűzött célok teljesítése és a probléma megoldása egyszerre követeli meg az ismeretek és a készségek mozgósítását.
A hibaelhárítási képességek fejlesztésének egyik legjobb módja, ha elsőként az adott hálózati probléma megoldásához szükséges ismeretek és képességek elemzésére kerül sor. A szükséges ismeretek feltárását követően érdemes eljátszani a gondolattal, hogy mi történne, ha azok nem lennének ismertek. Ajánlott egy lista készítése a lehetséges kimenetelekről, majd annak eldöntése, milyen készségeket igényelne egy-egy probléma felismerése és kijavítása, ha az bekövetkezne. Elsőre bonyolultnak hangozhat mindez, de az alábbi példák segíthetik az áttekintést: 
• Mi történne, ha a technikus nem lenne tisztában az alhálózatban kiosztható állomáscímek számával adott alhálózati maszk használata esetén? Hogyan ismerhető fel a probléma, és mit lehet tenni a megoldása érdekében?
• Milyen problémák származhatnak abból, ha egy RIPv2 hálózatban van olyan útvonal a forrás és a cél között, amely hosszabb 15 ugrásnál? Milyen tünetek tapasztalhatók ilyen esetben? Hogyan oldható meg a probléma?
Szükséges információ:
Felmerülő problémák:
A problémák lehetséges tünetei:
9.6.3 Elhatározás
Minősítő vizsgát tenni komoly elszántságot kíván megoldani. A vizsgára készülés is sikeresebb lesz - ha kisebb részfeladatokra bontjuk:
1. Elhatározás
2. Tervkészítés
3. Vizsgarutin megszerzése Ezután a pár lépés után megkezdődhet a tényleges felkészülés. 
A Cisco képesítés megszerzéséhez vezető út első lépése az elhatározás, a kellő idő és energia ráfordítása érdekében. Az elhatározásnak együtt kell járnia azzal, hogy a felkészülésnek maximális prioritást adunk, hiszen nyilván más tevékenységektől kell elvonni a ráfordítandó időt.
A ráfordított idő önmagában nem elegendő: megfelelő figyelmet is kell szentelni a felkészülésnek. Meg kell keresni azt a helyet otthon vagy az iskolában, ahol a zavartalan tanulás hosszabb ideig biztosított. A hálózati ismereteket és készségeket nem lehet úgy elsajátítani, ha folyton mindenféle zavaró tényezők hátráltatják a felkészülést.
Ugyanilyen fontos, hogy rendelkezésre álljanak a megfelelő készülékek és erőforrások. Gondoskodni kell róla, hogy elérhető legyen egy számítógép on-line tananyag hozzáféréssel és a Packet Tracer alkalmazással. Oktatói egyeztetés után a labor használata is ajánlott, valódi eszközökön szerzett tapasztalatok elsajátítása céljából. Érdemes utána nézni, hogy van-e a környezetben internetes labor hozzáférés.
Segíthet a család és a barátok tájékoztatása is a CCENT bizonyítvány megszerzésére irányuló elhatározásról. Támogatásuk és segítségük fontos lehet a felkészülési időszakban. Emlékeztetőkártyákkal vagy gyakorlókérdésekkel akkor is segíthetnek a felkészülésben, ha ők nem járatosak a számítógép-hálózatokban. Az is könnyebbséget jelethet, ha tiszteletben tartják a nyugodt felkészülési időre való igényt. Érdemes lehet tanulócsoportokat alakítani az osztály többi, szintén a vizsgára készülő tagjával.
9.6.4 Tervkészítés
Az elhatározás, majd az ICND1 vizsgára történő felkészülés megfelelő körülményeinek megteremtése és kialakítása után, következhet a tervkészítés. A felkészülési terv tartalmazza a felkészülés tervezett menetét, az ütemezést és a szükséges erőforrások listáját.
Alapvetően kétféleképp lehet felkészülni egy vizsgára: egyénileg vagy csoportosan. Sokan előnyben részesítik a csoportos felkészülést, mert az segíthet a tananyag alaposabb feldolgozásában és a határidők betartásában.
A csoportos felkészülés szempontjából lényeges többek között, hogy minden résztvevő tisztában legyen a kapcsolattartás módjával, a találkozások időpontjaival és helyszínével. Érdemes lehet az egyes feladatokra felelőst kijelölni a csoportból:
• Tananyagok összegyűjtése és kiosztása
• Laboridő beosztása
• Fogyóeszközök biztosítása
• Csoport előmenetelének követése
• Felmerült problémák megoldása
Az egyéni felkészülés megkönnyítheti az erőforrásokkal való gazdálkodást, ami nem jelenti azt, hogy felesleges tervet készíteni.
A heti felkészülésre szánható időmennyiség alapján reális időpontot kell kitűzni a vizsga letételére.
A rövidebb rendelkezésre álló időszeletek használhatók az elméleti felkészülésre, az egybefüggő, hosszabb időegységek pedig a gyakorlati tevékenységekre. Roppant bosszantó, ha egy laborfeladat vagy más gyakorlati tevékenység elkezdése után nem marad elég idő a befejezésre.
A Cisco Press gondozásában megjelent "31 Days to the CCENT" (31 nap alatt CCENT vizsgát) felkészülési útmutató kiadvány segíthet az időrend összeállításában (angol nyelven elérhető csak). A könyv vizsgacélok mentén haladva emeli ki a legfontosabb tanulnivalókat. Rendre megjelöli a CCNA Discovery: Otthoni és kisvállalati hálózatok és CCNA Discovery: Hálózati feladatok kis- és középvállalatoknál vagy internetszolgáltatóknál tananyag vonatkozó fejezeteit, melyek alapján fel lehet készülni.
Az ütemterv készítésének első lépéseként rögzítsük a rendelkezésre álló időszakokat a naptárba. Ezután a rendelkezésre álló időblokkok rögtön konkrét feladatokhoz rendelhetők, például "az OSI modell rétegeinek és feladataiknak áttekintése" vagy "IP-alhálózatok kialakításának gyakorlása". Amikor sikerült minden feladathoz időpontot rendelni, a vizsga időpontjának kitűzése következhet.
Vizsgáljuk meg a felkészüléshez rendelkezésre álló eszközöket és erőforrásokat. Az ICND1 vizsgán a jelen kurzus, és a CCNA Discovery: Otthoni és kisvállalati hálózatok kurzus során elsajátítható ismereteket és készségeket ellenőrzik. A sikeres felkészülés előfeltétele, hozzáférés az on-line tananyaghoz, a laborgyakorlatokhoz és a Packet Tracer alkalmazáshoz.
A Cisco CCNA minősítés weboldalán rengeteg további segédanyag található (jellemzően angol nyelven). A CCNA felkészülési központ weboldala:
CCNA Prep Center
A Cisco Press gondozásában számos kiadvány jelent már meg, mely feldolgozza a CCENT vizsga tartalmát. Ezek a kiadványok megvásárolhatók (angol nyelven) a Cisco Marketplace Bookstore elektronikus könyváruházában.
Cisco Marketplace Bookstore
Következő lépés az összegyűjtött anyagok rendszerezése. A CCENT vizsgához szükséges ismeretek és képességek mennyisége túl nagy ahhoz, hogy csapongva, kapkodva át lehessen őket tekinteni és kellőképpen be lehessen őket gyakorolni. Sokkal könnyebb olyan dolgokra emlékezni, melyeket rendszerezetten sajátított el az ember.
9.6.5 Vizsgarutin megszerzése
A hálózati készségek felidézése és teljesítése vizsgaszituációban teljesen más mint otthoni vagy osztálytermi környezetben. Lényeges a vizsga lebonyolításának és formájának ismerete.
Látogatás a vizsgaközpontban
A vizsga előtt ajánlott ellátogatni a vizsgaközpontba, és kérdésekkel tapasztalatot gyűjteni a vizsga menetéről. Egyes vizsgaközpontokban minden vizsgázó külön munkakörnyezetben dolgozik, míg másokban több vizsgázó tevékenykedik ugyanabban a térben. Mindenképpen tájékozodni kell a teremben engedélyezett és méginkább a tiltott eszközökről. A Cisco weboldalán megkereshető a lakóhelyhez legközelebbi vizsgaközpont.
A vizsga menete
A képesítővizsgákat ugyanúgy on-line kell letenni, mint a Hálózati Akadémia számonkéréseit. Van azonban néhány eltérés:
• Közvélemény-kutató kérdések előzhetik meg a tényleges vizsga megkezdését. Fontos az őszinte válasz. A közvélemény-kutató kérdések nincsenek kapcsolatban a tényleges vizsgával, és nem befolyásolják annak eredményét.
• A vizsga időre megy. A hátralevő idő a képernyő felső részén látható, így eldönthető, hogy egy-egy kérdésre mennyi idő szánható.
• A vizsgán belül sokféle kérdés és feladat fordulhat elő.
• Továbblépés után már nem lehet a korábbi kérdésekre visszatérni.
Nincs mód egy kérdés kihagyására, vagy megjelölésére későbbi ellenőrzés céljából. Bizonytalanság esetén legjobb tippelni, és továbblépni a következő kérdésre.
A Cisco vizsgaformák az alábbi kérdéstípusokat tartalmazzák:
• feleletválasztós kérdés, egy jó válasszal
• feleletválasztós kérdés, több jó válasszal
• fogd és vidd feladat
• üres mezők kitöltése
• kérdéscsoport
• szimulációs egység
• szimuláció
A vizsga előtt mindenképpen ajánlott megismerkedni az egyes feladatfajták működésével, különösen a kérdéscsoport (testlet), szimulációs egység (simlet) és a szimuláció (simulation tool) megismerése izgalmas. Ez a gyakorlat segíthet a vizsgán a tényleges feladatra összpontosítani a feladatfajta működése helyett. A Cisco CCNA felkészülési weboldalon található vizsgafelkészítő eszközök segítséget nyújtanak a gyakorlásban, és az összes feladatfajta megoldásáról szerzett pontos ismeretek kialakításában.
Bár semmi sem helyettesítheti igazán a tényleges vizsgarutint, mégis érdemes megoldani a gyakorlóvizsgát. A CCNA felkészülési weboldalon találhatók feladatválasztós kérdéseket tartalmazó minta-feladatsorok is az ICND1 vizsgához. A csoportos felkészülés során gyakorlókérdések önálló kidolgozása is célszerű, melyek megoszthók a csoporttársakkal. Az interneten kereskedelmi forgalomban levő vizsgakérdéssorok is megvásárolhatók vagy letölthetők.
A Cisco képesítővizsgák mindig tartalmaznak forgalomirányítók és kapcsolók működését szimuláló feladatokat is. Érdemes lehet újra végigcsinálni a laborgyakorlatokat és a Packet Tracer feladatokat a felkészülés során. A képesítővizsga összetett feladataira roppant nehéz pusztán a tananyagot olvasgatva és a laborokat kipróbálva felkészülni. Fontos próbálgatni, hogy mi történne, ha hiba lépne fel az adott eszköz telepítése vagy konfigurálása során. Sokat lehet tanulni szándékosan előidézett hibákból, melyek során megfigyelhetők az eszköz működésében és a parancsok kimenetében megjelenő változások. Az ICND1 vizsga esetleíráson alapuló feladatai túlnyomó többségben hálózati hibaelhárítási feladatok.
9.7 A fejezet összefoglalása
• Mind az OSI, mind a TCP/IP modell egyes rétegei jól meghatározott feladatokat látnak el adott protokollokkal. A hibaelhárítás során nagyban megkönnyíti a szakember munkáját, ha tisztában van az egyes rétegek feladataival, jellemzőivel, az azokhoz tartozó eszközökkel, valamint az adott réteg többi réteghez való viszonyával.
■ Az OSI modell felsőbb (5-7) rétegei jellemzően speciális alkalmazási funkciót látnak el, többnyire szoftveresen vannak megvalósítva. Az alacsonyabb rétegek (1-4) az adatátviteli feladatokat és a hálózat fizikai megvalósítását látják el.
• A hálózati modellekkel végzett munka során három fő hibaelhárítási megközelítést követhetünk:
* Fentröl lefelé
* Alulról felfelé
* Oszd meg és uralkodj
Hálózati hlbafelderltést elősegítő eszközök közé tartoznak:
* Hálózati diagramok és dokumentumok
* Hálózati dokumentációs és alapszint-ellenőrző eszközök
• Hálózatkezelési rendszerek
• Ismeret bázisok
- Protokollelemzők
Szoftveres eszközökkel sokszor nem könnyű az OSI modell alsó rétegeiben jelentkező hibák felismerése. Ezekben az esetekben nagy segítségünkre lehetnek a hardveres hibaelhárító eszközök: a kábelteszter, a multiméter és a hálózat¬analizátor.
■ A fizikai és az adatkapcsolati réteg hardveres és szoftveres megvalósításokat is tartalmaz.
• A fizikai réteg felelős az egyik állomásról a másik állomásra küldött bitek fizikai és elektromos jellemzőinek a definiálásáért függetlenül attól, hogy vezetékes vagy vezeték nélküli átviteli közeget alkalmazunk.
• 1. rétegbeli problémák közé tartoznak:
• Kábeltípus, hossz és csatlakozó problémák
• Duplexitásl problémák
• Az átvitelt megszakító interferencia és zaj
• Hardveres eszközhibák és rendszerindHásí problémák
• A forgalomirányító interfészének hibája gyakran az első tünete az 1. és 2. rétegbeli kapcsolati és kábelezési hibáknak.
■ Az eszközök LED kijelzői hasznos hibaelhárítási Információt tartalmaznak a kapcsolódási problémák kiszűrésére.
• Az adatkapcsolati réteg (azaz a 2, réteg) határozza meg az adott közegen történő továbbításra előkészített adatok formátumát. Ebben a rétegben kerül szabályozásra a közeghozzáférés is. A 2. réteg teremti meg a kapcsolatot a hálózati réteg szoftveres megvalósítása és az 1. réteg hardveres LAN és WAN technológiái között.
• 2. réteg problémái például:
• Beágyazási problémák
■ Ébrenléti jelek küldésének vagy vételének hiánya
• Időzítési problémák a WAN kapcsolatoknál
• A show version , show interfsces és a show interface brief
parancsok hibaelhárítási adatokat tartalmaznak az 1. réteg és a 2. réteg hibáinak azonosítására és szétválasztáséra.
• Az OSI modell 3. rétegének elsődleges feladata a hálózati címzés és a forgalomirányítás megvalósítása.
• Legtöbb esetben a rosszul megtervezett és kialakított IP-clmzési rendszer, jellegzetesen az átfedő alhélózati elmek okozzák a hálózat teljesítményének problémáit.
• Alhálózat! átfedést okozhat a nem kellő gondossággal kialakított címzés vagy a helytelenül megadott alhélózati maszk.
• A DHCP szervertől kapott címzés mellet előfordul, hogy az állomások automatikusan kapnak egy IP-címet a 169.254.0.0 (privát)hálózatból.
• NAT beállítási és működési problémák előidézhetik, hogy internet lapok nem elérhetők privát címzésű LAN-okból.
* A legtöbb hálózatban különböző típusú útvonalak is létezhetnek. Többek között statikus, dinamikus és alapértelmezett útvonalak kombinációi.
* A hibák forrása sokféle lehet: manuális útvonalbejegyzési hibák, Irányitóprotokollok beállítási és működési hibái, valamint az OSI alsóbb rétegeinek hibái.
* A 3. réteg problémáinak feltárására elsődleges eszköz a show ip route parancs. A forgalomirányító irányítótáblájának útvonalai a következő forrásokból származhatnak:
• Közvetlenül kapcsolódó hálózatok
* Statikus útvonalak
• Dinamikus irányítási protokollok
* Probléma lehet a RIPv2 irányító protokollal többek között:
■ A verzió megadásának elmulasztása a verziók különbözőségét okozhatja a forgalomirányítók között,
■ Hibás vagy hiányzó network parancsok.
* Helytelenül megadott interfész IP-címek.
• A 4. réteg felelős az adatcsomagok szállításáért, valamint definiálja az egyes alkalmazások eléréséhez használatos portszámokat.
• A tűzfalak és port-szűrő szabályok, amelyek átengedik vagy tiltják a nem megfelelő portok forgalmát, megakadályozhatják egyes szolgáltatások elérését az ügyfél gépéről.
• Felsőbb rétegek szolgáltatásai közé tartoznak a DNS névfeloldás, a titkosítás és a tömörítés. Az Ilyen funkcók hibái a végfelhasználó gépén futó alkalmazásokat működésképtelenné tehetik.
• A Windows nslookup parancsa segíthet a DNS hibák felderítésében.
• A hivatalos CCENT (Cisco Certified Entry Networking Technician - Cisco belépő szintű hálózati technikus) minősítés megszerzése igazolja, hogy a tulajdonosa rendelkezik a belépő szintű hálózati támogatási munkakörök ellátáshoz szükséges képességekkel. Számos sikeres karrier kiindulópontja a számítógépes hálózatok területén.
• A CCENT tanúsítvány megszerzéséhez, a jelöltnek le kell tennie az ICND1 (640¬822) vizsgát. Itt megvizsgálják, hogy képes-e egy fiókiroda hálózatának telepítésére, üzemeltetésére és hibaelhárítására.
• A Cisco vizsgák az alapján mérik a jelölt felkészültségét a számitógépes hálózatok tárgykörében, hogy miként tud a Cisco hálózati eszközökkel dolgozni. A feladatok egy jelentős része arra kiváncsi, hogy tudja-e a jelölt a különböző IOS parancsok, elsősorban a show parancsok kimenetét értelmezni,
• A vizsgára készülés - csakúgy mint egy ügyfél hálózatának a kialakítása - szintén hatékonyabb, ha lebontjuk kisebb feladatokra:
1. Elhatározás
2. Tervkészítés
3. Vizsgarutin megszerzése