LLQ for 9200 switch and isr 4331

[skulikov944]

Hi. I have a task to configure traffic prioritization, since the topic is very big, I don't really understand which solution in combination would be the best for me qos, llq, maybe something else... Please help.

1. I have a channel from an ISP of 300 megabits that comes into isr4331, I have a 9200 connected to the router where the end subscribers sit in their vlan and access points, 10 pieces.
2. In some offices there are up to 200 people who in large numbers can run simultaneous video conferencing sessions on different intercoms, cloud solution. With a large number of people there are delays in video, that is, I see a problem, the channel is loaded to the maximum.
My task is to make everyone feel comfortable, that is the main priority to give video traffic, but I do not understand how to do this.

At the moment I have such a configuration on the router isr4331:

Spoiler

class-map match-all bandwidth-traffic
match any
!
policy-map bandwidth-policy
class bandwidth-traffic
police cir 250000000 bc 10000000 be 20000000
conform-action transmit
exceed-action drop

interface GigabitEthernet0/1/0
description *ISP_01*
ip address 172.16.1.1 255.255.255.0
ip nat outside
ip access-group ACL_FOR_RESTRICT_WAN in
negotiation auto
service-policy input bandwidth-policy
service-policy output bandwidth-policy

Actually, I plan to do something like this on the switch, but i'm not sure:

Spoiler

class-map match-any VIDEO
match ip dscp af41

policy-map VIDEO-QOS
class VIDEO
priority percent 50
queue-limit 100
class class-default
queue-limit 100

interface GigabitEthernet1/0/1
description *TO ISR 4331*
service-policy input VIDEO-QOS
service-policy output VIDEO-QOS

In general, I can not figure out where I need to configure it all on the switch or router and how to properly make the overall channel restriction and whether it is necessary and prioritize the video traffic for video conferencing .

[Joseph W. Doherty]

For now, lets ignore the switch, as from what you've described, 300 Mbps ISP connection is your likely bottleneck.

Regarding your policy, first try the following (which we can monitor its impact and amend as needed):

class-map match-all bandwidth-traffic
match any
!
policy-map bandwidth-policy
class bandwidth-traffic
police cir 250000000 bc 10000000 be 20000000
conform-action transmit
exceed-action drop
class class-default
shape average 255000000
service-policy bandwidth-policy-priorization

policy-map bandwidth-policy-priorization
class class-default
fair-queue

interface GigabitEthernet0/1/0
description *ISP_01*
ip address 172.16.1.1 255.255.255.0
ip nat outside
ip access-group ACL_FOR_RESTRICT_WAN in
negotiation auto
service-policy input bandwidth-policy
service-policy output bandwidth-policy

[Joseph W. Doherty]

BTW, for QoS to be fully effective, it needs to manage bandwidth in both directions, unfortunately, an ingress policer is far, far from an optimal way to manage ingress bandwidth.

For your egress management, the prior can be much improved, depending on how much bandwidth your video conferencing will actually use.  To use such an improvement, you'll need to be able to identify all the video traffic you want to treat better.  Can you?  (Also, if you do get into policing ingress, you'll also need to identify the same video traffic.)

