QoS

[Jerome C.]

Hello

I would like to have your opinion/help. I want to put in place QoS because, sometimes, we have issues with our ToIP. I want to deploy a QoS to reserve a % of bandwidth when our WAN link (50Mbps) is statured. 

I have this configuration on my core switches to mark trafic with specific dscp value (ToIP/Videoconf system = AF31, networks for servers = AF21,..). Regarding queue conf, I'm not familar and I'm not sure about the conf...

switch core conf

---------------

mls qos srr-queue output cos-map queue 1 threshold 3 5
mls qos srr-queue output cos-map queue 2 threshold 1 2 4
mls qos srr-queue output cos-map queue 2 threshold 2 3
mls qos srr-queue output cos-map queue 2 threshold 3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3 0
mls qos srr-queue output cos-map queue 4 threshold 3 1
mls qos srr-queue output dscp-map queue 1 threshold 3 46
mls qos srr-queue output dscp-map queue 2 threshold 1 16 18 20 22 25 32 38
mls qos srr-queue output dscp-map queue 2 threshold 2 24 26
mls qos srr-queue output dscp-map queue 2 threshold 3 48 56
mls qos srr-queue output dscp-map queue 3 threshold 3 0
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos srr-queue output dscp-map queue 4 threshold 3 10 12 14
mls qos queue-set output 1 threshold 2 70 80 100 100
mls qos queue-set output 1 threshold 4 40 100 100 100
mls qos
!
class-map match-any CM_REALTIME_VOICE_TOIP
description Infra Voice Flows
match access-group name ACL_REALTIME_VOICE_TOIP
class-map match-any CM_PREMIUM_VIDEO_SKYPE
description Skype Video Flows
match access-group name ACL_PREMIUM_VIDEO_SKYPE
class-map match-any CM_PREMIUM_VIDEOCONFERENCE
description Infra Video Flows
match access-group name ACL_PREMIUM_VIDEOCONFERENCE
class-map match-any CM_REALTIME_VOICE_SKYPE
description Skype Voice Flows
match access-group name ACL_REALTIME_VOICE_SKYPE
class-map match-any CM_DSCP-IN-D2INP
description Standard Data Flows
match access-group name ACL_DSCP-IN-D2INP
class-map match-any CM_DSCP-IN-D3INP
description Miscellaneous Data Flows
match access-group name ACL_DSCP-IN-D3INP
class-map match-any CM_PREMIUM_D1INP
description Premium Data Flows
match access-group name ACL_PREMIUM_D1INP
!
policy-map PM_QOS_MARKING_ACCESS
class CM_REALTIME_VOICE_TOIP
set dscp af31
class CM_REALTIME_VOICE_SKYPE
set dscp af31
class CM_PREMIUM_VIDEO_SKYPE
set dscp af31
class CM_PREMIUM_VIDEOCONFERENCE
set dscp af31
class CM_PREMIUM_D1INP
set dscp af31
class CM_DSCP-IN-D2INP
set dscp af21
class CM_DSCP-IN-D3INP
set dscp af11
class class-default
!
ip access-list extended ACL_CIMPA_DSCP-IN-D2INP
deny ip any any fragments
remark == standard ACL conf
permit ip 192.168.1.0 0.0.0.255 any
permit ip any 192.168.1.0 0.0.0.255
permit ip 192.168.2.0 0.0.0.255 any
permit ip any 192.168.2.0 0.0.0.255
deny ip any any
ip access-list extended ACL_CIMPA_DSCP-IN-D3INP
permit tcp any any eq ftp
permit tcp any eq ftp any
permit tcp any any eq ftp-data
permit tcp any eq ftp-data any
permit udp any any eq tftp
permit udp any eq tftp any
permit tcp any any eq smtp
permit tcp any eq smtp any
permit tcp any any eq 989
permit tcp any eq 989 any
permit tcp any any eq 990
permit tcp any eq 990 any
deny ip any any
ip access-list extended ACL_CIMPA_PREMIUM_D1INP
deny ip any any fragments
permit udp any 192.168.3.0 0.0.0.255 eq snmp
permit udp 192.168.3.0 0.0.0.255 any eq snmp
permit udp 192.168.3.0 0.0.0.255 any eq snmptrap
permit udp any 192.168.3.0 0.0.0.255 eq snmptrap
deny ip any any
ip access-list extended ACL_CIMPA_PREMIUM_VIDEOCONFERENCE
deny ip any any fragments
permit ip 192.168.4.0 0.0.0.255 any
permit ip any 192.168.4.0 0.0.0.255
deny ip any any
ip access-list extended ACL_CIMPA_PREMIUM_VIDEO_SKYPE
deny ip any any fragments
permit udp any range 50020 50039 any eq 3478
permit udp any range 50020 50099 any range 50000 59999
permit tcp any range 50020 50039 any eq 443
permit tcp any range 50020 50039 any range 50000 59999
deny ip any any
ip access-list extended ACL_CIMPA_REALTIME_VOICE_SKYPE
deny ip any any fragments
permit udp any range 50000 50019 any eq 3478
permit udp any range 50000 50019 any range 50000 59999
permit tcp any range 50000 50019 any eq 443
permit tcp any range 50000 50019 any range 50000 59999
permit udp any range 50000 50019 any eq 3479
deny ip any any
ip access-list extended ACL_CIMPA_REALTIME_VOICE_TOIP
remark == To exlcude fragmented packets
deny ip any any fragments
permit ip 192.168.4.0 0.0.0.255 any
permit ip any 192.168.4.0 0.0.0.255
permit udp any range 16384 32767 192.172.1.0 0.0.1.255
deny ip any any

