Making use of OSPF forwarding addresses

By stretch | Wednesday, February 25, 2009 at 12:19 a.m. UTC

The topology below illustrates an OSPF network which is in the process of peering with a new partner network. Routers 2 and 3 connect the OSPF domain (10.0.0.0/16) to the partner network (172.16.0.0/16) via eBGP. Both physical uplinks are active, but unfortunately only one eBGP session has been configured so far (between R1 and R2) with the second due to be completed in a couple weeks.

topology.png

Although functional, this topology doesn't make use of R3's connection to the partner network, since only R2 has a BGP adjacency and thus is the only OSPF router redistributing a route for 172.16.0.0/16. We can see below that if R3 (or any other OSPF router in the cloud) needs to send traffic to R1, the only path is via R2.

R3# show ip route 172.16.0.0
Routing entry for 172.16.0.0/16
  Known via "ospf 1", distance 110, metric 1
  Tag 65100, type extern 2, forward metric 20
  Last update from 10.0.34.4 on FastEthernet0/1, 00:08:50 ago
  Routing Descriptor Blocks:
  * 10.0.34.4, from 192.168.0.2, 00:08:50 ago, via FastEthernet0/1
  Route metric is 1, traffic share count is 1
  Route tag 65100

flow1.png

Fortunately, OSPF provides a workaround mechanism for just such a situation. An OSPF router can set the forwarding address of a route to something other than itself to indicate an alternate next-hop. In most cases, the forwarding address is left null (0.0.0.0), suggesting that the route is reachable only via the advertising router. This is currently the case with our 172.16.0.0/16 route, as we can see:

R3# show ip ospf database external 172.16.0.0

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

Type-5 AS External Link States

Routing Bit Set on this LSA
  LS age: 786
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 172.16.0.0 (External Network Number )
  Advertising Router: 192.168.0.2
  LS Seq Number: 80000001
  Checksum: 0xD768
  Length: 36
  Network Mask: /16
    Metric Type: 2 (Larger than any link state path)
    TOS: 0 
    Metric: 1 
    Forward Address: 0.0.0.0
    External Route Tag: 65100

Several conditions must be met for a forwarding address to be set in an LSA, as outlined in this document by Cisco. Essentially, the advertising router must have an OSPF adjacency on the next-hop interface, and it must be a multiaccess adjacency (not point-to-point or point-to-multipoint). This is to ensure there is at least one other router within the OSPF domain which is directly connected to the next hop router; otherwise, there would be no reason to include the forwarding address.

Returning to our topology, we realize that we can implement an OSPF adjacency between R2 and R3 across the 192.168.0.0/24 backbone link without coordinating with our partner. This should trigger R2 to begin including the forwarding address for R1 in it's 172.16.0.0 LSA.

R2(config)# interface f0/0
R2(config-if)# ip ospf 1 area 0
R3(config)# interface f0/0
R3(config-if)# ip ospf 1 area 0

Double-check to ensure our R2-R3 adjacency is formed across the 192.168.0.0/24 subnet:

R2# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.0.3       1   FULL/DR         00:00:39    192.168.0.3     FastEthernet0/0
10.0.34.4         1   FULL/BDR        00:00:35    10.0.24.4       FastEthernet0/1

Now let's have another look at the LSA for 172.16.0.0/16 (note that because identical copies of an LSA are stored on all routers in the OSPF domain, it really doesn't matter which we check):

R3# show ip ospf database external 172.16.0.0

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

Type-5 AS External Link States

Routing Bit Set on this LSA
  LS age: 586
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 172.16.0.0 (External Network Number )
  Advertising Router: 192.168.0.2
  LS Seq Number: 80000002
  Checksum: 0x14C0
  Length: 36
  Network Mask: /16
    Metric Type: 2 (Larger than any link state path)
    TOS: 0 
    Metric: 1 
    Forward Address: 192.168.0.1
    External Route Tag: 65100

Aha! Where the forwarding address was previously null, R2 is now setting it to the next-hop address (R1). And, because R3 has a direct connection to 192.168.0.1, it can now forward traffic destined for 172.16.0.0/16 directly to R1:

