OSPF – Network Types

Fortsättning på tidigare inlägg om DR & BDR.

OSPF har ett flertal olika “Network Types” specificerade, och det är utefter detta som ospf-processen bestämmer om den behöver välja en DR/BDR under 2-way state i skapandet av en Neighbor Adjacency. Dessa är:

  • Non-Broadcast (NMBA)
  • Point-To-Multipoint
  • Point-To-Multipoint Non-Broadcast
  • Broadcast
  • Point-To-Point

Kom ihåg att DR/BDR endast behövs för multiaccess-nät. Detta innebär att för Point-to-Pointskippas hela DR/BDR-processen över och full adjacency sätts upp. Skillnaden går att se genom “sh ip ospf neighbor” där vi har en Point-to-Point länk på Fa0/1 och ett vanligt multiaccess (ethernet) på fa0/0.

Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:34 10.0.0.2 FastEthernet0/0
3.3.3.3 1 FULL/DROTHER 00:00:30 10.0.0.3 FastEthernet0/0
192.168.0.2 0 FULL/ – 00:00:33 192.168.0.2 FastEthernet0/1*

*Detta exempel är kanske lite förvirrande, per default är det alltid broadcast som network-type för Ethernetinterface, men för detta exempel ändrade jag detta genom “ip ospf network point-to-point”.

Samma sak gäller för Point-to-Multipoint & PtM Non-Broadcast räknas OSPF som flera inviduella Point-to-Point och väljer därför EJ någon DR/BDR.

Så vi kan konstatera att DR/BDR används endast för Broadcast & Non-Broadcast (NMBA – Non-Broadcast MultiAccess). 

Skönt nog har Cisco gjort det enkelt för oss och dessa nätverkstyper konfigureras automatiskt åt oss. Vi kan kontrollera vilken network type ett interface har genom kommandot “sh ip ospf interface“:

Ethernet: 

FastEthernet0/0 is up, line protocol is up
 Internet Address 10.0.0.1/24, Area 0
 Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10

Point-to-Point:

Serial0/0 is up, line protocol is up 
 Internet Address 192.168.0.2/30, Area 1 
 Process ID 1, Router ID 192.168.0.2, Network Type POINT_TO_POINT, Cost: 10

Point-to-MultiPoint

Serial0/0.1 is up, line protocol is up 
 Internet Address 172.16.0.1/16, Area 1 
 Process ID 1, Router ID 192.168.0.2, Network Type POINT_TO_MULTIPOINT, Cost: 64

Non-Broadcast:

Serial0/0 is up, line protocol is up
Internet Address 172.16.0.1/16, Area 1 
 Process ID 1, Router ID 192.168.0.2, Network Type NON_BROADCAST, Cost: 64

Det finns som tidigare nämnt möjlighet att manuellt justera vilken network-type ett interface skall ha, detta kan vara användbart i framförallt labb-miljöer. Du ändrar detta via kommandot “ip ospf network x“,

R4(config-if)#ip ospf network ?
 broadcast Specify OSPF broadcast multi-access network
 non-broadcast Specify OSPF NBMA network
 point-to-multipoint Specify OSPF point-to-multipoint network
 point-to-point Specify OSPF point-to-point network

DR/BDR i Frame-Relay

Ett problem som uppstår i en Frame-Relay miljö som använder sig av Hub & Spoke är som bekant att all trafik mellan “spokes” måste gå via huvudroutern. Och som du förhoppningsvis inte sovit under dina CCNA-studier känner du redan till att routrar ej forwardar Broadcast – detta innefattar även Multicast. Om vi tar följande topologi för att utveckla:

Framerelay DR

Vad händer om Spoke 1 skulle bli DR eller BDR? Spoke2 kommer försöka sätta upp en full adjacency till Spoke1, vilket kommer misslyckas då all multicast fastnar i Hub och ej forwardas.

