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:
class-map match-any VIDEO
set ip dscp 46 !
service-policy input POLICY1
class-map match-any EF_VIDEO
match ip dscp 46
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:
class-map match-any EF_VIDEO
match ip dscp 46
shape average 1600000
service-policy output SHAPE_OUT
I really hope I am helping you out here, please let me know how this works out. Good luck!
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :