Cisco Live! recap – Sunday

Wow – what a trip. My feet have finally stopped smoking. Note to self: next time, stay at the Mandalay bay next to the convention centre, you’ll still get plenty of exercise.

My memory of the finer details are fading fast, so here’s my shotgun recap for Sunday:

Sunday: I met an old buddy, Steve in Calgary, and we carried onto Vegas. We got checked into the hotel, and headed to the convention centre to pick up our badges and CLUS backpacks. Immediately, many of us who had “met” on twitter some time back were coordinating to meet up in person, like an awkward online dating experience, but with fewer expectations 😉

The convention centre is huge. and 3 floors. Steve and I were headed down the escalators from the 3rd floor when lo’ and behold… a wild Rob Boardman appeared riding upwards. A ‘shoot from the hip’ kind of guy, when we realized what was happening, I could see the gears turning. salmon-run-600x401He evaluated his options, turned around on the upwards traveling escalator, and began heading downwards to rendezvous with us. I felt like I was watching the #VegasSalmonRun watching Rob weave his way against the natural flow (even though there was no chance of any spawning). We noted that, for the remainder of the week, there were signs posted at the escalators to remind everyone to pay attention to the direction of travel. Rob made an immediate impression on CLUS.

Robb is the brains behind Hub Holster. If you do Wi-Fi site surveys, check out the site. More cool products are in development too – keep an eye on this sockeye.

Stoked to bask in the warm glow that is Rob’s in-person presence, we carried on our twitter escapade to combine the gravity of our own stars with the rest of the twitter galaxy.  Next thing I know, Steve, Robb and I ended up at “the Hub” of CLUS where we had the pleasure of meeting the Matts – Haedo and Ouellette (NOT a voice guy FYI) – two “CCIE pending”s – follow them to join the struggle. Ask them about the RSv5 written exam.

Hungry, we began wandering into the Mandalay bay looking for sustenance, catching up along the way with Rob #2, whom I refer to as superman. Superman is a longtime mentor of mine, and the nickname is not (just) because he’s a hero. Superman is no here.

Lunch at Citizen’s. One of the last moments of calm for the whole week, and a good start to new friendships.

Rob (superman), Steve and I would later meet up with another old friend, Schwaby for the Canadian world domination conference dinner at gfx-facebookTom Colicchio’s CraftSteak. What an awesome way to burn a hole in your pocket. Amazing steak, amazing food. The four of us were once upon a time all doing time at the same company. Together, we’re kind of like the power rangers, a bunch of Cisco engineers covering RS, Wireless, Collab, Security, and DC.

Sunday was a great day. I learned quickly that the people and new connections will without a doubt end up being the best thing about CLUS.

More recaps and new people to come.

When a 6 means 5 – Cisco WLAN QoS

Making sure QoS does its job as expected includes ensuring that the WLC is properly configured to translate between WMM markings on the WLAN and CoS/DSCP markings on the LAN. Many of us know that the WLC uses the Platinum QoS profile which is associated to the Access Category (AC) AC_VO which uses a user priority (UP) marking of 6. On the wired LAN, we tend to use a layer 2 CoS (or 802.1P) marking of 5, which is also usually mapped to a layer 3 DSCP marking of 46, or EF. So we know that a WLC or AP should map the UP 6 to a CoS 5 when bridging frames between the WLAN and LAN.

I’ve been reviewing some past projects, and I was reminded that Cisco documentation used to recommend that we map UP 6 to CoS 6. This didn’t make a lot of sense to me at the time, especially when I wanted the voice traffic to end up with a CoS 5 or DSCP EF on the wired LAN. Here is a screenshot I had taken from the Cisco configuration guide at the time:

Cisco Unified Wireless QoS Tech Note - Cisco Safari, Today at 8.28.19 PM

Sometimes mistakes make their way into documentation, so at the time I decided I had better test to see what the WLC would do with these settings. I set up packet captures on the wired switch ports and used a Cisco 7925 handset to get WLAN captures. With the QoS profile mapping set according to the screenshot above, here is what happened:

  • The 7925 marked the voice payload frame with UP 6 at L2, and DSCP EF at L3
  • From AP to WLC, the CAPWAP encapsulated frame was marked with DSCP EF
    • APs were on access ports, so no L2 CoS markings
  • When the WLC placed the packet on the wired LAN as an 802.3 frame, the markings were L2 CoS 5 and L3 DSCP EF

