But then you might as well use per-packet load balancing...
On Thu, 2009-01-15 at 14:37 -0600, Tony Varriale wrote: > Turn off fragmentation. You'll see your CPU drop way down. > > tv > ----- Original Message ----- > From: "Andrew Jimmy" <[email protected]> > To: <[email protected]>; <[email protected]> > Sent: Thursday, January 15, 2009 2:02 PM > Subject: Re: [c-nsp] Per packet load balancing with low latency applications > > > > I'm using MLPPP along with CRTP on Juniper routers (using AS PIC), And it > > is > > working like a charm... yea true MLPPP stuff is complicated on Cisco > > devices > > which is CPU hungry ... > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Mauritz Lewies > > Sent: Friday, January 16, 2009 12:40 AM > > To: [email protected] > > Subject: Re: [c-nsp] Per packet load balancing with low latency > > applications > > > > Hi > > > > Out of personal experience MLPPP sounds great in theory and technically > > should be a viable solution. However, Cisco has never really been able > > to deliver a bug free MLPPP implementation... > > > > We have had situations of per-packet, moving to MLPPP, going back to > > per-session and eventually having to aggregate into larger single links. > > IOS has just never really worked with MLPPP and I strongly advise > > against. > > > > > > > > > > On Thu, 2009-01-15 at 08:08 -0800, Yan Filyurin wrote: > > > >> Look for ways to aggregate multiple physical circuits into one logical > > that has a native way to load balance and still insure that packets are > > not > > out of sequence like MLPPP or MLFR since they have their own sequencing > > that prevents out of order arrival, not to mention a bunch of things like > > fragmentation and interleaving that is great for voice. As far as market > > data application goes, is it by any chance multicast and UDP, which could > > potentially make it subject to the same constraints as voice. You could > > always do all kinds of things to influence various types of traffic going > > over just a single link with redundancy and all or just do per > > destination. > > I would vote for MLPPP. > >> > >> Like the previous email said, you can use L3 technologies such as > > tunneling with sequence datagrams, but all it will do is drop packets that > > are out of order, thus moving the problem further from the application, > > but > > still creating it. I've only read about it. I am sure everyone here will > > vote for MLPPP. > >> > >> Yan > >> > >> > >> > >> > >> ________________________________ > >> From: William <[email protected]> > >> To: Brad Hedlund <[email protected]> > >> Cc: "[email protected]" <[email protected]> > >> Sent: Thursday, January 15, 2009 10:16:56 AM > >> Subject: Re: [c-nsp] Per packet load balancing with low latency > > applications > >> > >> Hi Brad, > >> > >> Thanks for your input. > >> > >> Is there anything else I can use to achieve my goal? I'm pretty sure > >> getting a bigger circuit will be a last resort. > >> > >> Regards, > >> > >> W > >> > >> 2009/1/15 Brad Hedlund <[email protected]>: > >> > On 1/15/09 6:25 AM, "William" <[email protected]> wrote: > >> > > >> >> My > >> >> question is what would cause the packets to arrive out of sequence? > >> > > >> > Path #1 might have a little more congestion than Path #2, which would > > cause > >> > Packet #1 sent down Path #1 to sit in a buffer an extra millisecond or > > two > >> > than Packet #2 sent down Path #2 with no congestion. This results in > > Packet > >> > #2 arriving at the destination before Packet #1. The result of this > > being > >> > poor application performance. > >> > > >> > Cheers, > >> > > >> > Brad Hedlund > >> > [email protected] > >> > http://www.internetworkexpert.org > >> > > >> > > >> > > >> _______________________________________________ > >> cisco-nsp mailing list [email protected] > >> https://puck.nether.net/mailman/listinfo/cisco-nsp > >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > >> > >> > >> > >> > >> _______________________________________________ > >> cisco-nsp mailing list [email protected] > >> https://puck.nether.net/mailman/listinfo/cisco-nsp > >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