R3# show ip route 172.16.0.0
Routing entry for 172.16.0.0/16
  Known via "ospf 1", distance 110, metric 1
  Tag 65100, type extern 2, forward metric 10
  Last update from 192.168.0.1 on FastEthernet0/0, 00:11:08 ago
  Routing Descriptor Blocks:
  * 192.168.0.1, from 192.168.0.2, 00:11:08 ago, via FastEthernet0/0
  Route metric is 1, traffic share count is 1
  Route tag 65100

flow2.png

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Routing

Comments


yapchinhoong (guest)
February 26, 2009 at 5:31 a.m. UTC

Hi stretch, how coincident is this. :) I notice this these few days as well. :) BTW, you don't need to run a routing protocol to demo this, just a static route and redistribute it into OSPF will do.

BTW, EIGRP should achieve the similar thing in the Next Hop field in their IP internal and external routes TLVs, but it is always having 0.0.0.0 in my POC and I have opened a TAC case for this. lolz


Ron (guest)
February 27, 2009 at 1:28 a.m. UTC

Great article. Keep it up!


B (guest)
February 27, 2009 at 2:43 a.m. UTC

Great article. One thing though, R2 and R3 don't need to have an adjacency. All that matter is that the ASBR (R2) has that interface in OSPF. In this case, enabling OSPF on R2's 192.168.0.2 interface is enough for it to include the Forward Address.


ibarrere (guest)
February 28, 2009 at 2:10 a.m. UTC

Awesome article! The detailed, lengthy ones are great!


shivlu jain (guest)
February 28, 2009 at 3:14 p.m. UTC

Awesome Article.
Can we say the role played by forwarding address in case of external routes. Link

regards
shivlu jain


shivlu jain (guest)
February 28, 2009 at 3:20 p.m. UTC

yapchinhoong

The forwarding adrress is 0.0.0.0 only in that case when the ASBR is advertsing the route and the OSPF cost is calculated to that ASBR only but in case if you get the ip address instead of 0.0.0.0 in that case the cost will be considered till that ip addres.

regards
shivlu jain


shef (guest)
March 2, 2009 at 3:59 p.m. UTC

nice article, but with this solution you create another problem in the network: asymmetrical routing.


Melvin Reyes (guest)
September 5, 2010 at 5:21 a.m. UTC

shef: asymmetrical routing is not a problem.. is a normal behavior in the internet world...


po3a (guest)
November 16, 2011 at 2:30 a.m. UTC

Awesome article! Clear my doubts completely! thanks for that!


sanjay (guest)
February 3, 2013 at 8:18 a.m. UTC

HIIIIII this too good dude .. thanks you have cleared my concept.


Zaheer (guest)
November 19, 2013 at 2:28 a.m. UTC

Awesome stretch!! Very good demonstration.

I have couple of questions if you don't mind though, let's say if there are R4 and R5 connected to R2/R3 respectively, then LSA type5 will go to R4/R5 with forwarding address 0.0.0.0? And what will happen if/when we (do and don't) advertise link between R1/R2 as Intra and/or Inter-area route (to R4/R5), actual forwarding address (192.168.0.1) or 0.0.0.0 address will be forwarded? and do we still need Type4s (across the ABR if R4/R5 get as Type5)? Any thoughts, I will also try to lab it by myself.

Thanks again!


gellert (guest)
March 8, 2014 at 1:34 p.m. UTC

Good article. But it's not necessary to form adjacency between R2 and R3, you can simply enable OSPF on R2's ethernet interface and that would be enough.


Ananth (guest)
October 26, 2015 at 10:38 a.m. UTC

Good article and Great questions

Asymmetrical routing is not a problem as long as firewalls and WAN optimizers etc are not involved.

If you have a router R4 in OSPF domain, connected to R2. If R4 have the Forwarding Address (FA) as 0.0.0.0 no issues.

But let’s say R4 have the Forwarding Address (FA) as 192.168.0.1 for the external route 172.16.0.0/16.

Then 1) R4 will accept 172.16.0.0/16 in its OSPF Database & install in its Routing table as long as FA 192.168.0.1 is known as an intra-area route. (OSPF enabled on 192.168.0.0/24)

2) R4 will accept 172.16.0.0/16 in its OSPF Database but it will NOT install 172.16.0.0/16 in the Routing table if FA 192.168.0.1 known as an external route. (for example 192.168.0.0/24 is redistributed into OSPF)

Comments have closed for this article due to its age.