LinkBack URL
About LinkBacks
Cisco VOIP QoS Policy Review
Reply With QuoteI've found that with QoS, it's important to keep the original configuration. The output of 'show run' is so mixed around that it's hard to really get a feel for what's going on. So first, let me reorganize and filter. At the minimum, this will show how I think things through in my head.
Mind you, I'm not expert on QOS, though I play one on TV.
Code:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Step 1: Classify on ingress.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! ACL 120 is undefined, and BRIX-Probe is unused... This should be removed for housekeeping purposes.
class-map match-any BRIX-Probe
match access-group 120
! Voice traffic will be assigned EF
class-map match-any Voice-Traffic
match protocol rtp audio
match protocol sip
! Interactive traffic will be assigned AF31
class-map match-any Interactive-Traffic
match protocol citrix
match access-group 101
match protocol rtcp
match protocol rtsp
match protocol telnet
match protocol rtp video
! DCOS_Classify is used to mark packets on ingress
policy-map DCOS_Classify
class BRIX-Probe
class Voice-Traffic
set ip dscp ef
class Interactive-Traffic
set ip dscp af31
class class-default
set ip dscp default
! Assign to interfaces. I think you only need this on fa0/0.1, and it's unnecessary on
! fa0/0, but would need to test to verify.
interface FastEthernet0/0
description Connection to Switch
service-policy input DCOS_Classify
!
interface FastEthernet0/0.1
service-policy input DCOS_Classify
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!
! Step 2: Identify and treat classes differently on egress
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!
class-map match-any Multimedia-EF
match ip dscp ef
class-map match-any Interactive-AF31
match ip dscp af31
! DCOS_Queue is used within the next policy-map... applying back pressure?
! Gives AF31 traffic 30% of the 800kbps assigned
policy-map DCOS_Queue
class Interactive-AF31
bandwidth remaining percent 30
class class-default
fair-queue
random-detect dscp-based
! DCOS_ShapeAndQueue is applied on egress
! Gives voice traffic 3.5Mbps of priority queue
! Gives remaining traffic 800kbps of remaining traffic
policy-map DCOS_ShapeAndQueue
class Multimedia-EF
priority 3500
class class-default
shape average 800000
service-policy DCOS_Queue
!
interface FastEthernet0/1
description WAN Connection
bandwidth 10240
service-policy output DCOS_ShapeAndQueue
First, I need to plead ignorance on the policy-map within a policy-map stuff. I've read about it being used to provide back-pressure, but that doesn't seem appropriate in this case.
Looking at the DCOS_ShapeAndQueue, what I think is happening is that voice traffic is being allocated and limited to 3.5Mbps, while remaining traffic is being shaped to 800kbps. Of that 800kbps, 30% is being allocated to AF31. The combination of these things seems wasteful, but I might not understand the process correctly.
Regarding your comments:
reloadin10 wrote:
1. RTCP, h323, skinny, mgcp and tftp are missing from the Voice-Traffic class-map.
Frankly, I would remove sip from the voice traffic class. You want to guarantee it bandwidth, but you don't want it competing with the actual RTP stream since it isn't delay or jitter sensitive. Throw SIP, H.323, and Skinny traffic into their own "Voice Control Traffic" and mark them AF41 or AF31. Leave tftp and similar to class default since they can usually take their time.
Quote:
2. Voice-traffic is not included in the DCOS_ShapeAndQueue and so it is ends up in the default queue rather than the EF queue.
Voice-Traffic is marked EF on ingress, and DCOS_ShapeAndQueue handles EF first. This seems right to me. Again, I'm not an expert, so I might be missing something, but I think the voice traffic is being handled correctly (other than it including the control traffic)
Quote:
Is there anything else I am missing? Are there any other improvements that can be made?
Tons of improvements can be made. QoS is never done. I'll have to sort through your 'show' commands at a later time.
My thoughts are:
(1) Voice Control should be assigned to a class, and allocated its own bandwidth.
(2) I think you're artificially limiting your 10Mbps connection to 4.3Mbps, at least in times of congestion. This may or may not be what was intended, and I may not understand the policy-map-within-policy-map behavior correctly, but it seems like you'd be better off using a 'bandwidth' reservation for the Interactive-AF31 class and then using fair-queue within class-default and getting rid of the recursive QoS (Unless you are trying to create back-pressure toward your LAN, which maybe you are, but you're probably missing a 0).
(3) Remove the BRIX-Probe stuff, since it appears to be unused.
Letting the rest fall into class default is fine, but you may also want to consider assigning certain bulk traffic (FTP, P2P, SMTP, etc) to a scavenger class and assigning it a smaller bandwidth reservation (if not shaping or policing it).
Again, you need to do your own research. I haven't yet formally studied this stuff, so this is all based on vague understanding. Don't quote me on any of this.
Bookmarks