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)
