Már mondtam, hogy frissíteni fogom az oktatóvideóimat a CCNA v3-ra. Minden, amit az előző leckéken tanult, teljes mértékben releváns az új kurzus szempontjából. Ha szükséges, további témákat is beiktatok az új leckékbe, így biztos lehet benne, hogy óráink a 200-125 CCNA tanfolyamhoz igazodnak.
Először is teljes mértékben tanulmányozzuk az első vizsga 100-105 ICND1 témáit. Még van néhány leckénk, ami után készen állsz a vizsgára. Ezután elkezdjük tanulni az ICND2 tanfolyamot. Garantálom, hogy a videó tanfolyam végére teljesen felkészült a 200-125 vizsgára. Az utolsó órán azt mondtam, hogy nem térünk vissza a RIP-hez, mert nem szerepel a CCNA tanfolyamban. De mivel a RIP bekerült a CCNA harmadik verziójába, tovább fogjuk tanulmányozni.
A mai óra témái a RIP használata során felmerülő három probléma lesz: Számlálás végtelenig, vagy számolás a végtelenig, Split Horizon – a kettéválás szabályai és Route Poison, avagy útvonalmérgezés.
Hogy megértsük a végtelenig számolás problémájának lényegét, térjünk át a diagramra. Tegyük fel, hogy van R1, R2 és R3 routerünk. Az első router a másodikhoz a 192.168.2.0/24 hálózat, a második a harmadikhoz a 192.168.3.0/24 hálózat, az első router a 192.168.1.0/24 hálózathoz, a harmadik pedig a 192.168.4.0/24 hálózathoz csatlakozik. XNUMX/XNUMX hálózat.
Nézzük meg az útvonalat a 192.168.1.0/24 hálózathoz az első routertől. A táblázatában ez az útvonal 192.168.1.0-ként jelenik meg, az ugrások száma 0.
A második útválasztó esetében ugyanaz az útvonal jelenik meg a táblázatban, mint a 192.168.1.0, az ugrások számával 1. Ebben az esetben a router útválasztási táblázatát az Update timer 30 másodpercenként frissíti. Az R1 értesíti R2-t, hogy a 192.168.1.0 hálózat elérhető rajta keresztül 0-val egyenlő ugrásokban. Az üzenet fogadásakor az R2 egy frissítéssel válaszol, hogy ugyanaz a hálózat elérhető rajta keresztül egy ugrással. Így működik a szokásos RIP-útválasztás.
Képzeljünk el egy olyan helyzetet, amikor az R1 és a 192.168.1.0/24 hálózat közötti kapcsolat megszakadt, ami után a router elvesztette a hozzáférését. Ezzel egyidejűleg az R2 router frissítést küld az R1 útválasztónak, amelyben azt jelenti, hogy a 192.168.1.0/24 hálózat egy ugrással elérhető számára. R1 tudja, hogy elvesztette a hozzáférését ehhez a hálózathoz, de R2 azt állítja, hogy ez a hálózat rajta keresztül elérhető egy ugrással, ezért az első útválasztó úgy véli, hogy frissítenie kell az útválasztási táblázatát, 0-ról 2-re módosítva az ugrások számát.
Ezt követően az R1 elküldi a frissítést az R2 útválasztónak. Azt mondja: „Oké, előtte küldtél egy frissítést, hogy a 192.168.1.0 hálózat nulla ugrással elérhető, most pedig azt jelenti, hogy ehhez a hálózathoz 2 ugrással meg lehet építeni egy útvonalat. Tehát frissítenem kell az útválasztási táblámat 1-ről 3-ra." A következő frissítésnél az R1 4-re, a második router 5-re, majd 5-re és 6-ra módosítja az ugrások számát, és ez a folyamat a végtelenségig folytatódik.
Ezt a problémát útválasztási huroknak nevezik, a RIP-ben pedig a végtelenig számláló problémának. A valóságban a 192.168.1.0/24 hálózat nem érhető el, de az R1, R2 és a hálózat összes többi útválasztója úgy gondolja, hogy elérhető, mert az útvonal folyamatosan hurkol. Ezt a problémát horizontosztó és útvonalmérgezési mechanizmusok segítségével lehet megoldani. Nézzük meg azt a hálózati topológiát, amellyel ma dolgozni fogunk.
Három R1,2,3, 192.168.1.10, 192.168.4.10 router és két 4 és 1.0 IP-című számítógép található a hálózaton. A számítógépek között 2.0 hálózat van: 3.0, 4.0, XNUMX és XNUMX. Az útválasztóknak van IP-címük, ahol az utolsó oktett a router száma, az utolsó előtti oktett pedig a hálózat száma. Bármilyen címet hozzárendelhet ezekhez a hálózati eszközökhöz, de én inkább ezeket szeretem, mert így könnyebb elmagyaráznom.
Hálózatunk konfigurálásához térjünk át a Packet Tracerre. Cisco 2911 útválasztókat használok, és ezt a sémát használom az IP-címek PC0 és PC1 gazdagéphez való hozzárendelésére.
Figyelmen kívül hagyhatja a kapcsolókat, mert „egyenesen a dobozból” vannak, és alapértelmezés szerint VLAN1-et használnak. A 2911 routerek két gigabites porttal rendelkeznek. Hogy megkönnyítsem a dolgunkat, minden útválasztóhoz kész konfigurációs fájlokat használok. Látogassa meg weboldalunkat, lépjen az Erőforrások lapra, és megtekintheti az összes oktatóvideót.
Jelenleg nincs itt minden frissítés, de példaként megtekintheti a 13. nap leckét, amelyhez munkafüzet hivatkozás tartozik. Ugyanezt a linket csatoljuk a mai oktatóvideóhoz is, és ennek követésével letöltheti a router konfigurációs fájljait.
Az útválasztóink konfigurálásához egyszerűen átmásolom az R1 konfigurációs szövegfájl tartalmát, megnyitom a konzolját a Packet Tracerben, és beírom a config t parancsot.
Ezután csak beillesztem a másolt szöveget, és kilépek a beállításokból.
Ugyanezt teszem a második és harmadik router beállításaival is. Ez a Cisco beállítások egyik előnye – egyszerűen átmásolhatja és beillesztheti a szükséges beállításokat a hálózati eszköz konfigurációs fájljaiba. Az én esetemben a kész konfigurációs fájlok elejére adok 2 parancsot is, hogy ne kerüljön be a konzolba - ezek az en (enable) és a config t. Ezután kimásolom a tartalmat, és beillesztem az egészet az R3 beállítások konzoljába.
Tehát mind a 3 útválasztót beállítottuk. Ha kész konfigurációs fájlokat szeretne használni útválasztóihoz, győződjön meg arról, hogy a modellek megegyeznek az ábrán láthatókkal – itt a routerek GigabitEthernet portokkal rendelkeznek. Előfordulhat, hogy javítania kell ezt a sort a FastEthernet fájlban, ha az útválasztó pontosan ezekkel a portokkal rendelkezik.
Látható, hogy az útválasztó port jelölői a diagramon továbbra is pirosak. Mi a probléma? A diagnosztizáláshoz lépjen az 1. útválasztó IOS parancssori felületére, és írja be a show ip interface short parancsot. Ez a parancs az Ön „svájci kése”, amikor különféle hálózati problémákat old meg.
Igen, van egy problémánk – látja, hogy a GigabitEthernet 0/0 interfész adminisztratívan leállt. A helyzet az, hogy a másolt konfigurációs fájlban elfelejtettem használni a no shutdown parancsot, és most manuálisan fogom beírni.
Most kézzel kell hozzáadnom ezt a sort az összes útválasztó beállításaihoz, ami után a portjelzők színe zöldre változik. Most az útválasztók mindhárom CLI ablakát egy közös képernyőn jelenítem meg, hogy kényelmesebb legyen a tevékenységem megfigyelése.
Jelenleg mind a 3 eszközön be van állítva a RIP protokoll, amit a debug ip rip paranccsal fogok hibakeresni, ami után minden eszköz RIP frissítést cserél. Ezek után az undebug all parancsot használom mind a 3 routerhez.
Láthatja, hogy az R3-nak problémái vannak a DNS-kiszolgáló megtalálásával. Később megvitatjuk a CCNA v3 DNS-kiszolgáló témaköreit, és megmutatom, hogyan lehet letiltani a keresési funkciót az adott szerveren. Egyelőre térjünk vissza a lecke témájához, és nézzük meg, hogyan működik a RIP frissítés.
Miután bekapcsoltuk az útválasztókat, az útválasztási tábláik bejegyzéseket tartalmaznak azokról a hálózatokról, amelyek közvetlenül csatlakoznak a portjukhoz. A táblázatokban ezek a rekordok C betűvel vannak fejtve, és a közvetlen kapcsolat ugrásainak száma 0.
Amikor az R1 frissítést küld az R2-nek, az információkat tartalmaz a 192.168.1.0 és a 192.168.2.0 hálózatokról. Mivel az R2 már ismeri a 192.168.2.0 hálózatot, csak a 192.168.1.0 hálózat frissítését helyezi el az útválasztási táblázatába.
Ennek a bejegyzésnek az élén az R betű áll, ami azt jelenti, hogy a 192.168.1.0 hálózathoz való csatlakozás az f0/0: 192.168.2.2 router interfészen keresztül csak a RIP protokollon keresztül lehetséges 1 ugrásszámmal.
Hasonlóképpen, amikor az R2 frissítést küld az R3-nak, a harmadik útválasztó egy bejegyzést helyez el az útválasztási táblázatába, amely szerint a 192.168.1.0 hálózat elérhető a 192.168.3.3 útválasztó interfészen keresztül RIP-n keresztül, 2-es ugrásszámmal. Így működik az útválasztási frissítés. .
Az útválasztási hurkok vagy a végtelen számlálás elkerülése érdekében a RIP rendelkezik egy osztott horizontú mechanizmussal. Ez a mechanizmus egy szabály: "ne küldjön hálózati vagy útvonal-frissítést azon az interfészen keresztül, amelyen keresztül a frissítést megkapta." Esetünkben ez így néz ki: ha az R2 frissítést kapott az R1-től a 192.168.1.0 hálózatról az f0/0: 192.168.2.2 interfészen keresztül, akkor nem küldhet frissítést erről a 0 hálózatról az első útválasztónak az f0/2.0 interfészen keresztül. . Csak a 192.168.3.0 és 192.168.4.0 hálózatokat érintő frissítéseket tud küldeni ezen az első útválasztóhoz társított interfészen keresztül. A 192.168.2.0 hálózatról sem szabad frissítést küldenie az f0/0 interfészen keresztül, mert ez az interfész már tud róla, mivel ez a hálózat közvetlenül kapcsolódik hozzá. Tehát amikor a második útválasztó frissítést küld az első útválasztónak, annak csak a 3.0-s és 4.0-s hálózatokról kell rekordokat tartalmaznia, mivel ezekről a hálózatokról egy másik interfészről - f0/1 - értesült.
Ez a horizont felosztásának egyszerű szabálya: soha ne küldjön információt egyetlen útvonalról sem ugyanabba az irányba, ahonnan az információ érkezett. Ez a szabály megakadályozza az útválasztási hurkot vagy a végtelenségig történő számlálást.
Ha megnézi a Packet Tracer-t, láthatja, hogy az R1 csak két hálózatról kapott frissítést a 192.168.2.2-ről a GigabitEthernet0/1 interfészen keresztül: a 3.0 és a 4.0. A második router nem jelentett semmit az 1.0-s és 2.0-s hálózatokról, mert éppen ezen az interfészen keresztül értesült ezekről a hálózatokról.
Az első R1 útválasztó frissítést küld a 224.0.0.9 számú multicast IP-címre – nem küld broadcast üzenetet. Ez a cím olyan, mint egy adott frekvencia, amelyen az FM rádióállomások sugároznak, vagyis csak azok a készülékek kapják az üzenetet, amelyek erre a multicast címre vannak hangolva. Ugyanígy az útválasztók úgy konfigurálják magukat, hogy fogadják a forgalmat a 224.0.0.9 címre. Tehát az R1 frissítést küld erre a címre a GigabitEthernet0/0 interfészen keresztül 192.168.1.1 IP-címmel. Ennek az interfésznek csak a 2.0, 3.0 és 4.0 hálózatokról kell frissítéseket továbbítania, mivel az 1.0 hálózat közvetlenül kapcsolódik hozzá. Látjuk, hogy ezt teszi.
Ezután frissítést küld a második f0/1 interfészen keresztül a 192.168.2.1 címmel. Hagyja figyelmen kívül az F betűt a FastEthernet esetében - ez csak egy példa, mivel útválasztóink GigabitEthernet interfészekkel rendelkeznek, amelyeket g betűvel kell jelölni. A 2.0, 3.0 és 4.0 hálózatokról ezen az interfészen keresztül nem tud frissítést küldeni, mert az f0/1 interfészen keresztül értesült róluk, így csak az 1.0 hálózatról küld frissítést.
Nézzük meg, mi történik, ha valamiért megszakad a kapcsolat az első hálózattal. Ebben az esetben az R1 azonnal bekapcsol egy „útmérgezés” nevű mechanizmusba. Ez abban rejlik, hogy amint megszakad a kapcsolat a hálózattal, az ugrások száma az útválasztási táblázatban a hálózatra vonatkozó bejegyzésben azonnal 16-ra nő. Mint tudjuk, a 16-nak megfelelő ugrások száma azt jelenti, hogy ez a hálózat nem elérhető.
Ebben az esetben az Update timer nincs használatban, ez egy trigger frissítés, amely azonnal elküldésre kerül a hálózaton keresztül a legközelebbi útválasztóhoz. Kék színnel jelölöm a diagramon. Az R2 router frissítést kap, amely szerint mostantól a 192.168.1.0 hálózat 16 ugrásszámmal érhető el, azaz elérhetetlen. Ezt nevezik útvonalmérgezésnek. Amint az R2 megkapja ezt a frissítést, azonnal 192.168.1.0-ra módosítja a 16 bejegyzéssor ugrásértékét, és elküldi ezt a frissítést a harmadik útválasztónak. Az R3 viszont az elérhetetlen hálózat ugrásainak számát is 16-ra módosítja. Így minden RIP-en keresztül csatlakoztatott eszköz tudja, hogy a 192.168.1.0 hálózat már nem elérhető.
Ezt a folyamatot konvergenciának nevezik. Ez azt jelenti, hogy minden útválasztó frissíti az útválasztási tábláit az aktuális állapotra, kizárva a 192.168.1.0 hálózatba vezető útvonalat.
Tehát a mai lecke összes témájával foglalkoztunk. Most megmutatom a hálózati problémák diagnosztizálására és hibaelhárítására használt parancsokat. A show ip interface short parancson kívül létezik a show ip protocols parancs is. Megmutatja a dinamikus útválasztást használó eszközök útválasztási protokoll beállításait és állapotát.
A parancs használata után információ jelenik meg az útválasztó által használt protokollokról. Itt azt írja ki, hogy az útválasztási protokoll RIP, a frissítések 30 másodpercenként kerülnek elküldésre, a következő frissítés 8 másodperc után, az Invalid timer 180 másodperc után indul, a Hold Down időzítő 180 másodperc után indul, az öblítési időzítő pedig azután indul. 240 másodperc. Ezek az értékek változtathatók, de ez nem a CCNA tanfolyamunk témája, ezért az alapértelmezett időzítő értékeket fogjuk használni. Hasonlóképpen, kurzusunk nem foglalkozik a kimenő és bejövő szűrési lista frissítéseivel az összes útválasztó interfészéhez.
Következő itt a protokollok újraelosztása - RIP, ez a lehetőség akkor használatos, ha az eszköz több protokollt használ, például megmutatja, hogy a RIP hogyan kommunikál az OSPF-fel és az OSPF a RIP-pel. Az újraelosztás szintén nem tartozik a CCNA tanfolyam hatókörébe.
Továbbá látható, hogy a protokoll az útvonalak automatikus összesítését használja, amit az előző videóban tárgyaltunk, és az adminisztratív távolság 120, amit szintén már tárgyaltunk.
Nézzük meg közelebbről a show ip route parancsot. Látja, hogy a 192.168.1.0/24 és a 192.168.2.0/24 hálózatok közvetlenül csatlakoznak az útválasztóhoz, további két hálózat, a 3.0 és a 4.0 használja a RIP útválasztási protokollt. Mindkét hálózat elérhető a GigabitEthernet0/1 interfészen és a 192.168.2.2 IP-című eszközön keresztül. A szögletes zárójelben lévő információ fontos - az első szám az adminisztratív távolságot, vagy adminisztratív távolságot, a második az ugrások számát jelenti. Az ugrások száma a RIP protokoll mérőszáma. Más protokolloknak, például az OSPF-nek, megvannak a saját mérőszámai, amelyekről a megfelelő téma tanulmányozásakor fogunk beszélni.
Amint arról már beszéltünk, az adminisztratív távolság a bizalom mértékére utal. A bizalom maximális fokának statikus útvonala van, amelynek adminisztratív távolsága 1. Ezért minél alacsonyabb ez az érték, annál jobb.
Tegyük fel, hogy a 192.168.3.0/24-es hálózat elérhető mind a RIP-t használó g0/1, mind a statikus útválasztást használó g0/0 interfészen keresztül. Ebben az esetben a router az összes forgalmat a statikus útvonalon az f0/0-n keresztül irányítja, mert ez az útvonal megbízhatóbb. Ebben az értelemben egy 120-as adminisztratív távolságú RIP protokoll rosszabb, mint egy 1-es távolságú statikus útválasztási protokoll.
A problémák diagnosztizálásához egy másik fontos parancs a show ip interface g0/1 parancs. Minden információt megjelenít egy adott útválasztó port paramétereiről és állapotáról.
Számunkra fontos az a sor, amelyik azt mondja, hogy a horizont felosztása engedélyezve van: a Split horizont engedélyezve van, mert problémái lehetnek, ha ez a mód le van tiltva. Ezért, ha problémák lépnek fel, győződjön meg arról, hogy az osztott horizont mód engedélyezve van ezen a felületen. Kérjük, vegye figyelembe, hogy alapértelmezés szerint ez a mód aktív.
Úgy gondolom, hogy eleget foglalkoztunk a RIP-pel kapcsolatos témával ahhoz, hogy ez a téma ne okozzon nehézséget a vizsgán.
Köszönjük, hogy velünk tartott. Tetszenek cikkeink? További érdekes tartalmakat szeretne látni? Támogass minket rendeléssel vagy ajánlj ismerőseidnek, 30% kedvezmény a Habr felhasználóknak a belépő szintű szerverek egyedülálló analógjára, amelyet mi találtunk ki Önnek: (RAID1 és RAID10, akár 24 maggal és akár 40 GB DDR4-gyel is elérhető).
Dell R730xd kétszer olcsóbb? Csak itt Hollandiában! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollártól! Olvasni valamiről
Forrás: will.com