Det är därför ett KRAV att Hub konfigureras till DR och att vi EJ tillåter varken Spoke1 eller Spoke2 att bli BDR, detta gäller för både Broadcast*- & NMBA i Hub&Spoke-nät. Har du läst den tidigare posten ang. BD/BDR så har du förhoppningsvis redan koll på hur vi löser detta (hint: genom ip ospf priority x).

*Kom ihåg att vi kan konfigurera Frame-Relay att tillåta en form av pseudo-broadcast genom antingen Inverse-ARP eller manuellt mappa dlci och ip-adress och sedan använda broadcast i statement, ex;

R1(config)#interface serial0 
R1(config-if)#no frame-relay inverse-arp 
R1(config-if)#frame map ip 200.1.1.2 122 broadcast 
R1(config-if)#frame map ip 200.1.1.3 123 broadcast

Neighbor adjacencys för Non-broadcast

Speciellt för Non-broadcast och Point-to-Multipoint Non-broadcast är ju som vi hör på namnet att de EJ tillåter broadcast (vilket även innebär att multicast stoppas). OSPF har dock möjlighet att helt använda sig av unicast istället, det enda vi behöver göra i detta fall är att manuellt ange våra neighbors. Väldigt enkelt!

R1(config)#router ospf 1
R1(config-router)#neighbor 10.0.0.2 
R1(config-router)#neighbor 10.0.0.3

Försöker vi dock göra detta på ett nätverk som tillåter broadcast får vi följande meddelande:

*Mar  1 01:43:08.991: %OSPF-4-CFG_NBR_INVAL_NET_TYPE: Can not use configured neighbor: neighbor command is allowed only on NBMA and point-to-multipoint networks

Här är förövrigt en bra “fusklapp” att använda.

networktypes

OSPF – The Basics II

Designated Router / Backup Designated Router

Om vi tänker tillbaka till den föregående posten, OSPF – The Basics, så kommer du förhoppningsvis ihåg hur omständigt det var att sätta upp neighbor adjacencys mellan två routrar, och alla paket som skickades fram och tillbaka för att lyckas med detta (Hello/DBD/LSR/LSU osv). Tänk då hur det kommer bli för följande topologi:

ospf-sharednetwork

Även efter adjacencys är upprättade så kommer en router, så fort den får en uppdatering (antingen om ett eget nät eller från någon annan router) annonsera ut detta till övriga på nätet. Så kommer det fortsätta för varje router – LSA-storm delux! 🙂

lsa storm

Det här problemet uppstår endast när vi har ett “Shared network segment” som ovan, för “Point-to-Point” så kan det ju endast finnas en neighbor. För att komma tillrätta med detta problem väljer routrarna istället ut en specifik  “ledare”, Designated Router (DR)som de sätter upp sin adjacency mot och sedan utbyter all routing-information med. Det är denna router som i sin tur är ansvarig för att hålla resterande enheter uppdaterade med routing-information.

För att vara på den säkra sidan om denna DR-router skulle gå ner väljs det även ut en Backup Designated Router (BDR). Låt oss säga att R6 blir vald till DR och R9 till BDR, neighbor adjacencys skulle då istället se ut såhär:

DR

Övriga routrar stannar kvar i “Steg 5” från OSPF – The Basics, 2-way state, mellan varandra och bildar ej en full neighbor adjacency. Om DR-routern går offline kommer BDR-routern att uppgradera sig till DR och en annan router kommer väljas till BDR.

Hur väljs då BD & BDR? Följande parametrar bestämmer vilken router som kommer väljas:

  • Routern med den högsta priorityn blir DR
  • Routern med den näst högsta priorityn blir BDR
  • Om priorityn är lika (default: 1), så är det istället den med högst/näst högst Router-ID som blir DR/BDR
  • För att välja en ny DR/BDR måste OSPF-processen alternativt hela routern startas om
  • Routrar som ej väljs till DR/BDR visas som DROTHER

