OSPF NSSA Translation

Justin asked a question that I did not immediately have an answer to (thank you Justin). It had to do with OSPF NSSA translation. He was stating that a router (R6) in area 0 had received only one Type-5 LSA translated from an NSSA area, but the RIB showed two equal cost paths to reach the network. The setup is a box network with R6 generating the Type-7 LSA in area 1, R1 and R4 are ABR's for area 1 and R5 is in area 0. R1 is the 7->5 translator.

R5#sho ip route
...
155.0.0.0/24 is subnetted, 2 subnets
C 155.0.0.0 is directly connected, Serial0/0
160.0.0.0/24 is subnetted, 1 subnets
O E2 160.0.60.0 [110/20] via 155.0.0.4, 00:04:02, Serial0/0
[110/20] via 155.0.0.1, 00:04:02, Serial0/0
150.0.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 150.0.5.0/24 is directly connected, Loopback0
O IA 150.0.6.6/32 [110/75] via 155.0.0.4, 00:04:02, Serial0/0
[110/75] via 155.0.0.1, 00:04:02, Serial0/0
O IA 150.0.4.4/32 [110/65] via 155.0.0.4, 00:04:02, Serial0/0
O IA 150.0.1.1/32 [110/65] via 155.0.0.1, 00:04:02, Serial0/0

R5#sho ip ospf data
...
Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
160.0.60.0 150.0.100.100 528 0x80000001 0x00DFE1 0

Well that's interesting. But what information does the LSA have in it?

R5#sho ip ospf data ext

OSPF Router with ID (150.0.5.5) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 649 Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 160.0.60.0 (External Network Number )
Advertising Router: 150.0.100.100
LS Seq Number: 80000001
Checksum: 0xDFE1
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 150.0.6.6
External Route Tag: 0

Ahh, the blessed Forwarding Address. Looking back at the routing table we do indeed have a route to 150.0.6.6, both to 155.0.0.1 and 155.0.0.4. So the routing table is updated that 160.0.60.0/24 can be reached equally by R1 and R4, even though R1 is the only one performing the translation.

Now is this OSPF performing this recursive lookup or is it the router? I filtered 150.0.6.6 from entering area 0 on both ABRs.

R1(config)#ip prefix-list plR6_out deny 150.0.6.6/32
R1(config)#ip prefix-list plR6_out permit 0.0.0.0/0 le 32
R1(config)#router ospf 1
R1(config-router)#area 1 filter-list prefix plR6_out out

R4(config)#ip prefix-list plR6_out deny 150.0.6.6/32
R4(config)#ip prefix-list plR6_out permit 0.0.0.0/0 le 32
R4(config)#router ospf 1
R4(config-router)#area 1 filter-list prefix plR6_out out

R5#sho ip route
...
155.0.0.0/24 is subnetted, 2 subnets
C 155.0.0.0 is directly connected, Serial0/0
150.0.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 150.0.5.0/24 is directly connected, Loopback0
O IA 150.0.4.4/32 [110/65] via 155.0.0.4, 00:16:50, Serial0/0
O IA 150.0.1.1/32 [110/65] via 155.0.0.1, 00:16:50, Serial0/0

Both the external route and the route to 150.0.6.6 have been removed. Next I added a static route to 150.0.6.6 to see if the external route would reappear...

R5(config)#ip route 150.0.6.6 255.255.255.255 155.0.0.4
R5#sho ip route
...
155.0.0.0/24 is subnetted, 2 subnets
C 155.0.0.0 is directly connected, Serial0/0
150.0.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 150.0.5.0/24 is directly connected, Loopback0
S 150.0.6.6/32 [1/0] via 155.0.0.4
O IA 150.0.4.4/32 [110/65] via 155.0.0.4, 00:22:07, Serial0/0
O IA 150.0.1.1/32 [110/65] via 155.0.0.1, 00:22:07, Serial0/0

Well it would appear that the recursive lookup to the forwarding address in type-5 LSA's are indeed completely within the OSPF process. This means I can have all kinds of fun.

First I can have R1 perform 7->5 translation, but send all traffic to R4. To accomplish I filter the router ID of the Forwarding Address on R1. Bingo presto all traffic to R6 now travels through R4, including the external network being translated by R1. As a side note, there is no need for the static route on R5.

Next I could send the translated traffic to R4, but have R1 be the primary means to get to R6. The same setup is used previously filtering out 150.0.6.6 on R1, but on R5 I include a static route to 150.0.6.6 to 155.0.0.1 (R1).

Of course, this is all one way traffic as the return traffic is not affected. So one must make the same modifications in the reverse direction to ensure route symmetry.

Anthony