 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
6 messages in net.nether.puck.cisco-nsp[c-nsp] Multilink PPP incorrect weights| From | Sent On | Attachments |
|---|---|---|
| Ben White | Dec 14, 2004 12:11 pm | |
| Rodney Dunn | Dec 28, 2004 7:41 pm | |
| Ben White | Jan 5, 2005 4:56 am | |
| Oliver Boehmer (oboehmer) | Jan 5, 2005 6:49 am | |
| Ben White | Jan 5, 2005 7:38 am | |
| Oliver Boehmer (oboehmer) | Jan 5, 2005 9:11 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | [c-nsp] Multilink PPP incorrect weights | Actions... |
|---|---|---|
| From: | Ben White (be...@keme.net) | |
| Date: | Jan 5, 2005 7:38:43 am | |
| List: | net.nether.puck.cisco-nsp | |
Hi,
Disabling fragments on the bundle hasn't helped, the downstream is still restricted to the speed of a single link.
The response I got from the telco was that bonding wasn't a supported feature of their wholesale product, so are unwilling to do anything. Apparently they have submitted a feature request to Juniper, but I don't expect to get anywhere there.
I think I'll have to go down the route of modifying the bandwidth on the virtual-template each time a session is established, although this seems like an awful kludge.
Ben
On Wed, 05 Jan 2005, Oliver Boehmer (oboehmer) wrote:
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 cisc...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________ cisco-nsp mailing list cisc...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/