> Hello,I am testing out the variance command under eigrp and it does not > seem to be working the way it is explained in the CCNP routing guide by > CiscoPress. Any ideas ? Sorry, Long post but need help.I have RTA > connected to RTB and RTC via FR physical intf. running eigrp 1RTB and > RTC > are connected to BBR via serials also running eigrp 1BBR is connected to > TS via serial running eigrp 1 and igrp 1TS is connected to REMOTE > running > rip.RTA to RTB to BBR have bandwidth = 64 configed.RTA to RTC to BBR > have > the default bw = 1.544On RTA, the route to Rip netw. 12. and 13. on > Remote show up via the RTC to BBR to TS to Remote route....which is > correct.D EX 12.0.0.0/8 [170/3245056] via 192.168.10.243, 00:12:37, > Serial0 > D EX 13.0.0.0/8 [170/3245056] via 192.168.10.243, 00:13:42, Serial0 The > metric via RTB to BBR to TS to Remote is 41538560 as inD EX 12.0.0.0/8 > [170/41538560] via 192.168.10.242, 00:00:17, Serial0 > D EX 13.0.0.0/8 [170/41538560] via 192.168.10.242, 00:00:17, Serial0 > After > doing the math,( multiplied 3245056 x 13 to get 42185728 which is > greater > than 41538560), I configed a variance of 13 on RTA and expected to see 2 > routes to networks 12. and 13. but only 1 route shows up, that thru > RTC.Is > there a reason why?Thank you. :
My Reply follows - **WARNING** The verbosity bit is set. Mark this message with (DE) if your latency is set to minimal values. TRANSLATION - Dump this email if you are time challenged. Looking at and understanding variance is best done first with IGRP in my humble opinion. The reasons for this are many. First, variance was introduced first in IGRP and later when EIGRP was developed, it was included as well. Secondly, variance has additional tweaks, knobs, and adjustments that also need to be understood and they are best demonstrated with IGRP. So, on to the explanations. Why variance? The need for variance grew out of a need expressed by you, Cisco's customers, to leverage your existing investment towards future upgrades. For example, if you had a Cisco 2501 router, you have two serial interfaces. These can be used for leased lines or frame relay or other technologies. Let's say you started out one day with a T-1 leased line. You only have two routers, one here and one at the branch office/remote site (this addresses one aspect of your post below- when dealing with variance keep it simple). You put the T-1 in and it's working fine, but one day it goes South on you. The network is down for five extremely long hours while the pointy headed boss is tapping his pencil. Finally, you get the circuit back up and discover one of those neat concepts in networking we all come to know called fault tolerance. You make a proposal to your boss to connect your site to the branch office with two separate lines, one from provider X (who provides your leased line T-1) and another from provider Y, who has a frame relay circuit he sold to you at a good discount. The only problem was the frame circuit is only a 1/2 T-1 (768kbps). If you set IGRP or EIGRP to run out of the box with no tweaks, knobs, or adjustments turned on, you will only get a full T-1, and the frame circuit will never get installed in the routing table, because IGRP and EIGRP do **equal** cost path load balancing out of the box. In fact, this doesn't bother you at all, since you only really need the frame circuit to come up when the T-1 goes down. All goes well until one day... You hit the 9:00 am web rush hour to pull down CNN and a whole bunch more and you notice that T-1 starting to max out on a semi-regular basis. You know that queuing will take care of temporary spikes, but these "temp" spikes are starting to last hours. Then you remember you have that 768kbps frame circuit and you say, "isn't there some way I can use this and have my packets traverse the link in a sane manner?" Cisco answered your call and included the functionality of the variance command. A lot of people get way too wrapped around the axle on computing the variance value. Try to simplify it a little bit. First, consider the fact that variance will be computed upon the underlying variables in the routing protocol, in this case for IGRP and EIGRP it gets simplified to bandwidth and delay. If your delay is not dramatically different on the links, then just focus on bandwidth. Look at a couple of examples, a T1 and a 1/2 T1(768kbps). If you want the lesser bandwidth route included, take the higher bandwidth route (T1) and divide its bandwidth by the lesser route (768kbps). That works out to a variance of 2. This says that any other route that is at least 2 times as smaller than the high bandwidth route (or higher) will be included in the routing table. In the above example with a variance of 2, a 896kbps route would be in the routing table, but a 708kbps route would not. Then look at another example, such as a T1 and a 64kbps frame link. Using the same process as above, you would expect to have a variance value of 24 to see the 64kbps route added to the routing table. This leads to another discussion - how much is too much? Specifically, is there a cutoff in terms of the usefulness of variance? This is delving into a design discussion. The design course might still address a specific number, but common sense should prevail. Do you really want to attempt to load balance a 64kbps frame link with a T1? I sure hope not, because you are asking for trouble. The underlying assumption with the variance value is that the relative bandwidth of the link, or links, is fairly close to each other. This is a leader into the next area regarding the variance command, namely the tweaks you can use with it, such as traffic-share balanced and traffic-share min. The traffic-share balanced command does what it says it does, it balances the traffic based upon the ratios specified when using the variance command. For example, if the variance was set to 2, you would expect that one packet would go down the 768kbps link and two packets would go down the T1 link. Hopefully, this makes logical sense. In reality, depending upon the type of switching used for the interface, you might expect per destination load balancing, but that is a different discussion. So what about the min command? I have a big revelation for you that you are not going to find this explained correctly at all any where on CCO, or any where in Cisco's texts. There is a reason for this. To quote Tim Brown, "original sin". The explanation for the min command was entered slightly misleading in the first command reference, and it has been perpetuated ever since. So what does it really do? It's a rapid fail over mechanism - that's it. Let's say you have a T-1 and a backup link that is a 64kbps frame circuit. I already mentioned the fact that you don't want to attempt to balance these two links, because you would likely have problems with either link congestion or packet reordering. On the other hand, you really do want a backup link in case the primary fails and the main thing you want it for is to control remote network devices for troubleshooting if the primary T-1 goes down(such as telnet). So, how does it work? First, you set the variance to the expected value. Once you do that, you change the default subcommand from the default of "balanced", to "min". What happens? When the T-1 and the 64kbps frame link are operational, both routes will be installed in the routing table, but only the T-1 route will be used. No traffic will go over the 64kbps frame link while the T-1 is operational. When the T-1 fails, the 64kbps frame link will be installed and used for routing. Some of you might be scratching your head and saying, "yeah, but routing will do that anyway when the T-1 route goes down. Yes, but there are certain qualifiers you need to remember. It will do it if it has knowledge that the route goes down. What if it doesn't have direct knowledge of the loss of a route? In a multi-access network, such as a LAN environment, you will not see a route go down. You will only note the absence of routing updates from a routing peer. If you ever wondered what the invalid timer is used for, that's the purpose. So what does it all look like? Shown below is ping output from a configuration where variance was set to 7, the links involved were a T1 and a 10Mbps Ethernet. The output shows the effect of the far side router having the link go down between the E0 interface on the router and the hub. Here's some output which is abbreviated: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!........ !......!......!......!......!......!..........!......!......!... ...!......!.........!......!......!......!......!...!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! This router above has no knowledge of the distant router's Ethernet failure. Note it is attempting to load balance roughly 7 to 1. Every seven packets goes on the Ethernet (and gets dropped) and one packet goes on the Serial link. Only the serial link packets will get a return reply. Then I brought the link back up. Variance was set to seven and the traffic- share command was set to balanced (default). In the example below, variance was set to 7 and the min command was selected. The same conditions apply, the far side ethernet was pulled. The packets dropped off completely, but picked back up. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!..................................................... ................................................................ .........!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!! Finally, contrast the behavior of the same conditions, but with variance set to 1 and traffic share set to balanced (everything off). Same fail over condition applies: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!............ ................................................................ ................................................................ ................................................................ ................................................................ ...................................................!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! So what can be gleaned from above? When you set the min command on traffic share, this ensures that all routes that are within the specified variance will be installed in the routing table. So what does that really mean if the route will not actually be used for routing purposes? Look at the number of dots between the two different outputs above. You will see that when the min command is used, there are 136 dots. Those dots correspond to a number of seconds in timeout. Then look at the last output, where the min route would not be in the routing table. You will note that there are 315 dots in the second output. I can tell you that I timed the second interval and it came out to 10 minutes 40 seconds. Using a straight ratio, the first interval would be 276 seconds. If you do a quick check of your "show ip protocols" while running IGRP, you will see that these roughly correspond to the invalid and flush timers. This should make sense. If you only have one route in the routing table, you will use it until it comes out of hold down, or it gets flushed. OTOH, if you have multiple routes in the routing table for the same destination network, once the invalid timer expires, you can start using that second "known good route". So what is really the purpose of the traffic-share min command? It's a tweak/knob to speed reconvergence if the primary route goes down. My question to you is how long do you want to wait, 270 seconds or over ten minutes? Of course, when you start looking at EIGRP, the whole situation changes. Reconvergence with EIGRP is exponentially faster than IGRP. Remember however what I stated at the beginning these commands were originally formed and implemented when EIGRP was not even around. One final point. This will be my last post to Groupstudy. I am not only leaving Groupstudy, but I am leaving the IT industry altogether. I am returning back to active duty in the US Army in the next few months. Fortunately, I am lucky enough to be able to get a UH-60 Blackhawk transition and command an aviation maintenance company, both of which I am looking forward to doing. Unfortunately, I have not always been able to post as often as I would like this past year; time always conspires against me. I wish everyone the best of luck. Enjoy your studies and learn for learning's sake. That's the learning that really stays with you over the long haul. Very Respectfully, Paul Werner ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=34179&t=34179 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
