Yes you verified what I have harped a few times, the added complexity of multilinking not to mention the several bugs I have encountered, is why I say just use CEF and load share per packet/destination. Also multilinking nor CEF give your greater speed but you do have more bandwidth. If you have a 2 lane verses a 4 lane highway the additional 2 lanes won't enable you to go any faster but you can get twice as many cars to their destination.
So yes two T1's will give you twice the thruput in x time but the links are still 1.5M no matter how you slice it. Dave Chuck Larrieu wrote: > > A couple of weeks ago there were a couple of discussions on this board about > using multiple T1's to improve data throughput. If memory serves, there were > two possible ways to do this: 1) per packet load sharing and 2) PPP > multilink > > for no particular reason I decided to do a little study on PPP multilink. > Well, OK, I do have two particular reasons - an upcoming Lab and a customer > who is asking about this. > > So, I build a scenario as follows: > > serial0 token ring > R6--------R5-----------R4 > |--------| > serial1 > > to test throughput, I used extended ping, with multiple pings and various > size payloads, from a loopback on R4 to a loopback on R6. > > the routing protocol was EIGRP, done to assure per packet routing between R6 > and R5 as a control. > > My results were interesting, to say the least. unexpected, but so consistent > that there is no question, in my mind, anyway, about some of the assumptions > many of us make about various load sharing and multiplexing options. > > a summary of the results are using the Cisco router reporting of > min/avg/max round trip times - the middle number is the one to watch. > > packet size PPP multilink single serial link configured as PPP > multilink > > 1000 24/24/132 20/20/104 > > 1500 28/29/52 24/27/112 > > 500 16/19/64 12/13/104 > > 64 12/14/60 4/7/104 > > note that in every case, the single link, configured for PPP multilink, is > SIGNIFICANTLY faster than the dual link. > > Interesting. So I constructed some further experiments, using extended ping, > multiple packets of variable size - range 64 to 1500: > > PPP multilink per packet load share single T1 > > 8/17/136 4/17/136 4/17/144 > > these figures are from over 15,000 pings per scenario, so it is not a case > of random chance here. there is no difference whatsoever between the results > of a single serial link, per packet load sharing over two serial links, and > PPP multilink. what is most surprising is that a single serial connection > proves JUST AS FAST as a dual serial connection. > > Now what I conclude from this is an opinion that multiple T1's DO NOT really > do much for you in terms of more bandwidth. At least for the kinds of data > flows I am able to generate in the lab. Furthermore, PPP multilink is > actually harmful to throughput. So I gotta ask - is load sharing really > adding anything to the mix? Really? In real world scenarios and data flows, > where is it that you are gaining anything? > > Lastly, I set up a final scenario in which I sent 5000 byte packets. this > means fragmentation and reassembly would occur, because the MTU on all wan > interfaces is 1500 bytes. Here are the results when pinging 5000 times using > a 5000 byte payload: > > single serial link: 64/66/168 > > per packet load share: 64/64/168 > > ppp multilink: 48/52/172 > > note here that the load sharing scenario is slightly faster than the single > serial link, and that the ppp multilink is FAR AND AWAY faster that the > other two. I suspect the reason for this is efficiencies gained under the > multilink scenario when fragmenting and reassembling the oversized payloads > > In any case, I hope this presentation will lead to some good discussion of > bandwidth and results. would it be fair to suggest that peoples' efforts to > solve what they perceive as bandwidth issues by implementing multiple WAN > links is really a study in fruitless activity? > > Maybe I should have set up some IPX scenarios? > > Chuck -- David Madland Sr. Network Engineer CCIE# 2016 Qwest Communications Int. Inc. [EMAIL PROTECTED] 612-664-3367 "Emotion should reflect reason not guide it" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=21671&t=21623 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