!

On my routeur, I have the following configuration. My goal is when our WAN link is satured (50Mbps), I have 20% of the bandwidth reserverd for the ToiP trafic to avoid bad performance, 40% of ramaining bandwidth not used by ToIP for servers trafic, etc... Is my configuration is correct ?

Router conf

--------- 

class-map match-all CRITICAL
match ip dscp af31
class-map match-all PRIORITY
match ip dscp af21
class-map match-all PREMIUM
match ip dscp af11
!
policy-map LAN-policy
  class CRITICAL
    priority percent 20
 class PRIORITY
    bandwidth remaining percent 40
 class PREMIUM
    bandwidth remaining percent 30
 class LOW
    bandwidth remaining percent 20
 class class-default
    fair queue
policy-map shape_50M
  class class-default
  shape average 50000000
  service-policy LAN-policy
!
interface GigabitEthernet0/0
description WAN-IF
ip address xx.xx.xx.xx 255.255.255.248
no ip redirects
no ip proxy-arp
ip ospf message-digest-key 1 md5 7 xxxxxxxxx
load-interval 30
service-policy output shape_50M

BR

Jerome

[droten]

This policy-map will assure that you always have 25% of the parent bandwidth (50Mb/sec * 25% = 12.5 Mb/sec) available for CRITICAL class traffic. It also ensures that PRIORITY, PREMIUM and class-default will always have a minimum level of traffic available even during congestion at the parent.
It does NOT prevent the CRITICAL traffic from virtually starving out all the other classes if CRITICAL traffic stays below 50Mb/sec. If you want a hard limit on CRITICAL, then use naked priority with a policer which will always rate limit critical traffic even when the parent is undersubscribed.
This policy will allow any of the classes to use all of the bandwidth, but as soon as another class presents any traffic it will be permitted at least up to the bandwidth remaining value and most likely higher due depending on exact profile of injected traffic.
Also, it is NOT recommended to change queue-limit values for priority classes.
Best practice would be to specify the queue-limits for the non-priority classes in units of milliseconds. This gives a predictable latency profile even with variable size packets moving through the queues.

[Jerome C.]

So based on my current configuration, is-it possible to request you to suggest modification about my conf ? 

BR

[Joseph W. Doherty]

"It does NOT prevent the CRITICAL traffic from virtually starving out all the other classes if CRITICAL traffic stays below 50Mb/sec"

Oh, did Cisco eliminate CBWFQ's implicit policer?

"Also, it is NOT recommended to change queue-limit values for priority classes."

Yea, although OP is also placing "unusual" traffic into the LLQ. I.e. it's more likely to burst congest then the typical LLQ like VoIP, and it's also likely to be less sensitive to additional queuing latency. Personally, from the one set of stats OP has posted, I think increasing queue depth for this class is unnecessary, but unsure in this case it would be harmful.

"Best practice would be to specify the queue-limits for the non-priority classes in units of milliseconds. "

Great suggestion, but note, millisecond option not available on older CBWFQ implementations.

[Joseph W. Doherty]

". . . I can reach my main objective to guarantee always 25% of the WAN link (50Mbps) for Critical traffic (ToIP, Skype, Videoconferencing system) and to avoid to have dropped packet for all class ?"

