Cisco Systems C3850NM410G User Manual

Cisco Catalyst 3850 Switch

Services Guide

April 2013

Guide

Contents

Overview ................................................................................................................................................................... 3

Cisco Catalyst 3850 Security Policy....................................................................................................................... 3

Configuring 802.1X in Converged Access ............................................................................................................. 3

802.1X Configuration for Wired Users .................................................................................................................. 5

802.1X Configuration for Wireless Users .............................................................................................................. 6

Downloadable Access Control List ........................................................................................................................ 8

Access Control List Deployment Considerations .................................................................................................. 9

Cisco Catalyst 3850 Quality of Service ................................................................................................................ 10

Wired Quality of Service...................................................................................................................................... 10

Cisco Catalyst 3850 Trust Behavior ............................................................................................................... 10

Configuring Ingress Quality of Service ........................................................................................................... 11

Egress Quality of Service ............................................................................................................................... 14

Wireless Quality of Service ................................................................................................................................. 15

Wireless Targets ................................................................................................................................ ................. 15

Wireless: Ingress Quality of Service ................................................................................................................... 16

Ingress Marking and Policing on Wireless Client............................................................................................ 16

Ingress Policies on WLAN/SSID..................................................................................................................... 18

Wireless: Egress Quality of Service .................................................................................................................... 19

Policy on Access Point/Port ........................................................................................................................... 19

Policy on Radio .............................................................................................................................................. 21

Policy on Service Set Identification ................................................................................................................ 22

Client .............................................................................................................................................................. 23

Flexible NetFlow .................................................................................................................................................... 23

Cisco Catalyst 3850 NetFlow Architecture (Wired and Wireless) ........................................................................ 24

NetFlow Cisco Catalyst 3850 Overview .............................................................................................................. 24

NetFlow Configuration on Cisco Catalyst 3850 Switch ....................................................................................... 24

Flow Record ................................................................................................................................................... 24

Exporter/Collector Information ........................................................................................................................ 25

Flow Monitor ................................................................................................................................................... 25

Attaching a Flow Monitor to Supported Port Types ............................................................................................. 26

Flexible NetFlow Outputs .................................................................................................................................... 27

Multicast Overview (Traditional and Converged Multicast) ................................................................................. 30

Restrictions of IP Multicast Routing Configuration .............................................................................................. 30

Configuring Wireless IP Multicast on Cisco Catalyst 3850 .................................................................................. 30

Multicast Mode Configuration .............................................................................................................................. 31

Multicast Show Commands................................................................................................................................. 32

Converged Access with the Cisco Catalyst 3850 ............................................................................................... 37

Distributed Functions Enabling Converged Access ........................................................................................ 37

Logical Hierarchical Groupings of Roles ........................................................................................................ 38

Converged Access Network Design with Cisco Catalyst 3850 .......................................................................... 39

Configuring Converged Access with Cisco Catalyst 3850 ................................................................................. 42

Roaming in Cisco Unified Wireless Network ....................................................................................................... 49

Understanding Roams in Converged Access ..................................................................................................... 52

Traffic Paths in Converged Access ...................................................................................................................... 54

Relevant Outputs for Tracking Client Roams in Converged Access ................................................................ 55

Nontunneled Roam in Converged Access ........................................................................................................... 64

Tunnel Roles in Converged Access ..................................................................................................................... 67

Appendix A: Detailed FnF Field Support ............................................................................................................. 68

Overview

The Cisco® Catalyst® 3850 Switch is built on a unified access data plane (UADP) application-specific integrated circuit (ASIC). This is a state-of-the-art ASIC that has all services fully integrated in the chip and thus requires no additional modules. The ASIC is programmable and is flexible to support future requirements. It also delivers services with flexibility and visibility across wired and wireless networks.

The access layer of the network has evolved from just pushing the traffic into the network to delivering a plethora of services. The convergence of wired and wireless networks adds another level to services being applied at the access layer. Service-rich and service-aware networking platforms allow organizations to achieve not only lower total cost of ownership (TCO), but also faster time to service delivery.

