There is an alternative to consider when you want to change the metric of EIGRP routes. This alternative is to use an offset list within EIGRP. The offset list can change the metric of EIGRP routes. Depending on how you assign the offset list it can change the metric of routes that you learn or it can change the metric of routes that you advertise.

One advantage of offset list is that you can specify exactly how much you want to increase the metric. You can look in the EIGRP topology table on router A, see the metric for routes advertised from B, and the metric for the same routes advertised from C. You can compare the advertised metrics and see exactly how much you need to change the metric to get the behavior that you want. And then you use that value in the offset list. If you change the delay on the interface it is hard to know exactly how much it will change the metric, so most of us would need to change the delay, look into the routing table to see if it was enough, and possibly cycle through this multiple times to find the best value to change the delay.

Another aspect of offset list is that it has the ability to change some route advertisements but not change others. Though the way the original question was asked it sounds like he wants to change all routes.

HTH

Rick

Hi Rick,

Thanks for providing the nice aspect of EIGRP Offset List. Can u clear me on this point : -

Does Manipulating the metric for any routing protocol (EIGRP/OSPF) requires consideration of all the routes to be changed and then changing the required value (Either Delay, Bandwidth or Offset).

I mean if i have 10 routes coming from a link and i want to make that link backup for all those routes, then is it possible that changing some specific values (either Delay, Bandwidth or Offset) may effect some routes and may not effect the others because of variable metric values associated with them)

I hope checking the metric for all the routes and then changing the values considering all of them would be a Tedious Task for a Enterprise WAN. I hope this is all try and test method.

Also what is the ideal way for OSPF metric manipulation (Changing the link bandwidth or IP OSPF COST command)

Hi Rohit,

Generally when we use offset list we change the delay value to change the metric to a significant value.

If you want you can change the metric of all the routes or for some routes that you want.

As already pointed out by rick that you check the feasible distance through A--> C and then compare the metric vlaue through the B. Just take a calculated vlaue and increase the delay to the value on C. This will not be tedious task if you want to change the metric for all the routes.

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c2d96.shtml#delayparaR4

When using OSPF you can use both of the methods but for best practice always IP OSPF COST is used under the interface.

regards,

-amit singh

Rohit

If you change an interface parameter such as delay or bandwidth it will impact the metric for every routing update received on the interface by protocols like EIGRP or OSPF (note that protocols like RIP and like BGP are not affected by this). There is no possibility to be selective when you change the interface parameter.

When you configure offset list you have choices. You can configure it to affect every received update (like the interface parameter change does) or you can configure it to selectively change some route metrics and not change others. Note that offset list works for EIGRP (and works for RIP) but offset list does not work for OSPF.

I believe that any time you start to manipulate and change the metric of routing updates that you should consider the potential impact of this change on every route received by the routing protocol. Depending on the particular network environment it might be a tedious task, but a network engineer should evaluate the potential impact on every route.

Also note that changing the metric may change the relationship of some routes and not change the relationship of others. For example if you have the 10 routes received on a particular interface and you increase the metric of those routes by 30. That may change some routes so that they become backup but some of the routes may still be primary (it might take increasing the metric by 100 to change all of the routes to backup).

HTH

Rick

Hi Rick,

Thanks for the nice and helpful explanation. It has cleared my doubts.

As per your given statement below mention is my understanding. Correct me if i am wrong....

Changing the metric (By delay/bandwidth or offset)may have the impact on some routes and may not effect the others in terms of my requirements. So for every change i need to see the impact on the routing table and accordingly i need to play with the changed value to get the desired results for other routes also. So basically i have to start with some value for change and then proceed...

Thanks

Rohit