Solved: QoS question

prakkdangc · ‎09-25-2009

Hi,

I have a new customer site behind a T1 that is going to join our company WAN. The plan is to join them to us initially using a VPN tunnel while we "assimilate" them, and them switch them to a higher speed connection. During the assimilation time, the customer requirements are to receive a scheduled FTP push three times daily, which brings any other traffic to it's knees. I want to be able to rate-limit/shape/police this ftp traffic to 50% (768k)until we move them to our private WAN. However, I only have control of the CE Router, not the PE router. My QoS is weak, but I know I can't use shaping on ingress. Can you help me with choosing the best method between rate limiting or policing? There will just be IPSEC site-to-site traffic, and the inbound FTP traffic.

Thanks,

Dave

Joseph W. Doherty · ‎09-25-2009

Not a good situation just using Cisco QoS features.

You can police the inbound FTP traffic and/or shape outbound ACKs for that traffic. Either or both techniques do work, but very difficult to regulate inbound congestion precisely. If supporting a very low (perhaps 10% of link) inbound FTP rate is acceptable, these techniques might be useful. (The reason for the low target rate, TCP will still burst across the link and to keep such bursts from adversely impacting other traffic, you need to slow such inbound traffic sooner rather than later.)

More precise inbound traffic regulation can be accomplished by using a device that spoofs receiving host's RWIN while monitoring bandwidth utilization. Don't believe any Cisco product supports this, but believe some 3rd party traffic shaping products do.

Another option might be consideration of installation of a 2nd inexpensive (e.g. ADSL, cable) Internet connection and not mix the exising Internet traffic with the transition VPN tunnel traffic.

View solution in original post

Joseph W. Doherty · ‎09-25-2009

You're correct, you can't shape in ingress although you can police.

Trying to manage bandwidth utilization at ingress is very difficult. (It's quite easy to limit FTP bandwidth downstream of the ingress point, but that's not really the same as keeping FTP from congesting the inbound link before it reaches the ingress point that has a policer.)

Since you mention CE and PE routers, could you further eloborate on the WAN topology and end-points for the FTP pushes? Unless this new site can be "hit" by other sites, why wouldn't outbound QoS control FTP to this site?

prakkdangc · ‎09-25-2009

The customer router (cisco 2600)is connected to a Qwest T1 line to the Internet. They currently get FTP data pushed to them from a server "in the wild" on the Internet. We are setting up an ASA to tunnel to our company over that same connection. The FTP source will remain the same. When we get the customer site connected to our private WAN, we will deal with the FTP traffic at our ePoP and route the traffic through our network.

Dave

Joseph W. Doherty · ‎09-25-2009

Not a good situation just using Cisco QoS features.

You can police the inbound FTP traffic and/or shape outbound ACKs for that traffic. Either or both techniques do work, but very difficult to regulate inbound congestion precisely. If supporting a very low (perhaps 10% of link) inbound FTP rate is acceptable, these techniques might be useful. (The reason for the low target rate, TCP will still burst across the link and to keep such bursts from adversely impacting other traffic, you need to slow such inbound traffic sooner rather than later.)

More precise inbound traffic regulation can be accomplished by using a device that spoofs receiving host's RWIN while monitoring bandwidth utilization. Don't believe any Cisco product supports this, but believe some 3rd party traffic shaping products do.

Another option might be consideration of installation of a 2nd inexpensive (e.g. ADSL, cable) Internet connection and not mix the exising Internet traffic with the transition VPN tunnel traffic.

prakkdangc · ‎09-25-2009

Thanks Joseph (Joe?), you've got me going in the right direction!