[c-nsp] SDSL Aggregation on 1841

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Sat Aug 26 08:43:10 EDT 2006


Ahmad Cheikh-Moussa <mailto:acm at netuse.de> wrote on Saturday, August 26,
2006 2:16 PM:

> Hi!
> 
> On Aug 26, 06, Oliver Boehmer (oboehmer) wrote:
>> does it freeze for everything from that moment on, i.e. can you
>> continue to work?
> Yes, I can.
> 
>> 
>> can you pls monitor "show ppp multilink" from both ends and watch
>> for show ppp multilink 
> 
> Virtual-Access7, bundle name is *********
>   Bundle up for 23:52:45, total bandwidth 2464, load 1/255
>   Receive buffer limit 24384 bytes, frag timeout 1000 ms
>   Using relaxed lost fragment detection algorithm.
>     0/0 fragments/bytes in reassembly list
>     0 lost fragments, 7303 reordered
>     0/0 discarded fragments/bytes, 0 lost received
>     0x3F51 received sequence, 0xB691 sent sequence
>   Member links: 2 (max 2, min not set)
>     mk_netuse:Vi14  (213.172.98.29), since 23:52:45, unsequenced
>     mk_netuse:Vi4  (213.172.98.29), since 23:52:45, unsequenced
> No inactive multilink interfaces

looks good.

> On the client:
> 
> c1841#sh ppp multilink
> 
> Virtual-Access3, bundle name is netuse-dsl
>   Bundle up for 23:52:55, total bandwidth 112, load 1/255
>   Receive buffer limit 24384 bytes, frag timeout 1741 ms
>   Dialer interface is Dialer1
>     0/0 fragments/bytes in reassembly list
>     276 lost fragments, 23074 reordered
>     1767/1293360 discarded fragments/bytes, 883 lost received
>     0xB691 received sequence, 0x3F51 sent sequence
>   Member links: 2 (max not set, min 2)
>     Vi1, since 23:52:55
>     Vi2, since 23:52:55
> No inactive multilink interfaces
> 
> Is there something, I have to tune ??
> Buffers or something like that.

you loose fragments. If the loss is due to reassembly buffer overflow
(for example when you see a high differential delay, i.e. one link
"lags" behind the other), you can try to tune the reassembly buffer
using "ppp multilink slippage mru <n>". Default ist 8*MRU*num_links
bytes (24384 bytes, as shown above), try to double it and see if the
fragment drops go away. What is the link speed (i.e. downstream speed
from LNS to client)?

If you can't rule out packet reorders between LNS and Client, try the
"ppp link reorders" command at the client's Dialer interface to enable
the relaxed lost fragment algorithm (which is enabled on the LNS by
default since the sessions arrive via L2TP), but don't think this will
help here..

	oli



More information about the cisco-nsp mailing list