Router A is connected with Router B with 64k Link and to Router C with 128K link.
Router B and C are again connected to WAN cloud and both are receiving Routes via EIGRP with different metric values. These routes are being sent to Router A.
Now Router A is taking the link to Router C as Primary because of low cost. I want the Link from A to B as the Primary for all the routes to reach the WAN.
Now if I increase the delay of the A to C link to make it a backup link, then would all my routes start coming from B to A ??
I mean changing the delay randomly may effect the metric of few Routes but may not effect the other routes as all Routes would have different cost. What is the ideal way to change the metric so that all my routes should follow one path. Do i need to keep on changing the cost till the time all my routes comes from B??
Set the delay on link A-> C to a very high value, (you can look at show interface, to find out what the default values are for the delay from A->B and A->C). Based on this you can set the delay to a much higher value on the link from A-> C. This should help EIGRP use A->B as primary link, while using A->C as a feasible successor.
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.
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)
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.
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).
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...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...