This document provides an overview of the Cisco Catalyst 3850 and the steps to deploy services with the Cisco Catalyst 3850. It broadly includes the following sections:

●

Security

●

Quality of service

●

Flexible NetFlow

●

Multicast

●

Mobility

Cisco Catalyst 3850 Security Policy

In today’s networking environment, it has become a challenge to manage security policies on wired and wireless networks. It is mainly due to the fact that wired and wireless users are being identified in different points on the network and are subject to different policies.

The Cisco Catalyst 3850 defines a major change in the architecture, because it brings wired and wireless networks together on an access switch. As we terminate the wireless users on the Cisco Catalyst 3850, we also get visibility to users who are getting onto the network at the access layer, similar to wired users. This change also moves the policy point to the access layer, and therefore it gets consistent with the wired endpoints.

Configuring 802.1X in Converged Access

In the topology diagram shown in Figure 1, a wired corporate user and access points are connected to the Cisco Catalyst 3850. Two wireless clients are connected to the service set identification (SSID) on the Cisco Catalyst

3850. One of the wireless users is a corporate user, and the other user is a partner. Corporate users and partner

users have different security policies defined on Cisco’s Identity Services Engine (ISE) server that is in the campus

services block. There are other servers such as call manager, video streaming server, and the Cisco Prime™ Infrastructure server in the campus services block as well.

aaa new-model

aaa authentication dot1x CLIENT_AUTH group radius

aaa authorization network CLIENT_AUTH group radius

!

radius server ise

address ipv4 9.9.9.9 auth-port 1812 acct-port 1813

timeout 60

retransmit 3

key cisco123

!

Figure 1. 802.1X with Converged Access

The authentication, authorization, and accounting (AAA) group and RADIUS server are set up on the Cisco Catalyst 3850. The authentication and authorization are redirected to the ISE server. The wireless clients are set up to get authenticated using dot1x.

The ISE server is the RADIUS server, and the switch is defined on the ISE server as one of the network devices. The RADIUS server needs to be defined on the switch.

dot1x system-auth-control

!

interface GigabitEthernet1/0/13

switchport access vlan 12

switchport mode access

access-session port-control auto

access-session host-mode single-host

dot1x pae authenticator

service-policy type control subscriber DOT1X

To define the Cisco Catalyst 3850, on the ISE screen, navigate to Administration  Network Resources  Network Devices as in Figure 2.

Figure 2. Device Definition in ISE

The dot1x needs to be enabled on the switch globally for wired and wireless clients.

802.1X Configuration for Wired Users

802.1X for wired users is configured per port. Here is the port configuration:

The Cisco Catalyst 3850 also introduces session-aware networking (SaNet), which is a replacement for Auth Manager that is present in current Cisco IOS® Software platforms.

The objective of having SaNet is to have no dependency between features applied to sessions or authentication method. Thus, with appropriate AAA interactions, any authentication method should derive authorization data for any feature, to be activated on a session. This can be accomplished by using a policy model similar to Modular Policy Framework (MPF), which is used in routing protocols, firewall rules, quality of service (QoS), and so on. For more details, see SaNet documentation at http://www.cisco.com/en/US/docs/ios-xml/ios/san/configuration/xe-

3se/3850/san-overview.html. The following policy is an example for SaNet:

class-map type control subscriber match-all DOT1X_NO_RESP

match method dot1x

!

policy-map type control subscriber DOT1X

event session-started match-all

1 class always do-until-failure

2 authenticate using dot1x retries 3 retry-time 60

event authentication-success match-all

event authentication-failure match-all

5 class DOT1X_NO_RESP do-until-failure

1 authentication-restart 60

!

wlan Predator 1 Predator

security dot1x authentication-list CLIENT_AUTH

Switch#sh access-session

Interface MAC Address Method Domain Status Fg Session ID

Gi1/0/13 0024.7eda.6440 dot1x DATA Auth 0A0101010000109927B3B90C

Ca1 b065.bdbf.77a3 dot1x DATA Auth 0a01010150f57a300000002e

Ca1 b065.bdb0.a1ad dot1x DATA Auth 0a01010150f57ac20000002f