Wait – didn’t we map the Platinum (UP 6) profile to CoS 6? Even better, if we mapped the profile to Cos 5, the result was… exactly the same!

Turns out Cisco’s was saying one thing and doing another. Here’s a recent tech-note where they come clean:

Cisco Unified Wireless QoS Tech Note - Cisco Safari, Today at 8.58.42 PM



I knew I remembered this from somewhere! What a odd behaviour. Note that the all that has changed is the default setting and thus the recommendation – we should map WMM 6 to CoS 5. The behaviour hasn’t changed and if you map to CoS 6, well then Cisco still goes ahead and spits out a 5 anyhow.

And frankly, that’s the right choice in my opinion.

My First Design Part 3 – ADDENDUM

I received some feedback on this post that I’d like to share. The idea behind this series of posts was to share my admittedly novice design process so that others could learn with me; and so, rather than edit the original post to fix errors, I’d like to call them out so others can see what I’m learning.

Here’s a quick recap of the coverage requirements set for this project:


Note that the channel overlap is set to a max of two APs at -86 dBm before the requirement is flagged as not being met. We’ll look at this later.

My signal strength heatmap settings were called into question:


Specifically, the fact that the grey edge ends at -73 dBm. What I had done was used the signal strength visualization to represent two metrics:

  1. Coverage I want – where the requirement is met, or anything above -67 dBm
  2. Coverage I don’t care about – where the requirement isn’t met, or anything below -67 dBm

Then I arbitrarily set -73 dBm as a threshold to indicate where the requirement wasn’t quite met, but wasn’t terrible overall. This was a poor choice on my part!

I had forgotten about something useful that I had learned in the ECSE course. The signal strength visualization can show us three useful metrics:

    1. Coverage I want – where the requirement is met, or anything above -67 dBm
    2. Coverage I DON’T WANT – where the requirement isn’t met, but the AP is still causing CCI on that channel, or -67 dBm to -86 dBm (-86 dBm to match the channel overlap requirement)
    3. Coverage I don’t care about – where the requirement isn’t met, and the AP signal should be low enough to not cause noticeable CCI; anything below -86 dBm

There’s an important distinction there!

Now this doesn’t change my design much. Let’s take a look with the heatmap coloring rules set to the appropriate “want/don’t want/don’t care” levels. Here again is the signal strength for the main floor showing the where the requirement is measured against the two strongest APs:


and here is what it looked like before:

Main Floor - Signal Strength (2 Strongest APs)

Minor changes showing where CCI flows into the areas I had stopped caring about before hand. For reference, here is the signal heat map for the strongest one AP, with the “don’t want” levels set to go to -86 dBm:


The real benefit of this though comes when we look at one AP at a time. Here I’m only looking at the coverage for a single AP. The green areas again indicate where our requirement is met, but look at all of that grey! These are areas where this AP is still heard above -86 dBm, meaning we can’t reuse that channel without causing CCI!


Ok, so has there been any effect on my CCI metrics? Let’s take a look. In this heatmap, the “don’t want” signal strength level has been left at -67 to -86 dBm, but we’ve moved to the channel overlap visualization:

Main Floor - Channel Overlap

Looks the same! Phew! Let’s see what it’s telling us:

We’re still using the -86 dBm threshold as the point where we stop counting overlap as CCI, so here we have two APs on the 40 MHz channel covering channels 108 and 112, both heard above -86 dBm (-63 and -74 in this case).

Hopefully this helps to clear up some of the last post! Let me know if anyone has more questions or comments!

My First Design Part 3 – Main floor

UPDATE: When you finish reading this post, please see the addendum post HERE

Welcome to the next part of my first design saga! Now we get to the good stuff…

Here we get to see what every client wants to see, but often doesn’t really know how to interpret – fancy heat maps! There is a lot of potential here to mislead. It is very easy to make every heat map look a nice shade of green over the entire coverage area without any explanation as to what we’re actually looking at. Therefore, let’s start with my legends:

Signal Strength Color Legend (values in dBm):


The map is calibrated to show colors for values from the minimum requirement of -67dBm and higher (better signal). Any values below -67dBm and as low as -73dBm are shown in grey.

