In this section I will look at who does the NSSA type 7 to 5 translation & how we can use the forwarding address to control routing towards external routes that have been brought into the OSPF domain via an NSSA. The topology we will use is below. Currently R4 is redistributing the 99.0.0.0/24 prefix into OSPF and all routers have reachability to it.

OSPF Forwarding Address With An NSSA & Two ABRs

In a network like above, only one ABR router connected to the NSSA is elected to do the LSA type 7 to 5 translation for the EIGRP route 99.0.0.0/24. The decision is based on who has the highest router-id. So if we look at the OSPF database for this external prefix on R1, we should see that the advertising router is R3 (3.3.3.3) because his router-id is higher than R2 (2.2.2.2) and therefore did the translation.

R1#sh ip ospf database external 99.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: 222
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 99.0.0.0 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0xE31D
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.0.34.4
External Route Tag: 0
The output confirms that R3 (3.3.3.3) has done the type 7 to 5 translation. So if we were to make R2’s RID higher than 3.3.3.3, then R2 would be the router who does the type 7 to 5 translation. Let’s do that now.

R2(config-router)#router-id 255.0.0.2
Reload or use “clear ip ospf process” command, for this to take effect
R2(config-router)#do clear ip ospf process
Reset ALL OSPF processes? [no]: yes
Let’s check that same ospf database output on R1 to check if the advertising router has now changed.

R1#sh ip ospf database external 99.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: 1
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 99.0.0.0 (External Network Number )
Advertising Router: 255.0.0.2
LS Seq Number: 80000003
Checksum: 0x2EDA
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.0.34.4
External Route Tag: 0
And it has, R2 (255.0.0.2) is how the router who did the translation.

Let’s move on to talking about the forwarding address. In short, it’s just an IP address that should be used to solve the shortest path to an external prefix instead of solving the shortest path to the node who advertised the prefix. In the output above, R2 has told R1 to go via 10.0.34.4 to reach 99.0.0.0/24. So now it’s just a matter of checking R1’s best path to 10.0.34.4. And from the routing table we can see that we can reach it via R3.

R1#sh ip route 10.0.34.4
Routing entry for 10.0.34.0/24
Known via “ospf 1”, distance 110, metric 20, type inter area
Last update from 10.0.13.3 on FastEthernet0/1, 00:08:37 ago
Routing Descriptor Blocks:
* 10.0.13.3, from 3.3.3.3, 00:08:37 ago, via FastEthernet0/1
Route metric is 20, traffic share count is 1
I guess the only thing I have to clarify so far is why the forwarding address was actually set to 10.0.34.4 in the first place. Well the forward address is always decided by the ASBR, in this case R4. The forward address is actually elected a lot differently to how it’s described in this link for my specific scenario. The reason why, is because usually you would be receiving external prefix from another router (as opposed to actually redistributing an EIGRP prefix into OSPF where that external prefix actually exists on the ASBR itself – as in my network). And this is where a lot of the confusion on the internet comes from. Loads of people say that they can get a non-zero forwarding address when the OSPF network type is point-to-point for that interface. Well yes you can, and in my network you can too. But if, say another router ,R5, was advertising this 99.0.0.0/24 route towards R4, and then R4 redistributes it into OSPF, then this is where the requirements in the Cisco documentation comes into play.

To work out what IP is actually used as the forward address in my scenario, it’s actually not documented anywhere by Cisco, however some of the steps are listed in the RFC 3101:

“When a router is forced to pick a forwarding address for a Type-7 LSA, preference should be given first to the router’s internal addresses (provided internal addressing is supported). If internal addresses are not available, preference should be given to the router’s active OSPF stub network addresses. These choices avoid the possible extra hop that may happen when a transit network’s address is used. When the interface whose IP address is the LSA’s forwarding address transitions to a Down state (see [OSPF] Section 9.3), the router must select a new forwarding address for the LSA and then re- originate it. If one is not available the LSA should be flushed.”

FYI, when it talks about internal addresses, it is referring to loopback addresses. Anyway, Cisco have met these requirements, but made it more specific. So this is the actual order that it is done in.

1. Newest OSPF enabled loopback interface IP address (note: On some IOS platforms it’s actually the oldest loopback IP)

2. Newest OSPF enabled non-loopback interface IP address that is connected to a transit stub network

3. Newest OSPF enabled non-loopback interface IP address that is connected to a non-transit stub network

To see how I proved this you can visit a discussion I made on the IEOC forum as it’s quite long winded . However, in this scenario, I’m just going to show an example of how the first bullet point is true, where enabling OSPF on a loopback interface takes priority over any OSPF enabled non-loopback interfaces.

