[114410] in North American Network Operators' Group
RE: PPP multilink help
daemon@ATHENA.MIT.EDU (Matthew Huff)
Mon May 11 12:32:43 2009
From: Matthew Huff <mhuff@ox.com>
To: Rodney Dunn <rodunn@cisco.com>, Andrey Gordon <andrey.gordon@gmail.com>
Date: Mon, 11 May 2009 12:32:03 -0400
In-Reply-To: <20090511160602.GI127@rtp-cse-489.cisco.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
I would also think the problem is with flow control not allowing the maximu=
m bandwidth. Trying multiple ftp streams and seeing if that would max it ou=
t would help.
I would think you would want to add a WRED to the class-default entry to pr=
event global tcp synchronization
...
class class-default
fair-queue 4096
random-detect dscp-based
----
Matthew Huff=A0=A0=A0=A0=A0=A0 | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
http://www.ox.com=A0 | Phone: 914-460-4039
aim: matthewbhuff=A0 | Fax:=A0=A0 914-460-4139
-----Original Message-----
From: Rodney Dunn [mailto:rodunn@cisco.com]=20
Sent: Monday, May 11, 2009 12:06 PM
To: Andrey Gordon
Cc: nanog@nanog.org
Subject: Re: PPP multilink help
On Mon, May 11, 2009 at 10:37:25AM -0400, Andrey Gordon wrote:
> Hey folks, I'm sure to you it's peanuts, but I'm a bit puzzled (most like=
ly
> because of the lack of knowledge, I bet).
>=20
> I'm buying an IP backbone from VNZ (presumably MPLS). I get a MLPPP hand =
off
> on all sites, so I don't do the actual labeling and switching, so I guess
> for practical purposes what I'm trying to say is that I have no physical
> control over the other side of my MLPPP links.
>=20
> When I transfer a large file over FTP (or CIFS, or anything else), I'd
> expect it to max out either one or both T1,
Most MLPPP implementations don't has the flows at the IP layer to an
individual MLPPP member link. The bundle is a virtual L3 interface and
the packets themselves are distributed over the member links. Some people
reference it as a "load balancing" scenario vs. "load sharing" as the
traffic is given to the link that isn't currently "busy".
but instead utilization on the
> T1s is hoovering at 70% on both and sometimes MLPPP link utilization even
> drops below 50%. What am I'm not gettting here?
If you have Multilink fragmentation disabled it sends a packet down each
path. It could be a reordering delay causing just enough variance in
the packet stream that the application thorttles back. If you have a bunch
of individual streams going you would probably see a higher throughput.
Remember there is additional overhead for the MLPPP.
Rodney
>=20
> Tx,
> Andrey
>=20
> Below is a snip of my config.
>=20
> controller T1 0/0/0
> cablelength long 0db
> channel-group 1 timeslots 1-24
> !
> controller T1 0/0/1
> cablelength long 0db
> channel-group 1 timeslots 1-24
> !
> ip nbar custom rdesktop tcp 3389
> ip cef
> !
> class-map match-any VoIP
> match dscp ef
> class-map match-any interactive
> match protocol rdesktop
> match protocol telnet
> match protocol ssh
> !
> policy-map QWAS
> class VoIP
> priority 100
> class interactive
> bandwidth 500
> class class-default
> fair-queue 4096
> !
> interface Multilink1
> description Verizon Business MPLS Circuit
> ip address x.x.x.150 255.255.255.252
> ip flow ingress
> ip nat inside
> ip virtual-reassembly
> load-interval 30
> no peer neighbor-route
> ppp chap hostname R1
> ppp multilink
> ppp multilink links minimum 1
> ppp multilink group 1
> ppp multilink fragment disable
> service-policy output QWAS
> !
> interface Serial0/0/0:1
> no ip address
> ip flow ingress
> encapsulation ppp
> load-interval 30
> fair-queue 4096 256 0
> ppp chap hostname R1
> ppp multilink
> ppp multilink group 1
> !
> interface Serial0/0/1:1
> no ip address
> ip flow ingress
> encapsulation ppp
> load-interval 30
> fair-queue 4096 256 0
> ppp chap hostname R1
> ppp multilink
> ppp multilink group 1
>=20
>=20
>=20
>=20
> -----
> Andrey Gordon [andrey.gordon@gmail.com]
