I dag skal vi begynne å studere EIGRP-protokollen, som sammen med å studere OSPF er det viktigste temaet på CCNA-kurset.
Vi kommer tilbake til seksjon 2.5 senere, men foreløpig, rett etter seksjon 2.4, går vi videre til seksjon 2.6, "Konfigurering, verifisering og feilsøking av EIGRP over IPv4 (ekskludert autentisering, filtrering, manuell oppsummering, redistribuering og stub). konfigurasjon).»
I dag vil vi ha en introduksjonsleksjon der jeg vil introdusere deg til konseptet med Enhanced Internal Gateway Routing Protocol EIGRP, og i de neste to leksjonene skal vi se på konfigurering og feilsøking av protokollens roboter. Men først vil jeg fortelle deg følgende.
I løpet av de siste timene har vi lært om OSPF. Nå vil jeg at du skal huske at da vi så på RIP for mange måneder siden, snakket vi om rutingsløyfer og teknologier som hindrer trafikk i å gå i loop. Hvordan kan du forhindre rutingløkker når du bruker OSPF? Er det mulig å bruke metoder som Route Poison eller Split Horizon for dette? Dette er spørsmål du må svare på selv. Du kan bruke andre tematiske ressurser, men finn svar på disse spørsmålene. Jeg vil at du skal lære hvordan du finner svarene selv ved å jobbe med forskjellige kilder, og jeg oppfordrer deg til å legge igjen kommentarene dine under denne videoen slik at jeg kan se hvor mange av elevene mine som har fullført denne oppgaven.
Hva er EIGRP? Det er en hybrid rutingprotokoll som kombinerer de nyttige funksjonene til både en avstandsvektorprotokoll som RIP og en link-state-protokoll som OSPF.
EIGRP er en proprietær Cisco-protokoll som ble gjort tilgjengelig for publikum i 2013. Fra protokollen for sporing av koblingstilstand tok han i bruk en algoritme for etablering av nabolag, i motsetning til RIP, som ikke skaper naboer. RIP utveksler også rutingtabeller med andre deltakere i protokollen, men OSPF danner en tilknytning før du starter denne utvekslingen. EIGRP fungerer på samme måte.
RIP-protokollen oppdaterer med jevne mellomrom den fullstendige rutetabellen hvert 30. sekund og distribuerer informasjon om alle grensesnitt og alle ruter til alle naboene. EIGRP utfører ikke periodiske fullstendige oppdateringer av informasjon, i stedet bruker konseptet med å kringkaste Hello-meldinger på samme måte som OSPF gjør. Med noen sekunders mellomrom sender den en Hei for å sikre at naboen fortsatt er "i live".
I motsetning til avstandsvektorprotokollen, som undersøker hele nettverkstopologien før man bestemmer seg for å danne en rute, lager EIGRP, som RIP, ruter basert på rykter. Når jeg sier rykter, mener jeg at når en nabo melder fra om noe, er EIGRP enig i det uten spørsmål. For eksempel, hvis en nabo sier at han vet hvordan han skal nå 10.1.1.2, tror EIGRP ham uten å spørre: «Hvordan visste du det? Fortell meg om topologien til hele nettverket!
Før 2013, hvis du bare brukte Cisco-infrastruktur, kunne du bruke EIGRP, siden denne protokollen ble opprettet tilbake i 1994. Mange selskaper, selv ved bruk av Cisco-utstyr, ønsket imidlertid ikke å jobbe med dette gapet. Etter min mening er EIGRP den beste dynamiske rutingprotokollen i dag fordi den er mye enklere å bruke, men folk foretrekker fortsatt OSPF. Jeg tror dette skyldes at de ikke ønsker å være bundet til Cisco-produkter. Men Cisco gjorde denne protokollen offentlig tilgjengelig fordi den støtter tredjeparts nettverksutstyr som Juniper, og hvis du slår deg sammen med et selskap som ikke bruker Cisco-utstyr, vil du ikke ha noen problemer.
La oss ta en kort ekskursjon inn i historien til nettverksprotokoller.
RIPv1-protokollen, som dukket opp på 1980-tallet, hadde en rekke begrensninger, for eksempel et maksimalt antall hopp på 16, og kunne derfor ikke gi ruting over store nettverk. Litt senere utviklet de den interne gateway-rutingsprotokollen IGRP, som var mye bedre enn RIP. Imidlertid var det mer en avstandsvektorprotokoll enn en lenketilstandsprotokoll. På slutten av 80-tallet dukket det opp en åpen standard, OSPFv2 link state protocol for IPv4.
På begynnelsen av 90-tallet bestemte Cisco at IGRP måtte forbedres og ga ut Enhanced Internal Gateway Routing Protocol EIGRP. Det var mye mer effektivt enn OSPF fordi det kombinerte funksjonene til både RIP og OSPF. Når vi begynner å utforske det, vil du se at EIGRP er mye enklere å konfigurere enn OSPF. Cisco prøvde å lage en protokoll som ville sikre raskest mulig nettverkskonvergens.
På slutten av 90-tallet ble en oppdatert klasseløs versjon av RIPv2-protokollen utgitt. På 2000-tallet dukket den tredje versjonen av OSPF, RIPng og EIGRPv6, som støttet IPv6-protokollen, opp. Verden nærmer seg gradvis en full overgang til IPv6, og utviklere av rutingprotokoller ønsker å være klare for dette.
Hvis du husker, studerte vi at når du velger den optimale ruten, styres RIP, som en avstandsvektorprotokoll, av bare ett kriterium - minimum antall hopp, eller minimum avstand til destinasjonsgrensesnittet. Så ruter R1 vil velge en direkte rute til ruter R3, til tross for at hastigheten på denne ruten er 64 kbit/s - flere ganger mindre enn hastigheten på ruten R1-R2-R3, lik 1544 kbit/s. RIP-protokollen vil vurdere en langsom rute på en hopplengde som optimal i stedet for en rask rute på 2 hopp.
OSPF vil studere hele nettverkstopologien og bestemme seg for å bruke ruten gjennom R3 som den raskere ruten for kommunikasjon med ruter R2. RIP bruker antall hopp som beregning, mens OSPFs beregning er kostnad, som i de fleste tilfeller er proporsjonal med båndbredden til koblingen.
EIGRP fokuserer også på rutekostnader, men beregningen er mye mer kompleks enn OSPF og er avhengig av mange faktorer, inkludert båndbredde, forsinkelse, pålitelighet, lasting og maksimal MTU. For eksempel, hvis en node er mer belastet enn andre, vil EIGRP analysere belastningen på hele ruten og velge en annen node med mindre belastning.
I CCNA-kurset vil vi kun ta hensyn til slike metriske dannelsesfaktorer som båndbredde og forsinkelse dette er de som den metriske formelen vil bruke.
Avstandsvektorprotokollen RIP bruker to konsepter: avstand og retning. Hvis vi har 3 rutere, og en av dem er koblet til 20.0.0.0-nettverket, vil valget bli tatt etter avstand - dette er hopp, i dette tilfellet 1 hopp, og etter retning, det vil si langs hvilken bane - øvre eller lavere - for å sende trafikk.
I tillegg bruker RIP periodisk oppdatering av informasjon, og distribuerer en komplett rutetabell over hele nettverket hvert 30. sekund. Denne oppdateringen gjør 2 ting. Den første er den faktiske oppdateringen av rutingtabellen, den andre er å sjekke levedyktigheten til naboen. Hvis enheten ikke mottar en responstabelloppdatering eller ny ruteinformasjon fra naboen innen 30 sekunder, forstår den at ruten til naboen ikke lenger kan brukes. Ruteren sender en oppdatering hvert 30. sekund for å finne ut om naboen fortsatt er i live og om ruten fortsatt er gyldig.
Som sagt brukes Split Horizon-teknologi for å forhindre rutesløyfer. Dette betyr at oppdateringen ikke sendes tilbake til grensesnittet den kom fra. Den andre teknologien for å forhindre løkker er Route Poison. Hvis forbindelsen med 20.0.0.0-nettverket vist på bildet blir avbrutt, sender ruteren som den ble koblet til en "forgiftet rute" til naboene, der den rapporterer at dette nettverket nå er tilgjengelig i 16 hopp, dvs. praktisk talt uoppnåelig. Dette er hvordan RIP-protokollen fungerer.
Hvordan fungerer EIGRP? Hvis du husker fra leksjonene om OSPF, utfører denne protokollen tre funksjoner: den etablerer et nabolag, bruker LSA til å oppdatere LSDB i samsvar med endringer i nettverkstopologien, og bygger en rutetabell. Å etablere et nabolag er en ganske kompleks prosedyre som bruker mange parametere. For eksempel sjekke og endre en 2WAY-forbindelse - noen tilkoblinger forblir i toveiskommunikasjonstilstand, noen går til FULL-tilstand. I motsetning til OSPF skjer ikke dette i EIGRP-protokollen - den sjekker kun 4 parametere.
I likhet med OSPF sender denne protokollen en Hello-melding som inneholder 10 parametere hvert 4. sekund. Det første er autentiseringskriteriet, hvis det har vært konfigurert tidligere. I dette tilfellet må alle enheter som det etableres nærhet med, ha de samme autentiseringsparametrene.
Den andre parameteren brukes til å sjekke om enheter tilhører det samme autonome systemet, det vil si at for å etablere tilknytning ved bruk av EIGRP-protokollen, må begge enhetene ha samme autonome systemnummer. Den tredje parameteren brukes til å kontrollere at Hello-meldinger sendes fra samme kilde-IP-adresse.
Den fjerde parameteren brukes til å kontrollere konsistensen til variabelen K-verdi-koeffisienter. EIRGP-protokollen bruker 5 slike koeffisienter fra K1 til K5. Hvis du husker, hvis K=0 ignoreres parametrene, men hvis K=1, brukes parametrene i formelen for beregning av metrikken. Dermed må verdiene til K1-5 for forskjellige enheter være de samme. I CCNA-kurset tar vi standardverdiene til disse koeffisientene: K1 og K3 er lik 1, og K2, K4 og K5 er lik 0.
Så hvis disse 4 parameterne samsvarer, etablerer EIGRP et naboforhold og enhetene går inn i nabotabellen. Deretter gjøres endringer i topologitabellen.
Alle Hello-meldinger sendes til multicast-IP-adressen 224.0.0.10, og oppdateringer, avhengig av konfigurasjonen, sendes til unicast-adressene til naboer eller til multicast-adressen. Denne oppdateringen kommer ikke over UDP eller TCP, men bruker en annen protokoll kalt RTP, Reliable Transport Protocol. Denne protokollen sjekker om naboen har mottatt en oppdatering, og som navnet antyder, er dens nøkkelfunksjon å sikre kommunikasjonspålitelighet. Hvis oppdateringen ikke når naboen, vil overføringen gjentas til naboen mottar den. OSPF har ikke en mekanisme for å sjekke mottakerenheten, så systemet vet ikke om naboenheter har mottatt oppdateringen eller ikke.
Hvis du husker det, sender RIP ut en oppdatering av hele nettverkstopologien hvert 30. sekund. EIGRP gjør dette bare hvis en ny enhet har dukket opp på nettverket eller noen endringer har skjedd. Hvis subnett-topologien har endret seg, vil protokollen sende ut en oppdatering, men ikke hele topologitabellen, men bare postene med denne endringen. Hvis et subnett endres, vil bare topologien oppdateres. Dette ser ut til å være en delvis oppdatering som skjer ved behov.
OSPF sender som kjent ut LSAer hvert 30. minutt, uavhengig av om det er endringer i nettverket. EIGRP vil ikke sende ut noen oppdateringer over en lengre periode før det er noen endringer i nettverket. Derfor er EIGRP mye mer effektiv enn OSPF.
Etter at ruterne har utvekslet oppdateringspakker, begynner det tredje trinnet - dannelsen av en rutetabell basert på metrikken, som beregnes ved hjelp av formelen vist i figuren. Hun beregner kostnaden og tar en beslutning basert på denne kostnaden.
La oss anta at R1 sendte Hello til ruter R2, og at ruteren sendte Hello til ruter R1. Hvis alle parametere samsvarer, oppretter ruterne en tabell over naboer. I denne tabellen skriver R2 en oppføring om ruteren R1, og R1 oppretter en oppføring om R2. Etter dette sender ruter R1 oppdateringen til nettverket 10.1.1.0/24 som er koblet til den. I rutetabellen ser dette ut som informasjon om IP-adressen til nettverket, rutergrensesnittet som gir kommunikasjon med det, og kostnadene for ruten gjennom dette grensesnittet. Hvis du husker, er kostnaden for EIGRP 90, og deretter er avstandsverdien angitt, som vi vil snakke om senere.
Den komplette metriske formelen ser mye mer komplisert ut, siden den inkluderer verdiene til K-koeffisientene og forskjellige transformasjoner. Cisco-nettstedet gir en fullstendig form for formelen, men hvis du erstatter standard koeffisientverdier, vil den bli konvertert til en enklere form - metrikken vil være lik (båndbredde + forsinkelse) * 256.
Vi vil bruke bare denne forenklede formen av formelen for å beregne metrikken, der båndbredden i kilobit er lik 107, delt på den minste båndbredden av alle grensesnitt som fører til destinasjonsnettverkets minste båndbredde, og den kumulative forsinkelsen er den totale forsinkelse på titalls mikrosekunder for alle grensesnitt som fører til destinasjonsnettverket.
Når vi lærer EIGRP, må vi forstå fire definisjoner: Gjennomførbar avstand, rapportert avstand, etterfølger (naboruter med lavest stikostnad til destinasjonsnettverket), og gjennomførbar etterfølger (backup naboruter). For å forstå hva de betyr, vurder følgende nettverkstopologi.
La oss starte med å lage en rutetabell R1 for å velge den beste ruten til nettverk 10.1.1.0/24. Ved siden av hver enhet vises gjennomstrømningen i kbit/s og ventetiden i ms. Vi bruker 100 Mbps eller 1000000 100000 10000 kbps GigabitEthernet-grensesnitt, 1544 XNUMX kbps FastEthernet, XNUMX XNUMX kbps Ethernet og XNUMX kbps serielle grensesnitt. Disse verdiene kan bli funnet ut ved å se egenskapene til de tilsvarende fysiske grensesnittene i ruterinnstillingene.
Standard gjennomstrømning av serielle grensesnitt er 1544 kbps, og selv om du har en 64 kbps linje, vil gjennomstrømningen fortsatt være 1544 kbps. Derfor, som nettverksadministrator, må du sørge for at du bruker riktig båndbreddeverdi. For et spesifikt grensesnitt kan det stilles inn ved hjelp av båndbreddekommandoen, og ved å bruke forsinkelseskommandoen kan du endre standard forsinkelsesverdi. Du trenger ikke å bekymre deg for standard båndbreddeverdier for GigabitEthernet eller Ethernet-grensesnitt, men vær forsiktig når du velger linjehastighet hvis du bruker et seriell grensesnitt.
Vær oppmerksom på at i dette diagrammet er forsinkelsen visstnok indikert i millisekunder ms, men i virkeligheten er det mikrosekunder, jeg har bare ikke bokstaven μ for korrekt å betegne mikrosekunder μs.
Vær oppmerksom på følgende faktum. Hvis du utsteder kommandoen show interface g0/0, vil systemet vise ventetiden i titalls mikrosekunder i stedet for bare mikrosekunder.
Vi vil se på dette problemet i detalj i neste video om å konfigurere EIGRP, for nå husk at når du erstatter latensverdier i formelen, blir 100 μs fra diagrammet til 10, siden formelen bruker titalls mikrosekunder, ikke enheter.
I diagrammet vil jeg indikere med røde prikker grensesnittene som de viste gjennomstrømningene og forsinkelsene gjelder.
Først av alt må vi bestemme den mulige gjennomførbare avstanden. Dette er FD-metrikken, som beregnes ved hjelp av formelen. For seksjonen fra R5 til det eksterne nettverket må vi dele 107 med 106, som et resultat får vi 10. Deretter må vi til denne båndbreddeverdien legge til en forsinkelse lik 1, fordi vi har 10 mikrosekunder, det vil si, en ti. Den resulterende verdien på 11 må multipliseres med 256, det vil si at den metriske verdien vil være 2816. Dette er FD-verdien for denne delen av nettverket.
Ruter R5 vil sende denne verdien til ruter R2, og for R2 vil den bli den deklarerte rapporterte avstanden, det vil si verdien som naboen fortalte den. Dermed vil den annonserte RD-avstanden for alle andre enheter være lik den mulige FD-avstanden til enheten som rapporterte det til deg.
Ruter R2 utfører FD-beregninger basert på dataene sine, det vil si deler 107 med 105 og får 100. Deretter legger den til denne verdien summen av forsinkelser på ruten til det eksterne nettverket: R5s forsinkelse, lik en ti mikrosekunder, og dens egen forsinkelse, lik ti tiere. Den totale forsinkelsen vil være 11 titalls mikrosekunder. Vi legger det til det resulterende hundre og får 111, multipliserer denne verdien med 256 og får verdien FD = 28416. Ruter R3 gjør det samme, og mottar etter beregningene verdien FD=281856. Ruter R4 beregner verdien FD=3072 og overfører den til R1 som RD.
Vær oppmerksom på at når du beregner FD, erstatter ikke ruter R1 sin egen båndbredde på 1000000 2 100000 kbit/s i formelen, men den nedre båndbredden til ruter R10.1.1.0, som er lik 24 2 kbit/s, fordi formelen alltid bruker minimumsbåndbredden på grensesnittet som fører til destinasjonsnettverket. I dette tilfellet er rutere R5 og R2 plassert på banen til nettverk 1/2, men siden den femte ruteren har større båndbredde, erstattes den minste båndbreddeverdien til ruter R5 i formelen. Den totale forsinkelsen langs banen R1-R10-R1 er 12+100+256 (tiere) = 30976, den reduserte gjennomstrømningen er XNUMX, og summen av disse tallene multiplisert med XNUMX gir verdien FD=XNUMX.
Så alle enheter har beregnet FD for grensesnittene deres, og ruteren R1 har 3 ruter som fører til destinasjonsnettverket. Dette er rutene R1-R2, R1-R3 og R1-R4. Ruteren velger minimumsverdien for mulig avstand FD, som er lik 30976 - dette er ruten til ruter R2. Denne ruteren blir etterfølgeren, eller "etterfølgeren". Rutingtabellen indikerer også Feasible Successor (backup successor) - det betyr at hvis forbindelsen mellom R1 og Successor blir brutt, vil ruten bli rutet gjennom backup Feasible Successor ruteren.
Gjennomførbare etterfølgere tildeles i henhold til en enkelt regel: den annonserte avstanden RD til denne ruteren må være mindre enn FD for ruteren i segmentet til etterfølgeren. I vårt tilfelle har R1-R2 FD = 30976, RD i seksjonen R1-K3 er lik 281856, og RD i seksjonen R1-R4 er lik 3072. Siden 3072 < 30976 er ruter R4 valgt som mulige etterfølgere.
Dette betyr at hvis kommunikasjonen blir forstyrret på R1-R2-nettverksdelen, vil trafikk til 10.1.1.0/24-nettverket sendes langs R1-R4-R5-ruten. Å bytte en rute når du bruker RIP tar flere titalls sekunder, når du bruker OSPF tar det flere sekunder, og i EIGRP skjer det umiddelbart. Dette er en annen fordel med EIGRP fremfor andre rutingprotokoller.
Hva skjer hvis både etterfølger og mulig etterfølger kobles fra samtidig? I dette tilfellet bruker EIGRP DUAL-algoritmen, som kan beregne en backuprute gjennom en sannsynlig etterfølger. Dette kan ta flere sekunder, hvor EIGRP vil finne en annen nabo som kan brukes til å videresende trafikken og plassere dataene i rutetabellen. Etter dette vil protokollen fortsette sitt vanlige rutingarbeid.
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, 30 % rabatt for Habr-brukere på en unik analog av inngangsnivåservere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2 ganger billigere? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com