För att justera en routers priority används kommandot “ip ospf priority x” på det aktuella interfacet, om vi sätter priority till 0 (det lägsta möjliga värdet), stoppar vi routern från att kunna bli varken DR eller BDR (även om det så bara finns två routrar på segmentet).

Hur ser då förloppet ut när BD & BDR väljs? Vi kan kontrollera detta genom kommandot debug ip ospf adj.

*Mar 1 00:04:12.227: OSPF: Interface FastEthernet0/0 going Up
*Mar 1 00:04:12.255: OSPF: 2 Way Communication to 2.2.2.2 on FastEthernet0/0, state 2WAY
*Mar 1 00:04:12.259: OSPF: Backup seen Event before WAIT timer on FastEthernet0/0
*Mar 1 00:04:12.259: OSPF: DR/BDR election on FastEthernet0/0 
*Mar 1 00:04:12.259: OSPF: Elect BDR 1.1.1.1
*Mar 1 00:04:12.259: OSPF: Elect DR 2.2.2.2
*Mar 1 00:04:12.259: OSPF: Elect BDR 1.1.1.1
*Mar 1 00:04:12.263: OSPF: Elect DR 2.2.2.2
*Mar 1 00:04:12.263: DR: 2.2.2.2 (Id) BDR: 1.1.1.1 (Id)

Vi kan kontrollera vem som valts till vad genom sh ip ospf neighbor.

R1#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
 2.2.2.2 1 FULL/DR 00:00:35 10.0.0.2 FastEthernet0/0
 3.3.3.3 1 FULL/DROTHER 00:00:39 10.0.0.3 FastEthernet0/0

Och ytterligare info kan fås genom show ip ospf interface fa0/0.

FastEthernet0/0 is up, line protocol is up 
 Internet Address 10.0.0.1/24, Area 0 
 Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10
 Transmit Delay is 1 sec, State BDR, Priority 1
 Designated Router (ID) 2.2.2.2, Interface address 10.0.0.2
 Backup Designated router (ID) 1.1.1.1, Interface address 10.0.0.1
 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
 oob-resync timeout 40
 Hello due in 00:00:08
 Supports Link-local Signaling (LLS)
 Cisco NSF helper support enabled
 IETF NSF helper support enabled
 Index 1/1, flood queue length 0
 Next 0x0(0)/0x0(0)
 Last flood scan length is 0, maximum is 1
 Last flood scan time is 0 msec, maximum is 0 msec
 Neighbor Count is 2, Adjacent neighbor count is 2 
 Adjacent with neighbor 2.2.2.2 (Designated Router)
 Adjacent with neighbor 3.3.3.3
 Suppress hello for 0 neighbor(s)

Best practice enligt Cisco är att inte låta en router vara DR/BDR för mer än ett nät, detta är ju dock inte alltid möjligt att följa. För kom ihåg att detta gäller inte en hel area utan DR/BDR bestäms per “shared network segment“. Se följande exempel (ritade/skrev lite på en screencap från Jeremys OSPF-nuggets):

DR

Observera att det ej väljs någon DR/BDR för Point-to-point nätet, routrarna kommer dock givetvis att bilda full adjacency som vanligt. Rent generellt är det inte speciellt viktigt vilken routern som blir DR/BDR, detta gäller dock inte för Frame-Relay, men mer om det senare!

Linkstate Advertisements

Om något inträffar på nätverket som kräver en uppdatering kommer ansvarig router att skicka ett LSU-paket (innehållandes ett LSA) för den berörde routen över multicast. I en DR/BDR-miljö skickas det på multicast-adressen 224.0.0.6, som endast DR & BDR lyssnar på, för Point-to-Point skickas allt på 224.0.0.5. DR/BDR skickar i sin tur ut samma information till resterande medlemmar via multicast på adressen 224.0.0.5.

Som exempel satte jag uppe följande topologi:

ospf lsu update