Session count = 3

Key to Session Events Status Flags:

A - Applying Policy (multi-line status for details)

D - Awaiting Deletion

F - Final Removal in progress

802.1X Configuration for Wireless Users

For wireless clients, 802.1x is configured under WLAN configuration mode. The AAA authentication method is similar to wired clients.

When a user provides credentials, the ISE server authenticates and authorizes the user. Upon successful authorization, the user is assigned a specific VLAN, which provides policies based on groups or device types in ISE. It also provides other policies such as QoS, downloadable access control list (dACL), and so on.

The client session is maintained on the Cisco Catalyst 3850 after authorization, until the session is terminated. The client states are controlled by the wireless control manager (WCM) process.

Any end station (wired or wireless) authenticating using dot1X is termed as a “client,” and all the policies such as

dACL and QoS that are specific to this client are installed on the client entity in hardware, unlike ports in the existing 3K switches. This is one way that consistency between wired and wireless clients is achieved.

To look at the overall wired and wireless devices connected on the switch, the following command can be used:

I - Awaiting IIF ID allocation

P - Pushed Session (non-transient state)

R - Removing User Profile (multi-line status for details)

U - Applying User Profile (multi-line status for details)

X - Unknown Blocker

Switch#sh access-session mac b065.bdb0.a1ad details

Interface: Capwap0

IIF-ID: 0xE49A0000000008

MAC Address: b065.bdb0.a1ad

IPv6 Address: Unknown

IPv4 Address: 12.0.0.2

User-Name: user1

Status: Authorized

Domain: DATA

Oper host mode: multi-auth

Oper control dir: both

Session timeout: N/A

<snip….snip>

Server Policies (priority 100)

ACS ACL: xACSACLx-IP-user1-46a243eb

Method status list:

Method State dot1x Authc Success

Switch#sh run int gig1/0/13 Building configuration...

Current configuration : 317 bytes ! interface GigabitEthernet1/0/13 description dot1X Wired Port in Vlan 30 switchport access vlan 30 switchport mode access load-interval 30 access-session host-mode single-host access-session port-control auto dot1x pae authenticator spanning-tree portfast service-policy type control subscriber 802.1x end

The following output shows the detailed view of the wireless client session:

The following is the configuration on the wired port:

Switch#sh access-session mac 0024.7eda.6440 details Interface: GigabitEthernet1/0/13 IIF-ID: 0x1092DC000000107 MAC Address: 0024.7eda.6440 IPv6 Address: Unknown IPv4 Address: 10.3.0.113 User-Name: corp1 Status: Authorized Domain: DATA Oper host mode: single-host Oper control dir: both Session timeout: N/A Common Session ID: 0A010101000011334A316CE0 Acct Session ID: Unknown Handle: 0x8B00039F Current Policy: 802.1x

Server Policies: ACS ACL: xACSACLx-IP-Corp-506f07b4

Method status list: Method State dot1x Authc Success

The following is the detailed output of the wired client session:

Note: In the preceding output, the ACL is installed on the client entity and not on the port.

Downloadable Access Control List

The screenshot in Figure 3 shows the dACL definition in ISE.

Figure 3. Downloadable ACL Screen

Switch#sh access-lists

Extended IP access list xACSACLx-IP-user1-46a243eb (per-user)

1 permit udp any any eq domain

2 permit tcp any any eq domain

3 permit udp any eq bootps any

4 permit udp any any eq bootpc

5 permit udp any eq bootpc any

6 permit ip any any

ACL Resources

Cisco Catalyst 3850

IPv4 ACE

3000 entries

IPv6 ACE

1500 entries

L4OPs/ACL

8 L4OPs

After defining ACL in ISE, it can be associated with an authorization profile, as shown in Figure 4.

Figure 4. Authorization Profile

Note: If a named authentication method-list is in place for AAA, an attribute needs to be set from ISE, as shown in 4 Method-List in this example is CLIENT_AUTH.

After successful download of ACL, the client is authorized, and the following is the output of ACL:

Access Control List Deployment Considerations

