Tonight I’m posting some updates to the IEWB-RS Volume 1 Version 5.0 section of OSPF, along with an interesting teaser on how OSPF path selection works towards external routes originated in an NSSA. In my pursuit of networking Nirvana, I have a motto; learn something new every day. This topic for sure will fall into that category for many engineers.
We all (hopefully) know what an NSSA is in OSPF. It’s that cute little area that’s sort of stubby, but not completely, which allows us to cut down on the size of the OSPF database while still doing redistribution into an area. What is a little lesser known fact however, is how calculation towards an external route originated in an NSSA differs from a normal route redistributed into OSPF. Check the above link for the detailed walkthrough of how this works, along with the diagram and initial configs for those of you that don’t already have a subscription to the product, but the spirit of the situation is as follows…
As previously seen with OSPF Not-So-Stubby Areas, Type-7 NSSA External LSAs are translated to Type-5 External LSAs by the ABR connecting the NSSA to area 0. When multiple ABRs connect the NSSA to area 0, the ABR with the highest router-id is elected as the Type-7 to 5 translator, and is responsible for re-originating the Type-5 LSA into area 0. This election process is an optimization of the OSPF database, and relates to how the Type-7 NSSA External route uses the forward address field to ensure optimal routing.
Recall that with normal external routes, only one Type-5 LSA is originated by the router performing the redistribution. When the route moves between areas, each ABR originates a Type-4 ASBR Summary LSA advertising their reachability to the ASBR. This means that for all Type-5 External LSA inter-area lookups OSPF would require Ext_Routes + Num_ABRs + Num_Routers LSAs, where Ext_Routes is the number of Type-5 LSAs, Num_ABRs is the number of ABRs generating Type-4 ASBR summaries, and Num_Routers is the number of Type-1 LSAs from the routers in the local area.
Now with Type-7 LSAs the situation becomes more complicated, because this information needs to be re-originated at the ABR level as the route moves into area 0. Let’s suppose for the sake of argument that each ABR connecting the NSSA to area 0 did do a translation of Type-7 to 5. This would mean for all inter-area lookups on a Type-5 External LSAs that were translated from Type-7, there would be (NSSA_Routes * Num_ABRs) + Num_ABRs + Num_Routers LSAs, where NSSA_Routes is the number of Type-7 LSAs to start.
This operation would be highly redundant and inefficient, because each ABR would re-originate the same Type-5 LSA, each with the same forwarding address. To avoid this only one ABR performs the Type-7 to 5 translation, but maintains the forward address field, essentially separating the relationship between the routing advertisement and the traffic flow. This principle can be illustrated as follows.
Before any modification in the OSPF domain, R5 performs a lookup on the Type-5 LSA for 9.9.9.9 that was translated from a Type-7 LSA. At this point R3 has an OSPF Router-ID of 150.1.3.3, and R6 has 150.1.6.6. The advertising router R5 sees is 150.1.6.6 (R6), since R6 won the translator election due to the higher RID. Note however, the forward address is set to 150.1.9.9 (SW3). This means that R5 next needs to figure out how to route towards 150.1.9.9.
The Type-7 to 5 translator election can be modified by increasing R3’s router-id to be higher than R6’s.
Although the advertising router has changed, the forward address is still 150.1.9.9, which means the traffic flow has not changed.
We all (hopefully) know what an NSSA is in OSPF. It’s that cute little area that’s sort of stubby, but not completely, which allows us to cut down on the size of the OSPF database while still doing redistribution into an area. What is a little lesser known fact however, is how calculation towards an external route originated in an NSSA differs from a normal route redistributed into OSPF. Check the above link for the detailed walkthrough of how this works, along with the diagram and initial configs for those of you that don’t already have a subscription to the product, but the spirit of the situation is as follows…
As previously seen with OSPF Not-So-Stubby Areas, Type-7 NSSA External LSAs are translated to Type-5 External LSAs by the ABR connecting the NSSA to area 0. When multiple ABRs connect the NSSA to area 0, the ABR with the highest router-id is elected as the Type-7 to 5 translator, and is responsible for re-originating the Type-5 LSA into area 0. This election process is an optimization of the OSPF database, and relates to how the Type-7 NSSA External route uses the forward address field to ensure optimal routing.
Recall that with normal external routes, only one Type-5 LSA is originated by the router performing the redistribution. When the route moves between areas, each ABR originates a Type-4 ASBR Summary LSA advertising their reachability to the ASBR. This means that for all Type-5 External LSA inter-area lookups OSPF would require Ext_Routes + Num_ABRs + Num_Routers LSAs, where Ext_Routes is the number of Type-5 LSAs, Num_ABRs is the number of ABRs generating Type-4 ASBR summaries, and Num_Routers is the number of Type-1 LSAs from the routers in the local area.
Now with Type-7 LSAs the situation becomes more complicated, because this information needs to be re-originated at the ABR level as the route moves into area 0. Let’s suppose for the sake of argument that each ABR connecting the NSSA to area 0 did do a translation of Type-7 to 5. This would mean for all inter-area lookups on a Type-5 External LSAs that were translated from Type-7, there would be (NSSA_Routes * Num_ABRs) + Num_ABRs + Num_Routers LSAs, where NSSA_Routes is the number of Type-7 LSAs to start.
This operation would be highly redundant and inefficient, because each ABR would re-originate the same Type-5 LSA, each with the same forwarding address. To avoid this only one ABR performs the Type-7 to 5 translation, but maintains the forward address field, essentially separating the relationship between the routing advertisement and the traffic flow. This principle can be illustrated as follows.
Before any modification in the OSPF domain, R5 performs a lookup on the Type-5 LSA for 9.9.9.9 that was translated from a Type-7 LSA. At this point R3 has an OSPF Router-ID of 150.1.3.3, and R6 has 150.1.6.6. The advertising router R5 sees is 150.1.6.6 (R6), since R6 won the translator election due to the higher RID. Note however, the forward address is set to 150.1.9.9 (SW3). This means that R5 next needs to figure out how to route towards 150.1.9.9.
Rack1R5#show ip ospf database external 9.9.9.9
OSPF Router with ID (150.1.5.5) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 224
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 9.9.9.9 (External Network Number )
Advertising Router: 150.1.6.6
LS Seq Number: 80000001
Checksum: 0x1F10
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 150.1.9.9
External Route Tag: 0Since 150.1.9.9 does not belong to a device in the same area as R5, an inter-area lookup is performed on the Type-3 LSA. R5 finds that two ABRs are advertising the route to 150.1.9.9, 150.1.3.3 (R3) and 150.1.6.6 (R6), both with a metric of 3.Rack1R5#show ip ospf database summary 150.1.9.9
OSPF Router with ID (150.1.5.5) (Process ID 1)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA
LS age: 603
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 150.1.9.9 (summary Network Number)
Advertising Router: 150.1.3.3
LS Seq Number: 80000001
Checksum: 0xBD35
Length: 28
Network Mask: /32
TOS: 0 Metric: 3
LS age: 4 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 150.1.9.9 (summary Network Number)
Advertising Router: 150.1.6.6
LS Seq Number: 80000001
Checksum: 0x9656
Length: 28
Network Mask: /32
TOS: 0 Metric: 3R5 now needs to find what the metric is to reach these ABRs. R5 checks its locally originated Type-1 Router LSA and finds that 150.1.1.1 (R1) and 150.1.3.3 (R3) are directly attached, both with a metric of 64.Rack1R5#show ip ospf database router 150.1.5.5 self-originate
OSPF Router with ID (150.1.5.5) (Process ID 1)
Router Link States (Area 0)
LS age: 1620
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 150.1.5.5
Advertising Router: 150.1.5.5
LS Seq Number: 80000019
Checksum: 0x7DAE
Length: 108
Area Border Router
Number of Links: 7
*snip*
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 150.1.1.1
(Link Data) Router Interface address: 155.1.0.5
Number of TOS metrics: 0
TOS 0 Metrics: 64
*snip*
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 150.1.3.3
(Link Data) Router Interface address: 155.1.0.5
Number of TOS metrics: 0
TOS 0 Metrics: 64
*snip*R5 asks R1 who it is adjacent with, and finds 150.1.6.6 (R6) is connected over the a Virtual-Link with a metric of 1.Rack1R5#show ip ospf database router 150.1.1.1
OSPF Router with ID (150.1.5.5) (Process ID 1)
Router Link States (Area 0)
Routing Bit Set on this LSA
LS age: 773
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 150.1.1.1
Advertising Router: 150.1.1.1
LS Seq Number: 8000001B
Checksum: 0xFA2E
Length: 72
Area Border Router
Number of Links: 4
Link connected to: a Virtual Link
(Link ID) Neighboring Router ID: 150.1.6.6
(Link Data) Router Interface address: 155.1.146.1
Number of TOS metrics: 0
TOS 0 Metrics: 1This means that R5’s intra-area cost to R3 is 64, and to R6 is 65. Since both R3 and R6 reported a cost of 3 to the forward address 150.1.9.9, the total forward metric through R6 is 65+3 = 68, but is only 64+3 = 67 through R3. Therefore although the route is originated into area 0 by R6, the Type-7 to 5 translator, the traffic does not actually flow through R6. Instead the path through R3 installed with the default redistribution metric of 20 for the E2 route, and a forward metric of 67 through R3.Rack1R5#show ip route 9.9.9.9
Routing entry for 9.9.9.9/32
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 67
Last update from 155.1.0.3 on Serial0/0, 00:17:27 ago
Routing Descriptor Blocks:
* 155.1.0.3, from 150.1.6.6, 00:17:27 ago, via Serial0/0
Route metric is 20, traffic share count is 1
Rack1R5#traceroute 9.9.9.9
Type escape sequence to abort.
Tracing the route to 9.9.9.9
1 155.1.0.3 28 msec 32 msec 32 msec
2 155.1.37.7 32 msec 32 msec 32 msec
3 155.1.79.9 28 msec * 28 msecThis illustrates why a Type-5 External route that was translated from a Type-7 NSSA External route does not use a Type-4 ASBR Summary LSA, because the forward address lookup replaces the need for the ASBR Summary lookup. Since the forward address is preserved only one router needs to do the translation, while the calculation of the final forwarding path stays independentThe Type-7 to 5 translator election can be modified by increasing R3’s router-id to be higher than R6’s.
Rack1R3#config t
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R3(config)#router ospf 1
Rack1R3(config-router)#router-id 150.1.30.30
Reload or use "clear ip ospf process" command, for this to take effect
Rack1R3(config-router)#end
Rack1R3#clear ip ospf 1 process
Reset OSPF process? [no]: yes
Rack1R3#
Rack1R5#show ip ospf database external 9.9.9.9
OSPF Router with ID (150.1.5.5) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 42
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 9.9.9.9 (External Network Number )
Advertising Router: 150.1.30.30
LS Seq Number: 80000001
Checksum: 0xE519
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 150.1.9.9
External Route Tag: 0R5 now sees the advertising router as 150.1.30.30 (R3), because this is the highest router-id of the ABRs connecting the NSSA to area 0.Although the advertising router has changed, the forward address is still 150.1.9.9, which means the traffic flow has not changed.
Rack1R5#traceroute 9.9.9.9 Type escape sequence to abort. Tracing the route to 9.9.9.9 1 155.1.0.3 28 msec 32 msec 28 msec 2 155.1.37.7 32 msec 32 msec 32 msec 3 155.1.79.9 28 msec * 28 msecOnly once the forward metric via R3 is higher than the forward metric via R6 will the path selection change. This can be accomplished by changing the OSPF cost on R3’s link to SW1.
Rack1R3#config t Enter configuration commands, one per line. End with CNTL/Z. Rack1R3(config)#interface Fa0/0 Rack1R3(config-if)#ip ospf cost 1000 Rack1R3(config-if)#endNow when R5 computes the forward metric through R3 it sees the same intra-area cost of 64 to R3, but R3 increased the advertised metric to 150.1.9.9 to 1002.
Rack1R5#show ip ospf database summary 150.1.9.9 adv-router 150.1.30.30
OSPF Router with ID (150.1.5.5) (Process ID 1)
Summary Net Link States (Area 0)
Routing Bit Set on this LSA
LS age: 70
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 150.1.9.9 (summary Network Number)
Advertising Router: 150.1.30.30
LS Seq Number: 80000002
Checksum: 0x854B
Length: 28
Network Mask: /32
TOS: 0 Metric: 1002The final result is that the route is installed via R6 with a metric of 20 reported by the ASBR, plus the forward metric of 68 through R6.Rack1R5#show ip route 9.9.9.9
Routing entry for 9.9.9.9/32
Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 68
Last update from 155.1.0.1 on Serial0/0, 00:02:06 ago
Routing Descriptor Blocks:
* 155.1.0.1, from 150.1.30.30, 00:02:06 ago, via Serial0/0
Route metric is 20, traffic share count is 1
Rack1R5#traceroute 9.9.9.9
Type escape sequence to abort.
Tracing the route to 9.9.9.9
1 155.1.0.1 29 msec 28 msec 28 msec
2 155.1.146.6 28 msec 32 msec 28 msec
3 155.1.67.7 32 msec 32 msec 28 msec
4 155.1.79.9 32 msec * 28 msecIf R6 loses connectivity to area 0 its route to the forward address is lost, and traffic is rerouted to R3.Rack1R6#config t Enter configuration commands, one per line. End with CNTL/Z. Rack1R6(config)#interface Fa0/0.146 Rack1R6(config-subif)#shutdown Rack1R6(config-subif)# Rack1R5#traceroute 9.9.9.9 Type escape sequence to abort. Tracing the route to 9.9.9.9 1 155.1.0.3 28 msec 32 msec 28 msec 2 155.1.37.7 28 msec 28 msec 28 msec 3 155.1.79.9 32 msec * 28 msec
0 comments:
Post a Comment