OSPF – NSSA LSA Type7-5 Translator Election

Forsätter nöta OSPF-labbar från GNS3 Vault. 🙂

ospfnssa7to5telect

GOAL:

  • All IP addresses have been preconfigured for you.
  • Configure OSPF Area 0.
  • Configure OSPF Area 1 as NSSA.
  • Redistribute the loopback0 interface on router Sam into OSPF Area 1.
  • Ensure router Tron is the router performing the translation from LSA Type 7 to Type 5 into area 0

Konfig:

Skippar all grundkonfig då det är väldigt basic. Använde redistribute connected för att få in 4.4.4.4/24-nätet in i OSPF.

Kontrollerar vi OSPF-databasen kan vi ses att det just nu är Quorra som utför Type 7->5 translations.

Kevin#sh ip ospf database external
OSPF Router with ID (192.168.13.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
 LS age: 53
 Options: (No TOS-capability, DC)
 LS Type: AS External Link
 Link State ID: 4.4.4.0 (External Network Number )
 Advertising Router: 192.168.34.3
 LS Seq Number: 80000001
 Checksum: 0x6E08
 Length: 36
 Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 192.168.34.4
 External Route Tag: 0

Hur kommer då detta sig? Om vi kontrollerar OSPF-databasen för både Quorra & Tron ser vi följande:

Quorra

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

Tron

Tron#sh ip ospf database nssa-external
OSPF Router with ID (192.168.24.2) (Process ID 1)
Type-7 AS External Link States (Area 1)
LS age: 1120
 Options: (No TOS-capability, Type 7/5 translation, DC)
 LS Type: AS External Link
 Link State ID: 4.4.4.0 (External Network Number )
 Advertising Router: 4.4.4.4
 LS Seq Number: 80000001
 Checksum: 0x6E7C
 Length: 36
 Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 192.168.34.4
 External Route Tag: 0

Så båda routrarna tar emot 4.4.4.0/24-nätet med information att de ska utföra Type 7 -> 5 translation. Kontrollerar vi istället databasen för Type-5 ser vi att endast Quorra som annonserar detta.

Quorra

Quorra#sh ip ospf database external
OSPF Router with ID (192.168.34.3) (Process ID 1)
Type-5 AS External Link States
LS age: 1252
 Options: (No TOS-capability, DC)
 LS Type: AS External Link
 Link State ID: 4.4.4.0 (External Network Number )
 Advertising Router: 192.168.34.3
 LS Seq Number: 80000001
 Checksum: 0x6E08
 Length: 36
 Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 192.168.34.4
 External Route Tag: 0

Tron

Tron#sh ip ospf database external
OSPF Router with ID (192.168.24.2) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
 LS age: 1316
 Options: (No TOS-capability, DC)
 LS Type: AS External Link
 Link State ID: 4.4.4.0 (External Network Number )
 Advertising Router: 192.168.34.3
 LS Seq Number: 80000001
 Checksum: 0x6E08
 Length: 36
 Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 192.168.34.4
 External Route Tag: 0

Varför? Lite efterforskning visade att Ciscos IOS ej har något stöd för att definiera translator direkt i OSPF-processen utan använder sig istället av högst Router-ID. När Tron tar emot LSA Type 5-annonseringen från Quorra som har ett högre RID “flushade” den bort sin egen Type-5 LSA och började använda Quorras istället.

Vill vi ändra Translator måste vi således ändra Router-ID.

Tron(config)#int lo0
Tron(config-if)#ip add 10.10.10.10 255.255.255.255
Tron(config-if)#router ospf 1
Tron(config-router)#router-id 10.10.10.10
Reload or use "clear ip ospf process" command, for this to take effect
Tron(config-router)#do clear ip ospf process
Reset ALL OSPF processes? [no]: yes
Quorra(config)#int lo0
Quorra(config-if)#ip add 9.9.9.9 255.255.255.255
Quorra(config-if)#router ospf 1
Quorra(config-router)#router-id 9.9.9.9
Reload or use "clear ip ospf process" command, for this to take effect
Quorra(config-router)#do clear ip ospf process
Reset ALL OSPF processes? [no]: yes

Kollar vi återigen i Kevin nu kan vi se att Tron har tagit över som Type 7-5 Translator pga ett högre RID. 🙂

Kevin#sh ip ospf database external
OSPF Router with ID (192.168.13.1) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
 LS age: 11
 Options: (No TOS-capability, DC)
 LS Type: AS External Link
 Link State ID: 4.4.4.0 (External Network Number )
 Advertising Router: 10.10.10.10
 LS Seq Number: 80000001
 Checksum: 0x4E8E
 Length: 36
 Network Mask: /24
 Metric Type: 2 (Larger than any link state path)
 TOS: 0
 Metric: 20
 Forward Address: 192.168.34.4
 External Route Tag: 0

Sweet!

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.

OSPF – Area Types & LSA Type 7

Att vi kan dela upp vårat nät i flera areas har väl knappast någon missat vid det här laget. Något som dock aldrig togs upp i CCNA är att det finns ett flertal olika typer av areas med olika användningsområden. Dessa är:

  • Backbone (area 0)
  • Standard area
  • Stub area
  • Totally stub area
  • Not so stubby area (NSSA)
  • Totally not so stubby area (T-NSSA)

Stub-varianterna kan liknas vid stub-funktionaliteten vi såg för EIGRP, de används för att begränsa vilka LSA-typer arean accepterar och håller nere storleken på routing-tabellerna. Det är kanske inte alltid nödvändigt att alla routrar inom en area, som kanske bara har en väg till backbone/area 0, behöver känna till varenda route i nätverket – skulle det inte gå lika bra med en enkel default-route?

Det är här de olika varianterna av areas kommer in i bilden.

Backbone area

Kräver väl knappast någon ytterligare beskrivning. Detta är area 0 som alltid måste finnas i ett OSPF-nätverk. Övriga area’s ska alltid ha en koppling till just Backbone/area 0 via en ABR alternativt Virtual-Link (mer om detta senare). Om trafik ska skickas från exempelvis area 10 till area 20 måste det alltid först gå via area 0. Backbone accepterar alla LSA-typer (1-8).

Standard area

Standard area är precis som det låter, specificerar du inget för en area så kommer den per default vara en “Standard area” och acceptera alla LSA-typer precis som Backbone.

Stub area

Stub area filtrerar bort LSA Type 5-paket (External routes) och ersätter dessa med en default-route istället. Om vi använder oss av följande topologi kan vi se hur detta fungerar i praktiken.

ospf area types topology

Om vi kollar routing table för R5 innan vi ändrar något kan vi se följande:

Gateway of last resort is not set
20.0.0.0/24 is subnetted, 4 subnets
O E2 20.0.0.0 [110/20] via 192.168.0.1, 00:00:02, FastEthernet0/1
O E2 20.0.1.0 [110/20] via 192.168.0.1, 00:00:02, FastEthernet0/1
O E2 20.0.2.0 [110/20] via 192.168.0.1, 00:00:02, FastEthernet0/1
O E2 20.0.3.0 [110/20] via 192.168.0.1, 00:00:02, FastEthernet0/1
O IA 172.16.0.0/16 [110/40] via 192.168.0.1, 00:00:02, 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:02, FastEthernet0/1
O IA 10.0.0.128 [110/20] via 192.168.0.1, 00:00:04, FastEthernet0/1
C 192.168.0.0/24 is directly connected, FastEthernet0/1

Vi ser att vi får in både LSA Type 5 (O E2) samt LSA Type 3 (O IA). Via wireshark kan vi se att 20.0.x.0-näten annonseras som vanligt.

ospf LSA5 innan stub

Låt oss konfigurera area 20 till stub istället:

router ospf 1
area 20 stub

OBS – Area förändringar måste göras på samtliga routrar inom arean (R4 & R5)!

Detta skall som sagt blockera LSA Type 5 och ersätta dessa med en default-route, låt oss se!

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:00, 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:00, FastEthernet0/1
O IA 10.0.0.128 [110/20] via 192.168.0.1, 00:00:00, FastEthernet0/1
C 192.168.0.0/24 is directly connected, FastEthernet0/1
O*IA 0.0.0.0/0 [110/11] via 192.168.0.1, 00:00:00, FastEthernet0/1

De externa route’sen (O E2) finns bevisligen inte kvar längre och vi har nu istället en default-route som pekar på R4 (vår ABR). En show ip ospf database visar följande:

OSPF Router with ID (5.5.5.5) (Process ID 1)
Router Link States (Area 20)
Link ID ADV Router Age Seq# Checksum Link count
4.4.4.4 4.4.4.4 133 0x80000004 0x0055DC 1
5.5.5.5 5.5.5.5 133 0x80000004 0x001416 1
Net Link States (Area 20)
Link ID ADV Router Age Seq# Checksum
192.168.0.2 5.5.5.5 133 0x80000001 0x00D4C3
Summary Net Link States (Area 20)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 4.4.4.4 138 0x80000001 0x0039F4
10.0.0.0 4.4.4.4 138 0x80000002 0x007619
10.0.0.128 4.4.4.4 138 0x80000002 0x000D0C
172.16.0.0 4.4.4.4 138 0x80000002 0x00D47E

Vi har med andra ord endast LSA Type 1, 2 & 3 cirkulerande i area 20 just nu. Låt oss verifiera genom wireshark också.

ospf area stub

Som synes skickas inte längre några AS-External-LSA (LSA Type 5), dessa har istället ersatts av ovanstående LSA Type 3-paket som annonserar 0.0.0.0 0.0.0.0 till Router-ID 4.4.4.4, en default-route till R4!

Observera att då vi blockerar LSA Type 5 finns det ingen möjlighet att ha en ASBR i area 20 nu.

Totally stub area

Totally stub fungerar precis som Stub area, med tillägget att även LSA Type 3 blockeras och vi använder istället endast en default-route. Detta är dock Cisco-proprietärt och finns ej hos andra leverantörer.

Vi konfigurerar precis som för stub alla routrar inom arean med kommandot:

router ospf 1
area 20 stub

Men på ABR-routern (R4) lägger vi även till:

area 20 stub no-summary

Hur ser då R5’s routing table ut nu?

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
O*IA 0.0.0.0/0 [110/11] via 192.168.0.1, 00:00:47, FastEthernet0/1

Rätt stor skillnad mot innan.. I whireshark kan vi se att endast en route nu advertisas från R4:

OSPF totally stub

Något som kan vara intressant att notera – Trots att vi nu blockerar Type 3- & Type 5-LSA’s så är det fortfarande ett Type 3-LSA som skickas från R4. Detta innehåller dock bevisligen bara en default-route och inget annat. På grund av just blockeringen av Type 5 finns det inte heller här någon möjlighet att ha en ASBR i arean.

Not so stubby area (NSSA)

Hur gör vi då om vi vill använda oss av LSA-filtreringen men vi även har en ASBR-router i vår area? Det är till detta LSA Type 7 och NSSA infördes! Låt oss uppdatera vår topologi lite och se hur detta fungerar i praktiken.

OSPF NSSA

Om vi lämnar area 20 som Totally stub från föregående exempel först och försöker redistribute 30.0.x.0/24-näten får vi följande felmeddelande:

*Mar  1 01:11:57.079: %OSPF-4-ASBR_WITHOUT_VALID_AREA: Router is currently an ASBR while having only one area which is a stub area

Och kollar vi routing table för ex. R3 så ser vi att dessa route’s inte skickats vidare från area 20.

Gateway of last resort is not set
20.0.0.0/24 is subnetted, 4 subnets
O E2 20.0.0.0 [110/20] via 10.0.0.1, 00:45:21, FastEthernet0/1
O E2 20.0.1.0 [110/20] via 10.0.0.1, 00:45:21, FastEthernet0/1
O E2 20.0.2.0 [110/20] via 10.0.0.1, 00:45:21, FastEthernet0/1
O E2 20.0.3.0 [110/20] via 10.0.0.1, 00:45:21, FastEthernet0/1
O IA 172.16.0.0/16 [110/20] via 10.0.0.1, 00:45:21, FastEthernet0/1
 10.0.0.0/25 is subnetted, 2 subnets
C 10.0.0.0 is directly connected, FastEthernet0/1

Inte ens R4 kan se näten!

Gateway of last resort is not set
20.0.0.0/24 is subnetted, 4 subnets
O E2 20.0.0.0 [110/20] via 10.0.0.129, 00:14:25, FastEthernet0/0
O E2 20.0.1.0 [110/20] via 10.0.0.129, 00:14:25, FastEthernet0/0
O E2 20.0.2.0 [110/20] via 10.0.0.129, 00:14:25, FastEthernet0/0
O E2 20.0.3.0 [110/20] via 10.0.0.129, 00:14:25, FastEthernet0/0
O IA 172.16.0.0/16 [110/30] via 10.0.0.129, 00:14:25, FastEthernet0/0
 10.0.0.0/25 is subnetted, 2 subnets
O 10.0.0.0 [110/20] via 10.0.0.129, 00:14:25, FastEthernet0/0
C 10.0.0.128 is directly connected, FastEthernet0/0
C 192.168.0.0/24 is directly connected, FastEthernet0/1

Låt oss ändra konfigurationen från Totally stub till Not so stubby area (NSSA):

router ospf 1
area 20 nssa

Och ytterligare ett tillägg behövs på ABR:

router ospf 1
area 20 nssa default-information-originate

Detta beror på att en default-route EJ annonseras automatiskt i en NSSA till skillnad från Stub & Totally Stub.

Vi kommer fortfarande blockera LSA Type 5-paket i vår area och ersätta dessa med en default-route som skickas ut från ABR (R4). Vår ASBR (R5 i detta fall) kommer istället att maskera dessa external routes som “LSA Type 7 – External Routes“. När dessa paket når vår ABR (R4) kommer den “ta bort masken” och vidarebefordra detta till övriga areas som ett vanligt LSA Type 5-paket.

Låt oss se detta “in action”. Efter ändringarna ser R5’s routing table ut såhär:

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:02, 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:02, FastEthernet0/1
O IA 10.0.0.128 [110/20] via 192.168.0.1, 00:00:02, FastEthernet0/1
C 192.168.0.0/24 is directly connected, FastEthernet0/1
 30.0.0.0/24 is subnetted, 2 subnets
S 30.0.0.0 is directly connected, Null0
S 30.0.1.0 is directly connected, Null0
O*N2 0.0.0.0/0 [110/1] via 192.168.0.1, 00:00:04, FastEthernet0/1

Så vi får fortfarande LSA Type 3-paket (O IA), men LSA Type 5 (O E1/E2) har dock bevisligen ersatts av en default-route. Om allt går som planerat ska nu ASBR (R5) maskera sina Type 5 som LSA-7 vilket ABR (R4) sen annonserar ut till övriga areas som ett LSA Type 5 igen.

Låt oss verifiera detta genom wireshark!

Från R5 har följande LSU skickats:

OSPF LSA7

Ser ju bra ut! Kontrollerar vi routing-tabellen för R3 igen kan vi nu se att redistribute av de statiska route’sen från R5 fungerar som det ska trots blockeringen av LSA Type 5.

Gateway of last resort is not set
20.0.0.0/24 is subnetted, 4 subnets
O E2 20.0.0.0 [110/20] via 10.0.0.1, 01:01:42, FastEthernet0/1
O E2 20.0.1.0 [110/20] via 10.0.0.1, 01:01:42, FastEthernet0/1
O E2 20.0.2.0 [110/20] via 10.0.0.1, 01:01:42, FastEthernet0/1
O E2 20.0.3.0 [110/20] via 10.0.0.1, 01:01:42, FastEthernet0/1
O IA 172.16.0.0/16 [110/20] via 10.0.0.1, 01:01:42, FastEthernet0/1
10.0.0.0/25 is subnetted, 2 subnets
C 10.0.0.0 is directly connected, FastEthernet0/1
C 10.0.0.128 is directly connected, FastEthernet0/0
O IA 192.168.0.0/24 [110/20] via 10.0.0.130, 00:05:27, FastEthernet0/0
30.0.0.0/24 is subnetted, 2 subnets
O E2 30.0.0.0 [110/20] via 10.0.0.130, 00:05:22, FastEthernet0/0
O E2 30.0.1.0 [110/20] via 10.0.0.130, 00:05:22, FastEthernet0/0

Totally Not so stubby area (T NSSA)

Detta kanske du redan har listat ut hur det fungerar? Precis som Totally stub så blockeras både LSA Type 3- & LSA Type 5-paket, men har samtidigt fördelen likt NSSA att det finns möjlighet att ha en ASBR i arean. I övrigt fungerar det precis likadant, LSA Type 5-paket kommer maskeras av ASBR till ett LSA Type 7-paket, ABR kommer sedan göra om det till ett vanligt LSA Type 5 innan det skickas ut på area 0.

Vi konfigurerar detta genom:

router ospf 1
area 20 nssa

Och ytterligare ett tillägg behövs på ABR:

router ospf 1
area 20 nssa no-summary

Observera att vi här INTE behöver tillägget default-information-originate utan default-routen skapas automatiskt, inte alls rörigt va? 😛

Kollar vi återigen routing table för R5 bör den nu vara identiskt med den från Totally stub:

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/24 is subnetted, 2 subnets
S 30.0.0.0 is directly connected, Null0
S 30.0.1.0 is directly connected, Null0
O*IA 0.0.0.0/0 [110/11] via 192.168.0.1, 00:00:13, FastEthernet0/1

I R4 har vi nu en ny typ av entry i routing-table, nämligen O N2 (OSPF NSSA External type 2).

Gateway of last resort is not set
O IA 172.16.0.0/16 [110/30] via 10.0.0.129, 00:58:57, FastEthernet0/0
 10.0.0.0/25 is subnetted, 2 subnets
O 10.0.0.0 [110/20] via 10.0.0.129, 00:58:57, FastEthernet0/0
C 10.0.0.128 is directly connected, FastEthernet0/0
C 192.168.0.0/24 is directly connected, FastEthernet0/1
 30.0.0.0/24 is subnetted, 2 subnets
O N2 30.0.0.0 [110/20] via 192.168.0.2, 00:59:07, FastEthernet0/1
O N2 30.0.1.0 [110/20] via 192.168.0.2, 00:59:07, FastEthernet0/1

Och för att verifiera att redistribute fortfarande fungerar har vi här ett utdrag från R3:

Gateway of last resort is not set
20.0.0.0/24 is subnetted, 4 subnets
O E2 20.0.0.0 [110/20] via 10.0.0.1, 01:11:54, FastEthernet0/1
O E2 20.0.1.0 [110/20] via 10.0.0.1, 01:11:54, FastEthernet0/1
O E2 20.0.2.0 [110/20] via 10.0.0.1, 01:11:54, FastEthernet0/1
O E2 20.0.3.0 [110/20] via 10.0.0.1, 01:11:54, FastEthernet0/1
O IA 172.16.0.0/16 [110/20] via 10.0.0.1, 01:11:54, FastEthernet0/1
 10.0.0.0/25 is subnetted, 2 subnets
C 10.0.0.0 is directly connected, FastEthernet0/1
C 10.0.0.128 is directly connected, FastEthernet0/0
O IA 192.168.0.0/24 [110/20] via 10.0.0.130, 00:15:40, FastEthernet0/0
 30.0.0.0/24 is subnetted, 2 subnets
O E2 30.0.0.0 [110/20] via 10.0.0.130, 00:15:35, FastEthernet0/0
O E2 30.0.1.0 [110/20] via 10.0.0.130, 00:15:35, FastEthernet0/0

Perfekt! Observera att 30.0.x.0/24-route nu återigen står som O E2 (External, LSA Type 5).

Detta täcker allt inom Area/Network/LSA Types! Vi har fortfarande kvar summering av nät, autentisering och virtual link att gå igenom men sedan är vi faktiskt klara med OSPF. 🙂