With the Cisco Catalyst 3850 and converged access, ACLs can now be applied to wireless clients as they are applied on wired ports/clients. The Cisco Catalyst 3850 has more ternary content-addressable memory (TCAM) space assigned for ACLs than 3K-X switches. The following paragraphs describe some of the scalability numbers.

Table 1 summarizes the access control entries (ACEs) scalability.

Table 1. Scale Numbers

Incoming Packet

Outgoing Packet

Trust Behavior

L3

Preserve DSCP/precedence

L2

Not applicable

Tagged

Preserve DSCP and class of service (CoS)

L3

Tagged

Preserve DSCP; CoS is set to 0

The total capacity of the ACEs is an aggregate number that constitutes all types of ACEs. One type of ACE, however, can scale up to 1500. For example, the total number of Port ACL (PACL) access control entries cannot exceed 1500. But a combination of PACL and Router ACL (RACL) access control entries can scale up to 3000.

Cisco Catalyst 3850 Quality of Service

One of the primary advantages of the Cisco Catalyst 3850 is the visibility into wireless packets at the access layer. This visibility is a powerful feature and enables network administrators to apply the rich intelligent services of wired traffic and extend these services to wireless traffic as well. QoS is one of the features that can be applied on wireless traffic similar to that of being applied on wired network.

Significant QoS features have been introduced for wired as well as wireless on the Cisco Catalyst 3850. Some of them are the following and are discussed in detail later in the document:

●

Modular QoS CLI (MQC)

●

Approximate Fair-Drop (AFD) algorithm for bandwidth management across wireless users, providing hierarchical support across access points, radios, Basic Service Set Identifier (BSSID), and clients.

●

Eight queues per port (wired) and 4 queues per port (wireless)

●

Bidirectional policing support in hardware for wireless clients

●

Two-level hierarchical QoS on wired ports

●

Per-SSID bandwidth management; differentiated bandwidth management across SSIDs

Because of the inherent differences of wired and wireless media and transmission methods, there are differences between wired and wireless QoS.

Wired QoS on the Cisco Catalyst 3850 is explained later, followed by wireless QoS in the following section.

Wired Quality of Service

Cisco Catalyst 3850 Trust Behavior

The trust behavior on the Cisco Catalyst 3850 has changed from the that of Cisco Catalyst 3K Series switches. By default, the Cisco Catalyst 3850 trusts markings on the wired ports. For wired ports, differentiated services code point (DSCP) markings in IP packets from endpoints such as IP phones, telepresence units, cameras, and laptops are trusted and retained.

Retained markings are summarized in Table 2.

Table 2. Trust Behavior

With the introduction of MQC, the “trust cos/dscp” CLI has been deprecated on the Cisco Catalyst 3850. However,

“trust device” on the interface level is still supported. The default mode on the interface is trusted and changes to

untrusted only when an untrusted device is detected. In the untrusted mode, the DSCP/precedence/CoS will be reset to 0.

qos wireless-default-untrust

table-map dscp2dscp

default copy

!

ip access-list extended BULK-DATA

remark FTP

permit tcp any any eq ftp

permit tcp any any eq ftp-data

..

ip access-list extended DEFAULT

remark EXPLICIT CLASS-DEFAULT

permit ip any any

ip access-list extended MULTIMEDIA-CONFERENCING

remark RTP

permit udp any any range 16384 32767

ip access-list extended SCAVENGER

remark KAZAA

permit tcp any any eq 1214

Unlike wired, wireless is considered untrusted on the Cisco Catalyst 3850. The default trust setting for wireless target is untrust: that is, the packets are marked down to 0 in the absence of SSID-based policy.

The startup configuration on the Cisco Catalyst 3850 always has the following CLI:

This CLI is part of the default configuration (automatically created) and cannot be modified in the current release. That means the wireless will always be untrusted.

If trust behavior (similar to wired) is desired on wireless, table-maps need to be defined. The option of default copy can be used to protect the markings in the table-maps.

Marking on the downstream traffic is not being preserved on wireless targets. Therefore, a table-map is required in the downstream direction to retain the markings.

The following is a sample table-map that will retain the markings:

