Here comes Mobility Field Day 2! 

I’m currently sitting in the Saskatoon airport waiting to board my first flight on the way to Mobility Field Day 2 in San Jose, and I am really excited to be a delegate for the first time!

Side note: as I prepare to spend two days seeing what the best in the mobility industry are up to, I’m disappointed to be sitting at YXE airport using my hotspot because the Wi-Fi is currently completely inoperable. It had been working very well on recent trips. Oh well.

First of all, I’d like to send a little shout out to the Tech Field Day crew – they have been awesome in helping us get ready to travel to San Jose and participate in this fantastic event. They’ve clearly done this before and know all of the steps to make sure everything goes as smoothly as possible. Thank you TFD team!

Tune into MFD2 on Tuesday, July 25 here. Dont forget to follow the hashtag #MFD2 on Twitter during the event to catch our up to date thoughts, and mention me (@CdnBeacon) or any of the other delegates if you have any questions you’d like us to ask!

Here’s what I’m looking forward to:

Mist Systems

I’ve had the chance to play with the Mist APs a little bit recently, and I’ve been impressed. It was very easy to get an SSID spun up, and what was really neat was how easy it was to setup their virtual BLE (Bluetooth low-energy) beacons. It took me longer to find the floor plans for my house (and I already knew where they were) than it did to set up the beacons and use their app to watch myself wander around the house. I wasn’t terribly familiar with Mist’s solutions before this, so I’m really looking forward to going in depth. Keep your ears open for things like “blue-dot experience” and lots about client experience analytics.

Mojo Networks

Mojo has gone through some reinventions over the past years. I was more familiar with them as Airtight, but they have a new focus now. I saw them at WLPC and their mojopackets online PCAP analyzer it pretty neat. I’m very curious to hear about their plans for Wi-Fi on open hardware. We’ve heard that idea before, let’s see if someone can make it a feasible reality for the enterprise, and in my case, industrial use cases as well.

Cape Networks

I was fortunate to come home from WLPC with my own Cape sensor, and I’ve had it running in my office ever since. Cape has a great UI, making it really easy to see the important metrics – how is the Wi-Fi working? I think it’s narrow-minded though to think of the Cape sensor as a Wi-Fi sensor only, because it’s really good at letting me know when the network isn’t the problem. Cape has some great potential and now that I’ve spent some time with it, I’m ready with some ideas for tweaks and improvements – bring your notepad, Drew. 

Nyansa

Nyansa has been doing some really interesting work in gathering huge amounts of Wi-Fi client behaviour data, and turning it into informative insights. This is another one that I am looking forward to learning about a bit more in depth. With so much client variation in our environments, I really love the idea of being able to identify, for example, that any iPhone 6 running iOS 9 has a bad habit of sticking to an AP well past when it should have roamed. 

Netscout

One of my favorite tools is my Netscout Aircheck G2. There is a lot of talk in the Wi-Fi industry these days about how difficult it is to get relevant data about Wi-Fi and client performance from the wireless clients themselves. My G2 is great for giving me data from a client perspective, and sometimes there is no substitute for a handheld tool. I’m still a network engineer as much as a mobility engineer, and I admit I’m trying to find a good reason to buy a LinkRunner AT. Netscout’s tools are great for giving me the answers I need quickly. 

On-premise IT roundtable

Rumor has it there might be a recording of Gestalt IT’s On-premise podcast. I’ve been enjoying these episodes since they started as a “just the right length” dive into various issues and technologies for our industry. Keep an eye out for an episode from MFD2 on iTunes, or the website here.

See you in San Jose!

Changing Wireshark Link-layer Header settings on Mac OS

This is one of those quick posts aiming to save me and (maybe you) some time the next time I forget this.

On my Mac, I use Wireshark primarily to capture Wi-Fi traffic, in monitor mode. I want to see the Radiotap and 802.11 headers. Usually I leave Wireshark set this way.

On occasion, I actually use Wireshark to inspect higher level traffic – I want to see the IP addresses and TCP/UDP ports etc. I might be troubleshooting an issue and am using my Mac as the client trying to recreate the issue – so I don’t need monitor mode for that. Simple enough – turn it off in the interface settings (Find this button on the Main toolbar Wi-Fi. en0 Wireshark, Today at 9.20.38 PM  to access the menu, then scroll to the right to find the Monitor mode drop down and make sure your Wi-Fi interface has this disabled):

Wireshark · Capture Interfaces Wireshark, Today at 9.30.03 PM

Then just set the Link-layer header back to Ethernet, just like your other interfaces:

Wireshark · Capture Interfaces Wireshark, Today at 9.30.57 PM

Except “Ethernet” isn’t an option. I could’ve sworn that’s what it is set to by default after install…

