Great response Jeff Sent from my iPad
> On Dec 29, 2013, at 11:15 AM, Jeff Rensink <[email protected]> wrote: > > 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 > CCIE # 24834 :: Wireless / R&S > :: World-Class Cisco Certification Training > > Direct: +1.810.326.1444 > :: Free Videos > :: Free Training / Product Offerings > :: CCIE Blog > :: Twitter > > >> 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
_______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
