[c-nsp] MLPP problems

Anton Kapela tkapela at gmail.com
Sat Jan 26 21:55:07 EST 2013


On Sat, Jan 26, 2013 at 4:21 AM, Pavel Dimow <paveldimow at gmail.com> wrote:
> Hi,
>
> I have a strange trouble with MLPP with four SHDSL links. The problem
> is that a few seconds or shall I say a minute everything works fine,
> then we suddenly experience huge latency ie from 14ms to 1000ms and

that's the default timeout for ppp reordering receive buffer - I'd
suggest trying tweaks like:

--read up on 'ppp timeout multilink lost-fragment' as segment ordering
is part of multilink; the default is 1000 msec.

http://www.cisco.com/en/US/docs/ios/12_2t/dial/command/reference/dftmupp.html#wp1135996

one note: to support less than 1 second reordering timouts, you will
need fairly specific code (12.2SB, 12.4(24)T, or 15 and later) on BOTH
ENDS of the link.

without looking at your mlppp bundle stats, I can't know which end is
'holding up the show' due to lost fragments. it could be the uplink
from the client, or the downlink to them, which is not getting all the
mlppp frames delivered.

--experiment with 'ppp link reorders' and short-as-you-can-tollerate
mlppp reordering timeouts to see if this issue changes character as
you adjust parameters

--lastly, are you doing MLPPPoA via static PVC's and subints per xDSL
link? if so, be sure you've set your ATM pvc to vbr-nrt mode, and are
cell shaping to slightly less than the xDSL physical layer bandwidth
-- this ensures congestion and queuing happens in your BRAS box, and
not on the crappy fifo's on god-knows-what DSLAM your client hangs off
of... this will rain on anyones mlppp parade quickly, and definitely
precipitate issues like this.

-Tk


More information about the cisco-nsp mailing list