Configuring Ingress Quality of Service

Ingress Classification

When creating QoS classification policies, the network administrator must consider applications that are to be present at the access layer of the network (in the ingress direction). The applications present at the access edge need to be classified to mark them with appropriate marking and/or policing.

MQC offers scalability and flexibility in configuring QoS and provides consistent configuration across various Cisco switches and routers. The following sample configuration creates an extended access list for each application and then applies it under class-map configuration mode:

permit udp any any eq 1214

ip access-list extended SIGNALING

remark SCCP

permit tcp any any range 2000 2002

remark SIP

permit tcp any any range 5060 5061

permit udp any any range 5060 5061

ip access-list extended TRANSACTIONAL-DATA

remark HTTPS

permit tcp any any eq 443

remark ORACLE-SQL*NET

permit tcp any any eq 1521

permit udp any any eq 1521

class-map match-any BULK-DATA

match access-group name BULK-DATA

class-map match-any VVLAN-SIGNALING

match ip dscp cs3

class-map match-any MULTIMEDIA-CONFERENCING

match access-group name MULTIMEDIA-CONFERENCING

class-map match-any DEFAULT

match access-group name DEFAULT

class-map match-any SCAVENGER

match access-group name SCAVENGER

class-map match-any SIGNALING

match access-group name SIGNALING

class-map match-any VVLAN-VOIP

match ip dscp ef

class-map match-any TRANSACTIONAL-DATA

match access-group name TRANSACTIONAL-DATA

The following is the configuration for creating a class-map for each application service and applying match statements:

Ingress Marking and Policing

It is important to limit the bandwidth that each class may use at the access layer in the ingress direction. To achieve proper policing, accurate DSCP marking on ingress traffic at the access-layer switch is critical. It is best to use an explicit marking command for all trusted application classes.

There are two methods for ingress marking. These are “table-map” and “set” commands. For marking down, however, table-map is the only option that can be used.

table-map cos2cos

default copy

policy-map cos-trust-policy

class class-default

set cos cos table cos2cos

policy-map Phone+PC-Policy

class VVLAN-VOIP

police 128000 8000 conform-action transmit exceed-action drop

set dscp ef

class VVLAN-SIGNALING

police 32000 8000 conform-action transmit exceed-action drop

set dscp cs3

class MULTIMEDIA-CONFERENCING

police 5000000 8000 conform-action transmit exceed-action drop

set dscp af41

class SIGNALING

police 32000 8000 conform-action transmit exceed-action drop

set dscp cs3

class TRANSACTIONAL-DATA

police 10000000 8000 conform-action transmit exceed-action set-dscp-transmit dscp table markdown

set dscp af21

class BULK-DATA

police 10000000 8000 conform-action transmit exceed-action set-dscp-transmit dscp table markdown

set dscp af11

class SCAVENGER

police 10000000 8000 conform-action transmit exceed-action drop

set dscp cs1

class DEFAULT

police 10000000 8000 conform-action transmit exceed-action set-dscp-transmit dscp table markdown

With table-maps, one can create a map of values that can be used between the same or different markings such as DSCP, CoS, and so on. The values that can be mapped are from 0 through 99 in decimal. Table-map also has a default mode of operation for values that do not have a mapping explicitly configured. If it is set to ignore, there will not be any change to the marking, unless an explicit mapping is configured. It can be configured to copy or to set a specific value.

The following is a sample table-map configuration:

The following sample configuration shows how to configure policing for multiple classes on ingress ports in accesslayer switches:

interface fastethernet0/4

description CONNECTED TO PHONE+PC

service-policy input Phone+PC-Policy

class-map VOICEQ

match dscp ef

class-map match-any VIDEOQ

match dscp cs4

class-map NETWORK-MGMT

match dscp cs6

Applying Ingress Policies

Like other Cisco Catalyst platforms, Cisco Catalyst 3850 Switches offer two simplified methods to apply service policies. Depending on the deployment model, either of the following methods may be used:

●

Port-based QoS: Applying service policy on a per-physical port basis will force traffic to pass through QoS policies before entering the network.