SNR Color Legend (values in dB):


The map is calibrated to show colors for values ranging from the minimum requirement of 25dB and higher (better SNR). Any values below 25dB as low as 20dB are shown in grey.

Channel Overlap Color Legend:


The map is calibrated to show green for areas with no channel overlap (that is, only one AP on the channel over -86 dBm). Yellow indicates areas with 2 APs overlapping; and grey is anything more than 2.

This is exactly how it appears in the document delivered to my client, Aperture Science. It’s important that the heat maps give us a visual reference for where we are or are not meeting our design requirements (see part 1 and part 2!), so the legends are set so that grey shades are used anywhere where the model predicts that our requirements are not going to be met.

Let’s look at the main floor. It’s half the size of the two upper floors. First, what the client was looking for overall – AP placements:

dual AP This is an example AP transmitting in both the 2.4 GHz and 5GHz bands. The purple box indicates the 2.4 GHz channel. The orange box indicates the channel and channel width (40 MHz).

5 only AP This in an example AP transmitting in the 5 GHz band only. 2.4 GHz is disabled to avoid creating co-channel interference.

Main Floor

Main Floor - Access Points

Simple enough. Next, a brief summary of how we made out trying to meet our requirements. Color coding to match Ekahau’s health map for later.

Predicted Metrics

Main Floor

1F - Predicted Metrics

Next, a brief summary of areas the predictive design identified as possible problem areas:

Potential Problem Areas

Main Floor

Signal Strength – The areas which have some potential for issues are the north elevator, the walk-in cooler and freezer, and a small space in the radioactive storage room.

SNR – The predictive design for the main floor includes one small location where the minimum requirement is not met in the outside corner of the north elevator.

Number of APs – Minor spots in the cylinder storage room, walk-in cooler, radioactive storage room, and east fume hood room areas.

These two parts were repeated for each floor, at the beginning of the document. The idea is to give the less technical folks the high-level results in the first handful of pages of the design doc without having to wade through the techno-babble.

Further along, I provide the detailed heat maps. Starting with Signal Strength, against the requirement for TWO APs at -67 dBm or higher:

Appendix: Design Details – 5 GHz

Main Floor Details

Signal Strength – 2 Strongest APs

Color Legend (values in dBm):


Main Floor - Signal Strength (2 Strongest APs)

The areas which have some potential for issues are the north elevator, the walk-in cooler and freezer, and a small space in the radioactive storage room.

Here we can see the aforementioned potential problem areas. The elevator is in the top left corner and has a white area (-72 dBm or lower), but we agreed the elevators were not critical. The middle of the drawing has a large grey area (-67 to -71 dBm) which is inside the walk-in cooler/freezer. You can imagine that the steel construction is a strong attenuator here. Note that grey means that we’re within 5 dBm of our requirement, even if we haven’t met it. I can tell you that we do meet the requirement with a single AP, so it’s likely that a 7925 handset will be able to make a call without problems in the freezer, but we can’t guarantee a successful roam. Luckily for us, there’s not likely to be a lot of roaming going on whilst in the freezer.

There are also a couple of minor grey areas on the bottom of the drawing, in the edges of the service area, in shelves, concrete stairwells, and rooms that aren’t actually in our coverage area.

Also, I did provide all of the heatmap files in a separate zip archive, and included the heatmap for the single strongest AP; but, since the signal strength for a single AP is not a metric we’re using to meet our requirements, I did not use it in the main document (the document gets long with the rest of the heatmaps as it is).

I also provided the visualization statistics. I haven’t decided if I will continue to use these in future design documents:


Less than 5% of the main floor area does not meet the signal strength requirement for the two strongest APs.

Next, SNR:


Color Legend (values in dB):


Main Floor - SNR

The predictive design for the main floor includes one small location where the minimum requirement is not met, the outside corner of the north elevator.

Pretty solid I think.

Next, I briefly pointed out the visualization statistics for Data Rate (100% met) and Number or APs (98.2% met). The heat maps for these are less useful, so I didn’t include them in the document, and just pointed out that there was no concern with these metrics.

Then Channel Overlap, or Co-Channel Interference:

Channel Overlap

Color Legend:


Main Floor - Channel Overlap

Minor overlap of two APs in the lower rooms in the image.

