I am trying to setup a QoS policy on our routers for better performance of Windows Terminal Server for our remote offices. We have 1841 routers in each remote location connecting into the 2800 series at our main location (spoke and hub). Each office utilizes Remote Desktop software to access Terminal Services, where the servers reside at our main location. 4 offices are using 512 frame relay links (with burstable speeds), while a 5th office has a full T1. Even with the full T1, users complain of sluggishness.
We have new servers each with dual processors, 4 GB of RAM, multiple/fast hard drives, etc. Windows 2003 Server on each server and I they only run a handfull of applications. We've done all we can to optimize the servers and they often run pretty good, but I'm wondering if a QoS policy might improve performance for all involved, particularly the frame relay offices.
I'm not a cisco expert by any stretch of the imagination but have some hands-on experience with configuration, but have never setup a QoS policy before. The routers only run data and do not utilize VoIP or video data across the wan links (occasionally a video will be watched online on the local desktop).
Can anyone offer some guidance on setting up a QoS policy? Whether it be an online guide to using the wizard in the SDM, best practices, or if possible a step-by-step guide using the CLI?
Your question probably got overlooked because of the forum you selected. I just stumbled across it while doing a search on "QoS". I believe you would get response in the "WAN, Routing and Switching" forum. QoS might indeed help. (Quick test - if remote desktop is only sluggish during peak usage, then QoS might help.)
What QoS does best is manage bandwidth instead of treating all traffic alike. For instance, you can insure your RDP traffic is not pushed aside by other bulk traffic, like file transfers. You can also use it to retain control of your bandwidth in certain situations.
You mention you're using frame-relay with a hub and spoke design. Depending on how you've sized your connections to the frame-relay cloud, it's often easy to overrun a frame-relay egress (from the cloud to your site) link. Most common causes are hub site having more bandwidth then some remote sites or aggregate of remote sites having more bandwidth than the hub. Either situation usually entails a single FIFO queue which often delays time sensitive traffic. You prevent this by using traffic shaping.
Once you preclude bottlenecks forming in the frame-relay cloud, you then can manage your RDP traffic to have sufficient bandwidth for it to operate best.
What QoS won't help you with is if you have insufficient bandwidth to support your RDP traffic or distance based latency.
If you can provide more information about all your physical link bandwidths and their CIRs, I could offer some specific suggestions.
Your description of the RDP traffic being pushed aside by other traffic seems to be an accurate description to what I think is happening. Internet downloads (legitimate) are being done from the local desktop as opposed to the remote desktop, such as large PDF's and occasionally some video or graphics files. If that is the case, I believe QoS would help guarantee the RDP traffic has a certain amount of bandwidth and continue to run smoothly no matter what is happening at the local desktop level.
While for most internet usage, they should be using the remote desktop's internet connection (which uses the main office), they complain about the security measures we have in place and until we find a better solution, this is the way it will be for some time.
About our network:
4 remote offices using a 128 kbps Frame Relay link into the central office for data, burstable to 512 kbps (these offices run with 2-3 people only). We have a total of 1.54 mbps of bandwidth for all 4 of these sites.
1 remote office uses a 512 kbps, burstable to 1.54 mbps - note, this is the office where most of the complaints come from - and the only one that uses their local desktops for anything, they also have 6-7 users. They have a private line into the main office with their own T1 card in our smart jack. We have 1.54 of bandwidth available to them.
Our central office uses a full T1 for internet traffic only and a connection for the 4 offices coming in on the 128 / 512 setup. The 512/1.54 connection has it's own line coming into the building into our routers.
For your one office with the 512/1544 that connects to your HQ 1544, first check whether WFQ is active both sides. If not, activate it and see if that cures the problem to that remote office. If not, you can define a policy somewhat like this.
(NB: syntax likely off)
ip access-list extended RDP_Servers
ip permit tcp host (your server IP) any
ip permit tcp any host (your server IP)
match group name RDP_Servers
bandwidth percentage 25
(apply to HQ and remote) serial #
service-policy out RDP_Servers
For your other links, assuming most data is from HQ to remote and assuming you've assigned subinterface per PVC, first try:
HUB serial #.##
traffic shape rate 512000 (think it bps)
If that alone doesn't do the trick, try:
service-policy RDP_Servers (requires all above for support 1.5 Mbps)
(apply to HQ) serial #.##
service-policy out 512_RDP
For 128/512 remotes, assure they're running WFQ. If that alone doesn't address the problem, try using the policy for HQ/remote 1.5 links. After that, try a policy similar to the last but shape to 350 Kbps.
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...