●

VLAN-based QoS: Applying service policy on per-VLAN basis requires the policy map to be attached to a logical Layer 3 interface or Switch Virtual Interface (SVI).

The following sample configuration shows how to deploy port-based QoS on the access-layer switches:

Egress Quality of Service

The Cisco Catalyst 3850 has eight queues per wired port. The switch can be configured to work in 2P6Q3T mode. Voice over IP (VoIP) Expedited Forwarding (EF) and broadcast video Class Selector 5 (CS5) can be assigned to the priority queues. Figure 5 illustrates 2P6Q3T mode.

Figure 5. 2P6Q3T Mode

class-map CALL-SIG

match dscp cs3

class-map CRITICAL-DATA

match dscp af21 af22 af23

class-map VIDEO-STREAM

match dscp af31 af32 af33

class-map Scavenger-Q

match dscp cs1

policy-map 2P6Q3T

class VOICEQ

priority level 1

class VIDEOQ

priority level 2

class NETWORK-MGMT

bandwidth remaining percent 10

class CALL-SIG

bandwidth remaining percent 10

class CRITICAL-DATA

bandwidth remaining percent 10

class VIDEO-STREAM

bandwidth remaining percent 10

class SCAVENGER

bandwidth remaining percent 1

class class-default

bandwidth remaining percent 25

After traffic is identified using DSCP, policy bases can be applied on classifications.

The egress policy can be applied to the port or L3 interface similar to the ingress policy.

Wireless Quality of Service

Wireless Targets

In wireless QoS, there are two terms: upstream and downstream. Upstream means ingressing from the access point and egressing from the wired network. Downstream means ingressing from the wired network and egressing out to the access point. The following table summarizes the QoS marking/policing and queuing capabilities on each type of target interface: access point, radio, SSID, and client.

In wireless targets, QoS policies can be applied on multiple levels. Each of these targets is discussed in the following sections.

policy-map PER-CLIENT

class VOICE

set dscp ef

police 128k 8000 exceed-action drop

class SIGNALING

set dscp cs3

police 32k 8000 exceed-action drop

class MULTIMEDIA-CONFERENCING

set dscp af41

police 5m 8000 exceed-action drop

class TRANSACTIONAL

set dscp af21

class CLASS-DEFAULT

set dscp default

wlan open 1 Employees

service-policy client input PER-CLIENT

Wireless: Ingress Quality of Service

Ingress Marking and Policing on Wireless Client

In the ingress direction, traffic can be marked and policed at client level. The following example provides differentiated marking and policing for the different class of application sourced from the client:

The client policy can be applied directly under the SSID interface (as in the following), or it can be pushed from the policy server (ISE).

Switch# sh policy-map interface wireless client

Client 000A.CC10.0001

Service-policy input: Standard-Employee

Class-map: Voice (match-all)

Match: access-group name Voice

police:

cir 128000 bps, bc 4000 bytes

conformed 0 bytes; actions:

transmit

…

QoS Set

dscp ef

…

Class-map: TRANSACTIONAL-DATA (match-all)

Match: access-group name TRANSACTIONAL-DATA

QoS Set

dscp af21

Class-map: class-default (match-any)

Match: any

QoS Set

dscp default

The applied policy can be shown with the following CLI:

The preceding configuration enforces the policer per wireless client that joined on the SSID. In this case the Cisco Catalyst 3850 uses microflow policers that act per client.

If the policy name is downloaded from the ISE server, the server needs to be configured as shown in Figure 6, with the AV pair ip:sub-qos-policy-in=Standard-Employee.

Figure 6. Authentication Profile

The same policy can be applied for open wired ports as well. The policy needs to be attached to the port and not to the clients. Currently QoS policies cannot be attached to wired “clients.”

Note: Wired port application is described earlier in the wired section.

Ingress Policies on WLAN/SSID

Although the policy application happens at the WLAN level from a CLI standpoint, the policies are actually applied to every instance of the SSID in each of the <access point, radio> pairs in the system. This is internally referred to as the BSSID. SSID is used synonymously with BSSID in this document. At SSID level we can police and mark. However, at SSID level, marking is only possible with a table-map. In the following example only table-map with a default action of copy is defined. It retains the incoming DSCP in the IP packet.

