Can QOS be used to restrict FTP Transmissions

[HenriettaHog]

We are getting ready to upgrade our internet connection to 20meg from 10meg. This is so we can FTP 1 Terra byte of data across a vpn tunnel to a server in a disaster recovery center. This transmission will occur every week.

The data originates from an IBM ZOS processor and is transmitted and placed on a virtual tape appliance.

I am using a PIX firewall on both ends of circuit. The controlling end of the connection has a Cisco 2621 router connected to the internet circuit.

I need to throttle the FTP transmission down to be no more than 75% of the 20meg bandwidth.

How is this accomplished?

I have looked at the Cisco configuration guide for the 2621 and do not not really understand the process to build the QoS policies etc.

Does anyone have an example of something they have done in the past that I can look at to help me understand what needs to be done.

Thanks
HenriettaHog

 

[leedsit]

Hi,

If only the FTP stream goes over the vpn then it would be quite simple on the 2621(if multiple streams traverse the VPN then because they are encrypted, it would be tricky to differentiate the traffic unless you use qos preclasify features on the pix).

Cisco qos features have a "shaping" ability where could configure the FTP to "shape average percent 75", which will prevent the ftp traffic from going over 75% of the bandwidth but you need to plan carefuly for times of congestion.

Do you want to upto 75% of the bandwidth to the FTP when its transmitting but not go over 75%? leaving only 25% of the bandwidth to other traffic? or Limit the max of FTP to 75% but allowing other traffic to use upto 100% thus vastly reducing the FTP throughput?

But either way the QOS features are very powerful giving you very granular control.

(hope the above makes sense)

LEEroy
MCNE6,CCNP,CWNA,CCSA,Project+

 

[dgrizzard]

Unless I'm reading this wrong you plan on transferring 1TB a week over a 15Mbits (20Mbits throttled to 75%)? That would take 8,888 hours at that speed (unless my math is wrong).

You may want to look at products like Data Domain. They use data deduplication (google if you're not familiar with the tech, very cool stuff) to only send over the WAN link what has changed bit wise. Over 1TB of data you may have a 1-5% change weekly depending on the type of data. You could easily send that over throughout the week (as the changes occur even).

If I've got what you're trying to do wrong, my apologies. For shaping though what LEEroy said is correct.

What I might suggest (alluding to what LEEroy brought up) is to do a service policy inside your shaping policy. I'll explain below with code

This is from one of my routers where I use VoIP qos over a GRE tunnel.

class-map match-any VoiceSignaling
 match ip dscp cs5
class-map match-any VoiceTraffic
 match ip dscp ef
!
!
policy-map Voip-Half
 class VoiceTraffic
    priority 768
 class VoiceSignaling
    bandwidth 64
 class class-default
   police rate 1500000 bps
     conform-action transmit
     exceed-action drop
policy-map tunnel-2mb
 class class-default
    shape peak 1500000
  service-policy Voip-Half

So what I've done is create a class map to match traffic, specifically dscp codes for different VoIP traffic. Then I created a "service policy" to prioritize my actual voice traffic (the audio), then cut out 64k for phone signaling (control traffic for the IP phone), and then police'd the entire connection to 1,500,000 bps and anything above that gets dropped.

Then I created a shaping policy below that (called tunnel-2mb) and shaped the peak speed to 1.5Mbits and then inside that applied the "service policy" from before. After that I applied the tunnel-2mb policy to the appropriate ethernet interface.

This is used mostly on GRE tunnels, but what you could do is use the class map to match the ftp traffic and apply a priority of 15000 (15,000 Kbits)to ftp traffic coming from that particular server, and then inside that policy apply a shaping policy to police the entire connection to 20,000,000 bps. Then the service policy will prioritize the FTP traffic while it is sending over and other traffic will flow normally when the FTP is not sending.

Again if I'm wrong on something, apologies