06-24-2019 05:21 AM
I am following the cisco validated design for the 3850 switch and have a question on the Classification and Queuing. They have the following example for queueing in their example
Policy-map Marker
class MULTIMEDIA-CONFERENCING
set dscp af41
They don't show the class-maps but I found on another website the following class-map
class-map MULTIMEDIA-CONFERENCING
match dscp af41
match dscp af42
match dscp af43
My question if I attach this policy to an interface it will take all AF41, AF42 and AF43 and set it to AF41. I did this in the lab and did a capture and I confirmed that any af42 or af43 would be remarked to af41.
How will AF42 ever hit the output queueing policy if any traffic coming in is automatically set to AF41 before going out the interface with the queueing policy applied?
class-map match-all MULTIMEDIA-CONFERENCING-QUEUE
MATCH DSCP AF41 AF42 AF43
class MULTIMEDIA-CONFERENCING-QUEUE
queue-limit dscp af43 percent 80
queue-limit dscp af42 percent 90
queue-limit dscp af41 percent 100
Solved! Go to Solution.
06-26-2019 06:06 AM
Hello CANMORMON,
if you have a trusted device on an access port you just need to trust DSCP on ingress there is no need to use a re-marking policy.
If trusting DSCP is your default you need to implement marking policies only on those ports that need a re-marking.
And as I have explained in my previous post at access layer you can use IP ACLs to decide how to mark traffic on a port when needed.
Your results just show that using a marking policy that invokes a class-map that matches on several DSCP values and set all of them to AF41 only packets with AF41 marking are the result.
It is a supported configuration but it is conceptually wrong because it is not what you want to achieve.
Again if you can trust a device just do it at port level and do not use a marking policy on that port.
On uplinks you will use a policy based on DSCP values
Hope to help
Giuseppe
06-24-2019 05:36 AM
Hello CANMORMON,
the marking policy should refer to class-maps that use an IP extended ACL and then mark to AF41 or other desired DSCP values.
This is usually performed at access layer near the end user devices including IP phones video conference stations and so on.
The queueing uses a different set of class-maps that match on DSCP value.
So marking on edge based on IP ACLs and queueing is performed at each switch hop using matching on DSCP values.
This is the usual and more scalable DiffServ QoS design.
In this way, distribution and core devices are not involved in complex traffic classification that is performed in access layer near the sources of flows and they just need to implement Queueing based on DSCP values.
Hope to help
Giuseppe
06-26-2019 05:51 AM
Thanks for the feedback but I am still confused.
In multiple examples I found for class-maps they show the dscp bit being set as my previous example.
If I do set the dscp bit on the ingress traffic to AF41 how will the AF42 queue ever get hit?
I did some testing in the lab and if have do a set dscp Af41 and I do the command
show platform hardware fed switch 1 qos dscp-cos counters interface gig 1/9/0/38
The egress AF41 only counter increments
Egress DSCP34 224794 0
Egress DSCP35 0 0
Egress DSCP36 251788 0
Egress DSCP37 0 0
Egress DSCP38 114839 0
Egress DSCP34 231530 0
Egress DSCP35 0 0
Egress DSCP36 251788 0
Egress DSCP37 0 0
Egress DSCP38 114839 0
If I take out the set dscp af41 marking then the rest of the dscp 34,36 and 38 counters all increment
Egress DSCP34 348909 0
Egress DSCP35 0 0
Egress DSCP36 253336 0
Egress DSCP37 0 0
Egress DSCP38 115397 0
Egress DSCP34 349469 0
Egress DSCP35 0 0
Egress DSCP36 254784 0
Egress DSCP37 0 0
Egress DSCP38 115857 0
Lets take for example I have a video camera on a port I trust (by default 3850 trusts all markings). The camera is sending dscp AF42.
In my post above this would get set to dscp 41.
If I want to be able to match dscp 41 and 41 (Multimedia Traffic) I would assume I would need to do the following
class-map MULTIMEDIA-CONFERENCING-AF41
set dscp af41
class-map MULTIMEDIA-CONFERENCING-AF42
match dscp af42
Then my policy-map
class MULTIMEDIA-CONFERENCING-MARK-AF41
set dscp af41
class MULTIMEDIA-CONFERENCING-MARK-AF42
set dscp af42
Thanks for helping
06-26-2019 06:06 AM
Hello CANMORMON,
if you have a trusted device on an access port you just need to trust DSCP on ingress there is no need to use a re-marking policy.
If trusting DSCP is your default you need to implement marking policies only on those ports that need a re-marking.
And as I have explained in my previous post at access layer you can use IP ACLs to decide how to mark traffic on a port when needed.
Your results just show that using a marking policy that invokes a class-map that matches on several DSCP values and set all of them to AF41 only packets with AF41 marking are the result.
It is a supported configuration but it is conceptually wrong because it is not what you want to achieve.
Again if you can trust a device just do it at port level and do not use a marking policy on that port.
On uplinks you will use a policy based on DSCP values
Hope to help
Giuseppe
06-26-2019 12:50 PM
Yes that help
Much appreciated
06-26-2019 08:26 AM
06-26-2019 12:52 PM
Thanks for all the information
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