OSPF – Svaren till “Veckans frågor”

Lite senare än planerat, men här kommer svaren från förra veckans post om OSPF.

ospf-fraga

1. Om vi vill summera subnäten 30.0.0.0/24 & 30.0.1.0/24 till en /23, var i nätet utför vi detta?

R5 – Då 30.0.x.0/24-näten redistributas in i OSPF räknas de som external routes och annonseras som LSA Type 5/7 (NSSA-External). Regeln att vi bara summerar i ABR’s (LSA Type 3 Summary) gäller endast för intra-area routes (LSA Type 1).

Innan vi går vidare kan vi se följande i R4 (observera att det är Type-7 pga NSSA-area):

R4#sh ip ospf database nssa-external
OSPF Router with ID (4.4.4.4) (Process ID 1)
Type-7 AS External Link States (Area 20)
Routing Bit Set on this LSA
 LS age: 65
 Options: (No TOS-capability, Type 7/5 translation, DC)
 LS Type: AS External Link
 Link State ID: 30.0.0.0 (External Network Number )
 Advertising Router: 5.5.5.5
 LS Seq Number: 80000001
 Checksum: 0x8177
 Length: 36
 Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 192.168.0.2
 External Route Tag: 0
Routing Bit Set on this LSA
 LS age: 65
 Options: (No TOS-capability, Type 7/5 translation, DC)
 LS Type: AS External Link
 Link State ID: 30.0.1.0 (External Network Number )
 Advertising Router: 5.5.5.5
 LS Seq Number: 80000001
 Checksum: 0x7681
 Length: 36
 Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 192.168.0.2
 External Route Tag: 0

Så vill vi summera gör vi detta direkt på R5 via:

R5(config)#router ospf 1
R5(config-router)#summary-address 30.0.0.0 255.255.254.0

R5 annonserar nu endast /23-nätet via Type 7-LSA till R4:

R4#sh ip ospf database nssa-external
OSPF Router with ID (4.4.4.4) (Process ID 1)
Type-7 AS External Link States (Area 20)
Routing Bit Set on this LSA
 LS age: 23
 Options: (No TOS-capability, Type 7/5 translation, DC)
 LS Type: AS External Link
 Link State ID: 30.0.0.0 (External Network Number )
 Advertising Router: 5.5.5.5
 LS Seq Number: 80000002
 Checksum: 0x7A7E
 Length: 36
 Network Mask: /23
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 192.168.0.2
 External Route Tag: 0

Vilket sen R4 konverterar till ett Type 5-LSA innan den vidarebefordrar det ut på backbone. Vi kan verifiera detta genom att kolla OSPF-databasen för ex. R1:

