05-14-2008 11:45 AM - edited 03-05-2019 10:59 PM
We are at early days, but it looks like we have a bit of an issue with QoS marking.
We have a client that wants several levels of QoS, and we have a cat3650 as access switch.
We have traffic that should be TCP, but when we ran it from a traffic generator, we did not get the traffic marked.
When we changed the access list to UDP, and generated traffic on the UDP port, it got marked.
The following marking config has been tested and seen to only work with VOICE class-map:
class-map match-all TRANSACTIONAL_DATA
match access-group name TRANSACTIONAL_DATA
class-map match-all IPTV
match access-group name IPTV
class-map match-all CALL_SIGNALLING
match access-group name CALL_SIGNALLING
class-map match-all VOICE
match access-group name VOICE
!
!
policy-map USER_QOS
class VOICE
police 384000 8000 exceed-action drop
set dscp ef
class CALL_SIGNALLING
set dscp cs3
police 32000 8000 exceed-action policed-dscp-transmit
class TRANSACTIONAL_DATA
set dscp af21
police 64000 8000 exceed-action policed-dscp-transmit
class class-default
police 10000000 8000 exceed-action policed-dscp-transmit
policy-map IPTV_SOURCE
class IPTV
set dscp cs4
class class-default
police 10000000 8000 exceed-action policed-dscp-transmit
ip access-list extended CALL_SIGNALLING
permit tcp 10.1.110.0 0.0.0.127 any range 1719 1720
ip access-list extended IPTV
permit tcp 10.1.20.0 0.0.0.127 any eq 1234
ip access-list extended TRANSACTIONAL_DATA
permit tcp 10.1.20.0 0.0.0.127 any eq 1494
permit tcp 10.1.20.0 0.0.0.127 any eq 2598
ip access-list extended VOICE
permit udp 10.1.110.0 0.0.0.127 any range 2048 6028
Thanks,
Paul.
05-15-2008 10:25 AM
Hi,
when this does not work for TCP, are you seeing "hits" on the actual ACL for the TCP traffic?? Without a match, it'll never be marked.
Also, are you using a sniffer to decode the DSCP values? What value do you see for the unmarked traffic? i.e. what did it default to?
05-15-2008 01:01 PM
Hi Paul, Just noticed that police statement comes first in the policy-map and set dscp ef is going after that... can you change it so set comes first and try again??
-serg
05-16-2008 01:46 AM
This is a 'feature' of the Catalyst 2960, 3560 and 3750 with QoS policies - they don't increment counters. When you issue the command 'show policy-map interface x/x' none of the counters work, this is a known and well documented 'feature'. The only counters you have are 'show mls qos interface x/x statistics' and 'show platform port-asic stats enqueue fastethernet x/x' and 'show platform port-asic stats drops fastethernet x/x'.
Andy
05-24-2008 07:19 AM
It's definitely not a feature, but a hardware caveat we are not able to get around in software. I think we should finally have a CLI warning about this command soon, it is all over the config guides that "show policy-map interface" is not supported though.
Note "show access-list" is also not a great way to troubleshoot on most switches, as they cannot update the counters at the rate frames go through the box.
Regards,
John Gill
05-23-2008 02:26 AM
Thanks for the suggestions. The 3560 was working exactly as it was configured to do, but the traffic did not match the definition.
On the LAB based testing, the tester was unusual - it needed ports entering in Hex for the TCP cvonnections, but decimal for UDP, so a simple change to TCP did not provide expected results.
The other issue was that the call signalling we werte tring to match was using the port not as we expected as a destination port, but as a source port!
Thanks for suggestions,
Paul.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: