The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
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.
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
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
Posted in Routing
Comments
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
February 27, 2009 at 1:28 a.m. UTC
Great article. Keep it up!
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.
February 28, 2009 at 2:10 a.m. UTC
Awesome article! The detailed, lengthy ones are great!
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
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
March 2, 2009 at 3:59 p.m. UTC
nice article, but with this solution you create another problem in the network: asymmetrical routing.
September 5, 2010 at 5:21 a.m. UTC
shef: asymmetrical routing is not a problem.. is a normal behavior in the internet world...
November 16, 2011 at 2:30 a.m. UTC
Awesome article! Clear my doubts completely! thanks for that!
February 3, 2013 at 8:18 a.m. UTC
HIIIIII this too good dude .. thanks you have cleared my concept.
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!
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.
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)