Compare OSPF Forwarding Address Behaviour on IOS and IOS-XR

Introduction

This document describes the concept of the Open Shortest Path First (OSPF) forwarding address on IOS-XR and IOS devices. It compares the OSPF behaviour between IOS-XR and IOS devices.

Prerequisites

Requirements

Cisco recommends that you have basic knowledge of OSPF protocol.

Components Used

The information in this document is based on these software and hardware versions:

• IOS-XR virtual device versions: 6.1.3, 6.1.2, 6.0.0, 5.3.0, 5.2.0
• Cisco IOS platforms

OSPF Forwarding Address

This section discusses the concept of the forwarding address in OSPF, if you are already familiar with this you can proceed to the next section.

When an OSPF router redistributes 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.
• Any other conditions besides these, sets the forwarding address to 0.0.0.0.

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.

This section review the topology for further clarification:

Image 1

In the image 1,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.

This can be seen here: 

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#

Differences between IOS and IOS-XR

This section describes a difference between IOS and IOS-XR devices when you know the forwarding address via another source. 

In IOS when you have an OSPF external route in the database and the forwarding address is set, the forwarding address must be known via OSPF inter or intra area route. If the forwarding address is not known via either OSPF intra or inter area route, router does not install the external OSPF route into Routing Information Base (RIB).

Verify what happens when you configure the forwarding address to be known via a static route.

Image 2

In the image 2 topology, R2 is configured as a redistribution point between EIGRP and OSPF. Router redistributes 172.16.3.3/32 from EIGRP into the OSPF domain. You can check on both R4 and XR5 to ensure what the differences are when the forwarding address is known via another source. The OSPF database on R4 is shown here.

R4# show ip ospf database external 172.16.3.3

            OSPF Router with ID (4.4.4.4) (Process ID 1)
                Type-5 AS External Link States
  LS age: 4
  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: 80000002
  Checksum: 0x8697
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 20
        Forward Address: 192.168.1.3
        External Route Tag: 0

 Check how you route to the forwarding address.

R4# show ip route 192.168.1.3
Routing entry for 192.168.1.0/24
  Known via "ospf 1", distance 110, metric 2, type intra area      <- Here you see it is know via OSPF intra area 
  Last update from 192.168.24.2 on GigabitEthernet0/0, 00:00:23 ago
  Routing Descriptor Blocks:
    192.168.24.2, from 1.1.1.1, 00:00:23 ago, via GigabitEthernet0/0
      Route metric is 2, traffic share count is 1
  * 192.168.14.1, from 1.1.1.1, 00:04:42 ago, via GigabitEthernet0/1
      Route metric is 2, traffic share count is 1

R4#

As you can see the router learns the forwarding address via intra area route which means it can install the external LSA in RIB. You can see the external LSA is installed in RIB.

R4#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.24.2 on GigabitEthernet0/0, 00:01:02 ago
  Routing Descriptor Blocks:
    192.168.24.2, from 2.2.2.2, 00:01:02 ago, via GigabitEthernet0/0
      Route metric is 20, traffic share count is 1
  * 192.168.14.1, from 2.2.2.2, 00:04:57 ago, via GigabitEthernet0/1
      Route metric is 20, traffic share count is 1

Configure a static route for the forwarding address goes towards the ASBR which is R2

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#ip route 192.168.1.0 255.255.255.0 192.168.24.2 

Run show ip route toward the forwarding address.

R4# show ip route 192.168.1.3
Routing entry for 192.168.1.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 192.168.24.2
      Route metric is 0, traffic share count is 1

As you can see the forwarding address is not learnt via OSPF but static, which means that now the external LSA for 172.16.3.3 can not pass the necessary criteria to be used.

R4#show ip ospf database external 172.16.3.3

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

                Type-5 AS External Link States

  LS age: 480
  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: 80000001
  Checksum: 0x8896
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 20
        Forward Address: 192.168.1.3
        External Route Tag: 0

Finally, check if the external route is installed from OSPF database into RIB.

R4#show ip route 172.16.3.3
% Network not in table

As you can see, the router does not install the external LSA from OSPF database into RIB, because the forwarding address is known via static and not OSPF intra or inter-area.

