8.0 Single-Area OSPF
8.0.1. Introductie
Open Shortest Path First (OSPF) is een routeringsprotocol met linkstatus dat is ontwikkeld als vervanging voor het afstandsvectorrouteringsprotocol, RIP. RIP was een acceptabel routeringsprotocol in de begindagen van netwerken en internet. De afhankelijkheid van RIP van het aantal hops als de enige maatstaf voor het bepalen van de beste route werd echter al snel problematisch. Het gebruik van het aantal hops schaalt niet goed in grotere netwerken met meerdere paden met verschillende snelheden. OSPF heeft aanzienlijke voordelen ten opzichte van RIP omdat het snellere convergentie biedt en schaalt naar veel grotere netwerkimplementaties.
OSPF is een klasseloos routeringsprotocol dat het concept van gebieden gebruikt voor schaalbaarheid. Dit hoofdstuk behandelt de basisimplementaties en configuraties van OSPF met één gebied.
8.1 Karakteristieken van OSPF
8.1.1. Open Shortest Path First
8.1.1.1. Evolutie van OSPF
Zoals weergegeven in de volgende tabel, is OSPF versie 2 (OSPFv2) beschikbaar voor IPv4, terwijl OSPF versie 3 (OSPFv3) beschikbaar is voor IPv6.
IGP | IGP | IGP | IGP | EGP | |
---|---|---|---|---|---|
Distance Vector | Distance Vector | Link-State | Link-State | Path-Vector | |
IPv4 | RIPv2 | EIGRP | OSPFv2 | IS-IS | BGP-4 |
IPv6 | RIPng | EIGRP for IPv6 | OSPFv3 | IS-IS for IPv6 | BGP-MP |
De initiële ontwikkeling van OSPF begon in 1987 door de OSPF Working Group van de Internet Engineering Task Force (IETF). In die tijd was internet grotendeels een academisch en onderzoeksnetwerk dat werd gefinancierd door de Amerikaanse overheid.
In 1989 werd de specificatie voor OSPFv1 gepubliceerd in RFC 1131. Er werden twee implementaties geschreven. De ene implementatie is ontwikkeld om op routers te draaien en de andere om op UNIX-werkstations te draaien. De laatste implementatie werd een wijdverbreid UNIX-proces dat bekend staat als GATED. OSPFv1 was een experimenteel routeringsprotocol en is nooit geïmplementeerd.
In 1991 werd OSPFv2 geïntroduceerd in RFC 1247 door John Moy. OSPFv2 bood aanzienlijke technische verbeteringen ten opzichte van OSPFv1. Het is klasseloos van opzet; daarom ondersteunt het VLSM en CIDR.
Op hetzelfde moment dat de OSPF werd geïntroduceerd, werkte ISO aan een eigen link-state routeringsprotocol, Intermediate System-to-Intermediate System (IS-IS). IETF koos OSPF als hun aanbevolen Interior Gateway Protocol (IGP).
In 1998 werd de OSPFv2-specificatie bijgewerkt in RFC 2328, wat de huidige RFC voor OSPF blijft.
In 1999 werd OSPFv3 voor IPv6 gepubliceerd in RFC 2740. OSPF voor IPv6, gemaakt door John Moy, Rob Coltun en Dennis Ferguson, is niet alleen een nieuwe protocolimplementatie voor IPv6, maar ook een ingrijpende herschrijving van de werking van het protocol.
In 2008 werd OSPFv3 bijgewerkt in RFC 5340 als OSPF voor IPv6.
Opmerking: in dit hoofdstuk wordt de term OSPF gebruikt om concepten aan te duiden die door beide worden gedeeld, tenzij expliciet aangegeven als OSPFv2 of OSPFv3.
8.1.1.2. Kenmerken van OSPF
OSPF-functies zijn te omvatten als:
- Klasseloos – Het is klasseloos van opzet; daarom ondersteunt het VLSM en CIDR.
- Efficiënt – Routeringswijzigingen activeren routeringsupdates (geen periodieke updates). Het gebruikt het SPF-algoritme om het beste pad te kiezen.
- Snelle convergentie – Het verspreidt snel netwerkveranderingen.
- Schaalbaar – Het werkt goed in kleine en grote netwerkgroottes. Routers kunnen worden gegroepeerd in gebieden om een hiërarchisch systeem te ondersteunen.
- Veilig – Het ondersteunt Message Digest 5 (MD5) authenticatie. Indien ingeschakeld, accepteren OSPF-routers alleen gecodeerde routeringsupdates van peers met hetzelfde vooraf gedeelde wachtwoord.
Administratieve afstand (AD) is de betrouwbaarheid (of voorkeur) van de routebron. OSPF heeft een standaard administratieve afstand van 110. Zoals weergegeven in onderstaande tabel, heeft OSPF de voorkeur boven IS-IS en RIP.
Route Bron | Administratieve Afstand |
---|---|
Geconnecteerd | 0 |
Statisch | 1 |
EIGRP samentvattende route | 5 |
External BGP | 20 |
Internal EIGRP | 90 |
IGRP | 100 |
OSPF | 110 |
IS-IS | 115 |
RIP | 120 |
External EIGRP | 170 |
Internal BGP | 200 |
8.1.1.3. Onderdelen van OSPF
Alle routeringsprotocollen delen vergelijkbare componenten. Ze gebruiken allemaal routeringsprotocolberichten om route-informatie uit te wisselen. De berichten helpen bij het bouwen van gegevensstructuren, die vervolgens worden verwerkt met behulp van een routeringsalgoritme.
De drie hoofdcomponenten van het OSPF-routeringsprotocol zijn:
Data structuren
OSPF creëert en onderhoudt drie databases: (zie onderstaande tabel).
- Aangrenzende database – Maakt de buurtabel
- Link-state database (LSDB) – Maakt de topologietabel
- Doorstuurdatabase – Maakt de routeringstabel
Databases | Tabel | Beschrijving |
---|---|---|
Aangrezende Database | Buurtabel | – Lijst met alle naburige routers waarmee een router bidirectionele communicatie tot stand heeft gebracht. – Deze tabel is uniek voor elke router. – Kan worden bekeken met behulp van de |
Link-state Database (LSDB) | Topologie tabel | – Geeft informatie weer over alle andere routers in het netwerk. – De database vertegenwoordigt de netwerktopologie. – Alle routers binnen een gebied hebben identieke LSDB. – Kan worden bekeken met behulp van de |
Doorstuur Database | Routeringstabel | – Lijst met routes die worden gegenereerd wanneer een algoritme wordt uitgevoerd op de link-state database. – De routeringstabel van elke router is uniek en bevat informatie over hoe en waar pakketten naar andere routers moeten worden verzonden. – De routeringstabel van elke router is uniek en bevat informatie over hoe en waar pakketten naar andere routers moeten worden verzonden. |
Deze tabellen bevatten een lijst van naburige routers om routeringsinformatie mee uit te wisselen en worden bewaard en onderhouden in RAM.
Protocolberichten routeren
OSPF wisselt berichten uit om routeringsinformatie over te brengen met behulp van vijf soorten pakketten. Deze pakketten, zoals weergegeven in figuur 2, zijn:
- Hallo pakket
- Databasebeschrijvingspakket
- Verzoekpakket voor koppelingsstatus
- Updatepakket voor linkstatus
- Bevestigingspakket voor koppelingsstatus
Deze pakketten worden gebruikt om naburige routers te ontdekken en ook om routeringsinformatie uit te wisselen om nauwkeurige informatie over het netwerk te behouden.
Algoritme
De CPU verwerkt de buur- en topologietabellen met behulp van Dijkstra’s SPF-algoritme. Het SPF-algoritme is gebaseerd op de cumulatieve kosten om een bestemming te bereiken.
Het SPF-algoritme maakt een SPF-boom door elke router aan de wortel van de boom te plaatsen en het kortste pad naar elk knooppunt te berekenen. De SPF-boom wordt vervolgens gebruikt om de beste routes te berekenen. OSPF plaatst de beste routes in de doorstuurdatabase, die wordt gebruikt om de routeringstabel te maken.
8.1.1.4. Link-State-werking
Om routeringsinformatie te behouden, voltooien OSPF-routers het volgende generieke routeringsproces met linkstatus om een staat van convergentie te bereiken:
- Breng naburige buren tot stand – OSPF-compatibele routers moeten elkaar op het netwerk herkennen voordat ze informatie kunnen delen. Een OSPF-compatibele router stuurt Hello-pakketten naar alle OSPF-compatibele interfaces om te bepalen of er buren aanwezig zijn op die links. Als er een buur aanwezig is, probeert de OSPF-compatibele router een buur tot stand te brengen met die buur.
- Link-State-advertenties uitwisselen – Nadat adjacencies tot stand zijn gebracht, wisselen routers vervolgens link-state-advertenties (LSA’s) uit. LSA’s bevatten de status en kosten van elke direct verbonden link. Routers overspoelen hun LSA’s naar aangrenzende buren. Aangrenzende buren die de LSA ontvangen, overspoelen de LSA onmiddellijk naar andere direct verbonden buren, totdat alle routers in het gebied alle LSA’s hebben.
- Bouw de topologietabel – Nadat LSA’s zijn ontvangen, bouwen OSPF-compatibele routers de topologietabel (LSDB) op basis van de ontvangen LSA’s. Deze database bevat uiteindelijk alle informatie over de topologie van het netwerk.
- Voer het SPF-algoritme uit – Routers voeren vervolgens het SPF-algoritme uit. De tandwielen in de figuur worden gebruikt om de uitvoering van het SPF-algoritme aan te geven. Het SPF-algoritme maakt de SPF-boom.
Vanuit de SPF-boom worden de beste paden in de routeringstabel ingevoegd. Routeringsbeslissingen worden genomen op basis van de gegevens in de routeringstabel.
8.1.1.5. Single-Area en Multi-Area OSPF
Om OSPF efficiënter en schaalbaarder te maken, ondersteunt OSPF hiërarchische routering met behulp van gebieden. Een OSPF-gebied is een groep routers die dezelfde link-state-informatie in hun LSDB’s delen.
OSPF kan op twee manieren worden geïmplementeerd:
- Single-Area OSPF – In de volgende figuur met Single-Area OSPF bevinden alle routers zich in één gebied dat het backbone-gebied wordt genoemd (gebied 0).
- Multi-Area OSPF – In de volgende figuur met Multi-Area OSPF wordt OSPF geïmplementeerd met behulp van meerdere gebieden, op een hiërarchische manier. Alle gebieden moeten aansluiten op het backbone-gebied (gebied 0). Routers die de gebieden met elkaar verbinden, worden Area Border Routers (ABR) genoemd.
Met multiarea OSPF kan OSPF één groot autonoom systeem (AS) opdelen in kleinere gebieden om hiërarchische routering te ondersteunen. Bij hiërarchische routering vindt routering nog steeds plaats tussen de gebieden (interarea routering), terwijl veel van de processorintensieve routeringsbewerkingen, zoals het herberekenen van de database, binnen een gebied worden gehouden.
Elke keer dat een router bijvoorbeeld nieuwe informatie ontvangt over een topologiewijziging binnen het gebied (inclusief het toevoegen, verwijderen of wijzigen van een link), moet de router het SPF-algoritme opnieuw uitvoeren, een nieuwe SPF-structuur maken en de routeringstabel bijwerken. Het SPF-algoritme is CPU-intensief en de tijd die nodig is voor de berekening hangt af van de grootte van het gebied.
Opmerking: Topologiewijzigingen worden naar routers in andere gebieden gedistribueerd in een afstandsvectorformaat. Met andere woorden, deze routers werken alleen hun routeringstabellen bij en hoeven het SPF-algoritme niet opnieuw uit te voeren.
Te veel routers in één gebied zouden de LSDB’s erg groot maken en de CPU belasten. Daarom verdeelt het rangschikken van routers in gebieden een potentieel grote database effectief in kleinere en beter beheersbare databases.
De hiërarchische topologiemogelijkheden van multiarea OSPF hebben de volgende voordelen:
- Kleinere routeringstabellen – Minder vermeldingen in de routeringstabel omdat netwerkadressen tussen gebieden kunnen worden samengevat. Routesamenvatting is standaard niet ingeschakeld.
- Minder overhead bij het updaten van de linkstatus – Minimaliseert de verwerkings- en geheugenvereisten.
- Verminderde frequentie van SPF-berekeningen – Lokaliseert de impact van een topologiewijziging binnen een gebied. Het minimaliseert bijvoorbeeld de impact van routeringsupdates omdat LSA-overstromingen stoppen bij de gebiedsgrens.
Volgende figuur illustreert deze voordelen.
R2 is bijvoorbeeld een ABR voor gebied 51. Als ABR zou het de routes van gebied 51 samenvatten in gebied 0. Wanneer een van de samengevatte verbindingen uitvalt, worden LSA’s alleen uitgewisseld binnen gebied 51. Routers in gebied 51 moeten het SPF-algoritme opnieuw uitvoeren om de beste routes te identificeren. De routers in area 0 en area 1 ontvangen echter geen updates; daarom voeren ze het SPF-algoritme niet uit.
De focus van dit hoofdstuk ligt op Single-Area OSPF.
8.1.2. OSPF berichten
8.1.2.1. OSPF-berichten inkapselen
OSPF-berichten die via een Ethernet-link worden verzonden, bevatten de volgende informatie:
- Data Link Ethernet Frame Header – Identificeert de multicast MAC-adressen 01-00-5E-00-00-05 of 01-00-5E-00-00-06 van de bestemming.
- IP Packet Header – Identificeert het IPv4-protocolveld 89 dat aangeeft dat dit een OSPF-pakket is. Het identificeert ook een van de twee OSPF-multicastadressen, 224.0.0.5 of 224.0.0.6.
- OSPF Packet Header – Identificeert het OSPF-pakkettype, de router-ID en de gebieds-ID.
- OSPF-pakkettypespecifieke gegevens – Bevat informatie over het OSPF-pakkettype. De inhoud verschilt afhankelijk van het pakkettype. In dit geval is het een IPv4-header.
Data Link Frame Header | IP Packet Header | OSPF Packet Header | OSPF Packet Type-Specific Database |
---|---|---|---|
Data Link Frame MAC Destination Address = Multicast: 01-00-5E-00-00-05 or 01-00-5E-00-00-06 MAC Source Address = Address of sending interface | IP Packet IP Source Address = Address of sending interface IP Destination Address = Multicast: 224.0.0.5 or 224.0.0.6 Protocol Field = 89 for OSPF | OSPF Packet Header Type code for OSPF Packet type Router ID and Area ID | OSPF Packet Types 0x01 Hello 0x02 Database Description (DD) 0X03 Link State Request 0X04 Link State Update 0X05 Link State Acknowledgment |
8.1.2.2. Soorten OSPF-pakketten
OSPF gebruikt link-state-pakketten (LSP’s) om aangrenzende aangrenzende gebieden tot stand te brengen en te onderhouden en routeringsupdates uit te wisselen.
De afbeelding toont de vijf verschillende typen LSP’s die door OSPF worden gebruikt. Elk pakket heeft een specifiek doel in het OSPF-routeringsproces:
- Type 1: Hallo pakket – Wordt gebruikt om verbinding met andere OSPF-routers tot stand te brengen en te behouden.
- Type 2: Database Description (DBD)-pakket – Bevat een verkorte lijst van de LSDB van de verzendende router en wordt gebruikt door ontvangende routers om te vergelijken met de lokale LSDB. De LSDB moet identiek zijn op alle routers met verbindingsstatus binnen een gebied om een nauwkeurige SPF-boom te bouwen.
- Type 3: Link-State Request (LSR)-pakket – Ontvangende routers kunnen vervolgens meer informatie over een item in de DBD opvragen door een LSR te verzenden.
- Type 4: Link-State Update (LSU)-pakket – Wordt gebruikt om LSR’s te beantwoorden en nieuwe informatie aan te kondigen. LSU’s bevatten zeven verschillende soorten LSA’s.
- Type 5: Link-State Acknowledgement (LSAck)-pakket – Wanneer een LSU wordt ontvangen, verzendt de router een LSAck om de ontvangst van de LSU te bevestigen. Het LSAck-gegevensveld is leeg.
8.1.2.3. Hello pakket
Het OSPF Type 1-pakket is het Hallo-pakket. Hello-pakketten worden gebruikt om:
- OSPF-buren to ontdekken en aangrenzende buren vaststellen.
- Adverteer parameters waarover twee routers moeten overeenkomen om buren te worden.
- Kies de Designated Router (DR) en Backup Designated Router (BDR) op multiaccess-netwerken zoals Ethernet en Frame Relay. Voor point-to-point-links is geen DR of BDR vereist.
De afbeelding toont de velden in het Type 1 Hello-pakket. Belangrijke velden die in de afbeelding worden weergegeven, zijn onder meer:
- Type – Identificeert het type pakket. Een één (1) geeft een Hello-pakket aan. Een waarde 2 identificeert een DBD-pakket, 3 een LSR-pakket, 4 een LSU-pakket en 5 een LSAck-pakket.
- Router-ID – Een 32-bits waarde uitgedrukt in decimale notatie met punten (een IPv4-adres) die wordt gebruikt om de oorspronkelijke router op unieke wijze te identificeren.
- Area ID – Gebied waaruit het pakket afkomstig is.
- Netwerkmasker – Subnetmasker dat is gekoppeld aan de verzendende interface.
- Hello-interval – Specificeert de frequentie, in seconden, waarop een router Hello-pakketten verzendt. Het standaard Hallo-interval op multiaccess-netwerken is 10 seconden. Deze timer moet hetzelfde zijn op naburige routers; anders wordt er geen nabijheid vastgesteld.
- Routerprioriteit – Gebruikt bij een DR/BDR-verkiezing. De standaardprioriteit voor alle OSPF-routers is 1, maar kan handmatig worden gewijzigd van 0 tot 255. Hoe hoger de waarde, hoe groter de kans dat de router de DR op de link wordt.
- Dead Interval – Is de tijd in seconden die een router wacht om van een buurman te horen voordat hij de naburige router buiten dienst stelt. Standaard is het Dead Interval van de router vier keer het Hello-interval. Deze timer moet hetzelfde zijn op naburige routers; anders wordt er geen nabijheid vastgesteld.
- Designated Router (DR) – Router-ID van de DR.
- Backup Designated Router (BDR) – Router-ID van de BDR.
- Lijst met buren – Lijst die de router-ID’s van alle aangrenzende routers identificeert.
8.1.2.4. Hello pakketintervallen
Zoals te zien is in de afbeelding, worden OSPF Hello-pakketten verzonden naar multicast-adres 224.00.0.5 in IPv4 en FF02::5 in IPv6 (alle OSPF-routers) om de:
- 10 seconden (standaard op multiaccess- en point-to-point-netwerken)
- 30 seconden (standaard op nonbroadcast multiaccess [NBMA]-netwerken; bijvoorbeeld Frame Relay)
Het Dead-interval is de periode dat de router wacht om een Hello-pakket te ontvangen voordat de buurman down wordt verklaard. Als het Dead-interval verloopt voordat de routers een Hello-pakket ontvangen, verwijdert OSPF die buur uit zijn LSDB. De router overspoelt de LSDB met informatie over de down-buur uit alle OSPF-compatibele interfaces.
Cisco gebruikt een standaardwaarde van 4 keer het Hello-interval:
- 40 seconden (standaard op multiaccess- en point-to-point-netwerken)
- 120 seconden (standaard op NBMA-netwerken; bijvoorbeeld Frame Relay)
8.1.2.5. Updates van linkstatus
Routers wisselen in eerste instantie Type 2 DBD-pakketten uit, wat een verkorte lijst is van de LSDB van de verzendende router en wordt gebruikt door ontvangende routers om te controleren met de lokale LSDB.
Een Type 3 LSR-pakket wordt door de ontvangende routers gebruikt om meer informatie over een item in de DBD op te vragen.
Het Type 4 LSU-pakket wordt gebruikt om te antwoorden op een LSR-pakket.
LSU’s worden ook gebruikt om OSPF-routeringsupdates, zoals koppelingswijzigingen, door te sturen. In het bijzonder kan een LSU-pakket 11 verschillende typen OSPFv2 LSA’s bevatten, zoals weergegeven in de afbeelding. OSPFv3 heeft verschillende van deze LSA’s hernoemd en bevat ook twee extra LSA’s.
Opmerking: het verschil tussen de LSU- en LSA-termen kan soms verwarrend zijn omdat deze termen vaak door elkaar worden gebruikt. Een LSU bevat echter een of meer LSA’s.
Type | Pakketnaam | Beschrijving |
---|---|---|
1 | Hello | Ontdekt buren en bouwt aangrenzende gebieden tussen hen |
2 | DBD | Controles op databasesynchronisatie tussen routers |
3 | LSR | Verzoekt specifieke link-state records van router naar router |
4 | LSU | Verzendt specifiek gevraagde link-state records |
5 | LSAck | Bevestigd de andere pakkettypes |
LSA Type | Beschrijving |
---|---|
1 | Router LSA’s |
2 | Netwek LSA’s |
3 of 4 | Samenvattende LSA’s |
5 | Autonome externe syteem LSA’s |
6 | Multicast OSPF LSA’s |
7 | Gedefinieerd voor ‘Not-Se-Stubby’ gebieden |
8 | Externe LSA attributen voor Border Gateway Protocol (BGP) |
9, 10, 11 | Ondoorzichtige LSA’s |
8.1.3. OSPF werking
8.1.3.1. OSPF Operationele Staten
Wanneer een OSPF-router voor het eerst is verbonden met een netwerk, probeert deze:
- Grenzen met buren te maken
- Routeringsinformatie uitwisselen
- Berekenen van de beste routes
- Bereik convergentie
OSPF vordert door verschillende staten terwijl het probeert convergentie te bereiken:
- Down state
- Init-status
- Two-Way state
- ExStart state
- Exchange state
- Loading state
- Full staat
Klik op de blauwe vakjes in de afbeelding voor meer informatie.
8.1.3.2. Aangrenzende met buren vastellen
Wanneer OSPF is ingeschakeld op een interface, moet de router bepalen of er een andere OSPF-buur op de link is. Om dit te bereiken, stuurt de router een Hello-pakket met zijn router-ID door naar alle OSPF-compatibele interfaces. De OSPF-router-ID wordt door het OSPF-proces gebruikt om elke router in het OSPF-gebied op unieke wijze te identificeren. Een router-ID is een IP-adres dat is toegewezen om een specifieke router te identificeren onder OSPF-peers.
Wanneer een naburige router met OSPF-functionaliteit een Hello-pakket ontvangt met een router-ID die niet in de lijst met buren staat, probeert de ontvangende router een verbinding tot stand te brengen met de initiërende router.
Raadpleeg R1 in volgende afbeelding. Wanneer OSPF is ingeschakeld, gaat de ingeschakelde Gigabit Ethernet 0/0-interface over van de down-status naar de init-status. R1 begint met het verzenden van Hello-pakketten naar alle OSPF-compatibele interfaces om OSPF-buren te ontdekken om aangrenzende gebieden mee te ontwikkelen.
In de volgende afbeelding ontvangt R2 het Hello-pakket van R1 en voegt de R1-router-ID toe aan de lijst met buren. R2 stuurt vervolgens een Hello-pakket naar R1. Het pakket bevat de R2-router-ID en de R1-router-ID in de lijst met buren op dezelfde interface.
In de volgende afbeelding ontvangt R1 de Hallo en voegt de R2-router-ID toe aan de lijst met OSPF-buren. Het ziet ook zijn eigen router-ID in de lijst met buren van het Hello-pakket. Wanneer een router een Hello-pakket ontvangt met zijn router-ID in de lijst met buren, gaat de router over van de Init-status naar de Two-Way-status.
De actie die wordt uitgevoerd in de tweerichtingsstatus hangt af van het type onderlinge verbinding tussen de aangrenzende routers:
- Als de twee aangrenzende buren met elkaar zijn verbonden via een punt-naar-punt-verbinding, gaan ze onmiddellijk over van de tweerichtingsstatus naar de databasesynchronisatiefase.
- Als de routers onderling zijn verbonden via een gemeenschappelijk Ethernet-netwerk, moeten een aangewezen router DR en een BDR worden gekozen.
Omdat R1 en R2 via een Ethernet-netwerk met elkaar zijn verbonden, vindt er een DR- en BDR-verkiezing plaats. Zoals weergegeven in onderstaande afbeedling, wordt R2 de DR en is R1 de BDR. Dit proces vindt alleen plaats op multi-access netwerken zoals Ethernet LAN’s.
Hello-pakketten worden voortdurend uitgewisseld om routerinformatie te behouden.
8.1.3.3. OSPF DR en BDR
Waarom is een DR- en BDR-verkiezing nodig?
Multiaccess-netwerken kunnen voor OSPF twee uitdagingen creëren met betrekking tot de overstroming van LSA’s:
- Creëren van meerdere aangrenzende netwerken – Ethernet-netwerken kunnen mogelijk veel OSPF-routers met elkaar verbinden via een gemeenschappelijke link. Het is onnodig en onwenselijk om bij elke router aangrenzendheid te creëren. Het zou leiden tot een buitensporig aantal LSA’s dat wordt uitgewisseld tussen routers op hetzelfde netwerk.
- Uitgebreide overstroming van LSA’s – Link-state routers overspoelen hun LSA’s telkens wanneer OSPF wordt geïnitialiseerd of wanneer er een verandering in de topologie is. Deze overstromingen kunnen buitensporig worden.
Om het probleem met meerdere aangrenzende gebieden te begrijpen, moeten we een formule bestuderen:
Voor een willekeurig aantal routers (aangeduid als n) op een multiaccess-netwerk zijn er n (n – 1) / 2 aangrenzende gebieden.
Bovenstaande afbeelding toont een eenvoudige topologie van vijf routers, die allemaal zijn aangesloten op hetzelfde multiaccess Ethernet-netwerk. Zonder een soort mechanisme om het aantal aangrenzende gebieden te verminderen, zouden deze routers samen 10 aangrenzende gebieden vormen:
5 (5 – 1) / 2 = 10
Dit lijkt misschien niet veel, maar naarmate er routers aan het netwerk worden toegevoegd, neemt het aantal aangrenzende gebieden drastisch toe, zoals weergegeven in figuur 2.
Routers | Aangrenzingen |
---|---|
n | n ( n – 1 ) / 2 |
5 | 10 |
10 | 45 |
20 | 190 |
100 | 4950 |
Om het probleem van uitgebreide overstromingen van LSA’s te begrijpen, moet u onderstaande animatie bekijken. In de animatie zendt R2 een LSA uit. Deze gebeurtenis activeert elke andere router om ook een LSA uit te zenden. Niet weergegeven in de animatie zijn de vereiste bevestigingen die zijn verzonden voor elke ontvangen LSA. Als elke router in een multiaccess-netwerk alle ontvangen LSA’s zou moeten overspoelen en bevestigen aan alle andere routers op datzelfde multiaccess-netwerk, zou het netwerkverkeer behoorlijk chaotisch worden.
De oplossing voor het beheren van het aantal aangrenzende gebieden en de overstroming van LSA’s op een multiaccess-netwerk is de DR. Op multiaccess-netwerken kiest OSPF een DR als verzamel- en distributiepunt voor verzonden en ontvangen LSA’s. Een BDR wordt ook gekozen in het geval dat de DR faalt. Alle andere routers worden DROTHER’s. Een DROTHER is een router die noch de DR, noch de BDR is.
Bekjik onderstaande animatie om de rol van DR te zien.
8.1.3.4. OSPF-databases synchroniseren
Na de tweerichtingsstatus gaan routers over naar databasesynchronisatiestatussen. Terwijl het Hello-pakket werd gebruikt om aangrenzende aangrenzende gebieden tot stand te brengen, worden de andere vier typen OSPF-pakketten gebruikt tijdens het uitwisselen en synchroniseren van LSDB’s.
In de ExStart-status wordt een master- en slave-relatie gecreëerd tussen elke router en de aangrenzende DR en BDR. De router met de hogere router-ID fungeert als de master voor de Exchange-status. In onderstaande afbeelding wordt R2 de master.
In de Exchange-status wisselen de master- en slave-routers een of meer DBD-pakketten uit. Een DBD-pakket bevat informatie over de LSA-invoerheader die in de LSDB van de router verschijnt. De vermeldingen kunnen gaan over een link of over een netwerk. Elke LSA-invoerkop bevat informatie over het type linkstatus, het adres van de advertentierouter, de kosten van de link en het volgnummer. De router gebruikt het volgnummer om de nieuwheid van de ontvangen informatie over de verbindingsstatus te bepalen.
In onderstaande afbeelding stuurt R2 een DBD-pakket naar R1. Wanneer R1 de DBD ontvangt, voert het de volgende acties uit:
- Het bevestigt de ontvangst van de DBD met behulp van het LSAck-pakket.
- R1 stuurt vervolgens DBD-pakketten naar R2.
- R2 bevestigt R1.
R1 vergelijkt de ontvangen informatie met de informatie die hij heeft in zijn eigen LSDB. Als het DBD-pakket een actuelere link-state-invoer heeft, gaat de router over naar de Loading-status.
In de volgende afbeelding stuurt R1 bijvoorbeeld een LSR met betrekking tot netwerk 172.16.6.0 naar R2. R2 antwoordt met de volledige informatie over 172.16.6.0 in een LSU-pakket. Nogmaals, wanneer R1 een LSU ontvangt, verzendt het een LSAck. R1 voegt vervolgens de nieuwe link-state-vermeldingen toe aan zijn LSDB.
Nadat aan alle LSR’s is voldaan voor een bepaalde router, worden de aangrenzende routers als gesynchroniseerd en in een volledige staat beschouwd.
Zolang de naburige routers Hello-pakketten blijven ontvangen, blijft het netwerk in de verzonden LSA’s in de topologiedatabase. Nadat de topologische databases zijn gesynchroniseerd, worden updates (LSU’s) alleen naar buren verzonden wanneer:
- Er een verandering wordt waargenomen (incrementele updates)
- Elke 30 minuten
8.2. Single-Area OSPFv2 configureren
8.2.1. OSPF Router ID
8.2.1.1. OSPF-netwerktopologie
OSPFv2, geïntroduceerd in 1991, is een routeringsprotocol met linkstatus voor IPv4. OSPF is ontworpen als alternatief voor een ander IPv4-routeringsprotocol, RIP.
De afbeelding toont de topologie die wordt gebruikt voor het configureren van OSPFv2 in deze sectie. De typen seriële interfaces en de bijbehorende bandbreedtes weerspiegelen mogelijk niet noodzakelijk de meer gebruikelijke typen verbindingen die tegenwoordig in netwerken worden aangetroffen. De bandbreedtes van de seriële verbindingen die in deze topologie worden gebruikt, zijn gekozen om de berekening van de routeringsprotocolstatistieken en het proces van de beste padselectie te helpen verklaren.
De routers in de topologie hebben een startconfiguratie, inclusief interface-adressen. Er is momenteel geen statische routering of dynamische routering geconfigureerd op een van de routers. Alle interfaces op routers R1, R2 en R3 (behalve de loopback op R2) bevinden zich binnen het OSPF-backbonegebied. De ISP-router wordt gebruikt als de gateway van het routeringsdomein naar internet.
Opmerking: in deze topologie wordt de loopback-interface gebruikt om de WAN-link naar internet te simuleren.
8.2.1.2. Router OSPF-configuratiemodus
Bonvenstaande afbeelding is de referentietopologie voor dit onderwerp. OSPFv2 wordt ingeschakeld met behulp van de router ospf process-id global configuration mode-opdracht. De process-id waarde vertegenwoordigt een getal tussen 1 en 65.535 en wordt geselecteerd door de netwerkbeheerder. De proces-id-waarde is lokaal significant, wat betekent dat het niet dezelfde waarde hoeft te zijn op de andere OSPF-routers om adjacencies met die buren tot stand te brengen.
Afbeelding 2 geeft een voorbeeld van het openen van de OSPF-configuratiemodus van de router op R1.
R1(config)# router ospf 10
R1(config-router)# ?
Router configuration commands
auto-cost Calculate OSPF interface cost according to bandwidth
network Enable routing on an IP network
no Negate a command or set its defaults
passive-interface Suppress routing updates on an interface
priority OSPF topology priority
router-id router-id for this OSPF process
Opmerking: de lijst met opdrachten is gewijzigd om alleen de opdrachten weer te geven die in dit hoofdstuk worden gebruikt. Gebruik voor een volledige lijst met opdrachten de Syntax Checkers in Afbeelding 3.
8.2.1.3. Router-ID’s
Elke router heeft een router-ID nodig om deel te nemen aan een OSPF-domein. De router-ID kan worden gedefinieerd door een beheerder of automatisch worden toegewezen door de router. De router-ID wordt door de OSPF-compatibele router gebruikt om:
- Unieke identificatie van de router – De router-ID wordt door andere routers gebruikt om elke router binnen het OSPF-domein en alle pakketten die daarvan afkomstig zijn, op unieke wijze te identificeren.
- Deelnemen aan de verkiezing van de DR – In een LAN-omgeving met meerdere toegangen vindt de verkiezing van de DR plaats tijdens de eerste oprichting van het OSPF-netwerk. Wanneer OSPF-koppelingen actief worden, wordt het routeringsapparaat dat met de hoogste prioriteit is geconfigureerd, de DR. Ervan uitgaande dat er geen prioriteit is geconfigureerd of dat er een gelijkspel is, wordt de router met de hoogste router-ID verkozen tot de DR. Het routeringsapparaat met de op één na hoogste router-ID wordt verkozen tot de BDR.
Maar hoe bepaalt de router de router-ID? Zoals geïllustreerd in de voorgaande afbeelding, leiden Cisco-routers de router-ID af op basis van een van de drie criteria, in de volgende voorkeursvolgorde:
- De router-ID wordt expliciet geconfigureerd met de opdracht OSPF router-id rid router configuration mode. De rid-waarde is elke 32-bits waarde uitgedrukt als een IPv4-adres. Dit is de aanbevolen methode om een router-ID toe te wijzen.
- Als de router-ID niet expliciet is geconfigureerd, kiest de router het hoogste IPv4-adres van een van de geconfigureerde loopback-interfaces. Dit is het op één na beste alternatief voor het toewijzen van een router-ID.
- Als er geen loopback-interfaces zijn geconfigureerd, kiest de router het hoogste actieve IPv4-adres van een van zijn fysieke interfaces. Dit is de minst aanbevolen methode omdat het het voor beheerders moeilijker maakt om onderscheid te maken tussen specifieke routers.
Als de router het hoogste IPv4-adres voor de router-ID gebruikt, hoeft de interface niet OSPF-geactiveerd te zijn. Dit betekent dat het interface-adres niet hoeft te worden opgenomen in een van de OSPF-netwerkopdrachten zodat de router dat IP-adres als router-ID kan gebruiken. De enige vereiste is dat de interface actief en up-to-date is.
Opmerking: de router-ID ziet eruit als een IP-adres, maar is niet routeerbaar en wordt daarom niet opgenomen in de routeringstabel, tenzij het OSPF-routeringsproces een interface kiest (fysiek of loopback) die op de juiste manier is gedefinieerd door een netwerkopdracht.
8.2.1.4. Een OSPF-router-ID configureren
Gebruik de opdracht router-id rid router-configuratiemodus om handmatig een 32-bits waarde, uitgedrukt als een IPv4-adres, toe te wijzen aan een router. Een OSPF-router identificeert zichzelf met andere routers met behulp van deze router-ID.
Zoals weergegeven in volgende afbeelding is R1 geconfigureerd met een router-ID van 1.1.1.1, R2 met 2.2.2.2 en R3 met 3.3.3.3.
In het volgende voorbeeld is de router-ID 1.1.1.1 toegewezen aan R1. Gebruik de opdracht show ip protocols om de router-ID te verifiëren.
R1(config)# router ospf 10
R1(config-router)# router-id 1.1.1.1
R1(config-router)# end
R1#
*Mar 25 19:50:36.595: %SYS-5-CONFIG_I: Configured from console by console
R1#
R1# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 10"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 1.1.1.1
Number of areas in this router is 0. 0 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 110)
Opmerking: R1 was nooit geconfigureerd met een OSPF-router-ID. Als dat het geval was, zou de router-ID moeten worden gewijzigd.
Als de router-ID hetzelfde is op twee aangrenzende routers, geeft de router een foutmelding weer die lijkt op die hieronder:
%OSPF-4-DUP_RTRID1: Detected router with duplicate router-ID.
Om dit probleem te verhelpen, configureert u alle routers zodat ze unieke OSPF-router-ID’s hebben.
8.2.1.5. Een router-ID aanpassen
Soms moet een router-ID worden gewijzigd, bijvoorbeeld wanneer een netwerkbeheerder een nieuw router-ID-schema voor het netwerk instelt. Nadat een router echter een router-ID heeft geselecteerd, staat een actieve OSPF-router niet toe dat de router-ID wordt gewijzigd totdat de router opnieuw is geladen of het OSPF-proces is gewist.
In figuur 1 ziet u dat de huidige router-ID 192.168.10.5 is. De router-ID moet 1.1.1.1 zijn.
R1# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 10"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 192.168.10.5
Number of areas in this router is 1. 1 normal 0 stub 0
nssa
Maximum path: 4
Routing for Networks:
172.16.1.0 0.0.0.255 area 0
172.16.3.0 0.0.0.3 area 0
192.168.10.4 0.0.0.3 area 0
Routing Information Sources:
Gateway Distance Last Update
209.165.200.225 110 00:07:02
192.168.10.10 110 00:07:02
Distance: (default is 110)
R1#
In Afbeelding 2 wordt de router-ID 1.1.1.1 toegewezen aan R1. Merk op hoe een informatief bericht verschijnt waarin staat dat het OSPF-proces moet worden gewist of dat de router opnieuw moet worden geladen. De reden is dat R1 al aangrenzend is aan andere buren die de router-ID 192.168.10.5 gebruiken. Over die aangrenzende gebieden moet opnieuw worden onderhandeld met behulp van de nieuwe router IP 1.1.1.1.
R1(config)# router ospf 10
R1(config-router) router-id 1.1.1.1
% OSPF: Reload or use "clear ip ospf process" command, for
this to take effect
R1(config-router) end
R1#
*Mar 25 19:46:09.711: %SYS-5-CONFIG_I: Configured from console by console
Het wissen van het OSPF-proces is de voorkeursmethode om de router-ID opnieuw in te stellen.
In Afbeelding 3 wordt het OSPF-routeringsproces gewist met de opdracht clear ip ospf process privileged EXEC mode. Dit dwingt OSPF op R1 om over te gaan naar de Down- en Init-statussen. Merk op dat de berichten over de nabijheid veranderen van vol naar beneden en vervolgens van laden naar vol. De opdracht show ip protocols controleert of de router-ID is gewijzigd.
R1# clear ip ospf process
Reset ALL OSPF processes? [no]: y
R1#
*Mar 25 19:46:22.423: %OSPF-5-ADJCHG: Process 10, Nbr
3.3.3.3 on Serial0/0/1 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar 25 19:46:22.423: %OSPF-5-ADJCHG: Process 10, Nbr
2.2.2.2 on Serial0/0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
*Mar 25 19:46:22.475: %OSPF-5-ADJCHG: Process 10, Nbr
3.3.3.3 on Serial0/0/1 from LOADING to FULL, Loading Done
*Mar 25 19:46:22.475: %OSPF-5-ADJCHG: Process 10, Nbr
2.2.2.2 on Serial0/0/0 from LOADING to FULL, Loading Done
R1#
R1# show ip protocols | section Router ID
Router ID 1.1.1.1
R1#
8.2.1.6. Een Loopback-interface gebruiken als router-ID
Een router-ID kan ook worden toegewezen met behulp van een loopback-interface.
Het IPv4-adres van de loopback-interface moet worden geconfigureerd met een 32-bits subnetmasker (255.255.255.255). Dit creëert effectief een hostroute. Een 32-bits hostroute wordt niet geadverteerd als een route naar andere OSPF-routers.
Het voorbeeld in de afbeelding laat zien hoe u een loopback-interface configureert met een hostroute op R1. R1 gebruikt de hostroute als router-ID, ervan uitgaande dat er geen router-ID expliciet is geconfigureerd of eerder is geleerd.
Opmerking: sommige oudere versies van de IOS herkennen het router-id commando niet; het gebruik van een loopback-interface is daarom de beste manier om de router-ID op die routers in te stellen.
R1(config)# interface loopback 0
R1(config-if)# ip address 1.1.1.1 255.255.255.255
R1(config-if)# end
R1#
8.2.2. Single-Area OSPFv2 configureren
8.2.1.1. OSPF inschakelen op interfaces
De opdracht network bepaalt welke interfaces deelnemen aan het routeringsproces voor een OSPF-gebied. Alle interfaces op een router die overeenkomen met het netwerkadres in de opdracht network, kunnen OSPF-pakketten verzenden en ontvangen. Als gevolg hiervan wordt het netwerkadres (of subnetadres) voor de interface opgenomen in OSPF-routeringsupdates.
De basissyntaxis van de opdracht is network network-address wildcard-mask area area-id.
De syntaxis van area area-id verwijst naar het OSPF-gebied. Bij het configureren van OSPF met één gebied, moet de opdracht network op alle routers worden geconfigureerd met dezelfde area-id waarde. Hoewel elk area-ID kan worden gebruikt, is het een goede gewoonte om een area-ID van 0 te gebruiken met OSPF met één gebied. Deze conventie maakt het gemakkelijker als het netwerk later wordt gewijzigd om OSPF met meerdere gebieden te ondersteunen.
De afbeelding toont de referentietopologie.
8.2.1.2. Wildcard Mask
OSPFv2 gebruikt de argumentcombinatie van netwerkadres-jokertekenmasker om OSPF op interfaces in te schakelen. OSPF is klasseloos van opzet; daarom is het jokertekenmasker altijd vereist. Bij het identificeren van interfaces die deelnemen aan een routeringsproces, is het jokertekenmasker meestal het omgekeerde van het subnetmasker dat op die interface is geconfigureerd.
Een wildcard-masker is een reeks van 32 binaire cijfers die door de router wordt gebruikt om te bepalen welke bits van het adres moeten worden onderzocht op een overeenkomst. In een subnetmasker is binair 1 gelijk aan een overeenkomst en is binair 0 geen overeenkomst. In een wildcard-masker is het omgekeerde waar:
- Wildcard mask bit 0 – Komt overeen met de corresponderende bitwaarde in het adres.
- Wildcard mask bit 1 – Negeert de corresponderende bitwaarde in het adres.
De eenvoudigste methode voor het berekenen van een jokertekenmasker is om het netwerksubnetmasker af te trekken van 255.255.255.255.
Het volgende voorbeeld berekent het wildcard masker op basis van het netwerkadres 192.168.10.0/24. Om dit te doen, wordt het subnetmasker 255.255.255.0 afgetrokken van 255.255.255.255, wat een resultaat oplevert van 0.0.0.255. Daarom is 192.168.10.0/24 192.168.10.0 met een wildcardmasker van 0.0.0.255.
Het volgende voorbeeld berekent het wildcard masker op basis van het netwerkadres 192.168.10.64/26. Nogmaals, het subnetmasker 255.255.255.192 wordt afgetrokken van 255.255.255.255, wat een resultaat oplevert van 0.0.0.63. Daarom is 192.168.10.0/26 192.168.10.0 met een wildcardmasker van 0.0.0.63.
8.2.2.3. De netwerkopdracht
Er zijn verschillende manieren om de interfaces te identificeren die zullen deelnemen aan het OSPFv2-routeringsproces.
Het volgend voorbeeld toont de vereiste opdrachten om te bepalen welke interfaces op R1 deelnemen aan het OSPFv2-routeringsproces voor een gebied. Let op het gebruik van jokertekenmaskers om de respectieve interfaces te identificeren op basis van hun netwerkadressen. Omdat dit een OSPF-netwerk met één gebied is, zijn alle gebieds-ID’s ingesteld op 0.
R1(config)# router ospf 10
R1(config-router)# network 172.16.1.0 0.0.0.255 area 0
R1(config-router)# network 172.16.3.0 0.0.0.3 area 0
R1(config-router)# network 192.168.10.4 0.0.0.3 area 0
R1(config-router)#
Als alternatief kan OSPFv2 worden ingeschakeld met behulp van de opdracht network intf-ip-address 0.0.0.0 area area-id routerconfiguratiemodus.
Het volgende voorbeel toont het specificeren van het IPv4-adres van de interface met een quad 0 jokertekenmasker. Het invoeren van netwerk 172.16.3.1 0.0.0.0 gebied 0 op R1 vertelt de router om interface Serial0/0/0 in te schakelen voor het routeringsproces. Als gevolg hiervan maakt het OSPFv2-proces reclame voor het netwerk dat zich op deze interface bevindt (172.16.3.0/30).
R1(config)# router ospf 10
R1(config-router)# network 172.16.1.1 0.0.0.0 area 0
R1(config-router)# network 172.16.3.1 0.0.0.0 area 0
R1(config-router)# network 192.168.10.5 0.0.0.0 area 0
R1(config-router)#
Het voordeel van het specificeren van de interface is dat de berekening van het wildcard niet nodig is. OSPFv2 gebruikt het interface-adres en subnetmasker om het netwerk te bepalen om te adverteren.
Bij sommige IOS-versies kan het subnetmasker worden ingevoerd in plaats van het wildcard masker. De IOS converteert vervolgens het subnetmasker naar het wildcard-maskerformaat.
Opmerking: Let tijdens het voltooien van de syntaxiscontrole op de informatieve berichten die de nabijheid tussen R1 (1.1.1.1) en R2 (2.2.2.2) beschrijven. Het IPv4-adresseringsschema dat voor de router-ID wordt gebruikt, maakt het gemakkelijk om de buur te identificeren.
8.2.1.4. Passieve interface
Standaard worden OSPF-berichten doorgestuurd vanuit alle OSPF-compatibele interfaces. Deze berichten hoeven echter alleen maar te worden verzonden via interfaces die verbinding maken met andere OSPF-routers.
Raadpleeg de topologie in bovenstaande afbeelding. OSPF-berichten worden doorgestuurd vanuit alle drie de routers G0/0-interface, ook al bestaat er geen OSPF-buur op dat LAN. Het verzenden van onnodige berichten op een LAN heeft op drie manieren invloed op het netwerk:
- Inefficiënt gebruik van bandbreedte – Beschikbare bandbreedte wordt verbruikt voor het transporteren van onnodige berichten. Berichten zijn multicast; daarom sturen switches de berichten ook door naar alle poorten.
- Inefficiënt gebruik van bronnen – Alle apparaten op het LAN moeten het bericht verwerken en uiteindelijk het bericht weggooien.
- Verhoogd beveiligingsrisico – Advertentie-updates op een uitzendnetwerk vormen een beveiligingsrisico. OSPF-berichten kunnen worden onderschept met packet-sniffing software. Routeringsupdates kunnen worden gewijzigd en teruggestuurd naar de router, waardoor de routeringstabel wordt beschadigd met valse statistieken die het verkeer verkeerd omleiden.
8.2.1.5. Passieve interfaces configureren
Gebruik de passive-interface configuratiemodus opdracht om te voorkomen dat routeringsberichten via een routerinterface worden verzonden, maar laat dat netwerk nog steeds worden geadverteerd naar andere routers, zoals weergegeven in het volgende voorbeeld. De opdracht zorgt er met name voor dat routeringsberichten niet worden verzonden de opgegeven interface. Het netwerk waartoe de gespecificeerde interface behoort, wordt echter nog steeds geadverteerd in routeringsberichten die naar andere interfaces worden verzonden.
R1(config)# router ospf 10
R1(config-router)# passive-interface GigabitEthernet 0/0
R1(config-router)# end
R13
Het is bijvoorbeeld niet nodig dat R1, R2 en R3 OSPF-berichten vanuit hun LAN-interfaces doorsturen. De configuratie identificeert de R1 G0/0-interface als passief.
Het is belangrijk om te weten dat er geen aangrenzendheid kan worden gevormd via een passieve interface. Dit komt omdat pakketten met linkstatus niet kunnen worden verzonden of bevestigd.
R1# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 10"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 1.1.1.1
Number of areas in this router is 1. 1 normal 0 stub 0
nssa
Maximum path: 4
Routing for Networks:
172.16.1.1 0.0.0.0 area 0
172.16.3.1 0.0.0.0 area 0
192.168.10.5 0.0.0.0 area 0
Passive Interface(s):
GigabitEthernet0/0
Routing Information Sources:
Gateway Distance Last Update
3.3.3.3 110 00:08:35
2.2.2.2 110 00:08:35
Distance: (default is 110)
R1#
De opdracht show ip protocols wordt vervolgens gebruikt om te controleren of de Gigabit Ethernet-interface passief was, zoals weergegeven in het voorgaand voorbeeld. Merk op dat de G0/0-interface nu wordt vermeld onder de sectie Passieve interface(s). Het netwerk 172.16.1.0 wordt nog steeds vermeld onder Routing for Networks, wat betekent dat dit netwerk nog steeds wordt opgenomen als een route-item in OSPF-updates die naar R2 en R3 worden verzonden.
Opmerking: OSPFv2 en OSPFv3 ondersteunen beide de opdracht passieve interface.
Als alternatief kunnen alle interfaces passief gemaakt worden met behulp van de passive-interface default opdracht. Interfaces die niet passief mogen zijn, kunnen opnieuw worden ingeschakeld met de opdracht no passive-interface.
Opmerking: Let tijdens het voltooien van de syntaxiscontrole op de OSPF-informatiestatusberichten, aangezien de interfaces allemaal passief worden gemaakt en vervolgens de twee seriële interfaces niet-passief worden gemaakt.
8.2.3. OSPF cost
8.2.3.1. OSPF-metriek = kosten
Bedenk dat een routeringsprotocol een metriek gebruikt om het beste pad van een pakket over een netwerk te bepalen. Een metriek geeft een indicatie van de overhead die nodig is om pakketten over een bepaalde interface te verzenden. OSPF gebruikt kosten als maatstaf. Lagere kosten wijzen op een beter pad dan hogere kosten.
De kosten van een interface zijn omgekeerd evenredig met de bandbreedte van de interface. Daarom duidt een hogere bandbreedte op lagere kosten. Meer overhead en vertragingen staan gelijk aan hogere kosten. Daarom heeft een Ethernet-lijn van 10 Mb/s hogere kosten dan een Ethernet-lijn van 100 Mb/s.
De formule die wordt gebruikt om de OSPF-kosten te berekenen is:
- Kosten = referentiebandbreedte / interfacebandbreedte
De standaard referentiebandbreedte is 10^8 (100.000.000); daarom is de formule:
- Kosten = 100.000.000 bps / interfacebandbreedte in bps
Raadpleeg de tabel in de afbeelding voor een specificatie van de kostenberekening. Merk op dat FastEthernet-, Gigabit Ethernet- en 10 GigE-interfaces dezelfde kosten delen, omdat de OSPF-kostenwaarde een geheel getal moet zijn. Omdat de standaardreferentiebandbreedte is ingesteld op 100 Mb/s, hebben alle verbindingen die sneller zijn dan Fast Ethernet ook een prijs van 1.
Type interface | Referentie bandbreedte in bps / Standaard bandbreedte in bps | Kosten |
---|---|---|
10 Gigabit Ethernet 10 Gbps | 100.000.000 / 10.000.000.000 | 1 |
Gigabit Ethernet 1 Gbps | 100.000.000 / 1.000.000.000 | 1 |
Fast Ethernet 100Mbps | 100.000.000 / 100.000.000 | 1 |
Ethernet 10Mbps | 100.000.000 / 10.000.000 | 10 |
Serieel 1,544 Mbps | 100.000.000 / 1.544.000 | 64 |
Serieel 128 kbps | 100.000.000 / 128.000 | 781 |
Serieel 64 kbps | 100.000.000 / 64.000 | 1562 |
8.2.3.2. OSPF accumuleert kosten
De kosten van een OSPF-route zijn de geaccumuleerde waarde van de ene router naar het bestemmingsnetwerk.
In bovenstaande afbeelding zouden de kosten om de R2 LAN 172.16.2.0/24 vanuit R1 te bereiken bijvoorbeeld als volgt moeten zijn:
- Seriële link van R1 naar R2 kost = 64
- Gigabit Ethernet-link op R2-kosten = 1
- Totale kosten om 172.16.2.0/24 = 65 . te bereiken
De routeringstabel van R1 in volgend voorbeeld bevestigt dat de statistiek om het R2-LAN te bereiken 65 kost.
R1# show ip route | include 172.16.2.0
O 172.16.2.0/24 [110/65] ] via 172.16.3.2, 03:39:07, Serial0/0/0
R1#
R1# show ip route 172.16.2.0
Routing entry for 172.16.2.0/24
Known via "ospf 10", distance 110, metric 65, , type intra area
Last update from 172.16.3.2 on Serial0/0/0, 03:39:15 ago
Routing Descriptor Blocks:
* 172.16.3.2, from 2.2.2.2, 03:39:15 ago, via Serial0/0/0
Route metric is 65, traffic share count is 1
R1#
8.2.3.3. De referentiebandbreedte aanpassen
OSPF gebruikt een referentiebandbreedte van 100 Mb/s voor alle links die gelijk zijn aan of sneller zijn dan een snelle Ethernet-verbinding. Daarom zouden de kosten die worden toegewezen aan een snelle Ethernet-interface met een interfacebandbreedte van 100 Mb/s gelijk zijn aan 1.
Kosten = 100.000.000 bps / 100.000.000 = 1
Hoewel deze berekening werkt voor snelle Ethernet-interfaces, is het problematisch voor verbindingen die sneller zijn dan 100 Mb/s; omdat de OSPF-statistiek alleen gehele getallen gebruikt als de uiteindelijke kosten van een link. Als er iets wordt berekend dat kleiner is dan een geheel getal, rondt OSPF af op het dichtstbijzijnde gehele getal. Om deze reden heeft vanuit het OSPF-perspectief een interface met een interfacebandbreedte van 100 Mb/s (kostprijs 1) dezelfde kosten als een interface met een bandbreedte van 100 Gb/s (kostprijs 1).
Om OSPF te helpen bij het maken van de juiste padbepaling, moet de referentiebandbreedte worden gewijzigd in een hogere waarde voor netwerken met verbindingen die sneller zijn dan 100 Mb/s.
De referentiebandbreedte aanpassen
Het wijzigen van de referentiebandbreedte heeft eigenlijk geen invloed op de bandbreedtecapaciteit op de link; het is eerder van invloed op de berekening die wordt gebruikt om de metriek te bepalen. Om de referentiebandbreedte aan te passen, gebruikt u de auto-cost reference-bandwidth Mb/s routerconfiguratie opdracht. Deze opdracht moet op elke router in het OSPF-domein worden geconfigureerd. Merk op dat de waarde wordt uitgedrukt in Mb/s; daarom de kosten aanpassen voor:
- Gigabit Ethernet – referentiebandbreedte voor automatische kosten 1000
- 10 Gigabit Ethernet – referentiebandbreedte voor automatische kosten 10000
Gebruik de opdracht auto-cost reference-bandwidth 100 om terug te keren naar de standaard referentiebandbreedte.
De volgende tabel geeft de OSPF-kosten weer als de referentiebandbreedte is ingesteld op Gigabit Ethernet. Hoewel de metrische waarden toenemen, maakt OSPF betere keuzes omdat het nu onderscheid kan maken tussen FastEthernet- en Gigabit Ethernet-verbindingen.
Type interface | Referentie bandbreedte in bps / Standaard bandbreedte in bps | Kosten |
---|---|---|
10 Gigabit Ethernet 10 Gbps | 1.000.000.000 / 10.000.000.000 | 1 |
Gigabit Ethernet 1 Gbps | 1.000.000.000 / 1.000.000.000 | 1 |
Fast Ethernet 100Mbps | 1.-00.000.000 / 100.000.000 | 10 |
Ethernet 10Mbps | 1.000.000.000 / 10.000.000 | 100 |
Serieel 1,544 Mbps | 1.000.000.000 / 1.544.000 | 647 |
Serieel 128 kbps | 1.000.000.000 / 128.000 | 7812 |
Serieel 64 kbps | 1.000.000.000 / 64.000 | 15625 |
De volgende tabel geeft de OSPF-kosten weer als de referentiebandbreedte is aangepast om plaats te bieden aan 10 Gigabit Ethernet-verbindingen. De referentiebandbreedte moet worden aangepast wanneer er verbindingen zijn die sneller zijn dan FastEthernet (100 Mb/s).
Type interface | Referentie bandbreedte in bps / Standaard bandbreedte in bps | Kosten |
---|---|---|
10 Gigabit Ethernet 10 Gbps | 10.000.000.000 / 10.000.000.000 | 1 |
Gigabit Ethernet 1 Gbps | 10.000.000.000 / 1.000.000.000 | 10 |
Fast Ethernet 100Mbps | 10.-00.000.000 / 100.000.000 | 100 |
Ethernet 10Mbps | 10.000.000.000 / 10.000.000 | 1000 |
Serieel 1,544 Mbps | 10.000.000.000 / 1.544.000 | 6477 |
Serieel 128 kbps | 10.000.000.000 / 128.000 | 78125 |
Serieel 64 kbps | 10.000.000.000 / 64.000 | 156250 |
Let op: De kosten zijn gehele getallen die naar beneden zijn afgerond.
In onderstaande afbeelding zijn alle routers geconfigureerd om de Gigabit Ethernet-link te ondersteunen met de router configuratieopdracht auto-cost reference-bandwidth 1000. De nieuwe geaccumuleerde kosten om de R2 LAN 172.16.2.0/24 van R1 te bereiken:
- Seriële link van R1 naar R2 kost = 647
- Gigabit Ethernet-link op R2-kosten = 1
- Totale kosten om 172.16.2.0/24 = 648 . te bereiken
Gebruik de opdracht show ip ospf interface s0/0/0 om de huidige OSPF-kosten te verifiëren die zijn toegewezen aan de R1 seriële 0/0/0-interface, zoals weergegeven in afbeelding 4. Merk op hoe de kosten 647 worden weergegeven.
De routeringstabel van R1 in volgend voorbeeld bevestigt dat de statistiek om het R2-LAN te bereiken 648 kost.
R1# show ip ospf interface serial 0/0/0
Serial0/0/0 is up, line protocol is up
Internet Address 172.16.3.1/30,Area 0,Attached via Network Statement
Process ID 10,Router ID 1.1.1.1,Network Type POINT_TO_POINT, Cost:647
Topology-MTID Cost Disabled Shutdown Topology Name
0 647 no no Base
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:01
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 3/3, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 2.2.2.2
Suppress hello for 0 neighbor(s)
R1#
8.2.3.4. Standaard interface bandbreedtes
Aan alle interfaces zijn standaard bandbreedtewaarden toegewezen. Net als bij referentiebandbreedte hebben interfacebandbreedtewaarden geen daadwerkelijke invloed op de snelheid of capaciteit van de link. In plaats daarvan worden ze door OSPF gebruikt om de routeringsmetriek te berekenen. Daarom is het belangrijk dat de bandbreedtewaarde de werkelijke snelheid van de verbinding weerspiegelt, zodat de routeringstabel nauwkeurige informatie over het beste pad heeft.
Hoewel de bandbreedtewaarden van Ethernet-interfaces meestal overeenkomen met de verbindingssnelheid, zijn sommige andere interfaces dat misschien niet. Zo is de werkelijke snelheid van seriële interfaces vaak anders dan de standaard bandbreedte. Op Cisco-routers is de standaardbandbreedte op de meeste seriële interfaces ingesteld op 1.544 Mb/s.
Opmerking: oudere seriële interfaces kunnen standaard 128 kb/s zijn.
Raadpleeg het de referentie topologie in bovenstaande afbeelding Merk op dat de koppeling tussen:
- R1 en R2 moeten worden ingesteld op 1.544 kb/s (standaardwaarde)
- R2 en R3 moeten worden ingesteld op 1024 kb/s
- R1 en R3 moeten worden ingesteld op 64 kb/s
Gebruik de opdracht show interfaces om de bandbreedte-instelling van de interface te bekijken. Volgend voorbeeld toont de seriële interface 0/0/0-instellingen voor R1. De bandbreedte-instelling is nauwkeurig en daarom hoeft de seriële interface niet te worden aangepast.
R1# show interfaces serial 0/0/0
Hardware is WIC MBRD Serial
Description: Link to R2
Internet address is 172.16.3.1/30
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:05, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
215 packets input, 17786 bytes, 0 no buffer
Received 109 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
216 packets output, 17712 bytes, 0 underruns
0 output errors, 0 collisions, 5 interface resets
3 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
R1#
Het volgend voorbeeld toont de seriële interface 0/0/1-instellingen voor R1. Het bevestigt ook dat de interface de standaard interfacebandbreedte van 1.544 kb/s gebruikt. Volgens de referentietopologie moet deze worden ingesteld op 64 kb/s. Daarom moet de R1 seriële 0/0/1-interface worden aangepast.
R1# show interfaces serial 0/0/1 | include BW
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
R1#
Het volgend voorbeeld toont de resulterende kostenmaatstaf van 647, die is gebaseerd op de referentiebandbreedte die is ingesteld op 1.000.000.000 bps en de standaard interfacebandbreedte van 1.544 kb/s (1.000.000.000 / 1.544.000).
R1# show ip ospf interface serial 0/0/1
Serial0/0/1 is up, line protocol is up
Internet Address 192.168.10.5/30, Area 0, Attached via Network Statement
Network Statement
Process ID 10, Router ID 1.1.1.1, Network Type
POINT_TO_POINT, Cost: 647
Topology-MTID Cost Disabled Shutdown Topology Name
0 647 no no Base
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40,
Retransmit 5
oob-resync timeout 40
Hello due in 00:00:04
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 3/3, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 3.3.3.3
Suppress hello for 0 neighbor(s)
R1#
R1# show ip ospf interface serial 0/0/1 | include Cost:
Process ID 10, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 647
R1#
8.2.3.5. De interfacebandbreedte aanpassen
Gebruik de interfaceconfiguratieopdracht voor bandwidth kilobits om de interfacebandbreedte aan te passen. Gebruik de opdracht no bandwidth om de standaardwaarde te herstellen.
Het voorbeeld in figuur 1 stelt de R1 seriële 0/0/1-interfacebandbreedte in op 64 kb/s. Een snelle verificatie bevestigt dat de bandbreedte-instelling van de interface nu 64 kb/s is.
R1(config)# interface s0/0/1
R1(config-if)# bandwidth 64
R1(config-if)# end
R1#
*Mar 27 10:10:07.735: %SYS-5-CONFIG_I: Configured from console by c
R1#
R1# show interfaces serial 0/0/1 | include BW
MTU 1500 bytes, BW 64 Kbit/sec, , DLY 20000 usec,
R1#
R1# show ip ospf interface serial 0/0/1 | include Cost:
Process ID 10, Router ID 1.1.1.1, Network Type
POINT_TO_POINT, Cost: 15625
R1#
De bandbreedte moet aan elk uiteinde van de seriële verbindingen worden aangepast, daarom:
- R2 vereist dat zijn S0/0/1-interface wordt aangepast tot 1024 kb/s.
- R3 vereist dat de seriële 0/0/0 wordt aangepast tot 64 kb/s en dat de seriële 0/0/1 wordt aangepast tot 1024 kb/s.
Opmerking: Een veelvoorkomende misvatting voor studenten die nieuw zijn in netwerken en de Cisco IOS is om aan te nemen dat de bandbreedteopdracht de fysieke bandbreedte van de link verandert. De opdracht wijzigt alleen de bandbreedte die wordt gebruikt door EIGRP en OSPF. De opdracht wijzigt de werkelijke bandbreedte op de link niet.
8.2.3.6. De OSPF-kosten handmatig instellen
Als alternatief voor het instellen van de standaard interfacebandbreedte kunnen de kosten handmatig worden geconfigureerd op een interface met behulp van het ip ospf cost value interface-configuratiecommando.
Een voordeel van het configureren van kosten boven het instellen van de interfacebandbreedte is dat de router de metriek niet hoeft te berekenen wanneer de kosten handmatig worden geconfigureerd. Wanneer daarentegen de interfacebandbreedte is geconfigureerd, moet de router de OSPF-kosten berekenen op basis van de bandbreedte. De opdracht ip ospf cost is handig in omgevingen met meerdere leveranciers waar niet-Cisco-routers een andere maatstaf dan bandbreedte kunnen gebruiken om de OSPF-kosten te berekenen.
Zowel het bandwidth-interfacecommando als het ip ospf cost-interfacecommando bereiken hetzelfde resultaat, namelijk het verschaffen van een nauwkeurige waarde voor gebruik door OSPF bij het bepalen van de beste route.
In onderstaand voorbeeld wordt bijvoorbeeld de interfacebandbreedte van serieel 0/0/1 teruggezet naar de standaardwaarde en worden de OSPF-kosten handmatig ingesteld op 15.625. Hoewel de interfacebandbreedte wordt teruggezet naar de standaardwaarde, worden de OSPF-kosten ingesteld alsof de bandbreedte nog steeds is berekend.
R1(config)# interface s0/0/1
R1(config-if)# no bandwidth 64
R1(config-if)# ip ospf cost 15625
R1(config-if)# end
R1#
R1# show interface serial 0/0/1 | include BW
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
R1#
R1# show ip ospf interface serial 0/0/1 | include Cost:
Process ID 10, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 15625
R1#
Figuur 2 toont de twee alternatieven die kunnen worden gebruikt bij het wijzigen van de kosten van de seriële verbindingen in de topologie. De rechterkant van de afbeelding toont de ip ospf cost commando-equivalenten van de bandwidth commando’s aan de linkerkant.
Interface bandbreedte instellen | OSPF kosten manueel instellen |
---|---|
R1(config)# interface S0/0/1 R1(config-if)# bandwidth 64 | R1(config)# interface S0/0/1 R1(config-if)# ip ospf cost 15625 |
R2(config)# interface S0/0/1 R2(config-if)# bandwidth 1024 | R2(config)# interface S0/0/1 R2(config-if)# ip ospf cost 976 |
R3(config)# interface S0/0/0 R3(config-if)# bandwidth 64 | R3(config)# interface S0/0/0 R13config-if)# ip ospf cost 15625 |
R3(config)# interface S0/0/1 R3(config-if)# bandwidth 1024 | R3(config)# interface S0/0/1 R3(config-if)# ip ospf cost 976 |
8.2.4. Verifieer OSPF
8.2.4.1. OSPF Buren verifiëren
Gebruik de opdracht show ip ospf neighbour om te controleren of de router een aangrenzende router heeft gevormd. Als de router-ID van de naburige router niet wordt weergegeven, of niet wordt weergegeven als FULL, hebben de twee routers geen OSPF-nabijheid gevormd.
Als twee routers geen nabijheid tot stand brengen, wordt er geen informatie over de verbindingsstatus uitgewisseld. Onvolledige LSDB’s kunnen onnauwkeurige SPF-bomen en routeringstabellen veroorzaken. Routes naar bestemmingsnetwerken bestaan mogelijk niet of zijn niet het meest optimale pad.
Figuur 2 toont de aangrenzende nabijheid van R1. Voor elke buur geeft deze opdracht de volgende uitvoer weer:
- Neighbour ID – De router-ID van de naburige router.
- Pri – De OSPF-prioriteit van de interface. Deze waarde wordt gebruikt bij de DR- en BDR-verkiezingen.
- State – De OSPF-status van de interface. FULL-status betekent dat de router en zijn buur identieke OSPF LSDB’s hebben. Op multiaccess-netwerken, zoals Ethernet, kan de status van twee aangrenzende routers worden weergegeven als 2WAY. Het streepje geeft aan dat er geen DR of BDR vereist is vanwege het netwerktype.
- Dead Time – De resterende tijd die de router wacht om een OSPF Hello-pakket van de buur te ontvangen voordat de buur wordt gedeclareerd. Deze waarde wordt gereset wanneer de interface een Hello-pakket ontvangt.
- Address – Het IPv4-adres van de interface van de buren waarmee deze router rechtstreeks is verbonden.
- Interface – De interface waarop deze router nabijheid heeft gevormd met de buurman.
Gebruik de syntaxiscontrole in figuur 3 om de R2- en R3-buren te verifiëren met behulp van het show ip ospf neighbour commando.
Twee routers mogen geen aangrenzend OSPF vormen als:
- De subnetmaskers komen niet overeen, waardoor de routers zich op aparte netwerken bevinden.
- OSPF Hello of Dead Timers komen niet overeen.
- OSPF-netwerktypen komen niet overeen.
- Er is een ontbrekende of onjuiste OSPF netwerk opdracht.
R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 0 FULL/- 00:00:37 192.168.10.6 Serial0/0/1
2.2.2.2 0 FULL/- 00:00:30 172.16.3.2 Serial0/0/0
R1#
8.2.4.2. Controleer OSPF-protocolinstellingen
Zoals weergegeven in het volgende voorbeeld is de opdracht show ip protocols een snelle manier om essentiële OSPF-configuratie-informatie te verifiëren. Dit omvat de OSPF-proces-ID, de router-ID, netwerken waar de router reclame voor maakt, de buren waarvan de router updates ontvangt en de standaard administratieve afstand, die 110 is voor OSPF.
R1# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 10"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 1.1.1.1
Number of areas in this router is 1. 1 normal 0 stub 0
nssa
Maximum path: 4
Routing for Networks:
172.16.1.0 0.0.0.255 area 0
172.16.3.0 0.0.0.3 area 0
192.168.10.4 0.0.0.3 area 0
Routing Information Sources:
Gateway Distance Last Update
3.3.3.3 110 00:17:18
2.2.2.2 110 00:14:49
Distance: (default is 110)
R1#
8.2.4.3. OSPF-procesinformatie verifiëren
De opdracht show ip ospf kan ook worden gebruikt om de OSPF-proces-ID en router-ID te onderzoeken, zoals weergegeven in het volgende voorbeeld. Deze opdracht geeft de OSPF-gebiedsinformatie weer en de laatste keer dat het SPF-algoritme is berekend.
R# show ip ospf
Routing Process "ospf 10" with ID 1.1.1.1<br>
Start time: 01:37:15.156, Time elapsed: 01:32:57.776
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Supports NSSA (compatible with RFC 3101)
Event-log enabled, Maximum number of events: 1000, Mode: cyclic
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Incremental-SPF disabled
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Number of areas transit capable is 0
External flood list length 0
IETF NSF helper support enabled
Cisco NSF helper support enabled
Reference bandwidth unit is 1000 mbps
Area BACKBONE(0)
Number of interfaces in this area is 3
Area has no authentication
SPF algorithm last executed 01:30:45.364 ago
SPF algorithm executed 3 times
Area ranges are
Number of LSA 3. Checksum Sum 0x02033A
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
R1#
8.2.4.4. Controleer OSPF-interface-instellingen
De snelste manier om de OSPF-interface-instellingen te controleren, is door de opdracht show ip ospf interface te gebruiken. Deze opdracht biedt een gedetailleerde lijst voor elke OSPF-compatibele interface. Het commando is handig om te bepalen of de netwerk statements correct zijn opgesteld.
Gebruik de opdracht show ip ospf interface brief om een overzicht te krijgen van OSPF-interfaces, zoals weergegeven in het onderstaand voorbeeld.
R1# show ip ospf interface brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Se0/0/1 10 0 192.168.10.5/30 15625 P2P 1/1
Se0/0/0 10 0 172.16.3.1/30 647 P2P 1/1
Gi0/0 10 0 172.16.1.1/24 1 DR 0/0
R1#
8.3. Single-Area OSPFv2 configureren
8.3.1. OSPFv2 vs. OSPFv3
8.3.1.1. OSPFv3
OSPFv3 is het OSPFv2-equivalent voor het uitwisselen van IPv6-prefixen. Bedenk dat in IPv6 het netwerkadres de prefix wordt genoemd en het subnetmasker de prefixlengte.
Net als zijn IPv4-tegenhanger, wisselt OSPFv3 routeringsinformatie uit om de IPv6-routeringstabel te vullen met externe voorvoegsels, zoals weergegeven in de afbeelding.
Opmerking: Met de functie OSPFv3-adresfamilies biedt OSPFv3 ondersteuning voor zowel IPv4 als IPv6.
OSPFv2 loopt via de IPv4-netwerklaag, communiceert met andere OSPF IPv4-peers en adverteert alleen IPv4-routes.
OSPFv3 heeft dezelfde functionaliteit als OSPFv2, maar gebruikt IPv6 als netwerklaagtransport, communiceert met OSPFv3-peers en maakt reclame voor IPv6-routes. OSPFv3 gebruikt ook het SPF-algoritme als rekenmachine om de beste paden door het routeringsdomein te bepalen.
Zoals met alle IPv6-routeringsprotocollen, heeft OSPFv3 afzonderlijke processen van zijn IPv4-tegenhanger. De processen en bewerkingen zijn in principe hetzelfde als in het IPv4-routeringsprotocol, maar draaien onafhankelijk. OSPFv2 en OSPFv3 hebben elk afzonderlijke aangrenzende tabellen, OSPF-topologietabellen en IP-routeringstabellen, zoals weergegeven in de afbeelding.
De OSPFv3-configuratie- en verificatieopdrachten zijn vergelijkbaar met die in OSPFv2.
8.3.1.2. Overeenkomsten tussen OSPFv2 en OSPFv3
Zoals weergegeven in de afbeelding, zijn de volgende overeenkomsten tussen OSPFv2 en OSPFv3:
- Link-state – OSPFv2 en OSPFv3 zijn beide klasseloze routeringsprotocollen voor link-state.
- Routeringsalgoritme – OSPFv2 en OSPFv3 gebruiken het SPF-algoritme om routeringsbeslissingen te nemen.
- Metriek – De RFC’s voor zowel OSPFv2 als OSPFv3 definiëren de metriek als de kosten van het verzenden van pakketten via de interface. OSPFv2 en OSPFv3 kunnen worden gewijzigd met behulp van de opdracht auto-cost reference-bandwidth ref-bw routerconfiguratiemodus. De opdracht heeft alleen invloed op de OSPF-metriek waar deze is geconfigureerd. Als deze opdracht bijvoorbeeld is ingevoerd voor OSPFv3, heeft dit geen invloed op de OSPFv2-routeringsstatistieken.
- Gebieden – Het concept van meerdere gebieden in OSPFv3 is hetzelfde als in OSPFv2. Multi-gebieden die overstroming van link-states minimaliseren en betere stabiliteit bieden met het OSPF-domein.
- OSPF-pakkettypen – OSPFv3 gebruikt dezelfde vijf basispakkettypen als OSPFv2 (Hallo, DBD, LSR, LSU en LSAck).
- Mechanisme voor het ontdekken van buren – De machine voor de naburige toestand, inclusief de lijst met OSPF-statussen en gebeurtenissen, blijft ongewijzigd. OSPFv2 en OSPFv3 gebruiken het Hello-mechanisme om meer te weten te komen over naburige routers en om aangrenzende netwerken te vormen. In OSPFv3 is er echter geen vereiste voor het matchen van subnetten om aangrenzende aangrenzende gebieden te vormen. Dit komt omdat aangrenzende aangrenzende gebieden worden gevormd met behulp van link-local-adressen, niet met globale unicast-adressen.
- DR/BDR-verkiezingsproces – Het DR/BDR-verkiezingsproces blijft ongewijzigd in OSPFv3.
- Router-ID – Zowel OSPFv2 als OSPFv3 gebruiken een 32-bits nummer voor de router-ID die wordt weergegeven in decimale notatie. Meestal is dit een IPv4-adres. De opdracht OSPF router-id moet worden gebruikt om de router-ID te configureren. Het proces bij het bepalen van de 32-bits router-ID is in beide protocollen hetzelfde. Gebruik een expliciet geconfigureerde router-ID; anders wordt het hoogste loopback-IPv4-adres de router-ID.
Link-State | Ja |
Routeringsalfgoritme | SPF |
Metriek | Kosten |
Gebieden | Ondersteund dezelfde twee-niveaus hiearchie |
Pakkettypen | Dezelfde Hello, DBD, LSR, LSU en LSAck pakketten |
Neighbor Discovery | Overgangen door dezelfde toestanden met Hello-pakketten |
DR en BDR | Dezelfde functie en verkiezingsproces |
Router ID | 32-bit router ID: in beide protocollen bepaald door hetzelfde proces |
8.3.1.3. Verschillen tussen OSPFv2 en OSPFv3
De afbeelding toont de verschillen tussen OSPFv2 en OSPFv3:
- Adverteren – OSPFv2 adverteert IPv4-routes, terwijl OSPFv3 routes voor IPv6 adverteert.
- Bronadres – OSPFv2-berichten zijn afkomstig van het IPv4-adres van de exit-interface. In OSPFv3 worden OSPF-berichten afkomstig van het link-local-adres van de exit-interface.
- Alle multicast-adressen van de OSPF-router – OSPFv2 gebruikt 225.0.0.5; terwijl OSPFv3 FF02::5 gebruikt.
- DR/BDR multicast-adres – OSPFv2 gebruikt 224.0.0.6; terwijl OSPFv3 FF02::6 gebruikt.
- Adverteer netwerken – OSPFv2 maakt reclame voor netwerken met behulp van de configuratieopdracht van de netwerkrouter; terwijl OSPFv3 de ipv6 ospf process-id area area-id interface-configuratieopdracht gebruikt.
- IP unicast-routering – standaard ingeschakeld in IPv4; terwijl de ipv6 unicast-routing globale configuratieopdracht moet worden geconfigureerd.
- Verificatie – OSPFv2 gebruikt authenticatie in platte tekst of MD5-authenticatie. OSPFv3 gebruikt IPv6-authenticatie.
OSPFv2 | OSPFv3 | |
---|---|---|
Adverteren | IPv4 netwerken | IPv6 prefixen |
Bronadres | IPv4 bronadres | IPv6 bronadres |
Bestemmingsadres | Keuze uit: – Naburige IPv4 unicast adres – 224.0.0.5 all-OSPF-routers multicast adres – 224.0.0.6 DR/BDR multicast adres | Keuze uit: – Naburige IPv6 link-local adres – FF02::5 all-OSPFv3-routers muticast adres – FF02::6 DR/BDR multicast adres |
Adverteert netwerken | Geconfigureerd met behulp van het network routerconfiguratieopdracht | Geconfigureerd met behulp van het ipv6 ospf process-id area area-id interface configuratieopdracht |
IP unicast routering | IPv4-unicast-routering is standaard ingeschakeld. | IPv6 unicast forwarding is standaard niet mogelijk. Het ipv6 unicast-routing globaal configuratieopdracht moet geconfigureerd worden. |
Authenticatie | Platte tekst en MD5 | IPv6-authenticatie |
8.3.1.4. Link-lokale adressen
Routers met een dynamisch routeringsprotocol, zoals OSPF, wisselen berichten uit tussen buren op hetzelfde subnet of dezelfde link. Routers hoeven alleen routeringsprotocolberichten te verzenden en te ontvangen met hun direct verbonden buren. Deze berichten worden altijd verzonden vanaf het bron-IPv4-adres van de router die het doorsturen uitvoert.
IPv6 link-local adressen zijn hiervoor ideaal. Met een IPv6 link-local adres kan een apparaat communiceren met andere IPv6-compatibele apparaten op dezelfde link en alleen op die link (subnet). Pakketten met een bron- of bestemmingslink-lokaal adres kunnen niet verder worden gerouteerd dan de link waar het pakket vandaan kwam.
OSPFv3-berichten verzonden met:
- Bron IPv6-adres – Dit is het IPv6-link-local-adres van de exit-interface.
- Bestemmings-IPv6-adres – OSPFv3-pakketten kunnen naar een unicast-adres worden verzonden met behulp van het naburige IPv6-link-local-adres. Ze kunnen ook worden verzonden met een multicast-adres. Het FF02::5-adres is het all OSPF-routeradres, terwijl de FF02::6 het DR/BDR-multicastadres is.
8.3.2. OSPFv3 configureren
8.3.2.1. OSPFv3-netwerktopologie
Onderstaande afbeelding toont de netwerktopologie die wordt gebruikt om OSPFv3 te configureren.
Afbeelding 2 toont IPv6 unicast-routering en de configuratie van de globale unicast-adressen van R1, zoals geïdentificeerd in de referentietopologie. Neem aan dat de interfaces van R2 en R3 ook zijn geconfigureerd met hun globale unicast-adressen, zoals aangegeven in de topologie waarnaar wordt verwezen.
R1(config)# ipv6 unicast-routing
R1(config)# interface GigabitEthernet 0/0
R1(config-if)# description R1 LAN
R1(config-if)# ipv6 address 2001:DB8:CAFE:1::1/64
R1(config-if)# no shut
R1(config-if)#
R1(config-if)# interface Serial0/0/0
R1(config-if)# description Link to R2
R1(config-if)# ipv6 address 2001:DB8:CAFE:A001::1/64
R1(config-if)# clock rate 128000
R1(config-if)# no shut
R1(config-if)#
R1(config-if)# interface Serial0/0/1
R1(config-if)# description Link to R3
R1(config-if)# ipv6 address 2001:DB8:CAFE:A003::1/64
R1(config-if)# no shut
R1(config-if)# end
R1#
In deze topologie heeft geen van de routers IPv4-adressen geconfigureerd. Een netwerk met routerinterfaces geconfigureerd met IPv4- en IPv6-adressen wordt dual-stacked genoemd. Een dual-stacked netwerk kan OSPFv2 en OSPFv3 tegelijkertijd hebben ingeschakeld.
Stappen voor het configureren van basis OSPFv3 in een enkel gebied:
Stap1. Schakel IPv6 unicast-routering in:
Stap2. (Optioneel) Configureer link-local-adressen.
Stap3. Configureer een 32-bits router-ID in de OSPFv3-routerconfiguratiemodus met behulp van de router-id rid opdracht.
Stap 4. Configureer optionele routeringsspecificaties, zoals het aanpassen van de referentiebandbreedte.
Stap 5. (Optioneel) Configureer OSPFv3-interfacespecifieke instellingen. Pas bijvoorbeeld de bandbreedte van de interface aan.
Stap 6. Schakel IPv6-routering in met behulp van de ipv6 ospf area opdracht.
8.3.2.2. Link-local adressen
In de afbeelding bevestigt de uitvoer van de opdracht show ipv6 interface brief dat de juiste globale IPv6-adressen met succes zijn geconfigureerd en dat de interfaces zijn ingeschakeld. Merk ook op dat elke interface automatisch een link-local adres genereerde, zoals aangegeven in de afbeelding.
R1# show ipv6 interface brief
Em0/0 [administratively down/down]
unassigned
GigabitEthernet0/0
FE80::32F7:DFF:FEA3:DA0
2001:DB8:CAFE:1::1
GigabitEthernet0/1 [administratively down/down]
unassigned
Serial0/0/0 [up/up]
FE80::32F7:DFF:FEA3:DA0
2001:DB8:CAFE:A001::1
Serial0/0/1 [up/up]
FE80::32F7:DFF:FEA3:DA0
2001:DB8:CAFE:A003::1
R1#
Link-local-adressen worden automatisch aangemaakt wanneer een IPv6 globaal unicast-adres aan de interface wordt toegewezen. Globale unicast-adressen zijn niet vereist op een interface; IPv6 link-local-adressen zijn dat echter wel.
Tenzij handmatig geconfigureerd, creëren Cisco-routers het link-local-adres met behulp van het FE80::/10-voorvoegsel en het EUI-64-proces. EUI-64 omvat het gebruik van het 48-bit Ethernet MAC-adres, het invoegen van FFFE in het midden en het omdraaien van het zevende bit. Voor seriële interfaces gebruikt Cisco het MAC-adres van een Ethernet-interface. Merk in de afbeelding op dat alle drie de interfaces hetzelfde link-local adres gebruiken.
8.3.2.3. Link-local adressen toewijzen
Link-local adressen die zijn gemaakt met het EUI-64-formaat of in sommige gevallen willekeurige interface-ID’s, maken het moeilijk om die adressen te herkennen en te onthouden. Omdat IPv6-routeringsprotocollen IPv6-link-local-adressen gebruiken voor unicast-adressering en next-hop-adresinformatie in de routeringstabel, is het gebruikelijk om er een gemakkelijk herkenbaar adres van te maken.
Het handmatig configureren van het link-local adres biedt de mogelijkheid om een adres te creëren dat herkenbaar en gemakkelijker te onthouden is. Ook kan een router met meerdere interfaces hetzelfde link-local adres toewijzen aan elke IPv6-interface. Dit komt omdat het link-local adres alleen nodig is voor lokale communicatie.
Link-local-adressen kunnen handmatig worden geconfigureerd met dezelfde interfaceopdracht die wordt gebruikt om IPv6 globale unicast-adressen te maken, maar door het sleutelwoord link-local toe te voegen aan de ipv6 address opdracht.
Een link-local adres heeft een prefix binnen het bereik FE80 tot FEBF. Als een adres met dit hextet (16-bits segment) begint, moet het sleutelwoord link-local het adres volgen.
Het volgende voorbeeld configureert hetzelfde link-local adres FE80::1 op de drie R1-interfaces. FE80::1 is gekozen om het makkelijk te maken om de link-local adressen van R1 te onthouden.
R1(config)# interface GigabitEthernet 0/0
R1(config-if)# ipv6 address fe80::1 link-local
R1(config-if)# exit
R1(config)# interface Serial0/0/0
R1(config-if)# ipv6 address fe80::1 link-local
R1(config-if)# exit
R1(config)# interface Serial0/0/1
R1(config-if)# ipv6 address fe80::1 link-local
R1(config-if)#
Een snelle blik op de interfaces zoals weergegeven in het volgend voorbeeld bevestigt dat de R1-interface link-local-adressen zijn gewijzigd in FE80::1.
R1# show ipv6 interface brief
Em0/0 [administratively down/down]
unassigned
GigabitEthernet0/0 [up/up]
FE80::1
GigabitEthernet0/1 [administratively down/down]
unassigned
Serial0/0/0 [up/up]
FE80::1
2001:DB8:CAFE:A001::1</div>
Serial0/0/1 [up/up]
FE80::1
2001:DB8:CAFE:A003::1</div>
R1#
8.3.2.4. De OSPFv3-router-ID configureren
Gebruik de opdracht ipv6 router ospf process-id global configuration mode om de routerconfiguratiemodus te openen. De prompt voor de configuratiemodus van de IPv6-router is anders dan de prompt voor de configuratie van de IPv4-router. Gebruik de IPv6-routerbevestigingsmodus om algemene OSPFv3-parameters te configureren, zoals het toewijzen van een 32-bits OSPF-router-ID en referentiebandbreedte.
IPv6-routeringsprotocollen worden ingeschakeld op een interface en niet vanuit de routerconfiguratiemodus, zoals hun IPv4-tegenhangers. De network IPv4 router configuratieopdracht bestaat niet in IPv6.
Net als OSPFv2 is de process-id waarde een getal tussen 1 en 65.535 en wordt gekozen door de netwerkbeheerder. De proces-id-waarde is lokaal significant, wat betekent dat het niet hoeft te matchen met andere OSPF-routers om aangrenzendheden met die buren tot stand te brengen.
OSPFv3 vereist dat een 32-bits router-ID wordt toegewezen voordat OSPF op een interface kan worden ingeschakeld. Het logicaschema in afbeelding 1 laat zien hoe een router-ID wordt gekozen. Net als OSPFv2 gebruikt OSPFv3:
- Eerst een expliciet geconfigureerde router-ID.
- Als er geen zijn geconfigureerd, gebruikt de router het hoogst geconfigureerde IPv4-adres van een loopback-interface.
- Als er geen zijn geconfigureerd, gebruikt de router het hoogst geconfigureerde IPv4-adres van een actieve interface.
- Als er geen bronnen van IPv4-adressen op een router zijn, geeft de router een consolebericht weer om de router-ID handmatig te configureren.
Opmerking: voor consistentie gebruiken alle drie de routers de proces-ID 10.
Zoals weergegeven in de topologie in bovenstaande afbeelding, moeten routers R1, R2 en R3 de aangegeven router-ID’s krijgen. De router-id rid-opdracht die wordt gebruikt om een router-ID toe te wijzen in OSPFv2 is dezelfde opdracht die wordt gebruikt in OSPFv3.
R1(config) ipv6 router ospf 10
R1(config-rtr)#
*Mar 29 11:21:53.739: %OSPFv3-4-NORTRID: Process OSPFv3-1-
IPv6 could not pick a router-id, please configure manually
R1(config-rtr)# router-id 1.1.1.1
R1(config-rtr)# auto-cost reference-bandwidth 1000
% OSPFv3-1-IPv6: Reference bandwidth is changed. Please
ensure reference bandwidth is consistent across all routers
R1(config-rtr)# end
R1#
R1# show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "ND"
IPv6 Routing Protocol is "ospf 10"
Router ID 1.1.1.1
Number of areas: 0 normal, 0 stub, 0 nssa
Redistribution:
None
R1#
Het bovenstaand voorbeeld:
- Opent de OSPFv3-configuratiemodus van de router. Merk op dat de routerprompt anders is dan de standaard routerprompt in IPv4-routeringsprotocolmodus. Merk ook op hoe een informatief consolebericht verscheen toen de OSPFv3-routerconfiguratiemodus werd geopend.
- Wijst de router-ID 1.1.1.1 toe.
- Stelt de referentiebandbreedte in op 1.000.000.000 bps (1 Gb/s), omdat er Gigabit Ethernet-links in het netwerk zitten. Let op het bericht van de informatieconsole dat deze opdracht op alle routers in het routeringsdomein moet worden geconfigureerd.
- De opdracht show ipv6 protocols wordt gebruikt om te controleren of de OSPFv3-proces-ID 10 de router-ID 1.1.1.1 gebruikt.
8.3.2.5. Een OSPFv3-router-ID wijzigen
Router-ID’s moeten soms worden gewijzigd, bijvoorbeeld als de netwerkbeheerder een nieuw identificatieschema voor router-ID’s heeft opgesteld. Nadat een OSPFv3-router echter een router-ID heeft vastgesteld, kan die router-ID niet worden gewijzigd totdat de router opnieuw is geladen of het OSPF-proces is gewist.
In het volgende voorbeeld ziet u dat de huidige router-ID 10.1.1.1 is. De OSPFv3-router-ID moet 1.1.1.1 zijn.
R1# show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "ND"
IPv6 Routing Protocol is "ospf 10"
Router ID 1.1.1.1
Number of areas: 0 normal, 0 stub, 0 nssa
Redistribution:
None
R1#
In het volgende voorbeeld wordt de router-ID 1.1.1.1 toegewezen aan R1.
R1(config) ipv6 router ospf 10
R1(config-rtr)# router-id 1.1.1.1
R1(config-rtr)# end
R1#
Opmerking: het wissen van het OSPF-proces is de voorkeursmethode om de router-ID opnieuw in te stellen.
In het volgend voorbeeld wordt het OSPF-routeringsproces gewist met de opdracht clear ipv6 ospf process privileged EXEC mode. Hierdoor wordt OSPF op R1 gedwongen om opnieuw te onderhandelen over aangrenzende aangrenzende gebieden met behulp van de nieuwe router-ID.
De opdracht show ipv6 protocols controleert of de router-ID is gewijzigd.
R1# clear ipv6 ospf process
Reset selected OSPFv3 processes? [no]: y
R1#
R1# show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "ND
IPv6 Routing Protocol is "ospf 10"
Router ID 1.1.1.1
Number of areas: 0 normal, 0 stub, 0 nssa
Redistribution:
None
R1#
8.3.2.6. OSPFv3 inschakelen op interfaces
OSPFv3 gebruikt een andere methode om een interface voor OSPF in te schakelen. In plaats van de network router configuratiemodus opdracht te gebruiken om overeenkomende interface-adressen op te geven, wordt OSPFv3 rechtstreeks op de interface geconfigureerd.
Om OSPFv3 op een interface in te schakelen, gebruikt u de ipv6 ospf process-id area area-id interface configuratiemodus opdracht.
De process-id waarde identificeert het specifieke routeringsproces en moet hetzelfde zijn als de proces-ID die is gebruikt om het routeringsproces te maken in de ipv6 router ospf process-id-opdracht.
De area-id-waarde is het gebied dat moet worden gekoppeld aan de OSPFv3-interface. Hoewel elke waarde voor het gebied had kunnen worden geconfigureerd, werd 0 geselecteerd, omdat gebied 0 het ruggengraatgebied is waaraan alle andere gebieden moeten worden gekoppeld, zoals weergegeven in afbeelding 1. Dit helpt bij de migratie naar OSPF met meerdere gebieden, als dat nodig is.
In volgend voorbeeld is OSPFv3 ingeschakeld op de R1-interfaces met behulp van de opdracht ipv6 ospf 10 area 0. De opdracht show ipv6 ospf interface brief geeft de actieve OSPFv3-interfaces weer.
R1(config)# interface GigabitEthernet 0/0
R1(config-if)# ipv6 ospf 10 area 0
R1(config-if)#
R1(config-if)# interface Serial0/0/0
R1(config-if)# ipv6 ospf 10 area 0
R1(config-if)#
R1(config-if)# interface Serial0/0/1
R1(config-if)# ipv6 ospf 10 area 0
R1# end
R1# show ipv6 ospf interfaces brief
Interface PID Area Intf ID Cost State Nbrs F/C
Se0/0/1 10 0 7 15625 P2P 0/0
Se0/0/0 10 0 6 647 P2P 0/0
Gi0/0 10 0 3 1 WAIT 0/0
R1#
8.3.3. Verifieer OSPFv3
8.3.3.1. OSPFv3-buren verifiëren
Gebruik de opdracht show ipv6 ospf neighbour om te controleren of de router een aangrenzende router heeft gevormd. Als de router-ID van de naburige router niet wordt weergegeven, of als deze niet in de status FULL wordt weergegeven, hebben de twee routers geen OSPF-nabijheid gevormd.
Als twee routers geen naburige nabijheid tot stand brengen, wordt er geen informatie over de verbindingsstatus uitgewisseld. Onvolledige LSDB’s kunnen onnauwkeurige SPF-bomen en routeringstabellen veroorzaken. Routes naar bestemmingsnetwerken bestaan mogelijk niet of zijn niet het meest optimale pad.
R1# show ipv6 ospf neighbor
OSPFv3 Router with ID (1.1.1.1) (Process ID 10)
Neighbor ID Pri State Dead Time Interface ID Interface
3.3.3.3 0 FULL/ - 00:00:39 6 Serial0/0/1
2.2.2.2 0 FULL/ - 00:00:36 6 Serial0/0/0
R1#
Bovenstaand voorbeeld toont de aangrenzende nabijheid van R1. Voor elke buur geeft deze opdracht de volgende uitvoer weer:
- Neighbour ID – De router-ID van de naburige router.
- Pri – De OSPF-prioriteit van de interface. Waarde wordt gebruikt bij de DR- en BDR-verkiezingen.
- State – De OSPF-status van de interface. FULL-status betekent dat de router en zijn buur identieke OSPF LSDB’s hebben. Op multiaccess-netwerken zoals Ethernet kan de status van twee aangrenzende routers worden weergegeven als 2WAY. Het streepje geeft aan dat er geen DR of BDR vereist is vanwege het netwerktype.
- Dead Time – De resterende tijd die de router wacht om een OSPF Hello-pakket van de buur te ontvangen voordat de buur wordt gedeclareerd. Deze waarde wordt gereset wanneer de interface een Hello-pakket ontvangt.
- Interface-ID – De interface-ID of link-ID.
- Interface – De interface waarop deze router nabijheid heeft gevormd met de buurman.
8.3.3.2. Controleer OSPFv3-protocolinstellingen
Zoals weergegeven in volgende voorbeeld is de opdracht show ipv6 protocols een snelle manier om essentiële OSPFv3-configuratie-informatie te verifiëren, inclusief de OSPF-proces-ID, de router-ID en de interfaces die zijn ingeschakeld voor OSPFv3.
Gebruik de opdracht show ipv6 ospf om ook de OSPFv3-proces-ID en router-ID te onderzoeken. Deze opdracht geeft de OSPF-gebiedsinformatie weer en de laatste keer dat het SPF-algoritme is berekend.
R1# show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "ND"
IPv6 Routing Protocol is "ospf 10"
Router ID 1.1.1.1
Number of areas: 1 normal, 0 stub, 0 nssa
Interfaces (Area 0):
Serial0/0/1
Serial0/0/0
GigabitEthernet0/0
Redistribution:
None
R1#
8.3.3.3. Controleer OSPFv3-interfaces
De snelste manier om de OSPF-interface-instellingen te controleren, is door de opdracht show ipv6 ospf interface te gebruiken. Deze opdracht biedt een gedetailleerde lijst voor elke OSPF-compatibele interface.
Gebruik de opdracht show ipv6 ospf interface brief om een samenvatting van OSPFv3-compatibele interfaces op R1 op te halen en te bekijken, zoals weergegeven in het volgend voorbeeld.
R1# show ipv6 ospf interface brief
Interface PID Area Intf ID Cost State Nbrs F/C
Se0/0/1 10 0 7 15625 P2P 1/1
Se0/0/0 10 0 6 647 P2P 1/1
Gi0/0 10 0 3 1 DR 0/0
R1#
8.3.3.4. Controleer de IPv6-routeringstabel
In het volgend voorbeeld geeft de opdracht show ipv6 route ospf details over OSPF-routes in de routeringstabel.
R1# show ipv6 route ospf
IPv6 Routing Table - default - 10 entries
Codes:C - Connected, L - Local, S - Static, U - Per-user
Static route
B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF
NSSA ext 2
O 2001:DB8:CAFE:2::/64 [110/657]
via FE80::2, Serial0/0/0
O 2001:DB8:CAFE:3::/64 [110/1304]
via FE80::2, Serial0/0/0
O 2001:DB8:CAFE:A002::/64 [110/1294]
via FE80::2, Serial0/0/0
R1#
8.4. Samenvatting
De huidige versie van OSPF voor IPv4 is OSPFv2 geïntroduceerd in RFC 1247 en bijgewerkt in RFC 2328 door John Moy. In 1999 werd OSPFv3 voor IPv6 gepubliceerd in RFC 2740.
OSPF is een klasseloos routeringsprotocol met linkstatus met een standaard administratieve afstand van 110 en wordt in de routeringstabel aangegeven met een routebroncode van O.
OSPF wordt ingeschakeld met de opdracht router ospf process-id global configuration mode. De proces-id-waarde is lokaal significant, wat betekent dat het niet met andere OSPF-routers hoeft te matchen om aangrenzendheden met die buren tot stand te brengen.
De netwerkopdracht die met OSPF wordt gebruikt, heeft dezelfde functie als bij andere IGP-routeringsprotocollen, maar met een iets andere syntaxis. De waarde van het jokertekenmasker is het omgekeerde van het subnetmasker en de waarde van het gebied-ID moet worden ingesteld op 0.
Standaard worden OSPF Hello-pakketten elke 10 seconden verzonden op multiaccess- en point-to-point-segmenten en elke 30 seconden op NBMA-segmenten (Frame Relay, X.25, ATM), en worden ze door OSPF gebruikt om aangrenzende aangrenzende gebieden vast te stellen. Het Dead-interval is standaard vier keer het Hello-interval.
Om routers aangrenzend te laten worden, moeten hun Hello-interval, Dead-interval, netwerktypen en subnetmaskers overeenkomen. Gebruik de opdracht show ip ospf buren om OSPF-nabijheden te verifiëren.
OSPF kiest een DR om op te treden als verzamel- en distributiepunt voor LSA’s die worden verzonden en ontvangen in het multiaccess-netwerk. Een BDR wordt gekozen om de rol van de DR op zich te nemen als de DR faalt. Alle andere routers staan bekend als DROTHER’s. Alle routers sturen hun LSA’s naar de DR, die de LSA vervolgens overstroomt naar alle andere routers in het multiaccess-netwerk.
De opdracht show ip protocols wordt gebruikt om belangrijke OSPF-configuratie-informatie te verifiëren, inclusief de OSPF-proces-ID, de router-ID en de netwerken waarvoor de router reclame maakt.
OSPFv3 is ingeschakeld op een interface en niet in de routerconfiguratiemodus. OSPFv3 heeft link-local adressen nodig om te worden geconfigureerd. IPv6 Unicast-routering moet zijn ingeschakeld voor OSPFv3. Een 32-bits router-ID is vereist voordat een interface kan worden ingeschakeld voor OSPFv3.