[c-nsp] Multilink PPP incorrect weights

Wed Jan 5 06:49:58 EST 2005

Ben,

try to disable multilink fragmentation on the vtemplate ("ppp multilink
fragment disable"). the bundle member's weight is used to calculate the
fragment size (i.e. we send smaller fragments over "smaller" links to
compensate for the lower bandwidth).  
Caveat of this is that the receiver might need to queue more packets
during re-ordering, so you want to watch "show ppp multilink" on your
CPE.

Try to find out if the ERX is able to report a more "accurate"
bandwidth, I didn't find a way to overwrite/ignore the received RX-speed
in the L2TP-AVP..

	oli

Ben White <> wrote on Wednesday, January 05, 2005 10:57 AM:

> Rodney,
> 
> The 2 links are both 2Mb ADSL circuits plugged into a Cisco 1721
> which I'm 
> testing with.
> 
> The upstream traffic is bundling ok and I get the full double
> upstream. 
> 
> The bit I've no control of is the telco part, which is documented in
> SIN374 
> from http://www.sinet.bt.com/
> 
> I've got various debugs of the login process and access to the kit at
> both ends 
> if anything would help diagnose the problem.
> 
> Debug at the LNS end when I first noticed the problem was showing
> this: 
> 
> Aug 16 08:17:56:  Tnl/Sn 2704/70 L2TP: Parse  AVP 19, len 10, flag
> 0x8000 (M) 
> Aug 16 08:17:56:  Tnl/Sn 2704/70 L2TP: Framing Type 1
> Aug 16 08:17:56:  Tnl/Sn 2704/70 L2TP: Parse  AVP 24, len 10, flag
> 0x8000 (M) 
> Aug 16 08:17:56:  Tnl/Sn 2704/70 L2TP: Connect Speed 155520000
> Aug 16 08:17:56:  Tnl/Sn 2704/70 L2TP: No missing AVPs in ICCN
> 
> Aug 16 08:17:58:  Tnl/Sn 57819/71 L2TP: Parse  AVP 19, len 10, flag
> 0x8000 (M) 
> Aug 16 08:17:58:  Tnl/Sn 57819/71 L2TP: Framing Type 1
> Aug 16 08:17:58:  Tnl/Sn 57819/71 L2TP: Parse  AVP 24, len 10, flag
> 0x8000 (M) 
> Aug 16 08:17:58:  Tnl/Sn 57819/71 L2TP: Connect Speed 2315264
> Aug 16 08:17:58:  Tnl/Sn 57819/71 L2TP: Parse  AVP 38, len 10, flag
> 0x0 
> Aug 16 08:17:58:  Tnl/Sn 57819/71 L2TP: Rx Speed 2315264
> Aug 16 08:17:58:  Tnl/Sn 57819/71 L2TP: No missing AVPs in ICCN
> 
> The established bundle interface at the LNS shows this:
> Virtual-Access725, bundle name is my.realm.com/mlpppuser
>   Bundle up for 00:01:59, 1/255 load
>   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, 6 reordered
>     0/0 discarded fragments/bytes, 0 lost received
>     0x58 received sequence, 0x4A sent sequence
>   Member links: 2 (max 2, min not set)
>     my.realm.com:Vi2303  (10.0.9.222), since 00:01:59, 583200 weight,
>     1496 frag size, unsequenced my.realm.com:Vi7769  (10.0.9.222),
> since 00:00:32, 8681 weight, 1496 frag size, unsequenced 
> 
> Someone from the telco has previously said to me that it's due to the
> different 
> LAC's, connections from Cisco6400 LACs forward the correct speed,
> whereas 
> connections from ERX Juniper LACs do not.
> 
> Ideally I'd be looking for a way to reset the speeds when the session
> is 
> established, preferably through the aaa profile.
> 
> The only way I've found to fix it so far is to manually modify the
> bandwidth on 
> the Virtual-Template after all of the sessions are established.
> 
> This resets the speeds on all the Virtual-Access interfaces and then
> both the 
> upstream and downstream bonding work ok.
> 
> Any ideas greatly appreciated.
> 
> Ben
> 
> On Tue, 28 Dec 2004, Rodney Dunn wrote:
>> Ben,
>> 
>> I did a bit of reading on this and from everything I
>> can find the BW of the link actually doesn't come
>> in to play when sending data on the member links.
>> I mean the BW configured on the link.
>> 
>> It's the actual transmission rate of the link itself
>> that determines which one gets more data.
>> 
>> From what I have read about the Cisco implementation
>> the packets are held at the bundle interface and
>> are transmitted on the member links as they can handle them.
>> 
>> Now with PPPoX it gets tricky because there isn't really
>> a direct underlying backpressure mechanism to the bundle.
>> 
>> In your setup, where are the links actually going to?
>> 
>> Rodney
>> 
>>  On Tue, Dec 14, 2004 at 05:12:13PM +0000, Ben White wrote:
>>> I'm looking for a way to fix some multilink PPP via L2TP issues
>>> I've seen. 
>>> 
>>> The problem I have is some connections are being sent from our L2TP
>>> provider with incorrect connection speed values.
>>> 
>>> Eg. 2 * 2Mb links, one being established with the correct speed set
>>> (2Mb) and one with the incorrect speed (155Mb).
>>> 
>>> They happily get bundled together, but the multilink load sharing
>>> puts all of the outgoing traffic down the supposedly larger link
>>> and when that's full it doesn't go onto the other link.
>>> 
>>> I've tried various fixes, manually setting bandwidth on the radius
>>> profile/virtual-template etc, however it mostly gets ignored and the
>>> negotiated values override it, other things only get applied to the
>>> bundle interface and not the individual member links.
>>> 
>>> Getting the correct speed values sent with the connections isn't
>>> possible. 
>>> 
>>> Any ideas?
>>> 
>>> Thanks,
>>> 
>>> Ben White
>>> 
>>> _______________________________________________
>>> 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/