|
Home > Archive > CCIE > July 2002 > EIGRP & Load
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| MadChef 2002-06-24, 9:07 pm |
| If one sets the EIGRP loading metric weight to a positive number so that a router uses load to build the metric, the router computes a rolling load average over 5 minutes every 5 seconds. Does this then mean that a new metric is computed and advertised every 5 seconds? If not, then how often is the updated metric advertised? If it is updated that often then it seems like it would create a substantial scalability issue as updated metrics were propogated across the network at a staggering frequency.
Can anyone who is better versed in EIGRP enlighten me?
MadChef | |
| Yankee 2002-06-25, 3:03 am |
| A question I can answer!
No, load does not trigger a metric change only BW and delay do. If you changed it so load was a function to be used the next time the metric was calculated for a legitimate reason load would be a factor.
Yankee | |
| MadChef 2002-06-25, 4:45 am |
| Now, the next question is: Where did yoiu find this?
I spent a good bit of time on CCO, with doyle, etc, and I couldn't find anything on it. Care to share?
MadChef | |
| Yankee 2002-06-26, 2:45 am |
| MC don't trust me!
I can't swear which book it was in but the best one written on EIGRP is "EIGRP for IP" by Retana, White and Slice (3 Cisco people). It is paperback and lists for $19.95.
OK i felt guilty and looked it up.... page 15 of the above mentioned book:
"EIGRP will not recalculate the best path based on load of the links alone: Something else must change to prompt EIGRP to recalculate the path metric before it will notice that the load on the path has changed."
Yankee | |
| MadChef 2002-06-26, 2:15 pm |
| Excellent. Thank you very much.
I seldom deal with EIGRP but this customer has EIGRP all over their network. Originally they wanted to use the loading metric capability of EIGRP in making forwarding decisions (and I think they were told they were) but this had never been enabled. Duh. I wanted to be able to speak intelligently on exactly how that worked. This customer also provided a prime example of why you shouldn't turn on unequal cost load balancing just because EIGRP supports it. I don't think they had a firm grasp of the capabilities and limitations of EIGRP when they set it up. Oh well. I guess I learned something, at least!
MadChef | |
| cahillrobert 2002-06-26, 4:00 pm |
| MadChef
You piqued my interest with following...
quote:
customer also provided a prime example of why you shouldn't turn on unequal cost load balancing just because EIGRP supports it.
What was the reason that the client gave for not doing unequal load balancing.
From my reading, testing, and experience the prime EIGRP metric to fiddle with is DELAY.
Were they doing some level of backup on a slow WAN route? | |
| Yankee 2002-06-27, 3:09 am |
| I highly recommend that inexpensive book I mentioned in the previous post for anyone that uses EIGRP extensively, like me. It honestly is the best source I have found to date and believe me, I read a ton of different things before I ever found that book.
Delay is the recommended metric to modify because it is calculated in a cumlative manner where the BW metric is the only the narrowest "pipe" on that route. If you are messing with the delay metric it is usually because you have two equal cost routes and you want one of them to be preferred.
I would have thought the variance command would be used for unequal path load balancing, but you have to be careful with it too.
Yankee | |
| MadChef 2002-06-27, 4:37 am |
| quote:
Originally posted by cahillrobert
What was the reason that the client gave for not doing unequal load balancing.
They were doing unequal cost load balancing, and the problem is they really didn't need to. In fact, it was ultimately detrimental. And yes, Yankee, they were using variance to do this.
Imagine a remote site with two PVCs built to two Core locations: CoreA and CoreB. CoreA and CoreB are connected to each other via T1. CoreB is used solely for DR purposes. All traffic is basically from the remote site to CoreA-Net, the LAN off of CoreA. The PVC to CoreA provides the best metric to CoreA-Net. The PVC to CoreB provides a slightly worse metric to get to CoreA-Net (because it crosses the T1, too), but it the route met feasibility requirements and was within the variance. Therefore the remote site was sending a portion of its traffic (in this case the traffic share was 1 for each route, but I don't know how granular that is. Yankee?) destined to CoreA-Net througe CoreB and across those T1s. Both of the PVCs from the remote were way way way below their CIR. Meanwhile the T1 between CoreA and CoreB is saturated. My solution for this was to turn off variance and let all traffic destined for CoreA-Net go directly to CoreA instead of through CoreB. That frees up the T1 between the core sites. Perhaps this could have been done by using the load as a factor in the metric, but I think my solution is far simpler, easier to troubleshoot and easier to maintain.
I have a hunch that the network designers originally turned on variance in order to load balance across what is actually two T1s connecting two pairs of core routers at each site. This wasn't happen and I believe it's because it could never meet the feasibility requirements. So my question would be this:
Feasibility is met when the advertised distance to a network is less then the current feasible distance (I think I have the terms right, anyway). It will not meet the feasibility condition if the advertised distance is EQUAL to the feasible distance, will it? It seems like it should since that would still prevent loops since it's not possible to have a metric of 0 anywere along the line, but everything I've ever seen says less.
Just more musings on my part.
MadChef | |
| Yankee 2002-06-27, 7:24 am |
| I believe the variance command works at the conversation level, meaning once that session is established that conversation will continue over the same path so it is a one to one round robin based on connections which does not allow for "perfect traffic balance". Another thing to understand is that the variance command is of local significance only, so if in your example it was only applied to the remote router the return path would always be from CoreA to the remote site.
I'm not understanding the feasible route question, but if you are referring to a feasible successor that route is not in the routing table, but rather in the topology table as a second choice to get to a network should the primary fail. Only equally weighted routes will appear in the routing table.
Yankee | |
| MadChef 2002-06-27, 11:52 am |
| quote:
Originally posted by Yankee
Only equally weighted routes will appear in the routing table.
Not if variance is enabled. I thought I had a copy of the routing table in questions, but I don't. You could actually see multiple routes for the same net with diffent metrics.
MadChef | |
| Yankee 2002-06-27, 6:07 pm |
| Oh that would be true!
I have to correct my earlier statement about how variance round robins. I began to rethink what I had said and went back to the book to check....
Here is a correction to the answer I gave. In your example the remote site has two equal paths leaving router and the difference in metric was in effect the extra hop going thru B to get to A's ethernet. This is a bit more complicated to see why variance does what it does but the principle should be the same. Let me change the example to two different bandwidths say a 512K and 1024K circuit that you want to load balance, so you use a variance 2 command to make them look equal. EIGRP is smart enough to know that the BW is not really the same so it load balances with a ratio equal to the variance multiple of 2. Roughly speaking 2 packets will go out the 1024K circuit for every one out the 512K.
Another addition to my previous comments is that as MC said the alternative path you want to load balance with must meet the feasibility condition.
Sorry for the errors....
Yankee
Yankee | |
| doctorcisco 2002-07-01, 9:17 am |
| quote:
Originally posted by Yankee
EIGRP is smart enough to know that the BW is not really the same so it load balances with a ratio equal to the variance multiple of 2. Roughly speaking 2 packets will go out the 1024K circuit for every one out the 512K.
Yankee
If the load balancing is by session rather than by packet, would you then get a 2:1 ratio of sessions being initiated and sent over the unequal links?
doc | |
| MadChef 2002-07-02, 4:28 am |
| quote:
Originally posted by doctorcisco
If the load balancing is by session rather than by packet, would you then get a 2:1 ratio of sessions being initiated and sent over the unequal links?
Over time, yes. But if you looked at the links at any given point they might not be quite 2:1.
While EIGRP is resposible for determining the load share of each link, the switching method used is what really determines how even the ratio will be. Fast Switching (i.e. using the IP route cache) will be more uneven, probably even over time, because it caches only the destination. If 98% of your traffic hits one host, the load sharing will not be very effective. Process switching will even things out on a per packet basis but will introduce significant overhead. CEF, if supported on your platform, can per packet load balance when load sharing occurs, so it should give us a 2:1 ratio. It can also load balance per source/destination pair which is most analgous to your question and will be close to 2:1 over time.
In my case, the previous vendor left fast switching enabled even though everything supports CEF. They just didn't quite know what they were doing.
So anyway, the whole point was to say that the implemenation of load sharing is independent of EIGRP which may or may not have been clear to you.
MadChef |
|
|
|
|