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

[Oliver Boehmer (oboehmer)]

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/