R1 är DR och R2 BDR i detta exempel, vad händer när vi lägger till ytterligare ett nät på R3 och annonserar ut detta? Wireshark visar följande:

ospf lsu

ospf lsu update debug

En liten notis som jag inte sett nämnas i något av det material jag läst så skickar BDR LS Ack tillbaka på 224.0.0.5, medans DROTHER’s skickar sina på 224.0.0.6, och DR verkar bevisligen inte skicka någon LS Ack tillbaka över huvudtaget.

Mottagaren använder sedan följande flödesschema efter de mottagit en LSA:

lsa flow

Som synes kontrollerar mottagaren inte bara om route:n redan finns inlagd, utan även om dess sequence nummer är högre än vad den själv har. Detta skulle betyda att informationen är nyare och att routern behöver uppdatera sin egen databas.

Skulle det istället vara så att mottagaren själv har ett högre sequence nummer för route:n kommer den istället skicka tillbaka en LSU med sin egen info för att hjälpa avsändaren få en korrekt bild av nätet. Varje genererat LSA-paket har en lifetime på 30 minuter, när detta gått ut så genererar varje router ett nytt paket (samt ökar sequence-number med 1) och skickar ut detta på nätverket.

Vi kan kontrollera sequence-numret genom kommandot “sh ip ospf database”,

R1#sh ip ospf database
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 1625 0x80000002 0x000DFD 1
2.2.2.2 2.2.2.2 1098 0x80000003 0x005A2C 2
3.3.3.3 3.3.3.3 875 0x80000003 0x002AA8 2

Detta skrapar dock endast lite på ytan av LSA och jag kommer återkomma med fler poster på samma ämne var så säker.. 😉

OSPF – The Basics

Intro

OSPF är ett Link-state Routing Protocol, som till skillnad från Distance Vector (EIGRP/RIP) har en karta över hela nätverket (åtminstone sin area, men mer om det senare) i sin topology-table, och varje router räknar själv ut den bästa vägen för att nå sin destination genom Dijkstra’s Shortest Path First (SPF)-Algoritm.

Förhoppningsvis har vi inte redan glömt att nackdelen med just Distance Vector är att de endast vet vad dess grannar berättat. En annan stor fördel gentemot  EIGRP är att OSPF är OpenSource och ej låst till Cisco, det  finns med andra ord möjligheter att sätta upp ett “mixed vendor”-nätverk och få dessa att prata med varandra genom OSPF!

OSPF använder sig av triggade updates, och skickar endast ut information om någon förändring inträffar på nätverket, som ex att en länk går ner/ett nät läggs till. Har det dock inte hänt något på 30 minuter skickas en “ls refresh” från varje router med dess routing-information för att vara säker på att alla har samma bild av nätverket och inget har missats.

OSPF använder precis som EIGRP tre “tables”:

Neighbor Table

Innehåller information om grannar som skickat Hello-paket till routern (behöver nödvändigtvis ej ha full adjacency mellan varandra). Information som ex. Router-ID, IP-adress och interface sparas här.

R1#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
3.3.3.3 1 FULL/DR 00:00:30 12.0.0.2 FastEthernet0/1
2.2.2.2 1 FULL/DR 00:00:38 10.0.0.2 FastEthernet0/0

Topology Table

Innehåller samtliga routes inom en area, tillskillnad från ex. EIGRP som endast sparar successor/f.successor-routes.

R1#show ip ospf route
OSPF Router with ID (1.1.1.1) (Process ID 1)
Area BACKBONE(0)
Intra-area Route List
* 12.0.0.0/24, Intra, cost 10, area 0, Connected
 via 12.0.0.1, FastEthernet0/1
* 10.0.0.0/24, Intra, cost 10, area 0, Connected
 via 10.0.0.1, FastEthernet0/0
*> 11.0.0.0/24, Intra, cost 20, area 0
 via 12.0.0.2, FastEthernet0/1
 via 10.0.0.2, FastEthernet0/0
*> 192.168.0.0/24, Intra, cost 11, area 0
 via 12.0.0.2, FastEthernet0/1
* 1.1.1.1/32, Intra, cost 1, area 0, Connected
 via 1.1.1.1, Loopback0
*> 2.2.2.2/32, Intra, cost 11, area 0
 via 10.0.0.2, FastEthernet0/0
*> 3.3.3.3/32, Intra, cost 11, area 0
 via 12.0.0.2, FastEthernet0/1

Routing Table

Fungerar precis som vanligt, de routes med lägst metric till en destination sparas här. Observera att även OSPF har lastbalansering då det installerats två vägar till nätet 11.0.0.0/24 när metricen är densamma.

1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
 2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/11] via 10.0.0.2, 00:24:35, FastEthernet0/0
 3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/11] via 12.0.0.2, 00:22:30, FastEthernet0/1
 10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0
 11.0.0.0/24 is subnetted, 1 subnets
O 11.0.0.0 [110/20] via 12.0.0.2, 00:22:30, FastEthernet0/1
           [110/20] via 10.0.0.2, 00:24:36, FastEthernet0/0
O 192.168.0.0/24 [110/11] via 12.0.0.2, 00:14:28, FastEthernet0/1
 12.0.0.0/24 is subnetted, 1 subnets
C 12.0.0.0 is directly connected, FastEthernet0/1

Metric

OSPF använder sig av en metric som kallas “cost”. Cost adderas för varje utgående interface och får dess värde från =  10^8 / Bandwith, men vi kan förenkla detta genom att istället skriva 100 / Bandwith (i Mbps). Till skillnad från EIGRP så sparar OSPF endast den bästa routen som räknats ut genom SPF, om en förändring sker måste routern därför gå tillbaka och räkna ut en ny väg (om möjligt).

Här är en tabell med de vanligaste hastigheterna och dess cost:

  • 56k – 1785
  • 64k – 1562
  • T1 (1,544) – 65
  • E1 (2,048) – 48
  • Ethernet – 10
  • Fast Ethernet – 1

Som du kanske ser så har OSPF per default ingen möjlighet att se skillnad på länkar över 100Mbit, främst pga cost-utträkningen togs fram under 80-talet.. 🙂 Vi kan dock ändra detta genom kommandot:

router ospf x
auto-cost reference-bandwith x (anges i Mbps, 100 är default)

Om vi har länkar upp till 10Gb i vårat nätverk skulle vi då sätta reference-bandwith till 10000, detta måste ändras på samtliga routrar!

Areas

OSPF använder sig av ett koncept som kallas Area’s, per default kommer du alltid ha en standard-area, “0”, detta är även vad vi kallar “Backbone area“. Genom att använda area’s får vi en möjlighet att segmentera nätverket vilket har flera fördelar, exempelvis behöver OSPF endast skicka uppdateringar och använda SPF-algoritmen för att räkna ut den bästa vägen inom sin egen area. Detta minskar belastningen på CPU:er och ger snabbare konvergenstider. Om vi använder oss av en liknelse med GPS, så går det ju betydligt snabbare att räkna ut kortaste vägen mellan två gator inom samma stad än ex. hela sträckan mellan Västerås –  Malmö (Västerås hade varit en egen ospf-area).

OSPF areas

Det finns vissa regler som gäller för just areas:

  • Varje area måste ha en anslutning till area 0 / Backbone (kan dock vara virtuell, mer om detta senare)
  • Alla routrar inom en area måste ha samma topology-table/samma uppfattning om hur nätet ser ut
  • Uppdateringar skickas endast inom den egna arean
  • Routrar mellan två area’s kallas “Area Border Router” (ABR)
  • Routrar som är anslutet till ett annat nätverk som inte använder OSPF (ex BGP/RIP/EIGRP) kallas “Autonomous Border Router” (ASBR)
  • Nätsummeringar kan endast göras i ABR & ASBR
  • Neighbor-adjacencys skapas endast inom samma area

Cisco rekommenderar förövrigt att vi har max 50st routrar per area, och varje router bör endast vara neightbor med max. 16st andra. Men efter att ha lyssnat på OSPF – Design från PacketPushers  som jag länkade i ett tidigare inlägg så kan vi konstatera att detta är grovt överdrivet, och det är egentligen inga som helst problem att ha hundratals routrar i en och samma area. KSS – Keep it Simple Stupid! 🙂

Packet Types

OSPF använder sig ej av TCP för sin kommunikation utan har skapat sitt eget Lager 4-protokoll för att verifiera att allt sänds OK. De paket-typer som finns i OSPF är följande:

  • Hello-packet: Används för att sätta upp Neighbor-adjacencys
  • Database Description-packet (DBD): En “lightversion” av routerns linkstate database
  • Linkstate Request (LSR*): Används för att be om mer detaljerad information från en router
  • Linkstate Update(LSU*): Används för att skicka mer detaljerad routing-information
  • Linkstate Advertisement(LSA): En LSU innehåller en/flera LSA’s för att minska det antal paket som behöver skickas, varje enskild LSA innehåller information om en specifik route
  • Linkstack Acknowledgement(LSAck): För att bekräfta att DBD/LSR/LSU-paket kommit fram skickas en LSAck tillbaka

*Vid debugging visas LSR som LS REQ och LSU som LS UPD.

Hello-Packets

Efter att vi startat OSPF-processen för ett interface kommer routern börja skicka ut Hello-paket. Till skillnad från EIGRP så är det ganska mycket information som dessa innehåller och ett flertal fält måste vara identiska för att en adjacency skall kunna skapas. Hello-paketet består för följande information:

  • Router-ID: Varje OSPF-Router behöver ett unikt router-id, mer om detta senare)
  • Hello / Dead interval*: Här bestäms intervallet som Hello-paket kommer att skickas samt hur länge vi väntar innan en neighbor anses som offline (samma som EIGRP’s Holdtimer), dead interval är per default “Hellotimer x 4”
  • Neighbors: Innehåller information om routerns övriga neighbors
  • Area ID*: Vilket area routern befinner sig i
  • Router Priority: Används för att bestämma vem som blir Designated Router (DR) / Backup Designated Router (BDR), mer om detta senare
  • DR & BDR IP-adress: IP-adressen till routerns DR / BDR
  • Authentication Password*: Används för lösenordsskyddade routinguppdateringar, antingen i cleartext eller md5
  • Stub area flag*:  Förutom olika area-nummer har OSPF även olika typer av areas, mer om detta senare

Punkterna markerade med “*” kräver att båda routrarna har identiskt information för respektive fält. Hello-paket skickas per default ut var 10:e sekund på Broadcast/P2P-länkar, och var 30:e sekund på NMBA. Då dead interval var “4 x hello-timer” innebär detta att det sedan kommer ta 40 sekunder innan en router anser att sin granne är död på ex. ett ethernet-nätverk, och hela 180 sekunder på ett frame-relay nät!

Observera att AS-numret aldrig skickas med, till skillnad från EIGRP är OSPF’s AS endast lokalt, du kan därför blanda AS-nummer mellan routrarna och de kommer ändå få adjacency om resterande fält är ok. Varför man nu skulle vilja göra detta??.. 🙂

En debug så ser vi hur paketen ser ut i CLI:

R1#debug ip ospf packet
OSPF packet debugging is on
R1#
*Mar 1 04:00:27.539: OSPF: rcv. v:2 t:1 l:48 rid:3.3.3.3
 aid:0.0.0.0 chk:CF93 aut:0 auk: from FastEthernet0/1
  • V:2 – OSPF-version (IPv6 använder OSPFv3)
  • T:1 – Typ av OSPF-paket, 1 = Hello-paket
  • L:48 – Paketlängd i bytes
  • RID – Router-ID, i detta fall 3.3.3.3
  • AID – Area-ID, i detta fall 0
  • CHK:CF93 – Checksum för felhantering
  • AUT:0 – Autentisering, 0 = ingen (1 är cleartext, 2 md5)
  • AUK: – Används endast om autentisering är aktiverat

