Forward-Address not equal = 0.0.0.0 ( the why? )

I've been helping  trouble-shooting some  weird ospf E1 external networks issues over the last 2 days, and found something interesting that I would like to share.

1st

after identifying the problem  of  additional metric-cost for type Ext1 ospf routes. I started scratching my head , & checked to see if cisco had anything posted and found this article. This link explain a little bit of the same thing that I encountered with a client of mine.


http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080124c7d.shtml

( i'm highlighting the following from the above link  )

Note: Router 3 and Router 4 do not include network 172.16.3.0 255.255.255.0 in the OSPF process; therefore, the type 5 LSAs generated by both routers have the forwarding addresses set to 0.0.0.0


Keep the above in mind as you continue to read this post.

The normal behavior for any ospf redistributed routes, is to install these as External-type2 . By default the asbr that originates the redistribution does  this regardless if it was statical or from another dynamic routing protocol ( i.e BGP, EIGRP, rip, etc,)

These routes will be listed in the ospf database  ( external ) with the forward-address set to 0.0.0.0 if NO network statement matches the next-hop of the redistributed routes within the "router ospf" .


BUT

If you have any network statements that matches the next-hop of the route to be installed within that  ASBR, it will populate the Forward Address entry  &  with that value of the next-hop and your metric is now computed as following ;

redistribute-metric-cost  + cost-2-the-forward_address + link-cost for external-type 1.

okay let demonstrate this concept, once you see it executed it would be quite clear. Keep in mind, this is more of an issues with E1 type routes. Without knowing the above, you could be chasing your tail around in circles with regards to weird metric or your routing not as optimized as what you wanted or expected.

Here's my  OSPF topology;

R1+R2 are receiving the redistributed route via Ospf As a E1 route. All three routers are in area 0.0.0.0



R3 configuration:

R2 configuration:

R1 configuration:

Let's look at the ospf database as it stands now & for  the 192.0.2.0/24 prefix.

1st up:


R1 & R2

Notice the  Forward Address   =   0.0.0.0 ?


2nd

If we change the  configuration on R3 by adding a network statement that matches the  next-hop of 50.50.50.2, than the forward address will be  changed in our ospf database;


Here's R3 new configuration ( nothing was changed on R1 or R2 btw  )

And let's take a new  look at the both ospf database on r1 and r2.

Notice how we now have a Forward_Address that's not 0.0.0.0 & equals the next-hop address ? The ospf metric will now reflect this change as well.

B4 we modified the network statements here's how our ospf route table looked for the 192.0.2.0/24;

show ip route 192.0.2.1

After the network statement was entered;


show ip route 192.0.2.1

The over all end2end metric was increased because of the forward_address included in the cost analysis.


Keep these thoughts in mind when using E1 types in your ospf redistributions ?

• This is mainly a big issues if you use E1 vrs E2 external ospf routes

• The Forward Address,  is changed if you used E2 ( the default redistribution type ) and the same for E1, if you have a network statement entry that matches the next-hop

• The Froward Address cost is NOT calculated in E2 type of redistributions

NOTE: This diagnostics was kinda of interesting, and similar to what you will find in a CCIE R/S lab. So if your dusty in your OSPF skills, you might want  lab some examples or explore  OSPF  and with redistributions methods and concepts.


For reference, I'm going to show the difference of the ospf database and route table once we redistribute  the same  static route, but this time as an External-Type 2.

R3 new configuration ( nothing was changed in R1 or R2 configurations ):

( btw default redistribution type = E2 )

R1 & R2  ospf database  + route table ;

( with the network statement under  my router ospf  )

R1 & R2  ospf database  + route table ;

( without  the network statement  on R3)

I underlined a something in the last displayed snapshot from above.

• When you see the "forward metric" in any  external ospf route display, that means it's a E2 route and that would be the cost to the ASBR, which is not included in the route ospf metric 

• It's what's not added to the final metric cost for the Type5 LSA ( external summary )  only 

I love messing around with OSPF. It's an strange and not overly complex routing protocol, but the behavior is predictable if you understand it. Outside of NSSA, ospf is very simple to use and once you take a few stabs at design and deployment, it's rather easy to trouble-shoot.


I've seen a lot of IT staffer struggle with fixing OSPF and 10 out of 10 times, it because they didn't have an handle on the issue(s) and used the wrong t-shoot logic

I hope this blog helps you out with any ospf redistribution issues

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   @ )=

          o
       /     \