Cisco OSPF distance command issues!

I am running a single DMVPN with dual hubs.... everythign works except the fact that I am trying to get the spoke routers to prefer one hub over the using the "distance 111 192.168.0.1 0.0.0.0 53"   from what I understand this command is supposed to change the adminstrative distance for routes in the access-list 53 where the "via" is 192.168.0.1 to 111... but this is not working for me the AD is not being changed can anybody please give me a description of how this command works...?

Google searches turn a lot of contradictions...
LVL 1
justinl525Asked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
cosmicfoxConnect With a Mentor Commented:
The ospf cost could be done on your hub router. That would affect all of the spoke routers that use that hub.
0
 
cosmicfoxCommented:
Why are you trying to change the AD, you could just change the OSPF cost on the link. with "ip ospf 1 cost" command.
0
 
justinl525Author Commented:
That will cause both of the route's metrics to  change and I only want 1 of the routes metrics to change... both of the next hop routers to the subnet in question are reachable via the same interface (in this case a Tunnel interface). So, I change the tun0 interface's ospf cost it will apply to both route's and I will be right back to where I was.  2 routes and the router load balancing them...
I went ahead and opened a ticket with Cisco also and so far they are able to recreate the problem but dont know for sure why it is happening....
0
 
justinl525Author Commented:
Dude!!! you are right.... sorry man! my brain got freakin stuck because the powers that be, I think, (sobbing and in the fetal position) are trying to see if they can kill a man with more projects than he can handle :-(
I got stuck on thinking only relative to the spoke....

I later decided that it could be done for the interfaces on the hub that were connected to the prefixes that I wanted to modify and it worked like a charm.

I used the   ip ospf cost 10 command on the interface that are on the secondary hub connected to the subnets in question so  that the ospf metric would be higher for the router and therefore the spokes would not prefer it as the next hop.

Just so anyone reading knows... The distance [AD] [neighbor] [mask] [acl]
is a valid command for this scenario however Cisco has confirmed that there is a bug in this command for this particular scenario:

CSCsk29338
Conditions:
When two equal cost routes to the same prefix are learned from different neighbors, the distance command may not take work for certain neighbors.

Workaround:
Symptom:
OSPF distance command does not take effect for certain neighbors.
Seen on

Conditions:
When two equal cost routes to the same prefix are learned from different neighbors, the distance command may not take work for certain neighbors.

Work around is to use ip ospf cost.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.