In this post we will see how to classify traffic in this switch platform. Real advantage of 3850 (or any other CA switch platform) is you can classify both wired & wireless traffic using the same classification rules on your access layer. In CUWN you cannot do this as all wireless traffic is CAPWAP tunnel back to your WLC.

Here is our CA topology where two PCs (PC-1 & PC-2) with Jabber clients connected to two VoIP phones. iPhone5 with Jabber client (v9.5.0.153580) using as wireless client for testing. We will see how we can use classification policy to mark this traffic consistently whether it is coming via wired or wireless.

Jabber using SIP (Session Initiation Protocol) TCP/UDP 5060 & 5061 for voice signalling & RTP (Real Time Protocol) UDP 16384-32767 as destination port range. There may be additional TCP ports using for directory services, file transfers between CUCM & jabber clients, but those protocol may not require any specific prioritization.

If you sniff a wireless packets when iPhone5 is making a jabber video call you can see the QoS setting of these frames. Here are two wireless frames, one for SIP signalling & one for RTP media.

When these wireless frame hits AP it will map original packet DSCP to outer CAPWAP header DSCP (unless you do WMM_UP to DSCP mapping). So signaling packet goes as CS3 & media packet goes as AF41. Here is the packet capture at G1/0/2 proving inner DSCP value copies across to outer CAPWAP DSCP.

If you are using window7 laptop as wireless client with Jabber (v9.2.2 Build 3271), you will see DSCP value will be 0 (or BE) for both signalling & media traffic (unless you classify at group policy level). So when it goes to wired network both video & signalling traffic goes as Best Effort in this scenario.

Let’s create a service policy to classify these traffic. Here is our interesting traffic classification in this scenario. This is more generic classification ACL & if you really want you can be more restrictive instead of any keyword.

3850-2(config)#ip access-list extended VOIP
3850-2(config-ext-nacl)#permit udp any any range 16384 32767

3850-2(config)#ip access-list extended SIP
3850-2(config-ext-nacl)#permit udp any any range 5060 5061       
3850-2(config-ext-nacl)#permit tcp any any range 5060 5061

Now let’s define class-map for each type of traffic. I have used “match-any” keyword, where you can use multiple classification ACL later on still using the same class-map.

3850-2(config)#class-map match-any VOIP-TRAFFIC
3850-2(config-cmap)#match access-group name VOIP

3850-2(config-cmap)#class-map match-any SIGNALLING  
3850-2(config-cmap)#match access-group name SIP 

Finally define a policy-map to re-classify the traffic

3850-2(config)#policy-map LTU-INGRESS-POLICY
3850-2(config-pmap)#class VOIP-TRAFFIC
3850-2(config-pmap-c)#set dscp ef
3850-2(config-pmap-c)#class SIGNALLING
3850-2(config-pmap-c)#set dscp CS3

Now you can apply this policy on your WLAN as shown below. I have used “client” keyword, then policy is applied to each wireless client authorized into the SSID and is applied independently to each of clients. When using service policy without client keyword, the policy applies to the SSID and treats all clients as aggregate (This is important to remember, specially if your ingress service policy include some policing element). Also note that WLAN to be disabled prior to apply the service policy via CLI.

3850-2(config-wlan)#service-policy ?
  client  Assign policy-map to all clients in WLAN
  input   Assign policy-map to WLAN input
  output  Assign policy-map to WLAN output

3850-2(config-wlan)#service-policy client ?
  input   Assign policy-map to all clients in WLAN
  output  Assign policy-map to all clients in WLAN

3850-2(config-wlan)#service-policy client input ?
  WORD  policy-map name

3850-2(config-wlan)#service-policy client input LTU-INGRESS-POLICY
% switch-1:wcm:Please disable WLAN before config client policies
3850-2(config-wlan)#shut
3850-2(config-wlan)#service-policy client input LTU-INGRESS-POLICY
3850-2(config-wlan)#no shut

You can verify your policy map configuration using “show policy-map <NAME>” command. Here is how our policy-map config looks like

3850-2#show policy-map LTU-INGRESS-POLICY
  Policy Map LTU-INGRESS-POLICY
    Class VOIP-TRAFFIC
      set dscp ef
    Class SIGNALLING
      set dscp cs3

3850-2#sh run | sec wlan 3850
wlan 3850 17 3850
 no broadcast-ssid
 client vlan WLN-STD-6
 radio dot11a
 no security wpa
 service-policy client input LTU-INGRESS-POLICY
 no shutdown

Now here is the traffic going out of the trunk port (G1/0/48) of 3850-2 switch. As you can see now traffic is classified according to your policy where signalling mark as DSCP CS3 & VoIP marking as EF.

Now if you look at the wired port traffic of (G1/0/11) when you make a jabber call between PC-1 & VoIP-2 you will see DSCP value of 0 for both media & signalling as shown below.

You can apply the same classification policy-map you created to these wiredports as well.

3850-2(config)#int range g1/0/11-12
3850-2(config-if-range)#service-policy input LTU-INGRESS-POLICY

Now if you look at the G1/0/12 (traffic going to VoIP-2) this time you will see media traffic go as EF. (if you take a packet capture of G1/0/48 you will see signalling traffic going as CS3 as well)

This is the real beauty of Converged access where you can apply same classification,marking,policing rule at your access layer to both wireless & wired traffic without any inconsistency. In CUWN you cannot do this as access layer switch does not have the visibility of inner IP packet (only see the CAPWAP traffic from AP to WLC).

In this example we have only used two traffic classes to illustrate the concept, but in real world you can use 8 class-map model to fit for all other type of traffic as well. In a future post we will see how to define a comprehensive service policy including policing as well.

Related Posts

1. 3850 QoS – Part 1 (QoS Touch Points)
2. 3850 QoS – Part 2 (Queuing Models)
3. 3850 QoS – Part 3 (Port specific QoS Roles)
4. 3850 QoS – Part 4 (Wireless QoS Mapping)