I would also think the problem is with flow control not allowing the maximum bandwidth. Trying multiple ftp streams and seeing if that would max it out would help. I would think you would want to add a WRED to the class-default entry to prevent global tcp synchronization ... class class-default fair-queue 4096 random-detect dscp-based ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -----Original Message----- From: Rodney Dunn [mailto:rodunn@cisco.com] 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 likely because of the lack of knowledge, I bet).
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.
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
Tx, Andrey
Below is a snip of my config.
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
----- Andrey Gordon [andrey.gordon@gmail.com]