Maybe you could share your capture file for us to look at. Not sure why a WLCCP frame would be purposefully destined to a wireless station.
But I wouldn't say that trusting CoS on an H-REAP port should be considered best practice. What you choose to trust is dependent on what traffic markings are most important to you. CoS is only available on the non-native VLAN. So if you trust CoS, you only preserve QoS markings for locally switched WLANs. You lose your markings for centrally switched WLANs and for CAPWAP management traffic. But the positive of trusting CoS is that CoS markings for locally switched WLANs should be capped at the WLAN maximum. So they are controlled by policy. Trusting DSCP works for everything. But the main risk here is that the DSCP on the wired network is a direct copy of the DSCP of the wireless frame (as marked by the client). So your clients could be marking their traffic with elevated DSCP values and get priority treatment on the wired network. So you need to weigh which markings are most important to you to preserve and if capping QoS markings on the wired network is something that you need to do. Regards, Jeff Rensink : Sr Instructor : iPexpert <http://www.ipexpert.com/> CCIE # 24834 :: Wireless / R&S :: World-Class Cisco Certification Training Direct: +1.810.326.1444 :: Free Videos <http://www.youtube.com/ipexpertinc> :: Free Training / Product Offerings <http://www.facebook.com/ipexpert> :: CCIE Blog <http://blog.ipexpert.com/> :: Twitter <http://www.twitter.com/ipexpert> On Sun, Dec 29, 2013 at 11:00 AM, Andre Aubet <[email protected]> wrote: > Hi all! > > > > I'm currently working on the QoS part of my study. > > > > For the HREAP (FlexConnect AP) locally switched, connected on a trunk > port, it is recommended to trust CoS on the switch. I completely understand > this point, to preserve the priority cos tag. > > > > However, I was wondering how could the cos tag be preserved for the CAPWAP > control traffic? Indeed, HREAP APs communicate with the controller over the > native vlan. By default this vlan is not tagged with a 802.1q header, so no > cos value can be added? > > > > I captured traffic on a HREAP AP link, and I can see the following: > > > > - 802.11 management frames are CAPWAP-encapsulated and sent to the > controller with no 802.1q tag (so no cos priority) > - CAPWAP control frames (Discovery/DTLS) are tagged with 802.1q vlan > (native vlan), and the cos is present (cos = 6) > > > > I can see also some frames with the 802.1q header of the native vlan with > a cos = 4. These frames are identified by Wireshark: > > > > - as 802.11 frames, encapsulated with CAPWAP (from WLC to AP) > - the 802.11 part is identified as the WLCCP protocol > - the 802.11 frame encapsulated has the following addresses: > - Receiver + Dest. address: STA (laptop) > - Transmitter + Source address: LAP > > > > I don't know what are these specific frames. If someone has the answer, > I'm interested > > > Andre > > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc >
_______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
