ccie blog

Understanding The OSPF Forwarding Address

There seems to be a lot of confusion on the web about what the OSPF forwarding address is. So I’ve 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 & didn’t 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 modified 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, wouldn’t 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 doesn’t 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.

Let’s 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 (that’s just how I’ve set this network up), it means the cost to reach R2 via Area 0 would be 20 (as it’s 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 let’s 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 ASBR’s next hop interface AND
  • ASBR’s next hop interface is non-passive under OSPF AND
  • ASBR’s next hop interface is not point-to-point AND
  • ASBR’s next hop interface is not point-to-multipoint AND
  • ASBR’s 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 let’s 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. It’s been set to R4’s 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 R3’s 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 R3’s 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

5 Comments

AshutoshOctober 9th, 2015 at 5:27 am

Awesome, Very helpful. Thanks for your blogs.

CsillaOctober 27th, 2015 at 9:03 am

Nice one 😉 Very detailed article. Good luck for your studies.

StephenGarbettNovember 7th, 2015 at 6:54 pm

Hey Csilla, is that you from CACI?

SubrataJune 6th, 2016 at 9:52 am

this is great. simple and to the point. thanks

abdo refkyAugust 13th, 2016 at 9:28 am

very good .. the history part is also great to make us remeber why it work that way.

Leave a comment

Your comment