Ok, we have a few areas where two APs on the same channel can be heard over our threshold of -86 dBm. This is not the end of the world, but it does mean that we do not have quite the full capacity of 14 APs across 40 MHz channels each; but we do have 96% of the area without overlap, and the experts I’ve heard from seem to agree that anything over 90% is quite good.

Now it’s important to remember here that this is the PREDICTIVE design, and therefore doesnt take into account interference from neighboring Wi-Fi radios that won’t be under Aperture’s control. This is a multi-tenant building; and looking at the floor plan for the main floor, this is about a quarter of the entire floor area in the building.

The good news is that Aperture is the only tenant on all three floors of this building’s East half. The main floor plan we’re looking at here is the North side of the East half, and the South side is also occupied only by Aperture. The building’s exterior facade is heavy brick masonry, and the construction should also do a good job of isolating radio signals from the West half of the building, so if I’m lucky, the CCI won’t be terribly higher than the predictive model. That being said, I am not banking on this assumption and the document is clear:


There is no channel overlap in the 96% of the coverage area. This will certainly change in the validation stage when some signals will be heard from sources outside of Aperture’s control.

Validation is important. We have no way of knowing whether or not we’ve met our design requirement unless we validate, and here I’m trying to imply that validation is not an optional step. This project was sold to the client with validation as an included component.

I also included Ekahau’s Health map as a high-level reference:

Main Floor – Overall Health & Problem Areas

1F - Health

Health Leg.png

Signal Strength – elevator and walk-in cooler, walk-in freezer areas. Minor reductions in signal at the east lab entry zone and radioactive storage room.

Number of APs – Minor spots in the cylinder storage room, walk-in cooler, radioactive storage room, and east fume hood room areas.

SNR – Minor spot inside the walk-in cooler/freezer which is actually within tolerance.

I’m not sure why, but Ekahau calls out SNR (blue tiles) in the cooler/freezer, even though the metric is met on the SNR heatmap. Jerry – if you’re reading this, feel free to comment if you can shed some light on this.

I’ll wrap this post up here, and we’ll look at the other floors next, then perhaps some of the specific obstacles on some of the floors that I’m curious to see how well my predictive results align with the real world behavior.

UPDATE: See the addendum post HERE


I got home from the CWAP bootcamp last Saturday, and, knowing that the CWAP exam was about to switch to the new version at the end of the month, immediately checked Pearson Vue for appointments to write the current version.

Unfortunately, For whatever Monday at 830am was the only appointment available, so I had no other choice but to take it. I had initially thought that it said Monday when I booked on Sunday, so I got quite concerned that I had roughly 12 hours to finish getting ready, but thankfully I quickly realized that I had one week to go – I wrote this morning, and can happily say I passed without too much difficulty.

CWAP has been a huge learning experience. The amount of packet level knowledge is phenomenal, and I’m glad I took the exam before it was refreshed.

Onto CWSP…

My First Design part 2 – Overall design

I want to thank everyone for their feedback on the first post in this series! Next I’m going to share the “Overall Design” section of my first predictive design project. This section describes some of the specifications that the predictive design is based on, like the AP transmit power and placements.

This section is a little verbose – the client does not have a lot of expertise in RF so I wanted to give them some context to read; but in the future I’m hoping to clean this up. Recommendations or examples are welcome!

A couple of notes:

  • While this section is technical, I did try to keep it understandable for non-experts. We had an in-person meeting where we went over the document and they asked questions. At this time, they are primarily concerned with telling the architects where the Ethernet pulls should be located (with service loops to allow for repositioning).
  • You will see RRM referenced. Yes, the client (and I) are planning on allowing RRM to make channel and power level decisions – but I will be tuning RRM from the defaults.  I would love to hear recommendations on good ways to do this to work with this design. I have a few years of experience with Cisco’s implementation, but could certainly use a refresher. I’m planning to decide on the RRM settings during the validation phase.
  • I’m curious to hear feedback on the AP power settings – did I make a good choice?
  • Also curious to hear feedback on the choice to use 40MHz channels. There are non-VoIP clients which have less stringent RF needs, but who can make use of the bonded channels. I think the indirect benefit to the VoIP handset in addition to the other clients makes this a good choice… am I right?

I realize that some of these items rely on details regarding the building. Here’s a sneak peek of the placements and map of the 2nd floor:

