Lately, I have been spending a lot of time reading about OSPF, especially as it relates to forwarding address. In the last article, we discussed what forwarding address is and its use as it relates to AS external routes. In this article, we will visit the concept again but from a different perspective – as it relates to NSSA.

In OSPF, there is a middle ground between a stub area and an area that can have OSPF external routes and this is known as the “not-so-stubby area” (NSSA). Within an NSSA, external routes are carried as Type-7 LSAs, but what happens to other areas in the OSPF domain; how will they know about the external routes? This is taken care of by Type-7 to Type-5 translation by the NSSA ABR(s).

Let’s start with the diagram below:

In the diagram above, R4 is running both OSPF and EIGRP routing protocols and it is performing mutual redistribution between both protocols. Area 1 is an NSSA with two border routers – R2 and R3. The configurations on the routers are as follows:

hostname R2
!
interface Ethernet0/0
 ip address 10.10.12.2 255.255.255.0
!
interface Ethernet0/1
 ip address 10.10.24.2 255.255.255.0
!
router ospf 1
 router-id 2.2.2.2
 area 1 nssa
 network 10.10.12.0 0.0.0.255 area 0
 network 10.10.24.0 0.0.0.255 area 1
!

hostname R3
!
interface Ethernet0/0
ip address 10.10.13.3 255.255.255.0
!
interface Ethernet0/1
ip address 10.10.34.3 255.255.255.0
!
router ospf 1
router-id 3.3.3.3
area 1 nssa
network 10.10.13.0 0.0.0.255 area 0
network 10.10.34.0 0.0.0.255 area 1
!

hostname R4
!
interface Ethernet0/0
ip address 10.10.24.4 255.255.255.0
!
interface Ethernet0/1
ip address 10.10.34.4 255.255.255.0
!
interface Ethernet0/2
ip address 172.16.0.4 255.255.255.0
!
router eigrp 10
network 172.16.0.0 0.0.0.255
redistribute ospf 1 metric 1500 10 1 1 1500
!
router ospf 1
router-id 4.4.4.4
area 1 nssa
redistribute eigrp 10 subnets
network 10.10.24.0 0.0.0.255 area 1
network 10.10.34.0 0.0.0.255 area 1
!

Let’s begin with R4: the EIGRP routes should be advertised into OSPF Area 1 as Type-7 LSAs:

As you can see, there are two Type-7 LSA routes: 60.60.60.0/24 and 172.16.0.0/24. Our focus is on the 60.60.60.0/24 route, so let’s take a closer look at it:

The first thing I would like to point out is that the P-bit is set, which is responsible for determining whether a Type-7 LSA can be translated to a Type-5 LSA i.e. notice the Type 7/5 translation highlighted in the Options section above.

Hint: The P-bit means “Propagate” bit.

The next highlighted section is the forward address, which is set to the e0/1 interface IP address of R4. According to the RFC on the OSPF NSSA option, if the P-bit is set, then the forward address must have a non-zero value (except for aggregated Type-7 LSAs). If the forwarding address is 0.0.0.0, then the P-bit must not be set which means the Type-7 LSA will not be translated to a Type-5 LSA.

Before we move on to other routers, I will like to discuss how the forwarding address is chosen. Like the forwarding address in Type-5 LSAs, if the interface that connects to the external AS is advertised into OSPF (via the network statement), then the address of the adjacent AS’s external gateway is used as the forwarding address. For example, if we advertise the 172.16.0.0/24 network into OSPF, then the forwarding address will be 172.16.0.6.

If this is not the case, then the router will pick either the highest IP address on its loopback interfaces (if they are part of the OSPF network statements) or the highest IP address on its OSPF-advertised physical interfaces if the Loopback interfaces are not available or advertised. In our case, 10.10.34.4 is the highest IP address of a physical interface and that’s why it was the forwarding address.

Note: I have left the configuration above where I advertised the 172.16.0.0/24 network; therefore, the forwarding address will be 172.16.0.6 from here on.

R4 advertises this Type-7 LSA to both R2 and R3 as shown below:

Since the P-bit is set in this LSA, it means both R2 and R3 will try to translate this Type-7 LSA to a Type-5 LSA. However, the translated Type-5 LSA will be the same (same destination, same cost, same non-zero forwarding address) which leads to duplication of effort. Therefore, there must be a way to determine which ABR will perform the Type-7 to Type-5 translation and this is the ABR with the higher Router ID.

Therefore, if we check R1 for the Type-5 LSA for 60.60.60.0/24, we will see that it was advertised by R3 – R3 has a Router ID of 3.3.3.3, which is higher than that of R2 (2.2.2.2):

Determining which ABR Performs Type-7 to Type-5 Translation

Above we already established that the ABR with the higher Router ID is responsible for translating Type-7 LSAs to Type-5 LSAs. We can view which ABR is performing the translation by looking at the output from the show ip ospf command.

As you can see, R3 is the one performing the Type-7/Type-5 LSA translation. However, instead of just relying on Router IDs, we can configure an ABR to always perform Type-7/Type-5 LSA translation using the area [area_ID] nssa translate type7 always command.

For example, if I configure this command on R2, R2 will now be the ABR performing the translation and not R3:

Hint: This command actually affects the NSSATranslatorState, as defined in the RFC. When configured, the Nt bit in the router LSA is set and the NSSATranslatorState becomes enabled.

Note: When both R2 and R3 are configured with this command, they will both perform the Type-7/Type-5 translation.

Same ABR Generates Type-5 and Type-7 LSA for the Same Network

According to the RFC, “When an NSSA border router originates both a Type-5 LSA and a Type-7 LSA for the same network, then the P-bit must be clear in the Type-7 LSA so that it isn’t translated into a Type-5 LSA by another NSSA border router.”

To see this in action, let’s change the R3-R4 link to a different area (not NSSA). On both R3 and R4, we will make the following configuration change:

router ospf 1
 no network 10.10.34.0 0.0.0.255 area 1
 network 10.10.34.0 0.0.0.255 area 2

With this change, R4 is now an ABR that will generate a Type-7 LSA (for Area 1) and a Type-5 LSA (for Area 2). Therefore, the P-bit will not be set on the Type-7 LSA meaning that R2 will not be performing any translation:

If we check R1, we will see that the Type-5 LSA is now advertised by 4.4.4.4 and R3 has also advertised a Type-4 LSA:

Preference between Two Type-7 LSA

Let’s alter our diagram a little to include another router, R5, which is also redistributing EIGRP routes into OSPF.

With this alteration, R2 will now be receiving two Type-7 LSAs, one from R5 and another from R4. The RFC specifies the following preference for two type-7 LSAs:

  1. An LSA with the P-bit set is preferred over one with the P-bit clear.
  2. If the P-bit settings are the same, the LSA with the higher router ID is preferred.

In our case, the LSA from R5 will have the P-bit set while the one from R4 will have the P-bit clear (see previous section); therefore, R2 will prefer the one from R5:

Hint: If you want to see the LSA from R4 installed on R2 instead of the one from R5, increase the Router ID of R4 (to something higher than R5’s) and also remove the “network 10.10.34.0 0.0.0.255 area 2” statement so that the LSA will have the P-bit set.

Summary

This brings us to the end of this article, in which we have looked at Type-7 to Type-5 LSA translation in detail. We have seen that when there are multiple NSSA ABRs, the one with the higher Router ID does the translation, although this default behavior can be changed. We also saw that when an ABR generates both a Type-5 and Type-7 LSA for the same network, then it clears the P-bit on the Type-7 LSA. Finally, we have seen the method by which one Type-7 LSA is preferred over another.

I hope you have found this article insightful and I look forward to writing more articles in the OSPF series.

References and Further Reading

  • RFC 2328: OSPF Version 2: https://tools.ietf.org/html/rfc2328
  • RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option: https://tools.ietf.org/html/rfc3101
  • ASBR in NSSA – Choosing what IP to use as forwarding address: http://lostintransit.se/2012/09/20/asbr-in-nssa-choosing-what-ip-to-use-as-forwarding-address/