Tags
This is the first post about Converged Access (applicable to 3850/3650/5760) QoS in detail. The primary difference is these new platforms are using MQC (Modular QoS CLI) as oppose to MLS (Multi Layer Switching) QoS in Legacy switch platforms (3750X,3560,2960,etc) when provisioning. So this new CA platforms QoS is align with 4500/6500 QoS config mechanism.
In addition to this difference, 3850 is having 8 Queues for wired & 4 Queues for wireless traffic (In legacy systems they had 4 queues & no way to inspect wireless traffic as CAPWAP tunnels are not terminate on the access switch).
Due to inherent differences between wireless and wired technology, difference touch points within QoS architecture has defined.
1. Wired to Wireless
2. Wireless to Wired
Below diagram show the QoS touch points Wired to Wireless touch points
As traffic travels out of the wireless port (any port directly attached to an AP), there are several QoS touch point to consider.
1. Client Level – Classified on egress using class maps & provide two strict priority for voice & video.
2. SSID Level – Classified on egress using class maps. In addition to classifying & marking, there is a shape command to limit the rate of traffic at the SSID per radio (BSSID). A bandwidth for the SSID can also be configured to provide a ratio limit between the SSIDs sharing the same radio.
3. Radio Level – Traffic is subject to 4 egress queues, two of which are strict priority (for Voice & Video). The non-real-time queue is effectively the default class and the multicast-non-real time queue is used for all non real time multicast traffic. This is non configurable & generated based on the radio level shaper negotiation. Queing Sheduler is Class Based Weighted Fair Queue(CBWFQ) and bandwidth management is based on Approximate Fair Drop (AFD) algorithm, which provides faireness between users.
Below diagram illustrated the Wireless to Wired QoS touch points.
Marking or Policing policies can be applied to individual clients or at the SSID as an aggregate. If you do the classification or marking at the SSID level, it will have precedence over client level classification & marking.
As traffic leaves out wired port, again classification done by class maps & policing policies can be configured on physical port or on SVI. Queuing mechanism is CBWFQ and dual Low Latency Queues (LLQ) & the dropping algorithm is Weighted Tail Drop (WTD)
Now lets see how to default QoS configuration in these platform works. In MQC based products, QoS is enabled by default and any QoS markings are sent through the platform is untouched. There is one exception for this if traffic passes from a wireless-to-wired port or vice versa. In this situation QoS values are re-marked to default (0). 
However this is not the case with Wired-to-Wired traffic. This restriction can be disabled by disabling default un-trust command in 3850 global config as shown below.
3850-2#sh run | in qos qos wireless-default-untrust 3850-2#conf t Enter configuration commands, one per line. End with CNTL/Z. 3850-2(config)#no qos wireless-default-untrust
Also as described above, Radio level policy is non-configurable & hence it should be there in default config. You can verify that using “show policy-map interface wireless x” command. You should have a registered AP to check these.
3850-2#show ap summary Number of APs: 1 Global AP User Name: Not configured Global AP Dot1x User Name: Not configured AP Name AP Model Ethernet MAC Radio MAC State ---------------------------------------------------------------------------------------- AP3702I-1 3702I 7cad.74ff.2bc6 08cc.68b4.0370 Registered 3850-2#show policy-map interface wireless ? ap Wireless AP client Wireless Client radio Wireless Radio ssid Wireless SSID 3850-2#show policy-map interface wireless ap ? iifid Wireless target iifid name Wireless target identifier name | Output modifiers <cr> 3850-2#show policy-map interface wireless ap AP AP3702I-1 iifid: 0x010605C000000008 Service-policy output: defportac Class-map: class-default (match-any) Match: any 0 packets, 0 bytes 30 second rate 0 bps Queueing (total drops) 0 (bytes output) 18512197 shape (average) cir 1000000000, bc 4000000, be 4000000 target shape rate 1000000000 Service-policy : port_child_policy Class-map: non-client-nrt-class (match-any) Match: non-client-nrt 0 packets, 0 bytes 30 second rate 0 bps Queueing (total drops) 0 (bytes output) 18512197 bandwidth remaining ratio 10 Class-map: class-default (match-any) Match: any 0 packets, 0 bytes 30 second rate 0 bps (total drops) 0 (bytes output) 0 3850-2#show policy-map interface wireless radio Radio dot11b iifid: 0x010605C000000008.0x00CC838000000004 Service-policy output: def-11gn Class-map: class-default (match-any) Match: any 0 packets, 0 bytes 30 second rate 0 bps shape (average) cir 200000000, bc 800000, be 800000 target shape rate 200000000 Radio dot11a iifid: 0x010605C000000008.0x00CCB74000000005 Service-policy output: def-11ac Class-map: class-default (match-any) Match: any 0 packets, 0 bytes 30 second rate 0 bps shape (average) cir 1000000000, bc 4000000, be 4000000 target shape rate 1000000000
As you can see client & SSID level QoS is user defined & hence nothing is there by default.
3850-2#show policy-map interface wireless ssid ? iifid Wireless target iifid name Wireless SSID name | Output modifiers <cr> 3850-2#show policy-map interface wireless ssid ***** NO OUTPUT ****** 3850-2#show policy-map interface wireless client ? iifid Wireless target iifid mac Wireless target identifier name | Output modifiers <cr> 3850-2#show policy-map interface wireless client **** NO OUTPUT *****
Below diagram illustrate the port specific QoS role of a converged access campus access switch like 3850/3650.
In next post we will see how to configure QoS depending on the role switchport plays as shown in the above.
References
1. End to End QoS Design- Quality of Service for Rich-Media & Cloud Networks (2nd Edition)
2. BRKCRS-2890 Converged Access QoS
3. BRKCRS-2501: Campus QoS Design—Simplified
Related Posts
1. 3850 QoS – Part 2 (Queuing Models)
2. 3850 QoS – Part 3 (Port Specific QoS)
3. 3850 QoS – Part 4 (Wireless QoS Mapping)
4. 3850 QoS – Part 5 (Traffic Classification)
mrn-cciew 
Pingback: 3850 QoS – Part 3 (Port Specific QoS Role) | ytd2525
Hello Rasika,
It might be an old post, but still an extremley valuble resource to get clued up on this product.
I have also read the Cisco Catalyst 3850 Switch Services Guide – Dated April 2013, which list QoS examples with policing – otherwise not much context.
However, I can see from the information’s in your blog from cisco live QoS Roles in Campus Networks, that Policing is optional.
I was once told (not sure if this is still accurate) that policing on a campus network is not really necessary. Only on the Wan router/edge before traffic leaves the Wan circuit. i guess that the QoS roles picture confirms this.
Perhaps you can offer your expertise with the usage of policing – whether you are using it on your campus network or not. A reason why would you like to police traffic on the access switches
I believe you would need to police on the access layer and on the collapsed core/dist layer if you use hungry IT application on the access layer and management servers connected the core/dist swtich.
a) VOIP Phones connected to the access layer
b) VOIP Trading (separate vendor) to the access layer
c) Video Conferencing to the access layer and core/dist layer
d) voice gateway connected to the core/dist layer
One more item i picked up and i read in one of your replies here. You recommended applying Egress queue policy on all interfaces – > uplinks facing the dist/core and interfaces facing end user devices (VOIP, VC..etc..).
I guess this is based on your vast experience and from the QoS roles in the Campus Network diagram
I can see i.e Point 8 connected to the AP, or point 3 connected to TelePrecense Egress queuing is recommended, so the service policy shall be applied in the output direction as well?
Many thanks in advance for any help and comments.
Best wishes
Markus
Pingback: Cisco iOS | KB