R1#sh ip ospf database external 30.0.0.0
OSPF Router with ID (1.1.1.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
 LS age: 124
 Options: (No TOS-capability, DC)
 LS Type: AS External Link
 Link State ID: 30.0.0.0 (External Network Number )
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000003
 Checksum: 0x2BDA
 Length: 36
 Network Mask: /23
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 192.168.0.2
 External Route Tag: 0

2. Vad händer med eventuella LSA Type 5-paket som skickas till area 20 från area 10 eller backbone?

Då area 20 är ett NSSA filtreras Type 4 & Type 5. Detta ersätts istället med en default-route med R4 som next-hop.

R5#sh ip route | beg Gate
Gateway of last resort is 192.168.0.1 to network 0.0.0.0
O IA 172.16.0.0/16 [110/40] via 192.168.0.1, 00:00:15, FastEthernet0/1
 10.0.0.0/25 is subnetted, 2 subnets
O IA 10.0.0.0 [110/30] via 192.168.0.1, 00:00:15, FastEthernet0/1
O IA 10.0.0.128 [110/20] via 192.168.0.1, 00:00:15, FastEthernet0/1
C 192.168.0.0/24 is directly connected, FastEthernet0/1
 30.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
S 30.0.0.0/24 is directly connected, Null0
O 30.0.0.0/23 is a summary, 00:07:26, Null0
S 30.0.1.0/24 is directly connected, Null0
O*N2 0.0.0.0/0 [110/1] via 192.168.0.1, 00:00:12, FastEthernet0/1

Observera att det står O*N2, NSSA External Type 2. Detta är unikt för just NSSA-areas och jag har ännu inte hittat orsaken till varför det är så.

Default-routen som annonseras av R4 verkar redistributas in och skickas därför istället som en Type 7-LSA.

R5#sh ip ospf database nssa-external
OSPF Router with ID (5.5.5.5) (Process ID 1)
Type-7 AS External Link States (Area 20)
Routing Bit Set on this LSA
 LS age: 45
 Options: (No TOS-capability, No Type 7/5 translation, DC)
 LS Type: AS External Link
 Link State ID: 0.0.0.0 (External Network Number )
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000001
 Checksum: 0x940D
 Length: 36
 Network Mask: /0
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 1
 Forward Address: 0.0.0.0
 External Route Tag: 0

Detta gäller endast för NSSA, konfigurerar vi stub, totally stub eller totally NSSA så annonseras default-routen “som vanligt” med en Type 3-LSA istället.

R5#sh ip route | beg Gate

Gateway of last resort is 192.168.0.1 to network 0.0.0.0
C 192.168.0.0/24 is directly connected, FastEthernet0/1
 30.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
S 30.0.0.0/24 is directly connected, Null0
O 30.0.0.0/23 is a summary, 00:06:12, Null0
S 30.0.1.0/24 is directly connected, Null0
O*IA 0.0.0.0/0 [110/11] via 192.168.0.1, 00:08:15, FastEthernet0/1

Gjorde en forum-post på Cisco’s CCIE-forum för att se om någon kanske känner till varför det skiljer sig för just NSSA default-routes, finns att läsa här.

3. Vilka LSA-paket kommer informera R1 om det summerade 30.0.0.0/23-nätet och hur den ska hitta dit?

Vi har ju redan vad som hände med LSA-paketen efter vi summerade näten i R5;

  • R5 annonserar nätet som ett Type 7-LSA
  • R4 konverterar Type 7 till Type 5 och skickar ut på backbone

Men vad händer sen?

Ett LSA Type 5 skickas mellan areas utan modifikationer såvida det är en Standard/Backbone-area, vilket area 10 är i detta fall. Så R1 får Type-5 paketet av R4 vilket annonserar 30.0.0.0/23-nätet. Men vet R1 hur den ska hitta till R4? Type 1 & 2 innehåller information om andra routrar men skickas endast inom den egna arean. Type 3 annonseras av ABRs och används inte i detta fall.

R1 behöver därför även ett LSA Type 4-paket som informerar om hur den ska hitta till R4!

R1#sh ip ospf database
OSPF Router with ID (1.1.1.1) (Process ID 1)
Summary ASB Link States (Area 10)
Link ID ADV Router Age Seq# Checksum
4.4.4.4 2.2.2.2 1245 0x80000001 0x004FC0
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
20.0.0.0 2.2.2.2 1297 0x80000001 0x00A6DD 0
20.0.1.0 2.2.2.2 1297 0x80000001 0x009BE7 0
20.0.2.0 2.2.2.2 1297 0x80000001 0x0090F1 0
20.0.3.0 2.2.2.2 1297 0x80000001 0x0085FB 0
30.0.0.0 4.4.4.4 1144 0x80000003 0x002BDA 0

LSA Type 2-paketet skapas av R2 (ADV Router 2.2.2.2), med R4’s RID som Link-ID, 4.4.4.4.

R1 inser därmed att den behöver gå via R2 för att komma till R4.

Kunde du inte svaret på dessa är det nog läge att repetera LSAs igen, tidigare postar om detta finns här för Type 1-5 här, och Type 7 här.

OSPF – “Veckans frågor”

Precis som för EIGRP var det denna vecka dags att ta fram lite frågor att ställa till övriga klassen om OSPF.

ospf-fraga

1. Om vi vill summera subnäten 30.0.0.0/24 & 30.0.1.0/24 till en /23, var i nätet utför vi detta?

2. Vad händer med eventuella LSA Type 5-paket som skickas till area 20 från area 10 eller backbone?

3. Vilka LSA-paket kommer informera R1 om det summerade 30.0.0.0/23-nätet och hur den ska hitta dit?

Lägger upp svaren efter vi haft “förhören” på måndag.

IPv6 – OSPFv3

I ett utdrag från Jeff Doyle’s bok “Routing TCP/IP vol.1” står följande om historiken bakom OSPFv3:

As you have seen in previous chapters, routing IPv6 requires modifications to a protocol; primarily, the protocol messages must be modified to carry addresses four times as long as IPv4 addresses. In theory, this also could be done with Open Shortest Path First (OSPF), either by modifying the existing Link State Advertisements (LSA) or by defining new LSAs. But development of OSPF began in the very late 1980s, when router performance was low, latency was high, and memory was expensive. None of these are valid now, and several characteristics of OSPFv2 that were intended to accommodate or compensate for those early networking realities are now irrelevant. Further, extensive operational experience with OSPFv2 revealed several areas of inefficiency.

So when extension of OSPF to support IPv6 was first considered, it was recognized that there was an opportunity to improve the protocol itself. The result is that rather than just extending OSPFv2 for IPv6, a new and improved version of OSPF—OSPF version 3—has been created.

Vad är då nytt i OSPFv3?

  • RFC 5340
  • Ej bakåtkompatibelt med OSPFv2
  • Använder “link” för att kommunicera med neighbors istället för tidigare network/subnet, vilket innebär att neighbors nu kan ligga i skilda subnät
  • LSA Type-1 & 2 innehåller inte längre någon prefix-information
  • Routrar identifieras nu alltid via Router-ID, även för broadcast & NBMA network-types per default
  • LSA Type-3 Summary-network döptes om till inter-area-prefix-LSA
  • LSA Type-4 Summary-ASBR döptes om till inter-area-router-LSA
  • Två helt nya LSAs, Type 0008 link-LSA & Type 2009 intra-area-prefix-LSA
  • Förlitar sig nu på IPv6 Authentication Head (AH) & Encapsulating Security Paylod (ESP) för autentisering & kryptering
  • LSA Type skrivs nu i hex (16 bitar)

LSA Types

Se tidigare inlägg här (LSA 1-5) & här (area-types & LSA 7) för en mer ingående förklaring vad varje LSA-typ har för funktion och hur det fungerar i praktiken mellan olika area-typer etc.

Nu när vi gått över till IPv6 så benämns LSA-typerna i hex (16 bitar), men de har tack och lov ändå hållit det väldigt snarlikt som vi kan se i tabellen nedan:

OSPFv3-LSAtypes

Type-3 & 4 har bevisligen bytt namn, och tänker vi tillbaka hur dessa LSA-paket fungerar är det egentligen bara mer logiskt nu (Summary-network summerade ej per default osv).

Funktionen är fortfarande i princip densamma för alla LSA-typer, med några nya tillägg/modifieringar:

  • LSA Type-2001 – Skickas endast inom arean (Router-ID)
  • LSA Type-2002 – Skickas endast inom arean från DR (Router-ID)
  • LSA Type-2003 – Skickas mellan areas från ABRs, annonserar O IA-routes
  • LSA Type-2004 – Skickas mellan areas, annonserar gateway (ABR) för ASBR/LSA Type-4005
  • LSA Type-4005 – Skickas mellan areas, annonserar O E1/E2-routes
  • LSA Type-2007 – Skickas inom arean vid användandet av NSSA/T-NSSA, annonseras sedan av ABR som Type-4005 (O E1/E2-routes)
  • LSA Type-0008 – Skickas endast link-local till neighbors som är “Directly connected”
  • LSA Type-2009 – Skickas inom arean, annonserar de prefix som vi annars hade haft med i Type-2001/2002

OSPFv3-Topology

Satte upp följande topologi så vi kan testa detta lite mer ingående. R6 redistributar förövrigt fyra statiska ipv6-routes till RIPng, som R4 i sin tur redist. till OSPF-processen (ASBR).

Kommer hoppa direkt in i OSPFv3-Konfigen nu men den är väldigt basic så känns inte som det krävs någon närmare förklaring:

R1

ipv6 unicast-routing
 !
 interface Loopback0
 ipv6 address 2001:DB8:6783:1111::1/64
 !
 interface FastEthernet0/0
 ipv6 address FE80::1 link-local
 ipv6 address 2001:DB8:6783:1::1/64
 ipv6 ospf 1 area 64
 !
 interface FastEthernet0/1
 ipv6 address FE80::1 link-local
 ipv6 address 2001:DB8:6783::1/64
 ipv6 ospf 1 area 0
 !
 ipv6 router ospf 1
 router-id 1.1.1.1

R2

ipv6 unicast-routing
!
interface Loopback0
 ipv6 address 2001:DB8:6783:2222::2/64
!
interface FastEthernet0/0
 ipv6 address FE80::2 link-local
 ipv6 address 2001:DB8:6783:2::2/64
 ipv6 ospf 1 area 10
! 
interface FastEthernet0/1
 ipv6 address FE80::2 link-local
 ipv6 address 2001:DB8:6783::2/64
 ipv6 ospf 1 area 0
!
ipv6 router ospf 1
 router-id 2.2.2.2

R3

ipv6 unicast-routing
!
interface Loopback0
 ipv6 address 2001:DB8:6783:3333::3/64
!
interface FastEthernet0/0
 ipv6 address FE80::3 link-local
 ipv6 address 2001:DB8:6783:3::3/64
!
interface FastEthernet0/1
 ipv6 address FE80::3 link-local
 ipv6 address 2001:DB8:6783::3/64
 ipv6 ospf 1 area 0
 !
ipv6 router ospf 1
 router-id 3.3.3.3

R4

ipv6 unicast-routing
!
interface FastEthernet0/0
 ipv6 address FE80::4 link-local
 ipv6 address 2001:DB8:6783:1::4/64
 ipv6 ospf 1 area 64
!
interface FastEthernet0/1
 ipv6 address FE80::4 link-local
 ipv6 address 2001:DB8:6783:64::4/64
 ipv6 rip RIP-LAB enable
 !
ipv6 router ospf 1
 router-id 4.4.4.4
redistribute rip RIP-LAB metric 100

R5

ipv6 unicast-routing
!
interface FastEthernet0/0
 ipv6 address FE80::5 link-local
 ipv6 address 2001:DB8:6783:2::5/64
 ipv6 ospf 1 area 10
!
ipv6 router ospf 1
 router-id 5.5.5.5

R6

ipv6 unicast-routing
 !
 interface FastEthernet0/0
 ipv6 address FE80::6 link-local
 ipv6 address 2001:DB8:6783:64::6/64
 ipv6 rip RIP-LAB enable
 !
 ipv6 route 2002:DB10::/64 Null0
 ipv6 route 2002:DB10:1::/64 Null0
 ipv6 route 2002:DB10:2::/64 Null0
 ipv6 route 2002:DB10:3::/64 Null0
 !
 ipv6 router rip RIP-LAB
 redistribute static metric 5

För att få några inter-area routes la jag även till några loopbacks på R3 i efterhand:

int lo0
 ipv6 address 2001:DB8:6783:200::1/64
 ipv6 ospf 1 area 0
 ipv6 ospf network point-to-point
 int lo1
 ipv6 address 2001:DB8:6783:201::1/64
 ipv6 ospf 1 area 0
 ipv6 ospf network point-to-point
 int lo2
 ipv6 address 2001:DB8:6783:202::1/64
 ipv6 ospf 1 area 0
 ipv6 ospf network point-to-point
 int lo3
 ipv6 address 2001:DB8:6783:203::1/64
 ipv6 ospf 1 area 0
 ipv6 ospf network point-to-point

En show ip route på R1 visar nu följande:

ospfv3-r1

Och R5:

ospfv3-r5

So far so good.

OSPFv3s Hello-paket ser förövrigt ut såhär:

ospv3-hello

Om vi jämför med ett Hello-paket från OSPFv2 (IPv4) så kan vi se att det skiljer sig lite:

ospv2-hello

  • OSPFv3 använder inte längre någon inbyggd autentisering utan förlitar sig på underliggande protokoll (IPv6)
  • Använder Link-id istället för network
  • Listar förutom DR&BDR även övriga neighbors i arean

Vad har vi då för LSAs snurrandes i vårat nät?

Vi rensar ospf-processen på R1 med clear ipv6 ospf process [yes] och ser vad som händer..

LSA Type-0008

Det första R1 skickar ut innehåller den nya Link-LSA typen 0008.

lsa-link

Paketet innehåller:

  • Router-ID
  • Link-id
  • De ipv6-prefix som finns konfigurerade på interfacet

Vi kan även använda kommandot “sh ipv6 ospf database link” för att få ut samma information, och för enkelhetens skull skippar jag wireshark för resten av det här inlägget.

OSPFv3 Router with ID (1.1.1.1) (Process ID 1)
Link (Type-8) Link States (Area 0)
LS age: 1851
 Options: (V6-Bit E-Bit R-bit DC-Bit)
 LS Type: Link-LSA (Interface: FastEthernet0/1)
 Link State ID: 5 (Interface ID)
 Advertising Router: 1.1.1.1
 LS Seq Number: 80000005
 Checksum: 0x2A3F
 Length: 56
 Router Priority: 1
 Link Local Address: FE80::1
 Number of Prefixes: 1
 Prefix Address: 2001:DB8:6783::
 Prefix Length: 64, Options: None
LS age: 1375
 Options: (V6-Bit E-Bit R-bit DC-Bit)
 LS Type: Link-LSA (Interface: FastEthernet0/1)
 Link State ID: 5 (Interface ID)
 Advertising Router: 2.2.2.2
 LS Seq Number: 80000004
 Checksum: 0x2441
 Length: 56
 Router Priority: 1
 Link Local Address: FE80::2
 Number of Prefixes: 1
 Prefix Address: 2001:DB8:6783::
 Prefix Length: 64, Options: None
LS age: 1431
 Options: (V6-Bit E-Bit R-bit DC-Bit)
 LS Type: Link-LSA (Interface: FastEthernet0/1)
 Link State ID: 5 (Interface ID)
 Advertising Router: 3.3.3.3
 LS Seq Number: 80000004
 Checksum: 0x1C44
 Length: 56
 Router Priority: 1
 Link Local Address: FE80::3
 Number of Prefixes: 1
 Prefix Address: 2001:DB8:6783::
 Prefix Length: 64, Options: None

Vi kan se att vi tre Link-LSAs, vår egen samt R2 & R3s, Detta skickas som link-local och sprids endast till våra neighbors som är “Directly Connected”.  Vad händer då med neighbors som EJ är DC? Ta detta exempel:

lsa-linktype9

R5 kommer aldrig få information om vad R1 har för Link-ID & Prefix konfigurerat på sitt interface då R2 inte kommer vidarebefordra paketet. Det är istället här LSA Type-2009 intra-area-prefix-LSA kommer in i bilden, mer om den senare.

LSA Type-2001 Router-LSA

LSA Type-2001 Router LSA fungerar precis som i OSPFv2 med skillnaden att OSPF-Speakers EJ inkluderar intra-area prefixen den annars annonserar, detta skickas istället även det som ett LSA Type-2009 intra-area-prefix-LSA. Type-2001 innehåller endast information om Router-ID, Network-type & DR/BDR. Notera att den även hänvisar till interface-id vi lärt oss från LSA Type 0008 för att informera om vilket interface det gäller.

R1#sh ipv6 ospf database router
[...]
OSPFv3 Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
Routing Bit Set on this LSA
 LS age: 315
 Options: (V6-Bit E-Bit R-bit DC-Bit)
 LS Type: Router Links
 Link State ID: 0
 Advertising Router: 2.2.2.2
 LS Seq Number: 80000012
 Checksum: 0xBD08
 Length: 40
 Area Border Router
 Number of Links: 1
Link connected to: a Transit Network
 Link Metric: 10
 Local Interface ID: 5
 Neighbor (DR) Interface ID: 5
 Neighbor (DR) Router ID: 3.3.3.3
 [...]

LSA Type-2002 network-LSA

Detta skickas precis som vanligt endast av DR och innehåller i OSPFv3 endast information om vilka övriga routrar som finns i arean. I OSPFv2 har även tillhörande prefix inkluderats, men än en gång så har detta flyttats till LSA Type-2009 intra-area-prefix-LSA.

R1#sh ipv6 ospf database network
OSPFv3 Router with ID (1.1.1.1) (Process ID 1)
Net Link States (Area 0)
LS age: 1286
 Options: (V6-Bit E-Bit R-bit DC-Bit)
 LS Type: Network Links
 Link State ID: 5 (Interface ID of Designated Router)
 Advertising Router: 3.3.3.3
 LS Seq Number: 80000006
 Checksum: 0x7F57
 Length: 36
 Attached Router: 3.3.3.3
  Attached Router: 1.1.1.1
  Attached Router: 2.2.2.2

LSA Type-2003 inter-area-prefix-LSA

Detta fungerar precis som i OSPFv2, men då vi endast har två inter-area nät sett från area 0 blir det enklast att kontrollera detta i R3. Den bör se nätet R1 har i area 64 samt R2s nät i area 10:

R3#sh ipv6 ospf database inter-area prefix
OSPFv3 Router with ID (3.3.3.3) (Process ID 1)
Inter Area Prefix Link States (Area 0)
Routing Bit Set on this LSA
 LS age: 1849
 LS Type: Inter Area Prefix Links
 Link State ID: 0
 Advertising Router: 1.1.1.1
 LS Seq Number: 80000002
 Checksum: 0x20F4
 Length: 36
 Metric: 10
 Prefix Address: 2001:DB8:6783:1::
 Prefix Length: 64, Options: None
Routing Bit Set on this LSA
 LS age: 1238
 LS Type: Inter Area Prefix Links
 Link State ID: 1
 Advertising Router: 2.2.2.2
 LS Seq Number: 80000004
 Checksum: 0x607
 Length: 36
 Metric: 10
 Prefix Address: 2001:DB8:6783:2::
 Prefix Length: 64, Options: None

Kom ihåg att nätet vi redistributar från R4 EJ räknas som inter-area nät utan external (Type-4005).

LSA Type-2004 inter-area-router-LSA

Inget nytt från OSPFv2, möjliggör endast för routrar i andra areas att nå vår ASBR (annonseras av ABR).

R4 är ju i detta fall vår ASBR och R1 i rollen som ABR bör annonsera detta LSA-paket till resterande routrar i area 0.

R3#sh ipv6 ospf database inter-area router
OSPFv3 Router with ID (3.3.3.3) (Process ID 1)
Inter Area Router Link States (Area 0)
Routing Bit Set on this LSA
 LS age: 134
 Options: (V6-Bit E-Bit R-bit DC-Bit)
 LS Type: Inter Area Router Links
 Link State ID: 67372036
 Advertising Router: 1.1.1.1
 LS Seq Number: 80000003
 Checksum: 0x27AF
 Length: 32
 Metric: 10
 Destination Router ID: 4.4.4.4

För R5 bör det vara samma sak med skillnaden att R2 agerar ABR:

R5#sh ipv6 ospf database inter-area router
OSPFv3 Router with ID (5.5.5.5) (Process ID 1)
Inter Area Router Link States (Area 10)
Routing Bit Set on this LSA
 LS age: 63
 Options: (V6-Bit E-Bit R-bit DC-Bit)
 LS Type: Inter Area Router Links
 Link State ID: 67372036
 Advertising Router: 2.2.2.2
 LS Seq Number: 80000003
 Checksum: 0x6D5B
 Length: 32
 Metric: 20
 Destination Router ID: 4.4.4.4

LSA Type-4005 AS-external-LSA

Fungerar även den precis som i OSPFv2, sett från exempelvis R3:

R3#sh ipv6 ospf database external
OSPFv3 Router with ID (3.3.3.3) (Process ID 1)
Type-5 AS External Link States
[...]
Routing Bit Set on this LSA
 LS age: 1902
 LS Type: AS External Link
 Link State ID: 0
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000003
 Checksum: 0xE962
 Length: 36
 Prefix Address: 2002:DB10::
 Prefix Length: 64, Options: None
 Metric Type: 2 (Larger than any link state path)
 Metric: 100
 [...]

LSA Type-2007 NSSA-LSA

Inget nytt här heller, används när vi konfigurerat NSSA alternativt T-NSSA, Type-4005 skickas då istället som Type-2007 NSSA inom arean.

Vi kan verifiera detta genom att konfigurera area 64 till NSSA:

R1(config)#ipv6 router ospf 1
R1(config-rtr)#area 64 nssa

R4(config)#ipv6 router ospf 1
R4(config-rtr)#area 64 nssa
R4 får inte längre in några OE1/2 routes (type-4/5 blockeras):
R4#sh ipv6 route ospf 
IPv6 Routing Table - 16 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
 U - Per-user Static route, M - MIPv6
 I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
 O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
 D - EIGRP, EX - EIGRP external
OI 2001:DB8:6783::/64 [110/20]
 via FE80::1, FastEthernet0/0
OI 2001:DB8:6783:2::/64 [110/30]
 via FE80::1, FastEthernet0/0
OI 2001:DB8:6783:200::/64 [110/21]
 via FE80::1, FastEthernet0/0
OI 2001:DB8:6783:201::/64 [110/21]
 via FE80::1, FastEthernet0/0
OI 2001:DB8:6783:202::/64 [110/21]
 via FE80::1, FastEthernet0/0
OI 2001:DB8:6783:203::/64 [110/21]
 via FE80::1, FastEthernet0/0
OI 2001:DB8:6783:3333::/64 [110/21]
 via FE80::1, FastEthernet0/0

Men vi lyckas fortfarande annonsera våra externa routes till övriga areas:

R1#sh ipv6 ospf database NSSA
OSPFv3 Router with ID (1.1.1.1) (Process ID 1)
Type-7 AS External Link States (Area 64)
Routing Bit Set on this LSA
 LS age: 468
 LS Type: AS External Link
 Link State ID: 4
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000001
 Checksum: 0xCB94
 Length: 36
 Prefix Address: 2002:DB10::
 Prefix Length: 64, Options: P 
 Metric Type: 2 (Larger than any link state path)
 Metric: 100
[...]
R3#sh ipv6 ospf database external
OSPFv3 Router with ID (3.3.3.3) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
 LS age: 500
 LS Type: AS External Link
 Link State ID: 0
 Advertising Router: 1.1.1.1
 LS Seq Number: 80000001
 Checksum: 0x4812
 Length: 36
 Prefix Address: 2002:DB10::
 Prefix Length: 64, Options: None
 Metric Type: 2 (Larger than any link state path)
 Metric: 100

LSA Type-2009 intra-area-prefix-LSA

Detta har vi redan nämnt nu några gånger, Type-2009 är som sagt nytt för OSPFv3 och innehåller de prefix vi exkluderat från LSA Type-2001, 2002 & 0008 (i de fall vi ej är directly connected). R3 som i detta fall är DR sammanställer infon och skickar ut till sina neighbors. Observera att den även refererar till vilken LSA-typ prefixen hör till!:

R1#sh ipv6 ospf database prefix
OSPFv3 Router with ID (1.1.1.1) (Process ID 1)
Intra Area Prefix Link States (Area 0)
Routing Bit Set on this LSA
 LS age: 297
 LS Type: Intra-Area-Prefix-LSA
 Link State ID: 0
 Advertising Router: 3.3.3.3
 LS Seq Number: 80000009
 Checksum: 0x8856
 Length: 92
 Referenced LSA Type: 2001
 Referenced Link State ID: 0
 Referenced Advertising Router: 3.3.3.3
 Number of Prefixes: 5
 Prefix Address: 2001:DB8:6783:203::
 Prefix Length: 64, Options: None, Metric: 1
 Prefix Address: 2001:DB8:6783:202::
 Prefix Length: 64, Options: None, Metric: 1
 Prefix Address: 2001:DB8:6783:201::
 Prefix Length: 64, Options: None, Metric: 1
 Prefix Address: 2001:DB8:6783:200::
 Prefix Length: 64, Options: None, Metric: 1
 Prefix Address: 2001:DB8:6783:3333::
 Prefix Length: 64, Options: None, Metric: 1
Routing Bit Set on this LSA
 LS age: 559
 LS Type: Intra-Area-Prefix-LSA
 Link State ID: 5120
 Advertising Router: 3.3.3.3
 LS Seq Number: 80000005
 Checksum: 0x7846
 Length: 44
 Referenced LSA Type: 2002
 Referenced Link State ID: 5
 Referenced Advertising Router: 3.3.3.3
 Number of Prefixes: 1
 Prefix Address: 2001:DB8:6783::
 Prefix Length: 64, Options: None, Metric: 0
[...]

Puhhh! Tror vi avslutar OSPFv3 här, tanken var som sagt att endast ta upp det som skiljer från när vi kör OSPF i IPv4. 🙂

OSPF – LSA Types

OSPF fyller som bekant sin Linkstate Database (LSDB) via LSA-paket den får från andra routrar. Något vi ej nämnt tidigare är dock att det finns ett flertal olika typer av LSA-paket som alla har olika användningsområden och det är dessa vi kommer gå igenom nu. LSA Type 6 & 8 täcks dock inte av CCNP-materialet och kommer därför ej att förklaras mer ingående.

  • LSA Type 1 – Router LSA
  • LSA Type 2 – Network LSA
  • LSA Type 3 – Summary LSA
  • LSA Type 4 – Summary ASBR LSA
  • LSA Type 5 – Autonomous system external LSA
  • LSA Type 6 – Multicast OSPF LSA
  • LSA Type 7 – External LSA
  • LSA Type 8 – External attribute LSA for BGP

LSA Type 1 – Router LSA

Skickas av samtliga routrar och innehåller information om routerns alla directly connected-nät (som vi lagt till i ospf-processen). Denna LSA-typ skickas dock endast inom den egna arean.

  • IP-Prefix inkl subnätmask
  • Link type

För att göra det hela lite krångligare så finns det fyra olika varianter på “Link type“, ej att blanda ihop med Network Types som vi gick igenom i gårdagens post, de flesta är dock som tur är rätt självklara..

Link type 1 – Point-to-Point används för just Point-to-Point interface och innehåller Router-ID till neighborn.

Link type 2 – Link to transit network används för multiaccess nätverk som Ethernet när routern har lyckats skapa adjacency mot åtminstone en annan router (DR/BDR), alternativt att denna router är DR och bildat adjacency mot en DROTHER. Link ID innehåller här Router-ID:t för DR-routern.

Om ingen neighbor adjacency har lyckats skapats för ett multiaccess-nätverk annonseras det istället som ett Link type 3 – Link to stub network. Detta används även om vi annonserar nät som ligger på ett loopback-interface.

Link type 4 – Virtual Link används när vi skapat en virtuell länk mellan areas, mer om detta senare!

OSPF LSA1 linktypes

Låt oss använda följande topologi för att kolla hur dessa paket används och ser ut i praktiken.

ospf LSA topology

R2#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:38 10.0.0.2 FastEthernet0/0
3.3.3.3 1 FULL/BDR 00:00:32 10.0.0.3 FastEthernet0/0

Här är ett exempel på ett LSU-paket från R2 som annonserar sitt Loopback-nät på 2.2.2.2/32 samt Broadcast-nät på 10.0.0.0/24 till DR & BDR.

ospf lsa type 1 router lsa

Observera att för Link Type 2 så är det ip-adressen för DR som sätts under “Transit ID”.

LSA Type 2 – Network LSA

Används endast i multiaccess-nätverk där vi använder oss av DR & BDR. LSA Type 2 skickas av DR-routern och annonserar att det är just den routern som är DR. Det innehåller även en lista över samtliga routrar som är anslutna till segmentet inklusive IP-prefix och subnätmask. Detta skickas precis som LSA Type 1 endast inom den egna arean. Här har vi ett LSA-paket från R2 (DR) som skickas till R1 efter att de skapat en adjacency.

LSA type 2

Notera att under “Attached Router” så är det inte ip-adressen till routrarna som specificeras utan dess Router-ID.

LSA Type 3 – Summary LSA

Då LSA Type 1 endast annonseras inom den egna arean behöver vi ett sätt att sprida routing-information när vi använder oss av mer än bara area 0/backbone. Det är då ABR (Area Border Routers) kommer in i bilden, de tar Type 1 LSA-paketen och gör om dessa till ett LSA Type 3 vilket den sedan skickar ut till area 0 för vidare spridning. Om vi tar bygger ut vår tidigare topologi till följande så kan vi se hur detta går steg för steg.

Multiarea LSA

I ovanstående exempel kommer R1 att bli ABR mellan area 10 och area 0. R4 kommer skicka LSA Type 1 och informera om alla “directly connected”-nät (Lo0 44.44.44.44/32 & 192.168.0.0/24).  Då det är ett Point-to-Point nät så väljs som bekant ingen DR/BDR  och det skickas därför ej några LSA Type 2. Kom ihåg att LSA Type 1 endast skickas inom arean (10), för att R2 & R3 ska kunna lära sig dessa behöver R1 som i detta fall blir ABR annonsera detta.

R1 åstadkommer detta genom att göra om LSA Type 1-paketet från R4 till ett LSA Type 3 och annonserar sedan ut detta i area 0 till R2 & R3. Likaså kommer den ta LSA Type 1-paketen som skickas inom area 0 och skicka ut dessa som LSA Type 3 ut på area 10.

Type 3 LSA-routes visas som OSPF InterArea-route (O IA) i routing-tabellen för R3:

1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/11] via 10.0.0.1, 01:26:22, FastEthernet0/0
 2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/11] via 10.0.0.2, 01:27:41, FastEthernet0/0
 3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback0
 10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0