Neighbor Adjacency

Processen att sätta upp en Neighbor Adjacency i OSPF är tyvärr inte på långa vägar lika enkelt som EIGRP där vi endast behöver utbyta varsitt hello-paket, utan här är det betydligt mer omständigt. Efter att du startat OSPF-processen på R1 sker följande (vi förutsätter att det redan är aktiverat på R3):

ospf neighbors

R1 IP: 10.0.0.1
R2 IP: 10.0.0.2

Steg 1

R1 kommer först att välja ett Router-ID (ingår i Hello-paketet), och detta kan göras på tre olika sätt:

  • Routern väljer den högsta IP-adressen från något av sina aktiva interface (behöver ej köra OSPF)
  • Om ett loopback-interface finns konfigurerat har detta högre prioritet än andra interface oavsett IP-adress
  • Om du manuellt skriver in ett Router-ID så har detta prioritet över både Loopback och andra interface, oavsett adress

Det går sedan endast att byta Router-ID vid omstart av OSPF-processen alternativt hela routern. Kommer återkomma till detta när vi börjar prata om DR / BDR senare. I detta fall kommer Router-ID att bli 1.1.1.1.

Steg 2

R1 lägger till det interface du specificerat under “network x.x.x.x x.x.x.x area x” i “Link-state Database” (LSDB). Ex:

router ospf 1
network 10.0.0.0 0.0.0.3 area 0

Steg 3 – “Down State”

R1 börjar skicka ut Hello-paket på Fa0/1-interfacet innehållande den information vi skrev om under “Hello-packets” via multicast på adressen 224.0.0.5. Länken betraktas nu vara i ett “Down State” tills den själv mottar ett Hello-paket.

Steg 4 – “Init State”

R1 har nu förutom att börja skicka ut sina egna Hello-paket även mottagit ett från sin neighbor R3, detta skickades som ett unicast direkt till R1 på 10.0.0.1. Länken ändras från att vara i ett “Down State” till “Init State“, R1 & R3 jämför nu så att alla fält markerade med * under Hello-packet stämmer överens med den information de själv besitter. Är allt ok går de vidare till Steg 5, om inte så backar de länken till “Down State“/steg 3 igen.

Steg 5 – “2-way State”

R1 & R3 kontrollerar nu om den redan finns angiven under “Neighbors”-fältet i det mottagna Hello-paketet, om så är fallet bortser den från Hello-paketet och nollställer istället Dead interval.

Finns de inte med betraktas neighborn som ny och läggs istället till i “Neighbor Table“, de går sedan vidare till Steg 6.

Steg 6 – “Exstart State”

Länken ändras från ett “2-way State” till ett “Exstart State“. De två routrarna kommer nu överens om vem som skall vara Master & Slave, detta bestäms efter:

  • Priority (default “1”)
  • Om Priority är samma används istället Router-ID, där högst router-id = Master

Master/Slave-förhållandet bestämmer endast vilken av routrarna som skall börja skicka sin routing-information till den andra. I detta exempel hade R3 blivit Master, och R1 Slave. Efter de kommit överens sker följande:

  • Master skickar en “lightversion av sin routing-databas innehållande vilka routes den känner till, detta kallas “Database Description-Packet” (DBD), Jeremy från CBT kallade även detta “Cliffnotes of it’s linkstate database”
  • Slave skickar en Ack på Mastern’s DBD-paket och sänder sedan sitt egna DBD-paket
  • Master skickar en Ack på Slave’s DBD-paket

Steg 7 – “Loading State”

