The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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.
Cisco recommends that you have basic knowledge of OSPF protocol.
The information in this document is based on these software and hardware versions:
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:
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#
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.