O IA 192.168.0.0/24 [110/74] via 10.0.0.2, 00:07:31, FastEthernet0/0
 44.0.0.0/32 is subnetted, 1 subnets
O IA 44.44.44.44 [110/75] via 10.0.0.2, 00:05:30, FastEthernet0/0

Kollar vi i Wireshark ser LSA-paketet ut enligt följande (skickat från ABR R1 till area 10 som multicast på 224.0.0.5):

LSA Type 3

En show ip ospf database på R3 visar följande:

R3#sh ip ospf database
OSPF Router with ID (3.3.3.3) (Process ID 1)
Router Link States (Area 0) <- LSA Type 1
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 1745 0x80000005 0x00F001 2
2.2.2.2 2.2.2.2 866 0x80000006 0x0027BB 2
3.3.3.3 3.3.3.3 1634 0x80000006 0x0017BF 2
Net Link States (Area 0) <- LSA Type 2
Link ID ADV Router Age Seq# Checksum
10.0.0.2 2.2.2.2 1778 0x80000004 0x000CFA
Summary Net Link States (Area 0) <- LSA Type 3
Link ID ADV Router Age Seq# Checksum
44.44.44.44 2.2.2.2 739 0x80000001 0x00E959
192.168.0.0 2.2.2.2 862 0x80000001 0x001E6D