I can’t believe this still trips me up every few months. I spent half an hour the other day scratching my head, when the trick is simply to restart Wireshark. Close it entirely, reopen it and voila:

Wireshark · Capture Interfaces Wireshark, Today at 9.34.30 PM

Ethernet is back! Also, the 802.11 options have disappeared because we’re no longer in monitor mode. Now I can see Ethernet, IP, and TCP/UDP headers again:

Wi-Fi. en0 Wireshark, Today at 9.35.58 PM

In comparison to capturing 802.11 frames in monitor mode:

Wi-Fi. en0 Wireshark, Today at 9.38.08 PM

I keep forgetting the need to restart Wireshark for the Link-layer options to change #facepalm.

Note: you also need to restart Wireshark after enabling monitor mode before the 802.11 options will show up in the Link-layer header drop down option.

Or maybe it’s just me. I’m confident that I’ll still forget all about this post next time I try to show a University Computer Engineering class how many packets it takes to load the Facebook home page.

It was 781 (including DNS lookups and a couple of retransmitted frames), in case you’re wondering…

PING! Not always what you think! – Meraki Wireless troubleshooting

I’m quite fond of the Meraki dashboard. I’ve seen firsthand how it can enable lean and low-skilled IT departments to manage more of their own networks themselves. The dashboard GUI makes it easy to find status and troubleshoot at a basic level, but it’s still important to actually understand what is going on under the hood.

Here’s an example. If you’ve ever seen the Meraki dashboard, you’ve probably seen the Ping tool on every client status page. Here, a Meraki AP is successfully Ping-ing my MacBook Pro:

pign-success-invalid-ip

Pretty straightforward. Ping the client, client responds, client is online and working, right?

If you have a Meraki Security Appliance, you may stumble across this little note on the Addressing & VLANs page:

ping-is-arp

Wait… Ping is based on ARP? What happened to ICMP?

We may have jumped to conclusions here. As it turns out, Meraki is not using ICMP like most of us would assume. Here’s an example of a few PCAP frames of that same Meraki AP ARP-Ping-ing my MacBook Pro:

directed-arp

Notice this is a directed-ARP; the Meraki AP (MAC 13:da:90) is sending an ARP request to the MBP (MAC 91:75:d8) rather than sending a broadcast. That is, the Meraki AP already knows the MBPs MAC address. But the ARP response tells the Meraki AP that the MBP is alive, and online – just like an ICMP Ping.

This brings about an interesting question. We network engineers often use Ping as a way to confirm that the network is working. A successful Ping means that routing, IP addressing and the physical path are all functioning correctly at layer 3. But if we’re doing a Ping at layer 2 with ARP – would we be wrongly assuming all is well when we get a response, just like with ICMP?

There is definitely some potential to make incorrect assumptions here. In fact, even though that screenshot above of the Meraki AP Ping-ing my MBP has a loss of 0%, at the time, my MBP had an incorrect IP address and was not Ping-able by other devices in the network (well, via ICMP at least). Here’s the PCAP’d ARP frames from the same time as that Ping output:

directed-arp-wrong-ip

Almost identical, except that both the ARP request and response are from 10.11.3.1, when the subnet is actually 10.11.30.0/24. However, the client is still responding, albeit at layer 2, and that’s good enough for the Meraki AP.

Now, I do think this is one of those things where the vendor has made an odd decision to label this as a Ping without being clear about what is actually being done, but it is after all our responsibility as the network engineer to know what we’re looking at. There are similar examples where traceroute can use UDP or ICMP, depending on the OS, and now you know that sometimes Ping is ARP instead of ICMP.

Here’s the relevant documentation:

Meraki Ping Tool

Wireless Professionals Compensation Survey

Today, Wednesday, November 30th there will be a one-day independent survey to gather information on the current state of compensation in the Wireless LAN community. We respectfully request your participation in this 90-second survey. The current results will be available to all survey takers as they complete the survey for instant feedback. Later, the complete results will freely reported back the entire community.
Thank you for your support and participation!
http://surveymonkey.com/r/wlccs2016 – Wireless LAN Community Compensation Benchmark

Cisco Live! recap – Tuesday

I was pretty exhausted Tuesday morning. With two young kids at home, I run on a minimum of sleep already, and all of the activity of CLUS pushed me over the edge very quickly. When the alarm went off Tuesday AM, I had to make a command decision – I knew I was not going to be able to keep up the pace set at the start without recharging my batteries, so I reset my alarm and went back to sleep.

Yep, I was a rookie at CLUS, this year, and I’ll try to be better prepared next time. Unfortunately, that means I had to miss my morning session “Fog Computing at the World’s Largest Copper Mine”. Which it too bad, because I spend a lot of time in mining and we have been looking into Fog Computing a lot lately.

