Thanks, Paul, that was awesome! I'm sorry to hear that you're leaving us but I wish you well in your new endeavors.
Regards, John ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ---- On Sat, 2 Feb 2002, Paul Werner ([EMAIL PROTECTED]) wrote: > > 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 [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=34182&t=34182 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