Namnet Summary LSA är lite vilseledande då route’s inte summeras automatiskt.

LSA Type 4 – Summary ASBR LSA

När vi redistributar routing-information in till OSPF, exempelvis från RIP eller statiska routes, så kommer den ansvariga routern att ändra en bit i sin LSA Type 1 och identifiera sig som en ASBR (Autonomous System Border Router). Detta innebär dock samma problem igen, Type 1 skickas endast inom den egna arean och vi behöver ju sprida ut denna informationen till övriga areas.

När en ABR upptäcker denna ändring i LSA Type 1-paketet kommer den skapa ett LSA Type 4 för att skicka vidare ut till övriga areas. I detta paket pekas ASBR-routen ut så att övriga areas ska veta vem det är de ska prata med, advertising router kommer ju dock bli ABR, men den kommer ange Router-ID för ASBR under “Link State ID“.

Vi testar detta genom att skapa en statisk route på R4 för 172.16.0.0/16 och redistributar denna information till area 10.

R1 ser att R4 nu utger sig för att vara en ASBR och skapar därför ett LSA Type 4-paket och skickar ut på area 0 via multicast.

LSA type 4

Observera att Advertising router blir som sagt R1, men Link Sate ID pekar till R4 som destination. Paketet innehåller heller ingen information om nätet 172.16.0.0/16!