So if we look at the output below on R4 below, we can see that currently we have two non-loopback interfaces enabled with OSPF. The forwarding address that is currently being used for the external prefix is 10.0.34.4 & this is because it was the newest OSPF enabled interface I created.

R4#sh ip ospf int brief
Interface PID Area IP Address/Mask Cost State Nbrs F/C
Fa0/0 1 1 10.0.34.4/24 10 DR 1/1
Fa0/1 1 1 10.0.24.4/24 10 DR 1/1
I want to just confirm that what I’ve said so far is actually true. Where, in order for R1 to reach the external prefix 99.0.0.4, he must use the best path to the forward address (10.0.34.4) in order to get to the destination. And we can see this from a simple traceroute.

R1#traceroute 99.0.0.4

Type escape sequence to abort.
Tracing the route to 99.0.0.4

1 10.0.13.3 20 msec 48 msec 44 msec
2 10.0.34.4 48 msec 96 msec 60 msec
So now here comes the first way we can manipulate the path. Since we know the path to the external network is always via the forwarding address, let’s change what the forwarding address is on R4. From the order of which the forward IP address election works, I know that any OSPF enabled loopback interface beats any physical OSPF enabled interface IP, so let’s configure a loopback IP on R4 and advertise it into the NSSA.

R4(config)#int lo10
R4(config-if)#ip ospf 1 area 1
R4(config-if)#ip address 100.0.0.1 255.255.255.0
R4(config-if)#ip ospf network point-to-point
Now if we check the ospf database on R1, I expect the foward address to change to this loopback IP.

R1#sh ip ospf database external 99.0.0.0

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

Type-5 AS External Link States

Delete flag is set for this LSA
LS age: MAXAGE(3606)
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 99.0.0.0 (External Network Number )
Advertising Router: 255.0.0.2
LS Seq Number: 80000005
Checksum: 0xFCC
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 16777215
Forward Address: 100.0.0.1
External Route Tag: 0
And it does. And since the cost to this new network is now the same via R2 or R3 (as I haven’t changed any interface costs), I expect R1 to have two equal cost routes towards 100.0.0.1 in the routing table.

R1#sh ip route 100.0.0.1
Routing entry for 100.0.0.0/24
Known via “ospf 1”, distance 110, metric 21, type inter area
Last update from 10.0.13.3 on FastEthernet0/1, 00:00:18 ago
Routing Descriptor Blocks:
10.0.13.3, from 3.3.3.3, 00:00:18 ago, via FastEthernet0/1
Route metric is 21, traffic share count is 1
* 10.0.12.2, from 255.0.0.2, 00:00:18 ago, via FastEthernet0/0
Route metric is 21, traffic share count is 1
So now when we send traffic to 99.0.0.4, traffic is load shared between R2 and R3, as shown below.

R1#traceroute 99.0.0.4

Type escape sequence to abort.
Tracing the route to 99.0.0.4

1 10.0.13.3 28 msec
10.0.12.2 48 msec
10.0.13.3 48 msec
2 10.0.24.4 124 msec
10.0.34.4 76 msec
10.0.24.4 128 msec
Ok so that’s one way we can traffic engineer the path to 99.0.0.0/24; by manipulating the forwarding address. What about another way? What about if in the CCIE lab exam they have the network setup like I do now with the traffic being load shared between R2 and R3, and they say that you must get R1 to prefer the path via R2 only? There would be a couple of options. We could change the metric towards the 10.0.34.4 so that the path via R3 is worse than the path via R2. And that is probably the easiest fix. But what about if the question also said that we are also not allowed to manually change the metric in any way, shape or form? We could do something like this:

R2(config)#router ospf 1
R2(config-router)#area 1 nssa translate type7 always suppress-fa
What I’ve done here is forced R2 to do the type7 to type 5 translation using the keywords “type7 always”. This is just to ensure that R3 could never do the the type 7 to 5 translation in the event R3 created a higher OSPF router-id than R2 (so technically we don’t really need this for this solution but it’s a good command to be aware of). I’ve also forced R2 to set the forward address to 0.0.0.0 using the “suppress-fa” command (and this is key to the solution). So let’s check this on R1’s ospf database.

R1#sh ip ospf database external 99.0.0.0

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

Type-5 AS External Link States

LS age: 9
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 99.0.0.0 (External Network Number )
Advertising Router: 255.0.0.2
LS Seq Number: 80000001
Checksum: 0x9F95
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
So now traffic towards 99.0.0.4 must go towards R2 because the forward address is now 0.0.0.0. A simple traceroute can now confirm that R1 is now choosing the best path via R2.

R1#traceroute 99.0.0.4
Type escape sequence to abort.
Tracing the route to 99.0.0.4
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.12.2 4 msec 1 msec 1 msec
2 10.0.24.4 5 msec * 2 msec