Very interesting how these things evolve.  Many thanks for your responses. Regards, ... View more

@Rasika Nayanajith wrote: Hi Jerome,   Thank you very much for such a detailed response. We are lucky to have someone like you who is happily share your knowledge on CSC forum time to time.   From response you have given, I learnt something new about WiFi which I did not know before.   Pls come back to CSC more regularly & share your wisdom.   KIT Rasika Thank you both. This has been very helpful.   Sorry, but more holes keep appearing. Did they use 3-bits for the UP value to future proof the standard? Can't think why else when there's only 4 access categories used by EDCF? And if the packet's DSCP is mapped to one of 8 UP levels by the WiFi driver, then does the same WiFi driver also map a second time from UP level to an access category? Or maybe I've misunderstood something along the way. Also, if the client supports WMM but the application has not applied a DSCP marking to the packet then I assume the frame ends up in the AC_BK category, is that right?   I've watched the Jerome's AireOS 7.0 and 8.0 video and also had a read through some of the RFC. Not got to the Cisco Live video yet though :) ... View more

@Rasika Nayanajith wrote: 1.) If WMM certification is the 802.11e amendments around QoS, then why does the Cisco 8.6 install guide state, "This UP is used to derive the over-the-wire priorities for non-WMM traffic". I thought the 8 UP levels are mapped to 1 of 4 access classes, and only work with WMM compatible clients?   That's true, those 8 UP values are map to 4 different Access Categories. It is for WMM clients who are capable of differentiating its traffic based on those categories.   However early days of AireOS (7.x ) if non-WMM client send a frame, it will map to SSID configured QoS profile DSCP/UP value (that is if SSID configured with Platinum, those non-WMM client traffic get EF or UP=6). Therefore even non-WMM clients traffic get QoS treatment at the AP.   Great, makes sense, thank you   2.) Ref downstream over-the-air traffic, I assume it doesn't matter if the wireless client supports WMM, or not, cos the prioritisation is performed by the AP alone, by using 4 access classes each with different random back-off time windows? Or, is some cooperation required with the wireless client?   As per my  understanding, that is true. Packets get prioritized based on APs capability, if that supports WMM, it will have those 4 AC & voice traffic get priority over best effort for a given client. To do that no client cooperation required.   However if given client does not support WMM, it will not understand those QoS control information in wireless frame & might discard that info.   But even if the receiving wireless client doesn't support WMM and discards the marking, then it doesn't really matter, does it? Hasn't it already done its job and provided some basic form of prioritisation of over-the-air downstream traffic back to the wireless endpoint?   3.) Ref upstream network traffic between AP and controller (ignoring fabric enabled for now), my understanding is that, in 8.0+, the packet's DSCP marking is mapped to the CAPWAP header. I've read conflicting info. Is this on a per-SSID basis (i.e. not very granular), or per-packet basis?   This behavior is not per-SSID, it is a global setting. So it is per-packet basis. Here is a good video from Jerome, explaining those QoS changes introduced since 8.0 Qos: changes between AireOS 7.0 and 8.0   It's a bit late here now but I will watch this in the morning.   Many thanks for your thorough reply.   I have one more question if you, or anyone, is able to help.   4.) On a WMM-compatible wireless client, my understanding is that the application developer will set the DSCP marking appropriate to the type of application, but perhaps this is Apple devices only. Either way, how is the DSCP marking translated to an access class? I assume some form of mapping table. Do you know much about this side of things and whether or not vendors vary much in their implementation approach? I assume some, like Cisco, closely follow RFC 4594? The only bits I've picked up on this side of things is from Jerome's video on Apple Fastlane but that didn't quite cover this. ... View more

I'm not keen on a stacked core unless, as Julio says, it's a small company. Seen too many stack failures over the years. I'd prefer a pair of standalone L3 switches, provided you can provision a routed-only core. I suppose the same concerns should apply to VSS because it's a single control plane but VSS does generally seem very stable (based on customer feedback and speaking to our support centre). Cisco is really pushing the 9K - it seems to be the default answer to any question. That's fine and the 9K is likely the best long-term choice for many, but you just need to be a bit careful.  It's early days for me spec'ing these switches but they seem to be missing quite a lot of functionality. Today I've been looking at a dual 9500-40X core and trying to work out what tools the customer will have for a core upgrade. Doesn't seem to be much on offer. For example, the Graceful Insertion and Removal (GIR) feature is only available with ISIS. And we can't spec ISIS cos we need to keep the costs down and the Essentials lic (on 9300 edge) will only support OSPF for Access or Stub EIGRP. Happy days. ... View more