LSA Type 5 – Autonomous system external LSA

LSA Type 4 används bevisligen endast för att peka ut vilken/vlka router(s) som är ASBR. Vad händer då med nätet som nu redistributas in till OSPF av R4? Kollar vi i wireshark kan vi se följande LSA-paket skickas ut från ASBR/R4:

LSA type 5

Dessa route’s skickas EJ ut som vanliga LSA Type 1 då det inte är directly connected (även fast vi i detta fall gjort en statisk route som pekar till null0), istället märks dessa routes som “LSA Type 5 – External“. Dessa paket har ej samma begränsningar som Type 1 & 2 utan skickas automatiskt vidare av ABR’s till andra areas. Vi kan bekräfta detta genom att kolla vad R1 annonserar ut till area 0:

LSA type 5 area0

Kollar vi i R3 routing table kan vi se att dessa route’s markeras som O E1 eller O E2 (mer om detta senare) – Ospf External Type 1 / Type 2.

1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/11] via 10.0.0.1, 02:08:01, FastEthernet0/0
 2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/11] via 10.0.0.2, 02:09:20, FastEthernet0/0
 3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback0
O E2 172.16.0.0/16 [110/20] via 10.0.0.2, 00:16:54, FastEthernet0/0
 10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0
O IA 192.168.0.0/24 [110/74] via 10.0.0.2, 00:49:13, FastEthernet0/0
 44.0.0.0/32 is subnetted, 1 subnets