2nd Floor - Access Points

Aperture science will occupy all 3 floors of this side of the building, which is a mix of office space and research/lab areas. I’ll go into more detail on some of the materials and spaces in upcoming posts.

Credit to Steve McKim of Great White Wifi for his post on AP to client power matching which I referenced in describing the power settings for the design.

I’m really looking forward to hearing the Wi-Fi community’s opinion on some of these points!

2.4.  Overall Design

Design Power levels:

Device 1702I AP 7925G Handset
Max Transmit Power 22 dBm 16 dBm
Antenna Gain 4 dBi 3.11 dBi
Design Minimum Transmit Power 13 dBm 13 dBm
Design Maximum Transmit Power 16 dBm 16 dBm

In keeping with Aperture’s current WLAN hardware, the WLAN is modeled using only the Cisco 1702I model AP, which has an internal omni-directional antenna.

The design assumes that the APs are mounted at a ceiling height of 8 feet, with standard alignment. For the 1702I, the standard alignment is horizontally mounted, with the Cisco logo facing the floor.

APs are all modeled using a reduced power output in both the 5GHz, and the 2.4GHz band, where enabled, of 20 mW (or 13 dBm), which, when the antenna gain is taken into account, amounts to a total EIRP (Effective Isotropic Radiated Power) of 17 dBm. The 7925G-EX handset is capable of a maximum power output of 40 mW, which is 16 dBm. This means that the maximum output power of the handset is higher than the modeled power of the AP. Note that the handset will likely operate at a lower average power level (i.e. 13 dBm) when possible to conserve battery power.

A higher power on the AP compared to the client device can cause issues where the client may “hear” the AP at a strong signal level (e.g. “Full Bars”), but the AP may not be able to hear the client at an adequate level. However, antenna gain (in contrast to output power) improves the ability to both hear and to be heard. Therefore, an increase in antenna gain is preferred over and increase of output power when there is any imbalance between EIRP of the client devices and the APs.

With this design, an example can be made showing the signal levels from the perspective of the AP and the handset; in this case, at 50 meters apart. Power gains and losses are simple additions/subtractions:

Link Budget – Cisco 1702I AP at 13 dBm and Cisco 7925G Client at max power

Downlink Uplink
AP sending to Client Client Sending to AP
Transmit Power 13 dBm 16 dBm
Transmit Antenna Gain 4 dBi 3.1 dBi
Effective Power (EIRP) 17 dBm 19.1 dBm
Free Space Loss -80 dBm -80 dBm
Receive Antenna Gain 3.1 dBi 4 dBi
Received Signal Level Client hears -59.9 dBm AP hears -56.9 dBm

Here the client hears the AP at -59.9 dBm, and the AP hears the client at -56.9 dBm. This means the AP is hearing the client better than the opposite. This also means that the AP could increase its own power slightly (matching the client) if necessary.

At one power level higher, the client hears the AP at the same level as the AP hears the client – a good, equal link:

Link Budget – Cisco 1702I AP at 16 dBm and Cisco 7925G Client at max power

AP sending to Client Client Sending to AP
Transmit Power 16 dBm 16 dBm
Transmit Antenna Gain 4 dBi 3.1 dBi
Effective Power (EIRP) 20 dBm 19.1 dBm
Free Space Loss -80 dBm -80 dBm
Receive Antenna Gain 3.1 dBi 4 dBi
Received Signal Level -56.9 dBm -56.9 dBm

Therefore, the design allows some room for transmit power to be adjusted by Cisco’s Radio Resource Management (RRM) to close perceived coverage holes where clients are at the edge of a service area.

Finally, if the AP is operating at 13 dBm and the handset reduces power to 13 dBm to save battery life:

Link Budget – Cisco 1702I AP and Cisco 7925G Client both at 13 dBm

AP sending to Client Client Sending to AP
Transmit Power 13 dBm 13 dBm
Transmit Antenna Gain 4 dBi 3.1 dBi
Effective Power (EIRP) 17 dBm 16.1 dBm
Free Space Loss -80 dBm -80 dBm
Receive Antenna Gain 3.1 dBi 4 dBi
Received Signal Level -59.9 dBm -59.9 dBm

In all 3 examples, the Received Signal Levels are quite strong, and the handset RSL is well above the -67 dBm requirement.


