[c-nsp] Multilink PPP incorrect weights

[Ben White]

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/