01-09-2013 10:28 AM - edited 03-04-2019 06:39 PM
We have a pretty simple QoS policy on our network :
class-map match-any signal
match ip dscp cs5
class-map match-any rtp
match ip dscp cs3
policy-map simple-qos
class rtp
set ip dscp cs3
priority percent 70
class signal
set ip dscp cs5
bandwidth percent 5
I run the command show policy-map interface multilink1 (the interface its set on)
Service-policy output: simple-qos
Class-map: rtp (match-any)
26104 packets, 2956252 bytes
5 minute offered rate 9000 bps, drop rate 0 bps
Match: ip dscp cs3 (24)
26104 packets, 2956252 bytes
5 minute rate 9000 bps
QoS Set
dscp cs3
Packets marked 26104
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 70 (%)
Bandwidth 4300 (kbps) Burst 107500 (Bytes)
(pkts matched/bytes matched) 168/23716
(total drops/bytes drops) 0/0
Class-map: signal (match-any)
2133 packets, 1818542 bytes
5 minute offered rate 16000 bps, drop rate 0 bps
Match: ip dscp cs5 (40)
2133 packets, 1818542 bytes
5 minute rate 16000 bps
QoS Set
dscp cs5
Packets marked 2133
Queueing
Output Queue: Conversation 265
Bandwidth 5 (%)
Bandwidth 307 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 15/11107
(depth/total drops/no-buffer drops) 0/0/0
dscp Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
af11 0/0 0/0 0/0 32 40 1/10
af12 0/0 0/0 0/0 28 40 1/10
af13 0/0 0/0 0/0 24 40 1/10
af21 0/0 0/0 0/0 32 40 1/10
af22 0/0 0/0 0/0 28 40 1/10
af23 0/0 0/0 0/0 24 40 1/10
af31 0/0 0/0 0/0 32 40 1/10
af32 0/0 0/0 0/0 28 40 1/10
af33 0/0 0/0 0/0 24 40 1/10
af41 0/0 0/0 0/0 32 40 1/10
af42 0/0 0/0 0/0 28 40 1/10
af43 0/0 0/0 0/0 24 40 1/10
cs1 0/0 0/0 0/0 22 40 1/10
cs2 0/0 0/0 0/0 24 40 1/10
cs3 0/0 0/0 0/0 26 40 1/10
cs4 0/0 0/0 0/0 28 40 1/10
cs5 0/0 0/0 0/0 30 40 1/10
cs6 123/9514 0/0 0/0 32 40 1/10
cs7 0/0 0/0 0/0 34 40 1/10
ef 178916/12200070 0/0 0/0 36 40 1/10
rsvp 0/0 0/0 0/0 36 40 1/10
default 472679/71233103 0/0 0/0 20 40 1/10
If im reading correctly, the policy map is matching cs3/cs5 packets correctly but why don't I see them being calculated under transmitted packets? I also see that cs6/ef packets are being calculated, does that mean packets with dscp set to ef/cs6 are being transmitted outbound by this interface?
Solved! Go to Solution.
01-09-2013 12:36 PM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Since the complete policy map and show policy results aren't posted, but from what you have posted (2nd posting helped - thanks) . . .
"If im reading correctly, the policy map is matching cs3/cs5 packets correctly but why don't I see them being calculated under transmitted packets? I also see that cs6/ef packets are being calculated, does that mean packets with dscp set to ef/cs6 are being transmitted outbound by this interface?"
. . . I believe the answers to your questions are:
The transmitted stats are probably from random-detect (DSCP) in the class-default. If correct, those stats would only apply to packets in this (default) class. As your two other classes have already "snagged" cs3 and cs5, would be why they wouldn't show in these stats.
Yes, it appears CS6 and EF packets are being transmitted out your interface. CS6 is likely for routing control packets (running any dynamic routing protocol?). EF marked packets might be VoIP bearer packets (what's CS3 or CS5 used by - any VoIP signally?).
01-09-2013 10:45 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
You've listed the complete policy and all the show policy output? Reason I ask, from your output, it almost looks like you should have an explicit class-default with DSCP based WRED.
BTW, why are you setting ToS to the same DSCP you matched the packet on?
What platform and IOS is this?
01-09-2013 10:51 AM
No its not the complete policy only because I edited out some information, if you need to see that as well here it is:
Class-map: class-default (match-any)
651718 packets, 83442687 bytes
5 minute offered rate 442000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0
exponential weight: 9
It was someones previous config, why they made it like that I'm not sure, I plan to change it around to just match cs3/cs5 not match and then set to the same DSCP.
Platform is on 1841 router IOS 12.4(25f)
01-09-2013 12:36 PM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Since the complete policy map and show policy results aren't posted, but from what you have posted (2nd posting helped - thanks) . . .
"If im reading correctly, the policy map is matching cs3/cs5 packets correctly but why don't I see them being calculated under transmitted packets? I also see that cs6/ef packets are being calculated, does that mean packets with dscp set to ef/cs6 are being transmitted outbound by this interface?"
. . . I believe the answers to your questions are:
The transmitted stats are probably from random-detect (DSCP) in the class-default. If correct, those stats would only apply to packets in this (default) class. As your two other classes have already "snagged" cs3 and cs5, would be why they wouldn't show in these stats.
Yes, it appears CS6 and EF packets are being transmitted out your interface. CS6 is likely for routing control packets (running any dynamic routing protocol?). EF marked packets might be VoIP bearer packets (what's CS3 or CS5 used by - any VoIP signally?).
01-09-2013 01:40 PM
Makes sense, I didn't think about that.
I didn't notice dynamic routing but it doesn't mean theres not some stale configuration in there, I'll have to check.
Yes CS3 is used for RTP and CS5 for Signaling on our network, which is what led me to wonder where all the EF tagged traffic is coming from. I suspect something configured incorrectly. Nothing some wireshark and a mirrored port can't find.
Thanks.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide