WFQ and Multilink at core

[dkennedy99]

I have an MPLS network with a 9Mb, Multilink PPP pipe at the core and T1 or less pipes at the branch offices. We are connecting to our MPLS provider via BGP and we are using Cisco WAE's at each site with v4.1.1c of WAAS code as well.

The problem is that we are experiencing occassional slowness with remote sites with the receiving of data from the core. Occassionally, one user will copy or open a file via CIFS and consume all of the bandwidth. We recently went from a FIFO queueing strategy at the core (weighted fair-queue at the remote sites, by default) to a weighted fair-queue at the core with seemingly positive effects. However, we still get occassional reports of RDP latency. In addition, we are not using RDP on the standard port of 3389 -- we are using port 81 instead.

Here is the current config of the Multilink (6 T1's -- ugh) at the core. Does anyone have any suggestions for further configuration of this Multilink so that our remote sites don't experience the slowness in RDP? Or do I need to go down the road of priority queueing instead?

Here's the config of the Multilink PPP as it is now:

interface Multilink1

ip address xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx

ip nbar protocol-discovery

ip route-cache flow

fair-queue 256 256 0

ppp multilink

ppp multilink group 1

ppp multilink fragment disable

end

[Joseph W. Doherty]

When working with cloud WAN, you often need to consider congestion points both into the cloud (which you've done with WFQ) and exiting the cloud.

If all traffic is core to/from branches, you might define an individual traffic shaper for traffic going from core to each branch. If there's branch-to-branch traffic, you'll need to rely on QoS features supported by your MPLS vendor to handle cloud egress congestion.

PS:

BTW: I'm surprised WFQ is working well for you for at 9 Mbps. Original WFQ often seemed to be a CPU hog at higher bandwidths. FQ within CBWFQ seems to scale better.