table-map dscp2dscp

default copy

Policy-map TRUST

Table Map dscp2dscp

default copy

wlan open 1 Employees

service-policy input TRUST

The QoS policy is applied under the WLAN configuration. The SSID policy is applied as shown in the following example. This results in “trusted” behavior for traffic ingressing from wireless, similar to wired.

Wireless: Egress Quality of Service

This explains the capabilities of QoS that are available on the Cisco Catalyst 3850. On the egress (downstream), QoS capabilities exist per access point, radio, SSID, and client.

Policy on Access Point/Port

The ports that are connected to access points are termed wireless ports throughout this document. There are four queues on the wireless ports to match the four queues on the access point. The queue structure is 2P2Q3T: two priority queues, and two SRR queues, with three thresholds each. The recommended queuing configuration in a 2P2Q3T structure is shown in Figure 7.

Figure 7. 2P2Q3T Queue Model for Queuing Application Traffic

Four queues are created at the port level when a port is configured as a wireless port: real time 1 (RT1), RT2, unicast non real time (NRT), and multicast nonclient NRT.

The multicast nonclient is classified as any traffic that has a destination IP address of multicast or broadcast.

policy-map port_child_policy

class non-client-nrt-class

bandwidth remaining ratio 10

Switch#sh policy-map in gig1/0/3

GigabitEthernet1/0/3

Service-policy output: defportangn

Class-map: class-default (match-any)

Match: any

Queueing

(total drops) 0

(bytes output) 17633136

shape (average) cir 600000000, bc 2400000, be 2400000

target shape rate 600000000

Service-policy : port_child_policy

Class-map: non-client-nrt-class (match-any)

Match: non-client-nrt

Queueing

(total drops) 0

(bytes output) 17633136

The following is the default behavior of the four queues:

Q0 (RT1): Control traffic Q1 (RT2): None Q2 (NRT): Everything other than multicast NRT and control traffic Q3 (multicast NRT): Multicast and nonclient traffic

Default QoS policy is applied to the wireless port in the downstream (egress) direction. On port level no policy is supported in upstream (ingress) direction. The policy on the port is applied to the CAPWAP encapsulated packets egressing out to the access point.

The default wireless port policy includes a port shaper and a child policy. The parent policy cannot be modified by user and is controlled by the WCM. This parent policy has a port shaper that is the sum of the radio rates on the access point. The child policy on the wireless port is user configurable.

The following describes default child policy configuration:

The following is the overall wireless port policy:

bandwidth remaining ratio 10

Class-map: class-default (match-any)

Match: any

(total drops) 0

(bytes output) 0

Switch#sh run policy-map port_child_policy

Building configuration...

Current configuration : 227 bytes

!

class non-client-nrt-class

bandwidth remaining ratio 10

class voice

priority level 1

police 20000

class video

priority level 2

police 20000

class class-default

bandwidth remaining ratio 25

Switch#sh policy-map interface wireless radio

Radio dot11b iifid: 0x104F10000000011.0xC9CA4000000004

Service-policy output: def-11gn

Class-map: class-default (match-any)

The “port_child_policy” can be modified by the user to queue different application traffic at the SSID level. This

traffic is queued toward the appropriate queues at the port level. The following is the “port_child_policy” configuration example:

The “police 20000” statement in the “class voice” and “class video” polices aggregates multicast traffic for each

class at the port/access point level. It does not police unicast traffic that is classified using the “voice” and “video”

class-maps.

Policy on Radio

Radio-level policy is not user configurable. This is a rate limiter that limits all traffic going to the radio. Currently only two radios are supported per access point, and hence two rate limiters supported per access point. The Cisco Catalyst 3850 polls the access point to discover the maximum rate of the radio, and a shaper is placed in order to limit the oversubscription of the radio. Based on the discovery of maximum rate, the rate limiter can limit at 200 or 400 Mbps for 2.4G and 5G bands, respectively.

The following is the policy at radio level: