QOS on WAN

[2044418Puts]

Hi, I would like to configure QOS on my WAN link. I have a 1024 kbps SDSL WAN link and I would like to have 80% of the bandwidth reserved for ESP traffic. The remaining can be used for other traffic.

I've made a CBWFQ for the outbound traffic, but how can I rate limit the inbound traffic from the ISP to the router?

This is what I've configured for the outbound direction:

policy-map WAN_OUT_PM

class VPN_TRAFFIC_CM

priority percent 80

class class-default

bandwidth percent 20

I dont know exactly if this is the right configuration. Can anyone please verify this and help me out with the inbound QOS rules?

[Joseph W. Doherty]

Unsure what ESP traffic is, but priority (LLQ) queuing normally only used for real-time, although it doesn't preclude using it for other traffic. Your policy, as defined, will send the traffic that matches class VPN_TRAFFIC_CM first, but it will also cap the traffic at 80% when there's congestion.

If you continue to use just the one explicit class using priority, I would suggest using fair-queue within class-default.

Ideally inbound is controlled on the other side's outbound. Trying to control inbound on your side doesn't usually provide the results we really desire. To also provide your inbound ESP with 80%, similar to your outbound, an policy applied as "inbound" in you WAN facing interface, such as:

(NB: syntax might be incorrect and only the later IOS images support policing percentages)

policy-map WAN_OUT_PM

class VPN_TRAFFIC_CM

police percent 80

class class-default

police percent 20

might work. However, the above will not only cap ESP at 80% all the time, but it will also cap other traffic at 20% all the time. Further, both classes can burst higher on the inbound link before the policers drop their overspeed traffic.

I know the above isn't what you really desire, but again, very difficult to control inbound traffic as we can outbound traffic.

The only other technique that I know can influence inbound TCP traffic is shaping outbound ACKs, but that's very difficult to get to work as desired too.

[2044418Puts]

ESP traffic is just encrypted VPN traffic, which I can match with "permit esp any any".

I already doubt that there was a way to effectly manage incomming traffic. But the way I would like to use it is as follows:

Some of my branch offices use their WAN link also for Internet traffic. This results in slow VPN performance (citrix, etc.) when people start downloading in their non-citrix environment. So I would like to rate limit incoming traffic and give priority to ESP (VPN encrypted) traffic.

[Joseph W. Doherty]

ESP - IPSec, got it.

For outbound sites that mix both VPN and Internet traffic, you can treat the two differently. For example:

policy-map out

class VPN

bandwidth remaining 99 percent

class Internet

bandwidth remaining 1 percent

Effectively, VPN would have priority over Internet traffic without completely blocking Internet traffic. Whatever bandwidth is unused by VPN, Internet could use. You can also adjust the percentages if you want to guarantee Internet more outbound (but at the possible expense of VPN).

Further, if the VPN traffic is generated on a Cisco router or if the VPN traffic is marked (and the marking copied to the encrypted packet) for different applications, you can even treat the VPN traffic differently. For example:

policy-map out

class VPN-citrix

bandwidth remaining 50 percent

class VPN-routine

bandwidth remaining 40 percent

class VPN-background

bandwidth remaining 9 percent

class Internet

bandwidth remaining 1 percent

Again, unused bandwidth is available to the other classes.

For inbound, again, your options are very limited other than policing all inbound Internet traffic. If the Internet traffic is comprised of lots on non-TCP traffic, the policer may have little effect preserving bandwidth for VPN.

It's possible if your Internet provider defaults to something on their side like WFQ, higher IP Precedence markings on the VPN traffic might get them better service.

I have been in the situation of mixing VPN and Internet on a common link with generally poor results. Perhaps a good solution, if inexpensive cable or DSL internet is available, having one for general Internet and one for VPN. (Plus you can cover loss of one on the other.) Further, if you can "understand" different VPN traffic, you can use just the dedicated VPN Internet connection for critical VPN traffic and send other non-important (for performance) VPN traffic (e.g. backups) across the general Internet connection.

PS:

Allan makes a good point. If your outbound interface is Ethernet, you really need to shape to the supported bandwidth. If you have a physical interface that's ties directly to the supported bandwidth, shaping is unnecessary.

[allan.thomas]

Have you considered using nested service policies together with shaping on your outbound Branch WAN interfaces?

This could improve your overall link efficiency? However, this is largely dependant on whether congestion is always prevalent on the link?

This alternative will provide you with bandwidth guarantees for your respective classes during periods of congestion, and also provide average rate shaping upto the link size of 1024Kbps.

Although you can specifically configure peak-rate shaping which will also traffic to burst above the CIR, this can result in higher packets drops during congestion, hence it is more suitable to opt for average.

Take a look at the following example in your case:-

policy-map WAN_OUT_1Mbps

class VPN_TRAFFIC_CM

priority percent 80

class class-default

fair-queue

policy-map Shape_WAN_OUT_1Mbps

class class-default

shape average 1000000

service-policy WAN_OUT_1Mbps

In this example, if and when the traffic exceeds the shape rate, the VPN_TRAFFIC_CM class is guaranteed their 80%, and the class-default traffic at the child level incurs the drops.

The policy Shape_WAN_OUT_1Mbps is applied to the outbound WAN interface in this case.

HTH

Allan.