OSPF Load-Sharing with NSSA (Not-So-Stubby-Areas)

In this lesson(lab challenge), we will validates 3 key OSPF concepts:

• Not-So-Stubby-Areas (NSSA)
• Type 7 to 5 translation
• Forward Address

The aim of this challenge is to hone in our outstanding on these concepts. Our goal at the end of the lab is that  R1 should have 2 OSPF equal cost paths to the redistributed (external) loopback 0 IP address on R4. 

Here is the topology:

Area 34 is configured as an NSSA. R4 is redistributing lo0 with an IP address of 4.4.4.4/24. R1 should use both ABRs (R2 and R3) to reach the external route.

Lab Constraints:
Area 34 should remain as NSSA.
R2 and R3 should remain as ABRs.
Do not configure any tunnel.
Do not use another routing protocol.
Area 0 routers should remain in area 0.

Let’s dive right in …

The key to getting to the solution is to first understand how R1 is reaching the loopback 0 on R4, and why it is making such a  routing decision. The loopback 0 IP on R4 is 4.4.4.4/32. Because this is redistributed into Area 34 which is an NSSA, this shows in the route tables of R2 and R3 as Type 7 external routes(N2).

So how does this get to R1 ….

Note: Area 0 is not an NSSA(and in fact can’t be an NSSA). So to get the Type 7 routes into Area 0, they have to be translated from Type 7 to Type 5. But here’s the catch; only one of the ABRs( R2 and R3) actually does this translation. And this is the router with the higher router-id; R3 in our case.

So R1 is receiving this from R3, and the Forward Address is 34.34.34.4, which is the IP on R4 interface(Originator of 4.4.4.4) that connects to R3(Advertising router of 4.4.4.4 to R1).

R1 will recurse to the next-hop to reach 34.34.34.4, and use that as the next-hop to  forward to R4’s 4.4.4.4/32.

Now we know why R1 is not load-sharing across R2 and R3. How do we get it to load-share, while taking note of the lab constraints.

There are a number of options:

1. We need to influence the Forward Address such that it meets the criteria below:
   • Should be routed in OSPF
   • R1 should have 2 equal cost paths to reach this Forward Address
2. Suppress the Forward Address during the Type 7 to 5 translation. This will cause both ABRs to be used to forward traffic to R4’s loopback 0 interface. This should however be used with caution. See link

In this challenge, we use the first option.

To use this option, we must understand the rules for selecting the forward address. We can see from the previous output on R1 that forward address is an interface on the ASBR; in our example 34.34.34.4 which is on R4.

Forwarding address is selected on ASBR using the following rules:

1. If there is a loopback configured in the area then IP address of the loopback is selected as forwarding address.
2. If first condition is not met then the IP address of first interface on the OSPF interface list is selected as forwarding address. You can see OSPF interface list by using “show ip ospf interface brief” command. The interface on top will be the last interface which was attached to OSPF.

So before any change is made, 34.34.34.4 was chosen.

To influence this, we can configure another loopback interface on R4, and advertise this into OSPF(area 34).

After the change, loopback 1 on R4(ASBR) becomes the forward address.

R1 has two equal cost paths to the new Forward Address. So R1 will perform route-loopback for the next-hops to the forward address, and use these as the next-hop to the R4 loopback 0.