Både Master & Slave går nu över den information de fått i DBD-paketet och jämför med sin egen linkstate database. För de nät de inte redan känner till sker följande:

  • Slave skickar ett Linkstate Request (LSR) och ber om mer information för dessa nät
  • Master skickar en LSAck och svarar med en Linkstate Update (LSU), som i sin tur innehåller en Linkstate Advertisement (LSA) för varje route Slave behövde information om
  • Slave svarar med en LSAck
  • Master skickar ett Linkstate Request (LSR) och ber om mer information
  • Slave skickar en LSAck och svarar med en  Linkstate Update (LSU), som i sin tur innehåller en Linkstate Advertisement (LSA) för varje route Master behövde information om
  • Master svarar med en LSAck

Steg 8 – “Full State”

R1 & R3 är nu synkade med varandra och länken ändras från “Loading State” till “Full State“. Det är nu dags för SPF att kavla upp ärmarna och räkna ut vilka routes som skall läggas till i Routing Table.

Debug

Det är ju alltid bättre att se hur det faktiskt fungerar i verkligen än att jag sitter och skriver såhär. Här följer en debug från R1 som visar hela händelseförloppet från Steg 1 till Steg 8 (har dock rensat bort info om BD/BDR).

*Mar 1 04:17:22.914: OSPF: Interface FastEthernet0/1 going Up
*Mar 1 04:17:22.954: OSPF: 2 Way Communication to 3.3.3.3 on FastEthernet0/1, state 2WAY <- Steg 5
*Mar 1 04:17:22.958: OSPF: Backup seen Event before WAIT timer on FastEthernet0/1
*Mar 1 04:17:22.962: OSPF: Send DBD to 3.3.3.3 on FastEthernet0/1 seq 0x1DEF opt 0x52 flag 0x7 len 32
R1(config-router)#
*Mar 1 04:17:22.998: OSPF: Rcv DBD from 3.3.3.3 on FastEthernet0/1 seq 0xBD2 opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART <- Steg 6
*Mar 1 04:17:22.998: OSPF: NBR Negotiation Done. We are the SLAVE 
*Mar 1 04:17:23.002: OSPF: Send DBD to 3.3.3.3 on FastEthernet0/1 seq 0xBD2 opt 0x52 flag 0x0 len 32
*Mar 1 04:17:23.038: OSPF: Rcv DBD from 3.3.3.3 on FastEthernet0/1 seq 0xBD3 opt 0x52 flag 0x3 len 92 mtu 1500 state EXCHANGE
*Mar 1 04:17:23.038: OSPF: Send DBD to 3.3.3.3 on FastEthernet0/1 seq 0xBD3 opt 0x52 flag 0x0 len 32
*Mar 1 04:17:23.070: OSPF: Rcv DBD from 3.3.3.3 on FastEthernet0/1 seq 0xBD4 opt 0x52 flag 0x1 len 32 mtu 1500 state EXCHANGE
*Mar 1 04:17:23.070: OSPF: Exchange Done with 3.3.3.3 on FastEthernet0/1
*Mar 1 04:17:23.070: OSPF: Send LS REQ to 3.3.3.3 length 36 LSA count 3 <- Steg 7
*Mar 1 04:17:23.074: OSPF: Send DBD to 3.3.3.3 on FastEthernet0/1 seq 0xBD4 opt 0x52 flag 0x0 len 32
*Mar 1 04:17:23.106: OSPF: Rcv LS UPD from 3.3.3.3 on FastEthernet0/1 length 132 LSA count 3
*Mar 1 04:17:23.106: OSPF: Synchronized with 3.3.3.3 on FastEthernet0/1, state FULL
*Mar 1 04:17:23.106: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/1 from LOADING to FULL, Loading Done <- Steg 8

Och nu är det äntligen klart! Inte riktigt lika enkelt som EIGRP kanske.. 😉 Det finns dock undantag till ovanstående, men det återkommer jag till i nästa post om BD/BDR.