Interface OSPF cost issue

[itdojo]

Image link (the image above looks distorted in the post preview):  http://fodder.s3.amazonaws.com/ospf-cost-diagram.jpg

In the test network shown in the diagram I have the following issue that I can't seem to figure out:

Without any modification to ospf interface cost traffic from R8 to 172.16.88.1 (R5) takes R3 --> R2 --> R5 (total metric 67).

This is not ideal because of the f1/0 interface on R2.  The path via R3 --> R4 --> R6 --> R5 (total metric 68) is actually preferable but is not selected because of OSPF's baseline inability to distinguish between FastEthernet and greater link speeds.

I am fully aware that I can use the auto reference-bandwidth command on all the routers to fix things but I am testing behaviors of the ip ospf cost command at the moment.

Setting the ospf cost of the f1/0 interface on R2 to 10 changes the path for traffic coming from R8 on its way to 172.16.88.1 (R5).   This is desired result.  However, the return traffic from R5 continues to use the path through R2 (R2 --> R3 --> R8).  This is what is illustrated in the dotted arrows in the included image.  R2's interface cost is not being taken into account by R5, which I am assuming is because R5 respects his own interface cost on the link over R2's cost.  However, this is producing a sub-optimal return path.

My question is this:  Aside from using a route map is there an ospf configuration that I am overlooking that will cause R5 to stop thinking that the path through R2 is preferred?

[jeremycorkery]

Hi ItDojo,

I can't see how you can influence this, unless you have a second interface coming from R5 to R2 with a different ip ospf cost. Does changing the ospf auto cost reference-bandwidth change the behaviour?

I'm not sure what R5 would see the R5->R2 link as. A sh ip int g0/0 | inc cost may still have the same value????

Would you have a gns3 topology file for this?

[itdojo]

Hi Jeremy,

The GNS3 config is attached.  Thanks for your input.

Colin

[jeremycorkery]

Hi Colin,

The only way I could solve this was to change the cost on the return path of R5 to R8. It isn't tidy, but setting the ip ospf cost on R2's G0/0 port to 10, changes the cumulative path from R5 to R8.

I changed the reference bandwidth to 1000 in the topology to see how this would changes things. I just learnt that a 'no ip ospf cost' on both int g0/0 and f1/0 on R2, does not change the cost by itself, so had to clear the ospf process in order to affect the cost. Not sure if this is normal behaviour...

With no ip ospf cost configured on R2, and the ref bw changed to 1000, the path from R8 to R5 now takes the optimal path. However traffic R5 to R8 will still take the path through R2. Checking on the cost of G0/0 on R5 the cost is 1.

Great scenario... to get the optimal return path,R5 through R6 to R8, R2's G0/0 port needed manual adjusting to 10, so R5 would not have R2 as the best path to reach R8.
Taking R2 off the shared link of R5 and R6 and having it's own Fastethernet connection to R5 would be the simplest solution? Thanks for sharing Colin. 

Cheers, Jeremy.