Sanoin jo, että aion päivittää opetusvideoni CCNA v3:een. Kaikki, mitä opit edellisillä tunneilla, liittyy täysin uuteen kurssiin. Jos tarvetta ilmenee, lisään uusia aiheita uusille tunneille, jotta voit olla varma, että oppituntimme ovat linjassa 200-125 CCNA-kurssin kanssa.
Ensin tutkimme täysin ensimmäisen kokeen 100-105 ICND1 aiheita. Meillä on vielä muutama oppitunti jäljellä, minkä jälkeen olet valmis suorittamaan tämän kokeen. Sitten alamme opiskella ICND2-kurssia. Takaan, että tämän videokurssin loppuun mennessä olet täysin valmis suorittamaan 200-125 kokeen. Viime oppitunnilla sanoin, että emme palaa RIP:iin, koska se ei sisälly CCNA-kurssiin. Mutta koska RIP sisällytettiin CCNA:n kolmanteen versioon, jatkamme sen tutkimista.
Tämän päivän oppitunnin aiheina ovat kolme RIP:n käytön yhteydessä esiin nousevaa ongelmaa: Counting to Infinity, tai Counting to Infinity, Split Horizon - Split Horizons and Route Poison eli reittimyrkytys.
Ymmärtääksemme äärettömyyteen laskemisen ongelman olemuksen, siirrytään kaavioon. Oletetaan, että meillä on reititin R1, reititin R2 ja reititin R3. Ensimmäinen reititin on yhdistetty toiseen 192.168.2.0/24-verkolla, toinen kolmanteen 192.168.3.0/24-verkolla, ensimmäinen reititin on yhdistetty 192.168.1.0/24-verkkoon ja kolmas verkkoon 192.168.4.0/24-verkko.
Katsotaanpa reittiä 192.168.1.0/24-verkkoon ensimmäisestä reitittimestä. Taulukossa tämä reitti näkyy muodossa 192.168.1.0 ja hyppyjen määrä on 0.
Toiselle reitittimelle sama reitti näkyy taulukossa nimellä 192.168.1.0 hyppyjen määrällä 1. Tässä tapauksessa Päivitysajastin päivittää reitittimen reititystaulukon 30 sekunnin välein. R1 ilmoittaa R2:lle, että verkko 192.168.1.0 on tavoitettavissa sen kautta hyppyillä, jotka ovat yhtä suuria kuin 0. Vastaanotettuaan tämän viestin R2 vastaa päivityksellä, että sama verkko on tavoitettavissa sen kautta yhdellä hyppyllä. Näin toimii tavallinen RIP-reititys.
Kuvitellaanpa tilanne, jossa yhteys R1:n ja 192.168.1.0/24-verkon välillä katkesi, minkä jälkeen reititin menetti pääsyn siihen. Samaan aikaan reititin R2 lähettää päivityksen reitittimelle R1, jossa se ilmoittaa, että verkko 192.168.1.0/24 on sen käytettävissä yhdellä hyppyllä. R1 tietää menettäneensä pääsyn tähän verkkoon, mutta R2 väittää, että tämä verkko on käytettävissä hänen kauttaan yhdellä hyppyllä, joten ensimmäinen reititin uskoo, että sen on päivitettävä reititystaulukkonsa muuttamalla hyppyjen lukumäärä 0:sta 2:een.
Tämän jälkeen R1 lähettää päivityksen reitittimelle R2. Hän sanoo: "ok, ennen sitä lähetit minulle päivityksen, että verkko 192.168.1.0 on saatavilla nollahyppelyllä, nyt ilmoitat, että reitti tähän verkkoon voidaan rakentaa kahdessa hyppyssä. Joten minun on päivitettävä reititystaulukkoni yhdestä kolmeen." Seuraavassa päivityksessä R2 muuttaa hyppyjen määrän 1:ksi, toinen reititin 3:ksi, sitten 1:ksi ja 4:ksi, ja tämä prosessi jatkuu loputtomiin.
Tämä ongelma tunnetaan reitityssilmukana, ja RIP:ssä sitä kutsutaan count-to-infinity -ongelmaksi. Todellisuudessa verkko 192.168.1.0/24 ei ole käytettävissä, mutta R1, R2 ja kaikki muut verkon reitittimet uskovat, että siihen voidaan käyttää, koska reitti jatkuu silmukan. Tämä ongelma voidaan ratkaista käyttämällä horisonttijako- ja reittimyrkytysmekanismeja. Katsotaanpa verkkotopologiaa, jonka kanssa työskentelemme tänään.
Verkossa on kolme reititintä R1,2,3 ja kaksi tietokonetta, joiden IP-osoitteet ovat 192.168.1.10 ja 192.168.4.10. Tietokoneiden välillä on 4 verkkoa: 1.0, 2.0, 3.0 ja 4.0. Reitittimillä on IP-osoitteet, joissa viimeinen oktetti on reitittimen numero ja toiseksi viimeinen oktetti on verkon numero. Voit määrittää näille verkkolaitteille mitä tahansa osoitteita, mutta pidän näistä mieluummin, koska niiden avulla minun on helpompi selittää.
Jos haluat määrittää verkkomme, siirrytään Packet Traceriin. Käytän Cisco 2911 -reitittimiä ja käytän tätä mallia IP-osoitteiden määrittämiseen sekä isäntäkoneille PC0 että PC1.
Voit jättää kytkimet huomioimatta, koska ne ovat "suoraan pakkauksesta" ja käyttävät oletusarvoisesti VLAN1:tä. 2911-reitittimissä on kaksi gigabitin porttia. Helpottaaksemme toimintaamme käytän jokaiselle näistä reitittimistä valmiita määritystiedostoja. Voit vierailla verkkosivustollamme, mennä Resurssit-välilehteen ja katsoa kaikki video-opetusohjelmamme.
Meillä ei ole täällä tällä hetkellä kaikkia päivityksiä, mutta esimerkkinä voit katsoa 13. päivän oppituntia, jossa on työkirjalinkki. Sama linkki liitetään tämän päivän opetusvideoon, ja sitä seuraamalla voit ladata reitittimen asetustiedostot.
Reitittimien konfiguroimiseksi yksinkertaisesti kopioin R1-asetustekstitiedoston sisällön, avaan sen konsolin Packet Tracerissa ja kirjoitan config t -komennon.
Sitten liitän vain kopioitua tekstiä ja poistun asetuksista.
Teen samoin toisen ja kolmannen reitittimen asetuksilla. Tämä on yksi Ciscon asetusten eduista – voit yksinkertaisesti kopioida ja liittää tarvitsemasi asetukset verkkolaitteen asetustiedostoihin. Minun tapauksessani lisään myös 2 komentoa valmiiden asetustiedostojen alkuun, jotta en syötä niitä konsoliin - nämä ovat en (enable) ja config t. Sitten kopioin sisällön ja liitän koko jutun R3-asetuskonsoliin.
Joten olemme määrittäneet kaikki 3 reititintä. Jos haluat käyttää valmiita konfiguraatiotiedostoja reitittimillesi, varmista, että mallit vastaavat tässä kaaviossa esitettyjä - tässä reitittimissä on GigabitEthernet-portit. Sinun on ehkä korjattava tämä rivi FastEthernet-tiedostossa, jos reitittimessäsi on täsmälleen nämä portit.
Voit nähdä, että kaavion reitittimen porttimerkit ovat edelleen punaisia. Mikä on ongelma? Tee diagnoosi siirtymällä reitittimen 1 IOS-komentoriviliittymään ja kirjoittamalla show ip interface short -komento. Tämä komento on "sveitsiveitsi" kun ratkaiset erilaisia verkkoongelmia.
Kyllä, meillä on ongelma - näet, että GigabitEthernet 0/0 -liitäntä on hallinnollisesti alhaalla. Tosiasia on, että unohdin käyttää kopioidussa asetustiedostossa no shutdown -komentoa ja nyt syötän sen manuaalisesti.
Nyt minun on lisättävä tämä rivi manuaalisesti kaikkien reitittimien asetuksiin, minkä jälkeen porttimerkit muuttuvat vihreäksi. Nyt näytän kaikki kolme reitittimien CLI-ikkunaa yhteisellä näytöllä, jotta toimintojeni tarkkailu olisi helpompaa.
Tällä hetkellä RIP-protokolla on konfiguroitu kaikissa kolmessa laitteessa ja debug ip rip -komennolla, jonka jälkeen kaikki laitteet vaihtavat RIP-päivityksiä. Sen jälkeen käytän undebug all -komentoa kaikille kolmelle reitittimelle.
Voit nähdä, että R3:lla on vaikeuksia löytää DNS-palvelinta. Keskustelemme CCNA v3 DNS -palvelinaiheista myöhemmin, ja näytän sinulle, kuinka voit poistaa hakuominaisuuden käytöstä kyseiseltä palvelimelta. Palataan toistaiseksi oppitunnin aiheeseen ja katsotaan kuinka RIP-päivitys toimii.
Kun kytkemme reitittimet päälle, niiden reititystaulukot sisältävät merkintöjä verkoista, jotka on kytketty suoraan niiden portteihin. Taulukoissa nämä tietueet on otsikoitu kirjaimella C, ja suoran yhteyden hyppyjen määrä on 0.
Kun R1 lähettää päivityksen R2:lle, se sisältää tietoja verkoista 192.168.1.0 ja 192.168.2.0. Koska R2 tietää jo verkosta 192.168.2.0, se laittaa vain verkkoa 192.168.1.0 koskevan päivityksen reititystaulukkoonsa.
Tämän merkinnän otsikko on kirjain R, mikä tarkoittaa, että yhteys 192.168.1.0-verkkoon on mahdollista reitittimen liitännän f0/0: 192.168.2.2 kautta vain RIP-protokollan kautta hyppyjen määrällä 1.
Vastaavasti, kun R2 lähettää päivityksen R3:lle, kolmas reititin asettaa reititystaulukkoonsa merkinnän, jonka mukaan verkkoon 192.168.1.0 pääsee reitittimen liitännän 192.168.3.3 kautta RIP:n kautta 2 hyppymäärällä. Näin reitityspäivitys toimii. .
Reitityssilmukoiden tai loputtoman laskennan estämiseksi RIP:ssä on jaettu horisonttimekanismi. Tämä mekanismi on sääntö: "älä lähetä verkko- tai reittipäivitystä sen käyttöliittymän kautta, jonka kautta sait päivityksen." Meidän tapauksessamme se näyttää tältä: jos R2 sai päivityksen R1:ltä verkkoon 192.168.1.0 liitännän f0/0 kautta: 192.168.2.2, sen ei pitäisi lähettää tätä verkkoa 0 koskevaa päivitystä ensimmäiselle reitittimelle liitännän f0/2.0 kautta. . Se voi lähettää vain päivityksiä tämän ensimmäiseen reitittimeen liittyvän liitännän kautta, jotka koskevat verkkoja 192.168.3.0 ja 192.168.4.0. Sen ei myöskään pitäisi lähettää päivitystä verkosta 192.168.2.0 f0/0-liitännän kautta, koska tämä liitäntä jo tietää sen, koska tämä verkko on suoraan yhteydessä siihen. Joten kun toinen reititin lähettää päivityksen ensimmäiselle reitittimelle, sen tulisi sisältää tietueita vain verkoista 3.0 ja 4.0, koska se oppi näistä verkoista toisesta liitännästä - f0/1.
Tämä on yksinkertainen horisontin jaon sääntö: älä koskaan lähetä tietoa mistään reitistä takaisin samaan suuntaan, josta tieto tuli. Tämä sääntö estää reitityssilmukan tai laskemisen äärettömään.
Jos katsot Packet Tracer -ohjelmaa, voit nähdä, että R1 sai päivityksen 192.168.2.2:sta GigabitEthernet0/1-liitännän kautta vain kahdesta verkosta: 3.0 ja 4.0. Toinen reititin ei ilmoittanut mitään verkoista 1.0 ja 2.0, koska se sai tietää näistä verkoista juuri tämän käyttöliittymän kautta.
Ensimmäinen reititin R1 lähettää päivityksen ryhmälähetyksen IP-osoitteeseen 224.0.0.9 - se ei lähetä yleislähetysviestiä. Tämä osoite on jotain tiettyä taajuutta, jolla FM-radioasemat lähettävät, eli vain ne laitteet, jotka on viritetty tähän monilähetysosoitteeseen, vastaanottavat viestin. Samalla tavalla reitittimet määrittävät itsensä hyväksymään liikennettä osoitteeseen 224.0.0.9. Joten R1 lähettää päivityksen tähän osoitteeseen GigabitEthernet0/0-liitännän kautta IP-osoitteella 192.168.1.1. Tämän liitännän tulee lähettää vain päivityksiä verkoista 2.0, 3.0 ja 4.0, koska verkko 1.0 on kytketty siihen suoraan. Näemme hänen tekevän juuri niin.
Seuraavaksi se lähettää päivityksen toisen liitännän f0/1 kautta osoitteella 192.168.2.1. Jätä huomioimatta F-kirjain FastEthernetissä - tämä on vain esimerkki, koska reitittimillämme on GigabitEthernet-liitännät, jotka tulisi merkitä kirjaimella g. Hän ei voi lähettää päivitystä verkoista 2.0, 3.0 ja 4.0 tämän käyttöliittymän kautta, koska hän sai tiedon niistä f0/1-rajapinnan kautta, joten hän lähettää vain päivityksen verkosta 1.0.
Katsotaan mitä tapahtuu, jos yhteys ensimmäiseen verkkoon katkeaa jostain syystä. Tässä tapauksessa R1 aktivoi välittömästi mekanismin, jota kutsutaan "reittimyrkytykseksi". Se johtuu siitä, että heti kun yhteys verkkoon katkeaa, hyppyjen määrä reititystaulukon tämän verkon merkinnässä kasvaa välittömästi 16:een. Kuten tiedämme, hyppyjen määrä 16 tarkoittaa, että tämä verkko ei ole käytettävissä.
Tässä tapauksessa päivitysajastinta ei käytetä, vaan se on käynnistyspäivitys, joka lähetetään välittömästi verkon kautta lähimmälle reitittimelle. Merkitsen sen kaavioon sinisellä. Reititin R2 saa päivityksen, jossa sanotaan, että tästä lähtien verkko 192.168.1.0 on saatavilla 16 hyppymäärällä, eli siihen ei päästä. Tätä kutsutaan reittimyrkytykseksi. Heti kun R2 vastaanottaa tämän päivityksen, se muuttaa välittömästi hyppyarvon 192.168.1.0-syöttörivillä 16:ksi ja lähettää tämän päivityksen kolmanteen reitittimeen. R3 puolestaan muuttaa myös tavoittamattoman verkon hyppyjen määrän 16:ksi. Näin kaikki RIP:n kautta kytketyt laitteet tietävät, että verkko 192.168.1.0 ei ole enää käytettävissä.
Tätä prosessia kutsutaan konvergenssiksi. Tämä tarkoittaa, että kaikki reitittimet päivittävät reititystaulukkonsa nykyiseen tilaan, jättäen reitin 192.168.1.0-verkkoon niistä pois.
Joten olemme käsitelleet kaikki tämän päivän oppitunnin aiheet. Nyt näytän sinulle komennot, joita käytetään verkko-ongelmien diagnosointiin ja vianmääritykseen. Show ip interface short -komennon lisäksi on show ip protocols -komento. Se näyttää reititysprotokollan asetukset ja tilan laitteille, jotka käyttävät dynaamista reititystä.
Tämän komennon käytön jälkeen näkyviin tulee tietoja tämän reitittimen käyttämistä protokollista. Tässä lukee, että reititysprotokolla on RIP, päivitykset lähetetään 30 sekunnin välein, seuraava päivitys lähetetään 8 sekunnin kuluttua, Invalid ajastin käynnistyy 180 sekunnin kuluttua, Hold Down -ajastin alkaa 180 sekunnin kuluttua ja huuhteluajastin alkaa tämän jälkeen. 240 sekuntia. Näitä arvoja voidaan muuttaa, mutta tämä ei ole CCNA-kurssimme aihe, joten käytämme oletusajastimen arvoja. Kurssimme ei myöskään käsittele kaikkien reitittimen liitäntöjen lähtevien ja saapuvien suodatusluettelopäivitysten ongelmia.
Seuraavaksi tässä on protokollan uudelleenjako - RIP, tätä vaihtoehtoa käytetään, kun laite käyttää useita protokollia, esimerkiksi se näyttää kuinka RIP on vuorovaikutuksessa OSPF:n kanssa ja kuinka OSPF on vuorovaikutuksessa RIP:n kanssa. Uudelleenjako ei myöskään kuulu CCNA-kurssiisi.
Edelleen näytetään, että protokolla käyttää automaattista reittien yhteenvetoa, josta keskustelimme edellisessä videossa, ja että hallinnollinen etäisyys on 120, josta myös jo keskustelimme.
Katsotaanpa tarkemmin show ip route -komentoa. Näet, että verkot 192.168.1.0/24 ja 192.168.2.0/24 ovat suoraan yhteydessä reitittimeen, kaksi muuta verkkoa, 3.0 ja 4.0, käyttävät RIP-reititysprotokollaa. Molemmat verkot ovat käytettävissä GigabitEthernet0/1-liitännän ja IP-osoitteen 192.168.2.2 laitteen kautta. Hakasulkeissa olevat tiedot ovat tärkeitä - ensimmäinen numero tarkoittaa hallinnollista etäisyyttä tai hallinnollista etäisyyttä, toinen - hyppyjen määrää. Hyppyjen määrä on RIP-protokollan metri. Muilla protokollilla, kuten OSPF:llä, on omat mittarinsa, joista puhumme vastaavaa aihetta tutkiessamme.
Kuten olemme jo käsitelleet, hallinnollinen etäisyys viittaa luottamuksen asteeseen. Maksimiluottamusasteella on staattinen reitti, jonka hallinnollinen etäisyys on 1. Siksi mitä pienempi tämä arvo, sitä parempi.
Oletetaan, että verkkoon 192.168.3.0/24 pääsee sekä RIP:tä käyttävän liitännän g0/1 kautta että staattista reititystä käyttävän liitännän g0/0 kautta. Tässä tapauksessa reititin reitittää kaiken staattisen reitin liikenteen f0/0:n kautta, koska tämä reitti on luotettavampi. Tässä mielessä RIP-protokolla, jonka hallinnollinen etäisyys on 120, on huonompi kuin staattinen reititysprotokolla, jonka etäisyys on 1.
Toinen tärkeä komento ongelmien diagnosoinnissa on show ip interface g0/1 -komento. Se näyttää kaikki tiedot tietyn reitittimen portin parametreista ja tilasta.
Meille rivi, joka sanoo, että jaettu horisontti on käytössä, on tärkeä: Split Horizon on käytössä, koska sinulla voi olla ongelmia, koska tämä tila on poistettu käytöstä. Siksi, jos ongelmia ilmenee, varmista, että jaettu horisontti -tila on käytössä tässä käyttöliittymässä. Huomaa, että tämä tila on oletuksena aktiivinen.
Uskon, että olemme käsitelleet tarpeeksi RIP-aiheita, jotta sinulla ei pitäisi olla vaikeuksia tämän aiheen kanssa kokeen suorittamisen aikana.
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, 30 %:n alennus Habr-käyttäjille ainutlaatuisesta lähtötason palvelimien analogista, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com