[c-nsp] MLPPP and ip load-sharing per-packet

[Shaikh, Nasir]

Hi,
According to the feature guide, "The ATM Multilink PPP Support on Multiple VCs feature does not support the link fragmentation and interleaving (LFI) functionality." so I guess I better disable the fragmentation.

So now that the load balancing is done by PPP I have another question. The feature desciption also says:
"The ATM MLP functionality keeps track of packet sequencing, and this functionality buffers any packets that arrive early. With this ability, ATM MLP preserves packet order across the entire bundle."

Are these buffers configurable? I am talking about combining 2 intercontinental atm pvcs of 24M each and want to be sure that I will not introduce extra latency as the router buffers out of sequence packets.

Any views on this are deeply appreciated.

tia

Nas

-----Original Message-----
From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
Sent: woensdag 12 oktober 2005 10:25
To: Shaikh, Nasir; Jon Lewis; Rodney Dunn (rodunn)
Cc: cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] MLPPP and ip load-sharing per-packet


Well,
 if you use MLPPP to create a single Layer3 interface, CEF will not do
any sort of load-sharing. It will be PPP doing the load distribution,
and it will make sure to put the fragments/packets back in order. 10-15
ms difference in latency should be ok, just watch the multilink counters
in "show ppp multilink" to make sure you're not loosing packets in case
the re-assembly queue fills up.. why do you want to disable
fragmentation?

	oli

Shaikh, Nasir <> wrote on Wednesday, October 12, 2005 9:40 AM:

> Hi,
> I have a related query, hope someone can help me out here.
> 
> I am planning to use MLPPP over 2 ATM pvcs from different providers.
> Is there any way that I can influence CEF not to use per-packet load
> balancing? There is about 10-15 ms difference in the latencies of the
> member links and I 
> do not want to strain the routers.
> I will disable fragmentation but will use MQC to ensure WFQ on the
> ATM pvcs. Purpose of using MLPPP is to make the 2 PVCs appear as one
> for the routing protocol (EIGRP in this case) and falling back to the
> shadow pvcs on another router if one or both the member links are
> down. 
> 
> So can I use MLPPP and ensure that CEF does not do per-packet load
> balancing? 
> 
> TIA
> 
> Nas
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Jon Lewis
> Sent: maandag 10 oktober 2005 14:38
> To: Rodney Dunn
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] MLPPP and ip load-sharing per-packet
> 
> 
> On Sat, 8 Oct 2005, Rodney Dunn wrote:
> 
>> On Sat, Oct 08, 2005 at 10:59:40AM -0400, Jon Lewis wrote:
>>> I recently converted a group of CEF T1s (ip load-sharing
>>> per-packet) to MLPPP, but forgot to remove the ip load-sharing
>>> per-packet from the individual T1s.  Does that command "do
>>> anything" when the circuits it's applied to are members of a
>>> multilink group? 
>> 
>> Nope. But please remove all commands from the member link T1's.
> 
> I suspected not, as it wouldn't make much sense, but we were still
> having 
> some issues with VOIP over the the Mu1 interface, so I did go ahead
> and 
> remove those.  I suppose it could be that we have brief traffic spikes
> high enough that I either need more bandwidth or a service-policy
> giving 
> VOIP traffic preferential treatment over the Mu1.
> 
> ----------------------------------------------------------------------
>   Jon Lewis                   |  I route
>   Senior Network Engineer     |  therefore you are
>   Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/