The logic here is that OSPF doesn't consider another source for routing towards the forwarding address as trustworthy, hence router must not take any external LSA which has a forwarding address not known via OSPF into account.

This section describes the same test on IOS-XR to verify the behaviour. On XR5, you have the external LSA:

 RP/0/0/CPU0:XR4#show ospf database external 172.16.3.3
Mon Mar 26 06:26:24.656 UTC


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

                Type-5 AS External Link States
 
  Routing Bit Set on this LSA
  LS age: 930
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 172.16.3.3 (External Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x8896
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 192.168.1.3
        External Route Tag: 0

Check when you configure a static route for the forwarding address towards R4 whether router install the external LSA into the database or not.

RP/0/0/CPU0:XR4#show route 192.168.1.3
Mon Mar 26 06:33:21.587 UTC
Routing entry for 192.168.1.0/24
  Known via "static", distance 1, metric 0    <- The forwarding address is now known via static
  Installed Mar 26 06:31:55.133 for 00:01:26
  Routing Descriptor Blocks
    192.168.60.4          <- Next-hop is R4
      Route metric is 0, Wt is 1
  No advertising protos.

You can see the forwarding address is learnt via static. Now, verify if the external LSA was installed into RIB.

RP/0/0/CPU0:XR4#show route 172.16.3.3
Mon Mar 26 06:42:24.830 UTC
Routing entry for 172.16.3.3/32
  Known via "ospf 1", distance 110, metric 20, type extern 2
  Installed Mar 26 06:25:09.841 for 00:17:15
  Routing Descriptor Blocks
    192.168.60.4, from 2.2.2.2, via GigabitEthernet0/0/0/0
      Route metric is 20
  No advertising protos.
RP/0/0/CPU0:XR4#

You can see a difference between IOS and IOS-XR. The External LSA was installed in RIB even though the forwarding address is learnt via static. The router still have the connectivity towards the external prefix.

RP/0/0/CPU0:XR4#ping 172.16.3.3
Mon Mar 26 06:44:25.772 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/19 ms
RP/0/0/CPU0:XR4#

It seems that IOS-XR populates the external LSA into RIB but doesn’t take into account the forwarding address for recursion, which now means it recurse towards the ASBR rather than lookup into RIB for the forwarding address.

The test gives you an indication that it can be considered. You can configure a static route for the forwarding address towards null0 and check if the connectivity towards the external prefix is still exist.

RP/0/0/CPU0:XR4#show ospf database external 172.16.3.3

Mon Mar 26 06:55:36.296 UTC
            OSPF Router with ID (192.168.60.1) (Process ID 1)
                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 667
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 172.16.3.3 (External Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0x8697
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 192.168.1.3
        External Route Tag: 0

RP/0/0/CPU0:XR4#show route 192.168.1.3

Mon Mar 26 06:55:38.966 UTC

Routing entry for 192.168.1.0/24
  Known via "static", distance 1, metric 0 (connected)
  Installed Mar 26 06:47:15.030 for 00:08:23
  Routing Descriptor Blocks
    directly connected, via Null0
      Route metric is 0, Wt is 1
  No advertising protos.
 

Check connectivity from XR5 towards 172.16.3.3.

RP/0/0/CPU0:XR4#ping 172.16.3.3
Mon Mar 26 06:56:45.261 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/7/19 ms
RP/0/0/CPU0:XR4#traceroute 172.16.3.3
Mon Mar 26 06:56:51.251 UTC
 
Type escape sequence to abort.
Tracing the route to 172.16.3.3
 1  192.168.60.4 0 msec  0 msec  0 msec
 2  192.168.14.1 0 msec  0 msec  0 msec
 3  192.168.1.3 9 msec  9 msec  0 msec
RP/0/0/CPU0:XR4 

In these tests, you saw the importance of the forwarding address and how to interpret routing when it is set. Also, the assumption that if the forwarding address is set, it must be used, can be false as it depends on the platform. When the forwarding address is known via OSPF intra/inter area, it is used, otherwise it is populated but not used for recursion. The behaviour on XR gives a level of reassurance, in the case an external LSAs forwarding address becomes known via another source, the traffic can not be blackholed.