I tried to set DSCP values to 2 applications, video and video conference, on cisco 3560 and cisco 2950 swtiches based on the source ip address of the servers.
So on the switches, I created an access-list to identify the servers' ip addresses.
Then I use "class-map match-any video" followed by "match access-group" for the access-list.
Then I use "policy-map policy1", then "class video" then "set dscp ef".
Finally I apply the policy to the INPUTS of all ports "service-policy input policy1"
But when I use a sniffer to sniff the ports, I see that the DSCP value is not "EF", instead it is "0x20, class 4".
Why is this so?
Where have I done wrongly?
Finally, on routers, where do I apply QOS policy? On input ports or output ports of routers?
It sounds like the required pieces are all there: class-map, policy-map, and service-policy applied inbound. So the traffic should be classified based on source ip, assigned the EF marking after being received at that inbound interface, and leave the device still marked as EF. Would it be possible to attach the entire config, minus any sensitive info such as passwords, community strings, ip's, etc.?
Maybe for a sanity check you could set that access-list to a permit any any, then look at the sniffer capture to see if you get the same behavior. If you then start to see marked packets, that would point to the access-list - just a thought.
For router QoS configuration, the recommendation is to perform classification as close to the source as possible, which would be on the inbound interface. Then you can perform scheduling/queuing such as LLQ on the outbound interface, based on the markings that you have applied inbound.
I know that is not much info, but if you could attach the config or provide additional info I would be happy to help as I can. Good luck!
Without seeing what you have in place so far, I'll see if I can answer some of those questions. If the switch connects to a router, then the outbound (egress) interface would in fact be that interface on the switch that connects to a router. Best practices dictate that the classification and marking should be done on the inbound (ingress) interface which connects the switch to the network where the host resides.
If you wanted to implement an end-to-end QoS solution, then you should configure QoS on every interface between the source and destination. This is because even FastE/GigE ports can become congested due to worm outbreak or DOS attack. But if all you want to do right now is guarantee bandwidth to the video traffic across the WAN, that can be accomplished by a) classifying and marking the video traffic as close to the source as possible, and b) configuring queuing/scheduling on the outbound WAN interface based on those markings.
Once the switch has marked the traffic with a DSCP value per (a), that DSCP value should remain intact until it reaches the WAN router per (b), and all the way until it reaches its destination. That is, unless there is a device somewhere in between that is remarking traffic. If the switch you reference is not directly connected to the router you reference, there could be another switch or router in between marking everything back to DSCP 0, meaning that all traffic is untrusted.
I don't have a 2950 here with me, but without checking syntax this is basically what you should have, if you just want to mark video traffic EF and then guarantee bandwidth on the wan:
2950:
access-list permit
class-map match-any VIDEO
match access-group
policy-map POLICY1
class VIDEO
set ip dscp 46 !
interface
service-policy input POLICY1
Router:
class-map match-any EF_VIDEO
match ip dscp 46
policy-map VIDEO_OUT
class EF_VIDEO
priority 1600
interface
service-policy output VIDEO_OUT
If you are sniffing traffic on that switch to ensure that video traffic is being marked, make sure that you are sniffing the outbound interface toward the router, not the inbound interface from the host. That will ensure that your sniffer trace picks up the traffic after it has been marked DSCP 46.
Just in case this post is related to your post where you want to lock the router WAN interface so that the 1.6 megs of video gets through but other traffic is dropped when the video takes the full 1.6 megs of bandwidth...
QoS queuing/scheduling only kicks in when the interface experiences congestion. If there is no congestion on the interface, traffic will still be marked and policed per the service policy, but not queued/scheduled - it will just fly right through the interface with the new markings. The only way to force such congestion at 1.6 megs is to use traffic shaping. You would need to shape the entire interface down to 1.6 megs, and THEN apply the priority bandwidth. This can be accomplished with a hierarchical policy-map as follows:
Router:
class-map match-any EF_VIDEO
match ip dscp 46
policy-map VIDEO_OUT
class EF_VIDEO
priority 1600
policy-map SHAPE_OUT
class class-default
shape average 1600000
service-policy VIDEO_OUT
interface
service-policy output SHAPE_OUT
I really hope I am helping you out here, please let me know how this works out. Good luck!
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:
