I dag skal vi begynne å lære om OSPF-ruting. Dette emnet, i likhet med EIGRP-protokollen, er det viktigste emnet i hele CCNA-kurset. Som du kan se, har avsnitt 2.4 tittelen "Konfigurering, testing og feilsøking av OSPFv2 Single-Zone og Multi-Zone for IPv4 (unntatt autentisering, filtrering, manuell ruteoppsummering, redistribuering, Stub Area, VNet og LSA)."
Temaet OSPF er ganske omfattende, så det vil ta 2, kanskje 3 videotimer. Dagens leksjon vil bli viet til den teoretiske siden av problemet; Jeg vil fortelle deg hva denne protokollen er i generelle termer og hvordan den fungerer. I den neste videoen går vi videre til OSPF-konfigurasjonsmodus ved å bruke Packet Tracer.
Så i denne leksjonen skal vi dekke tre ting: hva OSPF er, hvordan det fungerer og hva OSPF-soner er. I forrige leksjon sa vi at OSPF er en Link State-rutingsprotokoll som undersøker kommunikasjonsforbindelser mellom rutere og tar avgjørelser basert på hastigheten til disse koblingene. En lang kanal med høyere hastighet, det vil si med mer gjennomstrømning, vil bli prioritert fremfor en kort kanal med mindre gjennomstrømning.
RIP-protokollen, som er en avstandsvektorprotokoll, vil velge en enkelthoppbane, selv om denne koblingen har lav hastighet, og OSPF-protokollen vil velge en lang rute på flere hopp dersom den totale hastigheten på denne ruten er høyere enn trafikkhastighet på den korte ruten.
Vi skal se på beslutningsalgoritmen senere, men foreløpig bør du huske at OSPF er en Link State Protocol. Denne åpne standarden ble opprettet i 1988 slik at alle produsenter av nettverksutstyr og enhver nettverksleverandør kunne bruke den. Derfor er OSPF mye mer populær enn EIGRP.
OSPF versjon 2 støttet bare IPv4, og et år senere, i 1989, kunngjorde utviklerne versjon 3, som støttet IPv6. En fullt funksjonell tredje versjon av OSPF for IPv6 dukket imidlertid opp først i 2008. Hvorfor valgte du OSPF? I den siste leksjonen lærte vi at denne interne gateway-protokollen utfører rutekonvergens mye raskere enn RIP. Dette er en klasseløs protokoll.
Hvis du husker, er RIP en klassebasert protokoll, noe som betyr at den ikke sender subnettmaskeinformasjon, og hvis den støter på en klasse A/24 IP-adresse, vil den ikke godta den. For eksempel, hvis du presenterer den med en IP-adresse som 10.1.1.0/24, vil den oppfatte den som nettverk 10.0.0.0 fordi den ikke forstår når et nettverk er subnettet med mer enn én subnettmaske.
OSPF er en sikker protokoll. For eksempel, hvis to rutere utveksler OSPF-informasjon, kan du konfigurere autentisering slik at du bare kan dele informasjon med en naboruter etter å ha angitt et passord. Som vi allerede har sagt, er det en åpen standard, så OSPF brukes av mange produsenter av nettverksutstyr.
I global forstand er OSPF en mekanisme for å utveksle Link State Advertisements, eller LSAer. LSA-meldinger genereres av ruteren og inneholder mye informasjon: ruterens unike identifikator router-id, data om nettverk kjent for ruteren, data om kostnadene deres, og så videre. Ruteren trenger all denne informasjonen for å ta rutingbeslutninger.
Ruter R3 sender LSA-informasjon til ruter R5, og ruter R5 deler LSA-informasjon med R3. Disse LSA-ene representerer datastrukturen som danner Link State Data Base, eller LSDB. Ruteren samler alle mottatte LSAer og plasserer dem i sin LSDB. Etter at begge ruterne har opprettet databasene sine, utveksler de Hello-meldinger, som tjener til å oppdage naboer, og begynner prosedyren for å sammenligne LSDB-ene deres.
Ruter R3 sender ruter R5 en DBD- eller "databasebeskrivelse"-melding, og R5 sender DBD til ruter R3. Disse meldingene inneholder LSA-indekser som er tilgjengelige i databasene til hver ruter. Etter å ha mottatt DBD, sender R3 en LSR-nettverksstatusforespørsel til R5 og sier "Jeg har allerede meldinger 3,4 og 9, så send meg bare 5 og 7."
R5 gjør det samme, og forteller den tredje ruteren: "Jeg har informasjon 3,4 og 9, så send meg 1 og 2." Etter å ha mottatt LSR-forespørsler, sender ruterne tilbake LSU-nettverksstatusoppdateringspakker, det vil si, som svar på LSR, mottar den tredje ruteren en LSU fra ruter R5. Etter at ruterne har oppdatert databasene sine, vil alle, selv om du har 100 rutere, ha de samme LSDB-ene. Når LSDB-databasene er opprettet i ruterne, vil hver av dem vite om hele nettverket som helhet. OSPF-protokollen bruker Shortest Path First-algoritmen for å lage rutingtabellen, så den viktigste betingelsen for korrekt drift er at LSDB-ene til alle enheter på nettverket er synkronisert.
I diagrammet ovenfor er det 9 rutere, som hver utveksler LSR, LSU og så videre meldinger med naboene. Alle er koblet til hverandre via p2p, eller "punkt-til-punkt"-grensesnitt som støtter drift via OSPF-protokollen, og samhandler med hverandre for å lage den samme LSDB.
Så snart basene er synkronisert, danner hver ruter, ved å bruke den korteste veialgoritmen, sin egen rutingtabell. Disse tabellene vil være forskjellige for forskjellige rutere. Det vil si at alle rutere bruker samme LSDB, men lager rutetabeller basert på egne betraktninger om de korteste rutene. For å bruke denne algoritmen, må OSPF regelmessig oppdatere LSDB.
Så, for at OSPF skal fungere selv, må det først gi 3 betingelser: finne naboer, opprette og oppdatere LSDB og danne en rutingtabell. For å oppfylle den første betingelsen kan det hende at nettverksadministratoren må konfigurere ruter-ID, timings eller jokertegn manuelt. I den neste videoen vil vi se på å sette opp en enhet for å fungere med OSPF, for nå bør du vite at denne protokollen bruker en omvendt maske, og hvis den ikke stemmer, hvis subnettene dine ikke samsvarer, eller autentiseringen ikke stemmer overens. , vil et nabolag med rutere ikke kunne dannes. Derfor, når du feilsøker OSPF, må du finne ut hvorfor dette nabolaget ikke er dannet, det vil si at parametrene ovenfor samsvarer.
Som nettverksadministrator er du ikke involvert i LSDB-opprettingsprosessen. Databaser oppdateres automatisk etter å ha opprettet et nabolag med rutere, det samme er konstruksjonen av rutingtabeller. Alt dette utføres av selve enheten, konfigurert til å fungere med OSPF-protokollen.
La oss se på et eksempel. Vi har 2 rutere, som jeg har tildelt RID 1.1.1.1 og 2.2.2.2 for enkelhets skyld. Så snart vi kobler dem til, vil koblingskanalen umiddelbart gå til opp-tilstand, fordi jeg først konfigurerte disse ruterne til å fungere med OSPF. Så snart en kommunikasjonskanal er dannet, vil ruter A umiddelbart sende en Hello-pakke til ruter A. Denne pakken vil inneholde informasjon om at denne ruteren ennå ikke har "sett" noen på denne kanalen, fordi den sender Hello for første gang, samt sin egen identifikator, data om nettverket som er koblet til den, og annen informasjon den kan dele med en nabo.
Etter å ha mottatt denne pakken, vil ruter B si: "Jeg ser at det er en potensiell kandidat for en OSPF-nabo på denne kommunikasjonskanalen" og vil gå inn i Init-tilstanden. Hello-pakken er ikke en unicast- eller kringkastingsmelding, det er en multicast-pakke sendt til multicast OSPF IP-adressen 224.0.0.5. Noen spør hva som er nettverksmasken for multicast. Faktum er at multicast ikke har en subnettmaske; den forplanter seg som et radiosignal, som høres av alle enheter som er innstilt på frekvensen. For eksempel, hvis du vil høre en FM-radio som sendes på frekvensen 91,0, stiller du inn radioen til den frekvensen.
På samme måte er ruter B konfigurert til å motta meldinger for multicast-adressen 224.0.0.5. Mens den lytter til denne kanalen, mottar den Hello-pakken sendt av ruter A og svarer med sin egen melding.
I dette tilfellet kan et nabolag bare etableres hvis svar B tilfredsstiller et sett med kriterier. Det første kriteriet er at frekvensen for å sende Hello-meldinger og venteintervallet for svar på denne meldingen Dead Interval må være den samme for begge ruterne. Vanligvis er dødintervallet lik flere Hello-timerverdier. Således, hvis Hello-timeren til ruter A er 10 s, og ruter B sender den en melding etter 30 s, mens dødintervallet er 20 s, vil tilknytningen ikke finne sted.
Det andre kriteriet er at begge ruterne må bruke samme type autentisering. Følgelig må autentiseringspassord også samsvare.
Det tredje kriteriet er samsvaret med Arial ID-soneidentifikatorene, det fjerde er samsvaret med lengden på nettverksprefikset. Hvis ruter A rapporterer et /24-prefiks, må ruter B også ha et /24-nettverksprefiks. I neste video skal vi se på dette mer detaljert, for nå vil jeg merke at dette ikke er en subnettmaske, her bruker rutere en omvendt Wildcard-maske. Og selvfølgelig må Stub-områdeflaggene også matche hvis ruterne er i denne sonen.
Etter å ha sjekket disse kriteriene, hvis de samsvarer, sender ruter B sin Hello-pakke til ruter A. I motsetning til As melding melder ruter B at den så ruter A og introduserer seg selv.
Som svar på denne meldingen sender ruter A igjen Hei til ruter B, der den bekrefter at den også så ruter B, kommunikasjonskanalen mellom dem består av enhetene 1.1.1.1 og 2.2.2.2, og den er selv enhet 1.1.1.1 . Dette er et veldig viktig stadium for å etablere et nabolag. I dette tilfellet brukes en toveis 2-VEIS tilkobling, men hva skjer hvis vi har en switch med et distribuert nettverk på 4 rutere? I et slikt "delt" miljø bør en av ruterne spille rollen som en utpekt ruter DR, og den andre bør spille rollen som en sikkerhetskopi utpekt ruter, BDR
Hver av disse enhetene vil danne en full tilkobling, eller en tilstand av fullstendig sammenheng, senere vil vi se på hva dette er, men en tilkobling av denne typen vil kun etableres med DR og BDR; de to nedre ruterne D og B vil kommuniserer fortsatt med hverandre ved hjelp av et toveis tilkoblingsskjema "punkt-til-punkt".
Det vil si at med DR og BDR etablerer alle rutere et fullstendig nabolagsforhold, og med hverandre - en punkt-til-punkt-forbindelse. Dette er veldig viktig fordi under en toveisforbindelse mellom tilstøtende enheter, må alle Hello-pakkeparametere samsvare. I vårt tilfelle stemmer alt, så enhetene danner et nabolag uten problemer.
Så snart toveiskommunikasjon er etablert, sender ruter A ruter B en databasebeskrivelsespakke, eller "databasebeskrivelse", og går inn i ExStart-tilstanden - begynnelsen av utvekslingen, eller venter på lasting. Databasebeskrivelsen er informasjon som ligner på innholdsfortegnelsen til en bok - den er en liste over alt som er i rutingdatabasen. Som svar sender ruter B sin databasebeskrivelse til ruter A og går inn i Exchange-kanalkommunikasjonstilstanden. Hvis ruteren i Exchange-tilstanden oppdager at noe informasjon mangler i databasen, vil den gå inn i LOADING-lastingstilstanden og begynne å utveksle LSR-, LSU- og LSA-meldinger med naboen.
Så ruter A vil sende en LSR til naboen, som vil svare med en LSU-pakke, som ruter A vil svare på ruter B med en LSA-melding. Denne utvekslingen vil skje så mange ganger enhetene ønsker å utveksle LSA-meldinger. LOADING-tilstanden betyr at en full oppdatering av LSA-databasen ennå ikke har funnet sted. Når alle data er lastet ned, vil begge enhetene gå inn i FULL tilknytningstilstand.
Merk at med en toveis tilkobling er enhetene ganske enkelt i tilknytningstilstand, og full tilknytningstilstand er kun mulig mellom ruterne, DR og BDR. Dette betyr at hver ruter informerer DR om endringer i nettverket, og alle rutere. lære om disse endringene fra DR
Valget av DR og BDR er en viktig sak. La oss se på hvordan DR velges i et generelt miljø. La oss anta at ordningen vår har tre rutere og en switch. OSPF-enheter sammenligner først prioriteten i Hello-meldinger, og sammenligner deretter ruter-IDen.
Enheten med høyest prioritet blir DR Hvis prioriteringene til to enheter faller sammen, velges enheten med høyest ruter-ID fra de to og blir DR
Enheten med nest høyeste prioritet eller den nest høyeste ruter-ID-en blir den dedikerte backup-ruteren BDR. Hvis DR feiler, vil den umiddelbart bli erstattet av BDR. Den vil begynne å spille rollen som DR, og systemet vil velge en annen BDR
Jeg håper at du har funnet ut valget mellom DR og BDR, hvis ikke, vil jeg komme tilbake til dette problemet i en av de følgende videoene og forklare denne prosessen.
Så langt har vi sett på hva Hello er, Database Descriptor og LSR-, LSU- og LSA-meldinger. Før vi går videre til neste emne, la oss snakke litt om kostnadene ved OSPF.
Hos Cisco beregnes kostnaden for en rute ved hjelp av formelen for forholdet mellom referansebåndbredden, som er satt til 100 Mbit/s som standard, og kostnaden for kanalen. For eksempel ved tilkobling av enheter via en seriell port er hastigheten 1.544 Mbps, og kostnaden vil være 64. Ved bruk av en Ethernet-tilkobling med en hastighet på 10 Mbps vil kostnaden være 10, og kostnaden for en FastEthernet-tilkobling med en hastighet på 100 Mbps vil være 1.
Ved bruk av Gigabit Ethernet har vi en hastighet på 1000 Mbps, men i dette tilfellet antas hastigheten alltid å være 1. Så hvis du har Gigabit Ethernet på nettverket ditt, må du endre standardverdien til Ref. BW med 1000. I dette tilfellet vil kostnaden være 1, og hele tabellen vil bli beregnet på nytt med kostnadsverdiene som øker med 10 ganger. Når vi har dannet naboområdet og bygget LSDB, går vi videre til å bygge rutetabellen.
Etter å ha mottatt LSDB, begynner hver ruter uavhengig å generere en liste over ruter ved hjelp av SPF-algoritmen. I vårt opplegg vil ruter A lage en slik tabell for seg selv. For eksempel beregner den kostnaden for ruten A-R1 og bestemmer at den er 10. For å gjøre diagrammet lettere å forstå, anta at ruter A bestemmer den optimale ruten til ruter B. Kostnaden for koblingen A-R1 er 10 , koblingen A-R2 er 100, og kostnaden for ruten A-R3 er lik 11, det vil si summen av ruten A-R1(10) og R1-R3(1).
Hvis ruter A ønsker å komme til ruter R4, kan den gjøre dette enten langs ruten A-R1-R4 eller langs ruten A-R2-R4, og i begge tilfeller vil kostnaden for rutene være den samme: 10+100 =100+10=110. Rute A-R6 vil koste 100+1= 101, som allerede er bedre. Deretter vurderer vi banen til ruter R5 langs ruten A-R1-R3-R5, hvor kostnaden vil være 10+1+100 = 111.
Banen til ruter R7 kan legges langs to ruter: A-R1-R4-R7 eller A-R2-R6-R7. Kostnaden for den første vil være 210,-, den andre - 201, som betyr at du bør velge 201. Så, for å nå ruter B, kan ruter A bruke 4 ruter.
Kostnaden for rute A-R1-R3-R5-B vil være 121. Rute A-R1-R4-R7-B vil koste 220. Rute A-R2-R4-R7-B vil koste 210, og A-R2- R6-R7- B har en kostnad på 211. På bakgrunn av dette vil ruter A velge ruten med lavest kostnad, lik 121, og plassere den i rutetabellen. Dette er et veldig forenklet diagram over hvordan SPF-algoritmen fungerer. Faktisk inneholder tabellen ikke bare betegnelsene til ruterne som den optimale ruten går gjennom, men også betegnelsene til portene som forbinder dem og all annen nødvendig informasjon.
La oss se på et annet tema som angår rutingssoner. Vanligvis, når du setter opp et selskaps OSPF-enheter, er de alle plassert i én felles sone.
Hva skjer hvis enheten som er koblet til R3-ruteren plutselig svikter? Ruter R3 vil umiddelbart begynne å sende en melding til rutere R5 og R1 om at kanalen med denne enheten ikke lenger fungerer, og alle rutere vil begynne å utveksle oppdateringer om denne hendelsen.
Hvis du har 100 rutere, vil de alle oppdatere koblingsstatusinformasjonen fordi de er i samme felles sone. Det samme vil skje hvis en av naboruterne svikter - alle enheter i sonen vil utveksle LSA-oppdateringer. Etter utveksling av slike meldinger vil selve nettverkstopologien endres. Når dette skjer, vil SPF beregne rutetabellene på nytt i henhold til de endrede betingelsene. Dette er en veldig stor prosess, og hvis du har tusen enheter i én sone, må du kontrollere minnestørrelsen på ruterne slik at den er tilstrekkelig til å lagre alle LSA-ene og den enorme LSDB-lenketilstandsdatabasen. Så snart endringer skjer i en del av sonen, beregner SPF-algoritmen umiddelbart rutene på nytt. Som standard oppdateres LSA hvert 30. minutt. Denne prosessen skjer ikke på alle enheter samtidig, men i alle fall utføres oppdateringer av hver ruter hvert 30. minutt. Jo flere nettverksenheter. Jo mer minne og tid det tar å oppdatere LSDB.
Dette problemet kan løses ved å dele en felles sone i flere separate soner, det vil si å bruke multisoning. For å gjøre dette må du ha en plan eller diagram over hele nettverket du administrerer. OMRÅDE 0 er hovedområdet ditt. Dette er stedet hvor tilkoblingen til det eksterne nettverket gjøres, for eksempel tilgang til Internett. Når du oppretter nye soner, må du følge regelen: hver sone må ha en ABR, Area Border Router. En kantruter har ett grensesnitt i en sone og et andre grensesnitt i en annen sone. R5-ruteren har for eksempel grensesnitt i sone 1 og sone 0. Hver av sonene skal som sagt være koblet til sone null, det vil si ha en kantruter, hvor ett av grensesnittene er koblet til OMRÅDE 0.
La oss anta at R6-R7-tilkoblingen har mislyktes. I dette tilfellet vil LSA-oppdateringen bare spre seg gjennom OMRÅDE 1 og vil kun påvirke denne sonen. Enheter i sone 2 og sone 0 vil ikke engang vite om det. Edge-ruter R5 oppsummerer informasjon om hva som skjer i sonen sin og sender sammendragsinformasjon om nettverkets tilstand til hovedsonen OMRÅDE 0. Enheter i én sone trenger ikke å være klar over alle LSA-endringer innenfor andre soner fordi ABR-ruteren vil videresende oppsummerende ruteinformasjon fra én sone til en annen.
Hvis du ikke er helt klar på konseptet med soner, kan du lære mer i de neste leksjonene når vi kommer inn på konfigurering av OSPF-ruting og ser på noen eksempler.
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