Classification and Marking on Cisco Switch

Lessons Discussion
21

Hello Rene,

can we do the QOS lab (classification and marking on switch) on GNS3(1.3.3)?
as I didnot get the sh mls ? command on swicth

Switch#sh mls?
% Unrecognized command
Switch#sh mls

Please help me here.

22

Hi @singla55

You can’t use GNS3 for this, you’ll need some real switches to practice these QoS commands.

Rene

23

Thanks Rene,
One more question. as you mentioned switch will erase the QOS marking of all packet when we will enable the QOS on switch but default behavior of switch is to overwrite the DSCP value of the packet inside your frame according to the cos-to-dscp map.
so I confused what will happen? will erase or overwrite?
Waiting for your reply.

24

Once you enable MLS Qos, your switch doesn’t trust any CoS or DSCP values so if you have a DSCP value, it will erase it (rewrite it to 0).

Once you enable trust CoS, it will rewrite the DSCP value according to the cos-to-dscp map.

25

Hi
Thanks for the Lesson
I have on question :
I classify skype trafic and and i marked this trafic for example EF ? how can I be sure that skype server will respond to my request with the same mark in the TOS header

Cordially

26

Hello Fabrice

If you mark Skype traffic (or any traffic for that matter), you can be sure that this traffic will be marked only within the network that you administrate. If the packet exits your network, (via your ISP, the Internet etc), you can’t be sure that those markings will be obeyed or even removed. It depends on the policies of your ISP and any agreements you have made with them. But even so, traffic that is destined to the internet at large does not generally have QoS mechanisms applied to it. The Internet is best effort at best.

So it is almost certain that the Skype server on the Internet will not receive QoS markings nor will it respond with QoS markings. What you can do however is you can add QoS markings on incoming Skype traffic at your edge devices, so that any such traffic will at least have QoS mechanisms operating for all traffic within your network.

I hope this has been helpful!

Laz

1 Like
27

Hello, Thanks for the lesson,
If we have a video streaming device, can we prioritize the multicast traffic and how can be the best implementation as an example?
I was thinking dscp value can be examined by L3 devices, and cos value is for L2. Is that correct?
Thanks

28

Hello Ike

It’s important to understand the difference between QoS that takes place in Layer 3 (DSCP and IP Precedence) and that which takes place on Layer 2 (CoS). Layer 2 QoS involves the prioritization of traffic over trunk links only. Layer 3 QoS prioritization takes place at every router or hop along the path. So if you want to employ QoS for your video, you will need to:

As far as applying DSCP:

  1. Classify your traffic accordingly
  2. Mark your traffic accordingly
  3. Apply QoS rules at each router for the appropriate queueing, policing, or shaping.

For L2 you are correct that you would apply the CoS values, however, it is possible, if the switch supports it, to use DSCP values as well for L2 queuing. The following lesson describes a situation where you can use either or both:

I hope this has been helpful!

Laz

29

Thank you , the linked lesson and the video inside is very informative.

1 Like
30

Hi,

quick question. I understand that the switch will mark ssh traffic from the server but, would it apply to remote ssh connections to the server? Let’s say that I have a vpn stablished to the router and I try to connect remotely to the server, would it this QoS be usefull in this scenario??? I reckon I would need to create another policy in the router for the packets heading to the router.

Regards,
Jorge

31

Hello Jorge

This specific configuration in the lesson only applies QoS for traffic coming from the server. For the first two examples, where ACLs are used, matched traffic is only that traffic that has a source IP address of the server. Traffic to the server has no QoS mechanisms applied.

In order to do this, you must add a second policy map with the appropriate extended ACL (using the IP address of the server as the destination IP, with the appropriate TCP port) and apply it to Fa0/1 in an outbound direction. Standard ACLs will not work in this case since destination IPs are being specified.

Such a configuration will work regardless of where the SSH client is connecting from, either a VPN that terminates on R1, on the WAN, or from R1 itself.

I hope this has been helpful!

Laz

32

Since classifying on access switches is limited, what would you recommend in a situation where you are trying to identify and classify traffic based on destination URL? In this case, I am thinking of classifying and marking at our core or internal routers as I can classify based off protocol http url. I can’t do this on access switches, even 3850s. I realize it is best to classify and mark as close to the source as possible however our voice traffic has it’s own dedicated circuit so I am not interested in setting the trust boundary there.

33

Hello Justin

I am not familiar with a way to classify based on destination URL, however, you should be able to classify based on destination IP. If the URL always maps to the same IP address, then you can easily take the URL out of the equation and set up a classification based on destination IP using route maps.

This is not something that you would configure using L2 QoS, since you need L3 parameters (the IP address) to define. The following lesson has an example of how you can mark traffic using a policy map.

You can then apply a QoS mechanism that will prioritize traffic based on these markings. You can apply this wherever you like on the network.

Now having said all of this, even if you have dedicated circuits for your voice traffic, you may want to consider setting up the QoS marking as close as possible to the source, as you mention yourself. Since all of your voice traffic ends up going to the destination URL anyway, it can be advantageous to mark all voice traffic in that way, rather than to do it at the core.

Would you like to share a little more about what you want to achieve so that we can suggest a more detailed solution to your particular arrangement?

I hope this has been helpful!

Laz

34

Hello, everyone!

There’s one thing that’s been confusing me for a while. Take a look at this

obrĂĄzok
obrázok1051×166 8.29 KB

So a switch can classify traffic and also mark it using the DSCP values, correct? My question is, what exactly would be the point of doing marking by using CoS (PCP in the Dot1q header) values if we can just use DSCP values instead?

Not to mention that DSCP values are also end-to-end while PCP values can only exist on a trunk link/access link with a voice VLAN.

Thank you!

David

35

Hello David

A switch is able to classify as well as mark traffic. Marking can be achieved using DSCP values in the IP header, but it can also be achieved by modifying the CoS values found in the 802.1Q VLAN tag.

So what would be the benefits of using CoS markings compared to DSCP? Well, for one thing, you’ve already answered the most important reason: DSCP values are applicable from end to end since they remain in the IP header for the duration of the transmission from source to destination, while CoS markings exist only wherever the VLAN tag exists, i.e. on trunks and on voice VLAN connections. So the CoS’s scope is very limited (localized) while that of DSCP is much broader.

The use of CoS and DSCP is not an “either-or” situation. Each one plays a different role, and as mentioned above, each has a different scope. Typically, CoS markings will only be applied on a switch for traffic traversing a trunk or a port configured with voice VLAN. So really, CoS values are only useful for assigning a priority that will ensure the correct management of traffic over a single specific trunk link (or voice VLAN connection) while DSCP is used at every hop.

I hope this has been helpful!

Laz