Home / Cisco R&S / Introduction to OSPF Forwarding Address Behaviour on Cisco IOS router

Introduction to OSPF Forwarding Address Behaviour on Cisco IOS router

Today I am going to talk about the concept of the forwarding address in OSPF protocol. When an OSPF router redistribute a route from another source protocol into OSPF as either E1 or E2, it can set a forwarding address in that particular external Link State Advertisement (LSA). The OSPF protocol must meet these conditions to be able to set that particular attribute. The forwarding address could be either populated (non-zero) or not populated (all zeros).

All these conditions must set the forwarding address field to a non-zero address:
  • OSPF is enabled on the Autonomous System Boundary Router (ASBR) of the next hop interface
  • ASBR's next hop interface is non-passive under OSPF
  • ASBR's next hop interface is not point-to-point
  • ASBR's next hop interface is not point-to-multipoint
  • ASBR's next hop interface address falls under the network range specified in the router ospf command.
When the forwarding address is set to all zeros (0.0.0.0), this means that the router must recurse to that particular node in the OSPF topology to correctly route traffic to the destination. 

A big difference with OSPF as a link-state routing protocol compared to the distance vector protocols is the link state enables it to have a full view of the topology in that particular area, router can calculate the shortest path to a node in the topology with an overall view of all devices and their costs. It does not necessarily route towards a prefix but to a node, which is a big difference.

When the forwarding address is set to a non-zero value, router checks what is the shortest path to that node which is connected to the forwarding address.

Fig 1.1- OSPF Forwarding Address
In the image above, Enhanced Interior Gateway Routing Protocol (EIGRP) runs between R2 and R3 on the shared segment 192.168.1.0/24. R1 is also connected to the shared segment 192.168.1.0/24, although there is no EIGRP. R2 is configured to redistribute 172.16.3.3/32 from EIGRP to OSPF as external E2 route. OSPF runs between R2 to R4, R1 to R4, R1 to Transit_Router and R4 towards XR5. XR5 router software is IOS-XR.

This section explains the importance of the forwarding address. Consider you have traffic goes towards 172.16.3.3/32 comes from the cloud network, this traffic arrives on the Transit_Router and it forwards as per the routing table.

Check what you have in the routing table of Transit_Router for prefix 172.16.3.3/32

Transit_Router# show ip route 172.16.3.3
Routing entry for 172.16.3.3/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 192.168.70.1 on GigabitEthernet1, 00:00:04 ago
  Routing Descriptor Blocks:
  * 192.168.70.1, from 2.2.2.2, 00:00:04 ago, via GigabitEthernet1        <- You see the prefix is from advertising router with router-id 2.2.2.2
      Route metric is 20, traffic share count is 1
Transit_Router#

The next-hop is 192.168.70.1 goes towards R1. Since R2 is redistributed the network 172.16.3.3/32 into OSPF you can assume that you must route towards R2 to get to destination 172.16.3.3/32.

You can run traceroute from Transit_Router towards 172.16.3.3/32.

Transit_Router# traceroute 172.16.3.3 timeout 1
Type escape sequence to abort.
Tracing the route to 172.16.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.70.1 7 msec 5 msec 8 msec           <- R1
  2 192.168.1.3 10 msec 11 msec 17 msec         <- R3

When R1 receives traffic destined to 172.16.3.3/32, it is actually routed directly towards R3. Run show ip route on R1 to see the routing table towards 172.16.3.3.

R1#show ip route 172.16.3.3
Routing entry for 172.16.3.3/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1
  Last update from 192.168.1.3 on GigabitEthernet0/0, 02:04:54 ago
  Routing Descriptor Blocks:
  * 192.168.1.3, from 2.2.2.2, 02:04:54 ago, via GigabitEthernet0/0    <-- Next-hop goes directly towards R3 over the shared segment
      Route metric is 20, traffic share count is 1

Because of the forwarding address, R1 has a next-hop of 192.168.1.3 goes towards R3, if you do not have any routing protocol between R1 and R3. Verify the external LSA on the Transit_Router.

Transit_Router# show ip ospf database external 172.16.3.3
  OSPF Router with ID (6.6.6.6) (Process ID 1)
  Type-5 AS External Link States
  LS age: 1641
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 172.16.3.3 (External Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000004
  Checksum: 0x8299
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 20
        Forward Address: 192.168.1.3      <-R3 interface towards the shared segment
        External Route Tag: 0

As you can see, the forwarding address is populated with an IP address of 192.168.1.3, which means if you want to route towards 172.16.3.3/32, you must recurse towards 192.168.1.3. This now implies that when R1 receives packets destined towards 172.16.3.3/32, it also has a Type-5 LSA for 172.16.3.3/32 with a forwarding address of 192.168.1.3 which is directly connected on Gi0/0 interface. Hence, R1 routes the packets towards 192.168.1.3.

The forwarding address assists in a way to mitigate suboptimal routing. If the forwarding address was not set on the Type-5 LSA, you need to route all packets destined to 172.16.3.3 via the ASBR which is R2.

To verify it, you can reset the forwarding address to 0.0.0.0 and run traceroute from the Transit_Router.

Transit_Router# show ip ospf database external 172.16.3.3
  OSPF Router with ID (6.6.6.6) (Process ID 1)
  Type-5 AS External Link States
  LS age: 14
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 172.16.3.3 (External Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000005
  Checksum: 0x196F
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 20
        Forward Address: 0.0.0.0    <- Recurse towards the ASBR (RID 2.2.2.2)
        External Route Tag: 0
Transit_Router#

You can see the forwarding address is set to 0.0.0.0 which as mentioned, it means you must now route packets to the ASBR which is R2. When you run a traceroute from Transit_Router destined towards 172.16.3.3, this traffic follows the path towards the ASBR R2.

Transit_Router# traceroute 172.16.3.3
Type escape sequence to abort.
Tracing the route to 172.16.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.70.1 17 msec 12 msec 3 msec     <-R1
  2 192.168.14.4 3 msec 18 msec 7 msec      <-R4
  3 192.168.24.2 15 msec 8 msec 5 msec      <-R2
  4 192.168.1.3 8 msec 11 msec 7 msec       <-R3
Transit_Router#