Yes to 25% guarantee, no to avoid drops for all classes. Understand, QoS often take bandwidth from one less important class to provide it to another more important class. So, often you lower the chance of drops for your more important traffic but increase the chance of drops for your less important traffic. Further, TCP traffic, by its nature, attempts to use the max available bandwidth connected to the sending host's port, which, especially combined with other concurrent flows will often exceed your WAN bandwidth. Originally, TCP replied on detecting drops to determine how much available bandwidth there is. I.e. some drops with TCPs is to be expected. However, later TCP implementations also watch for a sharp increase in RTT and assume traffic is being queued. If these TCP implementations detect that, they back off their transmission rate, hopefully before your queues overflow and you begin to drop packets.

"And be certain that traffic generated by the class Priority, Premieux, default-class will never used all bandwidth ?"

Not with your current policy. However, that generally is a good thing!  I.e. a class can take advantage of otherwise unused bandwidth. What a typical policy does, is it insures a certain amount of minimum bandwidth, per class.

BTW, I recall your FQ drop stats show per flow drops. Some CBWFQ implementation also support a per flow queue depth setting, but I don't recall the command.

---

[Jerome C.]

Hello,

When I run the command "show policy-map int gi0/0", I have this result :

GigabitEthernet0/0

Service-policy output: shape_50M

Class-map: class-default (match-any)
2338628708 packets, 1460505617396 bytes
30 second offered rate 50383000 bps, drop rate 466000 bps
Match: any
Queueing
queue limit 128 packets
(queue depth/total drops/no-buffer drops) 81/4860117/0
(pkts output/bytes output) 2334759778/1455483046040
shape (average) cir 50000000, bc 200000, be 200000
target shape rate 50000000

Service-policy : LAN-policy

queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 328318804/129404262244

Class-map: CRITICAL (match-all)
328349726 packets, 129450232209 bytes
30 second offered rate 3576000 bps, drop rate 0000 bps
Match: ip dscp af31 (26) ef (46)
Priority: 25% (12500 kbps), burst bytes 312500, b/w exceed drops: 30922

Class-map: PRIORITY (match-all)
1293249390 packets, 1033673007666 bytes
30 second offered rate 6479000 bps, drop rate 50000 bps
Match: ip dscp af21 (18)
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/2775278/0
(pkts output/bytes output) 1290474100/1030179999708
bandwidth remaining 45%

Class-map: PREMIUM (match-all)
289010 packets, 302770117 bytes
30 second offered rate 1000 bps, drop rate 0000 bps
Match: ip dscp af11 (10)
Queueing
queue limit 128 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 289010/302770117
bandwidth remaining 35%

Class-map: class-default (match-any)
716740584 packets, 297079604402 bytes
30 second offered rate 40325000 bps, drop rate 405000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 80/2053917/0/2053917
(pkts output/bytes output) 715677864/295596013971
bandwidth remaining 20%
Fair-queue: per-flow queue limit 16 packets

Is-it a problem to have some trafic droped for class Critical ? This class is used for our voice traffic and visioconference.

About my QoS, I have this conf :

!

class-map match-all CRITICAL
  match ip dscp af31 ef
class-map match-all PRIORITY
  match ip dscp af21
class-map match-all PREMIUM
  match ip dscp af11
!
policy-map LAN-policy
  class CRITICAL
    priority percent 25
  class PRIORITY
    bandwidth remaining percent 45
  class PREMIUM
    bandwidth remaining percent 35
    queue-limit 128 packets
  class class-default
     bandwidth remaining percent 20
     fair-queue
     queue-limit 128 packets
policy-map shape_50M
  class class-default
    shape average 50000000
    queue-limit 128 packets
      service-policy LAN-policy

!

interface GigabitEthernet0/0
description WAN-IF
ip address xx.xx.xx.xx 255.255.255.248
no ip redirects
no ip proxy-arp
load-interval 30
service-policy output shape_50M

!

BR

[Joseph W. Doherty]

"Is-it a problem to have some trafic droped for class Critical ? This class is used for our voice traffic and visioconference."

Maybe, maybe not, as your CRITICAL class drop percentage is low. What are users reporting for VoIP and video conferencing quality? Do you VoIP phones, or anything else, report a MOS score?

However for VoIP and/or real-time video, generally the goal is to not have any drops. I recall Cisco recommends going up to 1/3 of a link for LLQ, so you can bump your priority percentage up to 30 or 33% and see the results. If users, though, are not reporting any problems, you can leave it as is.

Your PRIORITY and class-default classes are dropping quite a bit.

For class-default, you might try doubling the overall queue limit and the per-flow queue limits.

For PRIORITY you might also double its queue-limit and/or consider implementing FQ. You might also reduce the class-default bandwidth allocation and give it to PRIORITY (the latter depends on just how importnat PRIORITY is over the class-default).