QOS on WAN link

[Skevich17]

HELLO!

I want to configure QOS on cisco router/ASA, that is facing ISP. Is it possible to somehow control bandwidth form ISP in such a way, that my important traffic (voice,video conference) wont be eaten by other traffic (torrents and stuff)? I read about qos features, like congestion management and congestion avoidance, but it seems they can only control outbound traffic. Is there any way to prevent unimportant traffic, coming from ISP, from eating whole BW??

[Giuseppe Larosa · Accepted solution]

Hello @Skevich17 ,

you are right QoS tools provide control on oubound direction that is the upstream direction.

In order to achieve what you want you should cooperate with your ISP in order to avoid bandwidth excessive usage in downstream direction.

This would lead to a paid service to have the ISP make the QoS for your on the WAN link.

On your own you can try to police the traffic in the opposite direction for these non important applications for example inbound on the internal LAN interfaces.

However, it is limited what you can achieve using QoS tools like policers. Because if a play is allowed on youtube for example the user can see a video stream of 30 minutes that can use a lot of BW for all this time.

Hope to help

Giuseppe

[Joseph W. Doherty · Accepted solution]

"Is there any way to prevent unimportant traffic, coming from ISP, from eating whole BW??"

Sometimes there are, but it's a very much a "it depends" answer, and even when it works, it's often far from an optimal/ideal solution.

The best approach was already described by Giuseppe, i.e. have your ISP provide QoS on their side of the link, on their egress traffic.  My experience (dated, though) has been most ISPs won't support QoS, although they often will gladly sell you more bandwidth.

Giuseppe has described one technique, which is to police ingress traffic.  Not mentioned, you might also be able to shape ingress traffic, but not on the actual ingress link (shaping might be done on an "internal" egress port).  Both techniques rely on the sender detecting packet loss (and for shaping, possibly a jump in RTT) and then slowing transmission rate.

Another technique, might be to shape, egress ACK packets (or other flow control packets returning to sender).  Some senders, for some traffic, if they see they return flow control packets slowed, assume their stream is being slowed and may slow their transmission rate.

Lastly, some third party traffic management appliances can better shape return flow control packets and/or do things like spoof a receiver's TCP RWIN, again, to try to get senders to slow their transmission rate.  (Besides having some capabilities not found on Cisco network devices, even when such QoS capabilities overlap, they might do them "better" than a Cisco network device.)

[Skevich17 · Accepted solution]

Thanks for your answers guys!!!

"Another technique, might be to shape, egress ACK packets (or other flow control packets returning to sender).  Some senders, for some traffic, if they see they return flow control packets slowed, assume their stream is being slowed and may slow their transmission rate."

How can we shape only ACK packets? Can you write pls an example config of this?

"Giuseppe has described one technique, which is to police ingress traffic.  Not mentioned, you might also be able to shape ingress traffic, but not on the actual ingress link (shaping might be done on an "internal" egress port).  Both techniques rely on the sender detecting packet loss (and for shaping, possibly a jump in RTT) and then slowing transmission rate."

So, should we police or shape it to the same rate as we have from ISP, or less? Can you also post some example of this?

Even if its not a perfect solution, maybe it will help me right now.

And another thing. If I configure wred, do you think it can help to avoid traffic from ISP to grow and eat all BW? And where should i better configure it: on internal port or external port?

[Giuseppe Larosa · Accepted solution]

Hello @Skevich17 ,

my suggestion is to police inbound on the internal LAN interface(s) the non important traffic to a low rate so that it is unlikely it can use a lot of bandwdith in download.

For example let's suppose that you don't want to have the non important traffic to use more then 5 Mbps download.

The idea here is to police inbound on tne internal LAN interfaces the non important traffic to something like 250 Kbps or even 200 Kbps.

by doing this you create a bottleneck for upstream traffic that will influence the amount of traffic coming in the opposite direction.

This idea applies only to TCP based applications that need to receive ACK from the receiver or they will slow down.

For UDP traffic this method is not effective.

Hope to help

Giuseppe

[Joseph W. Doherty · Accepted solution]

"For UDP traffic this method is not effective."

BTW, policing UDP traffic, can cause some of it to slow down.  UDP, itself, has no flow control, but the application using it might have some form of its own flow control that will slow when it detects drops.

[Joseph W. Doherty · Accepted solution]

"How can we shape only ACK packets? Can you write pls an example config of this?"

ip access-list extended ACK

permit tcp any any ack

class-map match-all ACK

match access-group name ACK

policy-map ACK

class ACK

shape average 8000

interface g# !WAN link

service-policy output ACK

"So, should we police or shape it to the same rate as we have from ISP, or less? Can you also post some example of this?"

It needs to be less than ISP.  Often much less as also mentioned by Giuseppe.

ip access-list extended LoPri

permit ip !you determine what should be used to match

class-map match-all LoPri

match access-group name LoPri

policy-map LoPri

class LoPri

police average 8000

interface g# !WAN link

service-policy input LoPri

"And another thing. If I configure wred, do you think it can help to avoid traffic from ISP to grow and eat all BW? And where should i better configure it: on internal port or external port?"

WRED can only be used for egress.  I generally suggest only QoS experts use this feature.