The presentation is missing from the link above, but thankfully the session video is there. Funny that the first thing presenter Francisco Soto says is “Thanks for waking up early for this.” Now I feel terrible.

RowellRobMitch, and I had a meeting setup before lunch with Jerry Olla from Ekahau. I was stoked to be meeting some of the Ekahau crew! Jerry sprung for coffee, and that coupled with a little extra beauty rest meant I was having a pretty good start to day #2! Thanks Jerry!

Jerry answered some of our nagging questions about using Ekahau Site Survey. ESS is indispensable in the WLAN design stage for helping to develop real requirements and turn them into actual channel plans, power settings, antenna coverages. Without a tool like this, many people are just “eyeballing” WLAN design. Jerry also showed us a neat little project he had been working on using an ODROID C2 to build a custom iPerf server.

Jerry is awesome. We may have thought that there was some potential to abuse our new insider relationship with Ekahau to get our hands on some sweet, sweet swag:

Buoyed by the warm reception from Jerry, and our unrequited love for Ekahau, we weren’t ready to part ways just yet, so we headed over to WoS to meet the rest of the Ekahau crew!

Jussi Kiviniemi is well known in the Wi-Fi community, and an excellent representative of the Ekahau team. I was excited to meet him in person he is all class! The whole Ekahau crew just has the right approach to being part of the community. For example, Hannele managed to dig out some primo swag in return for some testimonials:

Maybe I was excited most of all for the legendary Finnish candy. I wear my Ekahau Polo to work all the time.

I may have gotten a little carried away:

Also this happened. No explanations will be forthcoming.

Big Kudos to Ekahau for their continued community support and participation. Also a well deserved shout out to Robert Bartz!

There were TONS of other badass vendors to meet!

Check out Smitty and the team at Acceltex. They’ve got a nice spread of antennas and even better some well thought out brackets and mounts for their own gear and the Cisco APs with internal and external antennas as well. Meru Mitch swears by these guys.

We are all pretty pumped this summer about the new Aircheck G2 from NETSCOUT, and meeting their social media manager Kendall was another highlight.Robb was doing his best to see if a Aircheck G2 could find it’s way to his home somehow (Kendall, he ended up paying good money for one – so you won that round!). I think Kendall probably saw more of us at CLUS than anyone would have wanted, but if anyone could handle these hosers, it was her.

That wouldn’t be the last Kendall saw of us…

Ok I did also squeeze in a session Tuesday afternoon. BRKEWN-3014 “Best practices to deploy high-availability in Wireless LAN Architectures with Patrick Croak.

  • Patrick had some great advice regarding minimizing the number of SSIDs:

BRKEWN-3014.pdf (page 17 of 120) Preview, Today at 9.28.03 PM

  • And a good reminder about client based CCI:

Check out the presentation link above for all of the good stuff.

I was looking forward to the evening events on Tuesday, namely… the CCIE Party! Steve, Mitch and I were off to the Hard Rock Hotel for a beach party.

With Food, Music and Beer taken care of, it was back to meeting some familiar names.


Brian McGahan with INE, whose videos are in part responsible for me qualifying to attend this party. Brian was pumped about my tramp stamp.

Amy Renee is a well known ginger CCIE with a well known sparkly bat. My kids are gingers, so we cool.

I also had the pleasure of meeting and shooting the breeze with Fish herself. I’m confident that I learned something just standing near her.

I learned that Tom Hollingsworth is also a fan of the CCIE tramp stamp, and I was glad to meet one of the minds behind Tech Field Day. I’d love to participate in a TFD or better yet Mobility Field Day, so fingers crossed!

The biggest surprise though, would come from closer to home than expected, when I had the pleasure of meeting another fellow Canuck and Wifi guru @wirelessstew!
I was blown away when Stew said that, not only did he know who I was from my (very new) online presence, but that he had hoped to meet me and find out more about me and my mobility experience. Stew would turn out to be the final, and likely most influential of the hosers group of Canadians (Stew, Steve, and myself), and honorary Canadians, Robb and Meru Mitch.

Us Canadians were a bad influence on Mitch:

But the night was still young so we decided to brave the Vegas heat and check out some more of the CLUS festivities. It was only logical that we take our Canadianized Meru Mitch to the Cisco Canada party. Beer was once againMore beer, music and food, although we never did figure this part out:

So now I have to figure out how to introduce Mitch to poutine…

TL;DR: Tuesday was the meet/make friends/network day. CLUS is an amazing opportunity to make connections and I have already benefitted from my new connections.

Also, I was glad I slept in.

Stay tuned, more shenanigans came Wednesday.

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
source

 

 

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 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.