Again, not knowing video bandwidth requirements and/or whether you can identify video traffic, the policy I provided is possibly the best approach unless you can provide answers to those questions (i.e. bandwidth needed and what's video traffic, exactly?)

[skulikov944]

Hi Joseph!
Thank you very much for your recommendations, I immediately changed my configuration to your version and plan to see how the situation will change further.
Of course, the requirements for videoconferencing are as follows

Bandwidth requirements for my videoconference:

Data type                                           Bandwidth for 1 on 1 video meetings (outbound / inbound)
Audio only                                         205 Kbps
Audio + Video                                    3072 Kbps
Audio + Video + Screen Presentation 3072 Kbps

Also I wanted to ask you what to do in this case with input traffic, when I try to apply it to gi0/1/0 I get this error:
The input command is not supported in the input direction for this interface.
Failed to configure on GigabitEthernet0/1/0

service-policy input unfortunately doesn't work for shape,percentage,bandwidth, it's strange why it's like that in isr4331.

[Joseph W. Doherty]

Is the 3 Mbps average or max possible?  How many concurrent (and max) video sessions might be running?

Regarding unable to apply policy I provided, inbound, yup, that's correct.  You cannot use a policy that does "queuing" stuff, inbound.

If your ISP has an inbound 300 Mbps cap, you should only need to "worry" about QoS if such a 300 Mbps will transit an interface offering less bandwidth, and, ideally, would be applied at that bottleneck, or you're trying to "reserve" bandwidth, inbound.

E.g. if you wanted to "guarantee" 100 Mbps, for ingress video, you might police, on ingress, all non-video traffic to 200 Mbps.  (Although easy enough to configure, it has some "issues".  First, your non-video traffic is always limited to 200 Mbps, even if more bandwidth is available [i.e. being unused by video], and it assumes your video will not need more than 100 Mbps [reasons why knowing maximum number of video flows and their peak bandwidths is important] and the policer is downstream policing, i.e. non-video traffic can exceed 200 Mbps before it gets to the policer - i.e. video bandwidth not really guaranteed.)

[skulikov944]

Joseph, thanks for the explanation, I started to understand the general concept.

About the traffic:
1. Is the 3 Mbps average or max possible?

If we are talking about http(s), the requirements are the same and it is max possible.
Data type                                          Bandwidth for 1 on 1 video meetings (outbound / inbound)
Audio only                                         205 Kbps
Audio + video                                    3072 Kbps
Audio + Video + Screen presentation 3072 Kbps

If we're talking about the desktop version, the requirements are slightly different (I just found out about it...) and also the maximum possible:

Data type                                          Bandwidth for 1 on 1 video meetings (outbound / inbound)
Audio only                                         512 Kbps
Audio + video                                    3584 Kbps
Audio + Video + Screen Presentation 3584 Kbps

2. How many concurrent (and max) video sessions might be running?

An average of about 20 sessions, with a maximum of about 35. But sometimes we have big meetings where one person is broadcasting somewhere and everyone in the office, say 100 people, are connected from the office and listening, so that means 100 connections.

My main concern is that the channel is evenly distributed and always available for video because we often have this critical traffic. I don't want to have a situation where one person decides to download something, say 30gb from cloud storage, and the second person decides to upload something and starts uploading 30gb as well, so those two people don't kill the whole channel for the same video.
Do I need to add something else to the config in this case, or strengthen it somehow?

[Joseph W. Doherty · Accepted solution]

"Do I need to add something else to the config in this case, or strengthen it somehow?"

Possibly, yes.  Further, you may need to coordinate when there's going to be large number of concurrent users, and manually reconfigure to support them, this to avoid the negative impact of such QoS settings for your "usual" day-to-day operations.

Again, we can setup QoS to (more or less) not have any negative impact for egress toward your ISP.  "Protecting" ingress, from your ISP, is where QoS, to guarantee good performance for video, can be very adverse to your other traffic even when there's no video.

BTW, double check where those bandwidths are truly "maxes", as often "averages" are quoted.  Ideally, we want to know both average and max for planning purposes.

Working backwards, your WAN port policies will be something like:

interface GigabitEthernet0/1/0
service-policy input in-bandwidth-policy
service-policy output out-bandwidth-policy

!you need to be able to, somehow, identify your video traffic (often composite, video + audio combined, but if they can be told apart, might want separate classes for each)

class-map match-all/any video-traffic
match ???
match ???

policy-map in-bandwidth-policy
class video-traffic
class class-default
police # (value is total bandwidth less what we want to set aside for video - e.g. 300 less 100 for video = 200)

policy-map out-bandwidth-policy
class class-default
shape average 255000000 !try nominal link bandwidth less 15% - assumes L2 overhead not counted by shaper
service-policy out-bandwidth-policy-prioritization

policy-map out-bandwidth-policy-prioritization
class video-traffic !whatever video doesn't used is available for other traffic - this, BTW, is LLQ
priority level 2 !voip would use level 1 - I'm also assuming your 4K's IOS is new enough to accept this command
police percent # !up to about 50
class class-default
fair-queue

For an example of bandwidth allocation for video, 35 x 3.5 Mbps, is about 125 Mbps, or about 40% if your link's bandwidth.  Configured for that value, again, ingress QoS sets asides that bandwidth for exclusive video usage!

[skulikov944]

Thx a lot Joseph that helped me!

[Joseph W. Doherty]

You're most welcome, and, although I didn't explicitly mention this, but in the case of 100 sessions, which are only "listening" sessions, i.e. only using .5 Mbps or less, your bandwidth allocation planning can use audio bandwidths for what you need to set aside.  E.g. 100 * .5, would need about 50 Mbps.  (This also means, your worst case, if this is a worst case, won't be as demanding for needed bandwidth vs. as up to 35 needing 3.5 Mbps [video] each.)

If any other questions arise, depending on the question, either follow-up on this topic, or post a whole new topic.  Lots and lots of knowledgeable, and helpful, folk contribute to these forums!

[Joseph W. Doherty]

Great!  And, down the road, please try post how it all went, either good or bad (hopefully the former).