There seems to be a lot of confusion on the web about what the OSPF forwarding address is. So Ive decided to create a lab to show its purpose and how it works.
In this lab I used the topology below to create the scenario in which it was designed for. The actual use case was for BGP instead of EIGRP, but my IOS image was crap & didnt support BGP, so I could only use EIGRP for this lab (however, the principle is exactly the same).
R1, R2 and R3 have interfaces in OSPF area 0. R2 & R3 also have an OSPF relationship in Area1 over the LAN segment connecting to the switch. But only R2 is running EIGRP with R4.
OSPF Forwarding AddressIn this scenario (before ospf was actually modified by the people who created the protocol to allow a non-zero value for the forwarding address) only R2 does the redistribution between EIGRP and OSPF. What this means is that all routers (including R3) have to go via R2 in order to reach 200.1.1.1. The reason why is because R2 advertises that in order to reach 200.1.1.1/32 everyone must solve the shortest path to me (the ASBR), and then R2 knows the shortest path to the destination.
So when this issue was pointed out to John Moy (one of the OSPF engineers), he sat down and figured that providing all links are of equal bandwidth in this network, wouldnt it be better if R3 just went directly towards R4 to reach 200.1.1.1/32 instead? Since all R2 is going to do is send the traffic to the next hop IP (10.0.100.4) that is on the same Ethernet segment as R3 anyways, it doesnt seem logical that R3 should have to take a path via R2 first. The engineers then decided to then change OSPF so that R2 could just say that to reach 200.1.1.1, just solve the shortest path to 10.0.100.4 instead. We will take a look at how this is achieved in the lab in just a moment. But I want you to know is that this was original reason for allowing the forwarding to be changed.
Lets first see a demonstration of how the actual problem was initially reported. First lets check how R3 solves the shortest path to 200.1.1.1 by looking at the external LSA.
R3#sh ip ospf database external 200.1.1.1
OSPF Router with ID (3.3.3.3) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 740
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 200.1.1.1 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 80000006
Checksum: 0x4E79
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
The output shows that to reach this prefix, R3 must solve the shortest path to the ASBR 2.2.2.2. The reason why, is because the forward address is set to 0.0.0.0, which means that R3 must solve the shortest path to the advertising router, and in this case that is 2.2.2.2.
R3 actually knows two paths to reach R2, one via Area 0 and one via Area 1. But since all links in this network have a cost of 10 (thats just how Ive set this network up), it means the cost to reach R2 via Area 0 would be 20 (as its 2 hops away), and the cost to reach R2 via Area 1 would be 10 (as it is one hop away). So if we look at the self-originated router LSAs on R3, we should see an LSA that advertises reachability to R2 via Area1.
R3#sh ip ospf database router self-originate | b Area 1
Router Link States (Area 1)
LS age: 728
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 3.3.3.3
Advertising Router: 3.3.3.3
LS Seq Number: 8000000B
Checksum: 0x17EE
Length: 48
Area Border Router
Number of Links: 2
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 2.2.2.2
(Link Data) Router Interface address: 10.0.100.3
Number of TOS metrics: 0
TOS 0 Metrics: 10
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.0.100.0
(Link Data) Network Mask: 255.255.255.0
Number of TOS metrics: 0
TOS 0 Metrics: 10
…output omitted!
The output shows us that R3 has a point-to-point link to router 2 (2.2.2.2) via the interface configured with the IP 10.0.100.3. So R3 has now solved the shortest path to 200.1.1.1 via R2. And we can confirm this by doing a traceroute to the external destination.
R3#traceroute 200.1.1.1
Type escape sequence to abort.
Tracing the route to 200.1.1.1
1 10.0.100.2 72 msec 32 msec 32 msec
2 10.0.100.4 48 msec 44 msec 32 msec
Next lets look at how OSPF was modified to allow R3 to route directly to R4 to reach 200.1.1.1. The way it is achieved is by changing the forwarding address from 0.0.0.0, to 10.0.100.4. So instead of trying to solve the shortest path towards R2 in order to reach the destination, R3 will now solve the shortest path to 10.0.100.4 instead (thus avoiding R2 all together). Specifically, from the Cisco documentation, it states that in order to use a non-zero value for the forwarding address, the requirements below must be met:
OSPF is enabled on the ASBRs next hop interface AND
ASBRs next hop interface is non-passive under OSPF AND
ASBRs next hop interface is not point-to-point AND
ASBRs next hop interface is not point-to-multipoint AND
ASBRs next hop interface address falls under the network range specified in the router ospf command.
Any other conditions besides the above set the forwarding address to 0.0.0.0.
In my network, the only thing I need to do in order to meet these requirements is just change the OSPF network type in area 1 to broadcast (as it is currently P2P between R2 and R3).
R2(config)#int fa0/0
R2(config-if)#no ip ospf network point-to-point
R3(config)#int fa0/0
R3(config-if)#no ip ospf network point-to-point
R3(config-if)#end
As the interfaces are Ethernet, the default network type is broadcast, which means that by removing the P2P command it will default the interfaces to the broadcast network type. So now lets check that Type 5 LSA again on R3.
R3#sh ip ospf database external 200.1.1.1
OSPF Router with ID (3.3.3.3) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 157
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 200.1.1.1 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 80000007
Checksum: 0xC48
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 10.0.100.4
External Route Tag: 0
The difference here is that the forward address has now been set to a non-zero value. Its been set to R4s interface IP. This means that R3 must now solve the shortest path to 10.0.100.4 instead of the advertising router R2 (2.2.2.2). Since this IP is on R3s directly connected segment in area 1, it means that R3 will have already solved the shortest path to 10.0.100.4. And we can check this by looking at R3s self-generated router LSA for it.
R3# sh ip ospf database router self-originate | b Area 1
Router Link States (Area 1)
LS age: 644
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 3.3.3.3
Advertising Router: 3.3.3.3
LS Seq Number: 80000017
Checksum: 0xE428
Length: 36
Area Border Router
Number of Links: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.0.100.3
(Link Data) Router Interface address: 10.0.100.3
Number of TOS metrics: 0
TOS 0 Metrics: 10
…output omitted!
In this case the output says that we know about this path via a designated router 10.0.100.3. And the DR has stated the the metric to reach the forwarding address is actually 10. Since the DR is actually R3 itself in this case, it means that the actual forward metric to reach the forwarding address is just 10. We can see this by checking the routing table.
R3#sh ip route 200.1.1.1
Routing entry for 200.1.1.1/32
Known via “ospf 1”, distance 110, metric 20, type extern 2, forward metric 10
Last update from 10.0.100.4 on FastEthernet0/0, 00:11:03 ago
Routing Descriptor Blocks:
* 10.0.100.4, from 2.2.2.2, 00:11:03 ago, via FastEthernet0/0
Route metric is 20, traffic share count is 1
So now when R3 attempts to send traffic to 200.1.1.1, it should just go directly via R4 instead of via R2. The traceroute below confirms it.
R3#trace 200.1.1.1
Type escape sequence to abort.
Tracing the route to 200.1.1.1
1 10.0.100.4 12 msec 24 msec 16 msec