O IA 44.44.44.44 [110/75] via 10.0.0.2, 00:47:10, FastEthernet0/0

Och kontrollerar vi databasen igen ser vi att den byggts på lite sen sist:

OSPF Router with ID (3.3.3.3) (Process ID 1)
Router Link States (Area 0) <- Type 1
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 1870 0x80000006 0x00EE02 2
2.2.2.2 2.2.2.2 1195 0x80000007 0x0025BC 2
3.3.3.3 3.3.3.3 1801 0x80000007 0x0015C0 2
Net Link States (Area 0) <- Type 2
Link ID ADV Router Age Seq# Checksum
10.0.0.2 2.2.2.2 1974 0x80000005 0x000AFB
Summary Net Link States (Area 0) <- Type 3
Link ID ADV Router Age Seq# Checksum
44.44.44.44 2.2.2.2 948 0x80000002 0x00E75A
192.168.0.0 2.2.2.2 1195 0x80000002 0x001C6E
Summary ASB Link States (Area 0) <- Type 4
Link ID ADV Router Age Seq# Checksum
44.44.44.44 2.2.2.2 1097 0x80000001 0x00D171
Type-5 AS External Link States <- Type 5
Link ID ADV Router Age Seq# Checksum Tag
172.16.0.0 44.44.44.44 1105 0x80000001 0x0035FD 0

LSA Type 7 – External LSA

Denna LSA är lite speciell, för att förstå behovet av denna behöver vi först lära oss de olika Area Types som finns inom OSPF, det får bli nästa post!

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.