Learning Basic QoS part 2 – Catalyst 3560 QoS

In this post I will talk about Cisco Catalyst 3560 QoS. In Basic QoS part 1 I talked about policing and shaping on Cisco IOS routers.

 To illustrate the different examples in this post I will use the following topology:

IGP: EIGRP 10

 Platform/IOS: Catalyst 3560/ c3560-advipservicesk9-mz.122-44.SE6.bin

 Catalyst 3560 QoS Port-Based Classification

 As long as the QoS in not enabled with the command mls QoS, the QoS values in the packets are left intact when flowing through SW1 and SW2. That can be verified as follows:

As we can see from the output above, SW1 has QoS disabled (default) and is seeing packets from R1 marked with DSCP 48 (These are EIGRP updates, since routing traffic uses IP precedence of six which corresponds to DSCP 48). All incoming routing updates bear COS value of zero, since IOS does not set the COS field by default.

Let´s verify on R2 if packets with DSCP 48 are received by the control-plane:

Side note: In order to get the debug output above I just configured a policy-map matching DSCP 48 which is attached to the control-plane. Then under the class-map I configured the log keyword.

 Now let´s just reset the counters on the policy-map on R2 (clear control-plane *) and let´s enable QoS on SW1.

So as soon as we enable QoS on SW1, the port connected to R1 is in an untrusted state which means that any markings will be rewritten by the switch to zero which in turns means that R2 will not see EIGRP packet marked with DSCP of 48 but with a DSCP of zero:

As a matter of fact SW1 is still receiving packet sent by R2 with a DSCP of 48 via the trunk link connected to SW2:

But as we can see in the output above SW1 is sending packets toward R2 from R1 out the trunk link with a DSCP of zero.

 Side note: Just as a little reminder, CoS bits (three bits) is located in 802.1q/ISL header of a tagged frame. Those bits are known as 802.1p priority bits and are used for L2 QoS. ToS field (8 bits) located in the IP header is used for L3 QoS. 6 bits in the ToS field represent the DSCP value.

 In order to keep the DSCP value sent by R1 intact we configure R1 to trust the port connected to R1 (F0/1). This step forms part of the classification stage. You may classify using either interface level setting or by applying a pre-configured policy-map. Here is how classification works on the catalyst 3560:

     Trust DSCP or IP precedence (higher 3 bits in ToS field): For IP packets we can either trust on IP precedence or on DSCP value. When you trust DSCP the switch resolve the CoS value using the DSCP to CoS mapping table. When trusting IP precedence (IPP) the switch resolve the DSCP value using the IP precedence to DSCP mapping

    Trust CoS: Works for both IP and non-IP packets (ARP for example). If no CoS present in the 802.1q/ISL header the default CoS value assigned on the interface is used. The IPP and DSCP value are not taking into account and the DSCP/IPP value will be rewrite in the packet using the CoS to DSCP mapping table.