The 5 GHz band is the recommended band for serving VoIP due to the higher number of available channels and significantly lower likelihood of interference from non-Wi-Fi sources such as microwaves and cordless phones. As such, the design is for the requirements to be met only in the 5 GHz band. This design uses 40 MHz channels, which bonds two adjacent channels together, for more than twice the available bandwidth than a single channel.

While the 7925G handset is not able to use 40 MHz channels, most data devices can, and these devices require less airtime to send data when more bandwidth is available. Since they require less airtime, more is left available for the devices that can only use a single 20 MHz channel, so there is an indirect benefit for the handset.

Once the requirements were met using the 5 GHz band, the 2.4 GHz band was designed without attention to meeting the requirements. Instead, coverage levels were maximized as best as possible with the minimum amount of co-channel interference. The intent is for Aperture to push all capable client devices to the 5 GHz WLAN, and to only use the 2.4 GHz band with clients that are unable to use 5 GHz until they can be replaced.

Again, let me know what you think in the comments or on twitter @bmroute.

Meraki Auto-VPN over MPLS

Here’s a quick review of a recent Meraki MX deployment I wrapped up this week. The customer has 4 sites across Canada; one HQ with an Internet and MPLS connection, and 3 branches with only MPLS connections. We replaced their aging Juniper SSGs with MX65s.

Here’s the basic topology:

Initial State

The branch MXs reach the cloud controller through the HQ internet connection – internet connections are a requirement for running the Meraki gear; but it doesn’t have to be local. The branch MX uplink ports are connected to the MPLS cloud. At HQ, the MPLS cloud connects to a LAN port – keep this in mind.

Of course, site-to-site connectivity was required. Each site has two internal subnets/VLANs: one data, one voice. Simple enough right? Auto-VPN to the rescue!

VPN Setting

Turn on VPN at each site – we want full mesh, so every site is a hub. Then advertise the two local subnets into the VPN cloud at each site:

VPN networks

Done. Simple. Result:

Spoke to Spoke Only

Fancy green lines mean successfully established VPN connectivity! Auto-VPN is smart enough to realize that each branch/spoke appears on the internet at the same IP, but that the locally set uplink addresses are all reachable from spoke to spoke, so those VPNs form without a problem. But this is not what we wanted. Spoke-to-spoke traffic is good for voice calls, but all of our servers (including the call manager) are at HQ… and there are no fancy green lines to HQ.

What is going on? Well I can’t say with 100% certainty what exactly the limitation is, but I know one thing about the Meraki MX and VPNs – they won’t establish VPN SAs over non-uplink ports.

There are also some limitations with hairpinning – in this case, in order to establish an SA with the HQ uplink (Internet) port, the branches would need to exit the HQ uplink port, and do a 180° turn to form an ISAMKP SA. I have some intel that says Meraki has tested this feature, but I can’t say when it will be deployed to customers.

So in the meantime, we need another solution – and Meraki has just the feature.

Remember VPN concentrators?

Add Concentrator

We can put in another MX at the HQ in VPN concentrator mode. It’s a normal MX (in this case an MX64 because we only need the one port). We connect the uplink to another LAN port on the HQ MX, in this case, we gave it a separate subnet.

We can only use the uplink port on the MX when it is in this mode, and then it will serve as a dedicated hairpinning interface, effectively putting that uplink interface inside the HQ LAN.

passthrough setting

When we do this, the VPN settings page changes. On the concentrator, we manually specify the subnets at HQ that should be reachable over the VPN:

concentrator VPN settings

No routes required – the concentrator will send everything to it’s own default gateway, which in this case is the HQ MX, where both these subnets are homed.

We then turn OFF the VPN at the HQ MX, and create static routes on the HQ MX pointing to the concentrator.

The new result:

End Result

Now we have fancy blue lines showing the VPNs between the branches and HQ, resulting in a full mesh.

Rumor has it that we’ll see two improvements in these deployments sometime in the near future – the ability to use the second uplink port without an internet connection to terminate VPNs, as long as the primary uplink can reach the cloud controller; and the ability to hairpin out the uplink as I mentioned earlier. Either of these should have replaced the need for a dedicated concentrator.

In the meantime, here’s the Meraki deployment guide for the VPN concentrator role: