WIFI_NC

Sleeping, Wi-Fi clients

Sleeping, WiFi clients

DTIM stands for Delivery Traffic Indication Map. This is an information element inside the beacon that tells the associated client if the AP has Multicast traffic or Unicast traffic for the client.

TIM stands for Traffic Indication Map. This is an informational element inside the beacon that tells the associated client if the AP has any unicast traffic for the client.

APs send out Beacons to advertise the networks and the capabilities of these networks. Any wireless device will read these beacons and display the SSID of each network. These beacons are sent out every 102ms or so. A Beacon has either a TIM or a DTIM information element in the beacon. When the AP has unicast packets for a station the AP will send a beacon with TIM informational element in it. The Beacon will list the AID of that client. When the client wakes up it will read these beacons and send a (Null Data Frame ???) asking for these packets. The AP will send down the packets and set more flag (see screenshot) telling the client the AP has more data. The client will request the data the AP has, and this exchange will persist as long as the AP has data.

When the AP has multicast packets for a station the AP will send a beacon with DTIM information in it and the AID of the station. When the APs tell the station, it has Multicast packets it sends those packets out ASAP even if the station is asleep. The AP will hold Unicast packets, but it will not hold multicast packets longer than the DTIM period. The AP must dump these packets as soon as the DTIM expires.

When the DTIM is set to 1 the beacons with DTIM Informational Element will be sent out every beacon. If you set the DTIM value to 2 the Multicast packets will be sent out every 2 beacons. If you rely on Multicast to deliver audio and your DTIM is set to high you will hear choppy audio during Multicast sessions.

Some device manufacturers require a higher DTIM setting so their devices can sleep more often

This begs the question “Does a Lower DTIM make the device sleep less often?”

The obvious answer is yes. Since all devices must (per the IEEE) wake up at each DTIM Beacon. The less obvious answer is it depends (“It depends” was used with permission and all applicable fees and homage were paid to Sam Clements for use of this TM saying). Most devices will sleep longer than the DTIM period. Vocera badges for instance will sleep for 500ms. This means they may miss the 1^st few (up to 4) Multicast packets. It’s tough to say how often this happens since it will be tough to tell the difference between 100ms and 500ms as the badge is waking up.

Other device manufactures are the same. Ben Miller from @sniffwifi has an excellent blog called Go to Sleep, Go to sleep, Got to sleep little iPhone.

Ben Miller’s Blog Go To Sleep, Go To Sleep, Go To Sleep Little iPhone

https://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html

Static Channel Assignment vs RRM/ARM

Every time I scan a network that uses Radio Resource Management (RRM) or Adaptive Radio Management (ARM) and I see access points on the same channels near each other I cringe. I see this even with networks that are using all 26 5GHz channels. Why does RRM/ARM repeat channels so frequently? Every time I see this and I hear people saying RRM works every time without issue or configuration I have to chuckle a bit. Well, I think you will see as far as Channel planning it does not work well.

I have always been a fan of static channel assignments and static power. I know I am a dinosaur, but this is the only way you can be assured you will not see the same channel repeated very often.

I still recommend using an 8 channel plan, especially when using voice (as I said I am a dinosaur). I believe this is not a problem since back in the day we had 2.4GHz and only had 3 non over lapping channels to work with. Now if we recommend anyone use only 8 channels some network administrators cry like little schoolgirls saying “We want to use all the channels because we want the higher data rates that 40MHz and 80MHz channels give us”.

First of all, if you are using 80MHz in an enterprise environment (on 5GHz) you should be tarred and feathered. We all know how inefficient 80MHz channels are, but some Network Admins have bought into the marketing hype that bonded channels give you higher data rates and a faster more efficient network. This argument has plenty of holes in it.

The two I like to bring up are;

1.)The majority of even data packets are small (voice, email, web browsing) and these packets never use the full bandwidth of bonded channels.

2.)Even when larger packets are sent the secondary channels remain less than fully utilized.

I was once at a site that was using Extreme Access Point running Radio Resource Management (or whatever their version is). They had only 30 Access Points and were using 26 5GHz channels so, in theory, I should have seen only 4 channels repeated once and most channels never repeated. This of course was not the case. There were multiple times when I scanned the network and saw the same channels within range of each other. I can hear the skeptics saying that only happens with brands like Extreme but if you look at the screenshots below you will see this happens with Cisco and Aruba as well.

Each AP vendor has a crazy way of coming up with a list of preferred channels and they use these channels more often than others. Cisco used to heavily use Channel 36; now they’ve seemed to fix the channel 36 issues, but they still repeat channels in an RRM configuration far more than you would if you manually planned the channels.

When we design a wireless network, we always use a static channel and static power; this works extremely well. The problem comes in when we install the system and for whatever reason we let RRM take over after the design is done. Why is this? I have never heard of a design or customer requirement that states let RRM choose the channel and power. When you are planning your design the channel plan may be chosen by the design software like Ekahau or AirMagnet but this is still far better than RRM.

There are some arguments to be made for RRM over static channels design. Two of the arguments are the DFS channel issue and the coverage issues (if an AP goes offline). The first argument is the DFS channel issue. If you assigned your channel plan statically and used DFS channels, when the AP hears a radar event by the regulation, the AP needs to stay off that channel for 30 min. If you used static channels the AP would have to stop transmitting for 30 minutes. The AP does this because it lacks a mechanism to shift from the affected channel. The second argument for RRM is the coverage issue. If an AP goes offline then RRM can manually adjust the power of existing APs to fix the coverage gaps.

There are two fixes for this. The first is to keep to the 8-channel plan and you would never use a DFS channel. The second fix would be to design your network for voice coverage (two APs at -65 or better) if one AP went offline due to a radar event then there would be another AP to make sure the coverage was still good.

There are three screen shots below two from a Cisco network and one from an Aruba Network. These screenshots show multiple examples of RRM/ARM using the same channel in close proximity of each other.

This screenshot shows 2 APs on Channel 36 , 3 APs on Channel 100 . There is separation on some of these APs but my point is that, when left to RRM, Cisco uses channels more than they should on the same floor. This screenshot was filtered to show only the APs that my device was connecting to.

.....

This screenshot is from a Cisco site running RRM. You can see multiple APs have the same channel. There are 5 APs on Channel 36 , 6 APs on Channel 44 , and 2 APs on Channel 149 . This screenshot was filtered to show only the APs that my device was connecting to.

..............

Just in case you are thinking I am just picking on Cisco here is an Aruba site that has 2 APs using channel 44 , 2 APs using Channel 149 , and 2 APs using Channel 100 . This screenshot was filtered to show only the APs my device was connecting to.

......

In conclusion static channel power is the only way you can be certain that channels will not get used over and over again. RRM and ARM have there place but nothing can implement your channel plan better than you can.

Thank you for reading this blog. Please leave comments and continue this discussion on Twitter and Slack. If you haven’t followed me on Twitter please use this link to follow me.

Multicast MAC address

Multicast MAC address

This may or may not be particularly useful, but I found it interesting, so I decided to blog about it. Hopefully, this will help someone have a better understanding of multicast and how packets flow over the network. All packets on an IP network need to have a MAC address so the network can send the frames between layer 2 devices. This makes sense, but I was a bit surprised to find out the multicast sessions have their own MAC address. How else would multicast traffic and packets get delivered? I guess I never took the time to even think about it before.

I have always thought and talked about the multicast session in the form of an IP address like 230.230.0.1 but each MC session has a MAC address associated with it. The session would need this to move the traffic on a layer 2 network.

This blog will explain how the MAC address is created; I will show you some screenshots displaying these multicast MAC addresses. This might be confusing at first but once you read it over a few times it makes perfect sense.

All Multicast MAC addresses start 01:00:52:0 (the 25^th bit in the MAC address for a Multicast session is always 0) the next 23 bits are the IP address translated to binary or Hex. The table below shows the MAC address for the multicast IP session of 230.230.0.1



			230	230	0	1
IP address in Binary form			11100110	11100110	00000000	00000001




MAC address in Binary form	00000001	00000000	01011110	01100110	00000000	00000001
MAC Address	01	00	5E	66	00	01

There is an issue when you convert multicast IP into a MAC address. When we look at this a bit deeper you will see that since the 25^th bit is always 0 this MAC address for 230.230.0.1 and 230.102.0.1 would be the same. Both MAC addresses would be 01:00:5e:66:00:01 I have never seen this cause an issue before but theoretically, it could.



			230	102	0	1
IP address in Binary form			11100110	01100110	00000000	00000001




MAC address in Binary form	00000001	00000000	01011110	01100110	00000000	00000001
MAC Address	01	00	5E	66	00	01

Packet capture of a multicast MAC address

I work for Vocera so naturally, the packets I have captured are Vocera Multicast sessions. The Vocera Multicast group MAC address is normally 230.230.xxx.xxx The first session will have 230.230.0.1 and each session will increase by one. The range we use has 230.230.0.1 – 230.230.15.254 when the server runs out of addresses it will start over. Stopping and starting the server or a fail-over will reset the address’s space as well.

Vocera MC MAC address is always 01:00:5e:66:xx:xx xx:xx matches up with the 3^rd and 4^th Octet in the IP address. As the graph above shows 230.230.0.1 MAC address is 01:00:5e:66:00:01 the last Multicast session 230.230.15.254 would be 01:00:5e:66:0f:fe

I hope you found this interesting and thought-provoking. Thank you for reading this blog. Please leave comments and continue this discussion on Twitter and Slack. If you haven’t followed me on Twitter please use this link to follow me.

DFS channels and why to avoid them (even though you say you cannot)

DFS channels and why to avoid them (even though you say you cannot)

These days most wireless guys say they cannot stick to only 8 channels. Most people agree that you should use all 26 channels (including all the DFS channels). The truth is you can use an 8-channel plan if you use 20 MHz wide channels exclusively. I know …I know every marketing person, every manager and every user just lost their collective minds. Everyone wants to use 80 and 160 MHz wide channels and most people (even Wi-Fi people) want to use 40 MHz channels everywhere. If you use wide channels then you cannot stick to an 8-channel plan. On the other hand, if you agree that using 20 MHz channels is a more efficient use of the channels and spectrum, then you can very easily get away with using only 8 channels.

There are 9 non-DFS channels but when you use channel 165 (the highest channel in UNII-3) you may run into issues since there is not enough separation between Channel 165 and UNII-4 band channels. This has been known to cause issues, especially with voice clients. I always recommend staying away from channel 165 which leaves us with an 8-channel plan (36, 40, 44, 48, 149, 153, 157, and 161).

Back in the day when we used 2.4 GHz only networks, you were limited to only 3 channels, and despite this people more clever than, I got it to work with very few issues. Yes, there was always co-channel interference, but the better engineers would work to minimize it. In 5 GHz, suddenly using 8 channels is big a hassle for most people. Have we gotten lazy, or have we bought into the lie that wider channels are better? I will save my arguments for why 40MHz channels are highly inefficient for another blog. If you do not want to wait, you can look at Devin Akin’s blog at https://divdyn.com/wi-fi-throughput/ he does an amazing job diving into this point.

DFS Channels

What is a DFS channel? These channels share the spectrum with Weather Radar and Radar systems. For the FCC and IEEE to approve the use of these channels in WIFI, a mechanism had to be in place where these channels could co-exist. A mechanism called DFS (Dynamic Frequency Selection) was created to have the WIFI devices listen for radar events and either stop using the channels or automatically move off these channels. When RRM/ARM is used, and an AP hears a radar event it must pick a new channel and inform its clients to move to this new channel. If RRM/ARM is not used, then AP after hearing a radar event must stop transmitting for 30 minutes.

Why are DFS channels so bad?

There are 16 DFS channels in the UNII-2 and UNII-2e space (52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140, and 144). These channels have two major drawbacks, especially for voice clients. These drawbacks are 1.) The length of time it takes for a client to scan DFS channels. 2.) When radar events are heard the APs and device must move off that channel. The rest of this blog I will talk about these two issues.

The first issue is how long it takes a client to scan the DFS channels. This changes a bit with different clients but since I know the Vocera devices I will use them as an example. When the Vocera badge scans non-DFS channels, it immediately sends a probe request and gets back a probe response this takes roughly 15 – 20ms per channel. The device must return to its original channel for 50ms to do any TX/RX it may need. The total time to scan each channel is 65ms. When you multiply 65ms by 8 channels you get a total scan time of 520ms. When the badge scans a DFS channel it cannot send a probe right away. It must make sure there is no radar on this channel. It does this by listening for a beacon (100 – 104ms). The device will then send a Probe Request and receive a Probe Response only after it hears a beacon. Since it has stayed off its channel so long it needs to return to its original channel for 150ms for any Tx/Rx. The round trip time for every channel is roughly 250ms. When you multiply 250ms by 16 channels you get a total scan time of 4000ms (4 seconds). Four seconds may seem like a short time but, for a voice client that has a jitter buffer of 120ms, a 4-second delay can seem like a lifetime. When the device is in the middle of a call and needs to find another AP to roam to a delay beyond 120ms will cause choppy audio. It will take even longer if you hide the SSID since the badge must take an extra step of sending a Probe Request with the wildcard in it so all APs will respond.

This improves greatly when you have 802.11k enabled. When using 802.11k after the device connects to the AP it will request a Neighbor list. This neighbor list will (normally…if everything is working right) contain a list of APs that are its closest neighbors. This will cut down the number of channels the device has to scan. If the device happens to move away from all the APs in the neighbor list it will need to do a full scan.

The second issue with DFS channels is when a DFS event occurs (or even a false positive happens) the AP must send out a channel change announcement which tells the devices that it must move. Most clients will treat this as a new roaming event without the benefit of pre-scanning the channels before the move. They will have to rescan all the channels instead of just the one where the AP is moving to. If you are a laptop surfing the internet or reading email you may never notice the delay but if you are a voice client in the middle of a call you will experience choppy audio during the forced roam.

In conclusion, stick with 20 MHz channels and use only the 8 Non-DFS channels. By doing this you will avoid all the issues that come along with the DFS channels. If your devices or applications need to move massive amounts of data, either stick a cable in it or switch over to Wi-Fi 6e and you can have all the bonded channels you want. You will not have to worry about the fact you are running highly inefficient bonded channels until you start using 320 MHz bonded channels and Wi-Fi 6e will be down to 4 channels and this will restart the discussion all over bonded channels again.

Why should you go to professional conferences?

Professional development

Conferences are a great way to get a deeper understanding of new products, ideas, theories and practices in your chosen field. Every professional organization has conferences, nurses have hundreds of organizations like AONE, AACN, and NTI. Most of these organizations use conferences to present new information. All these organizations offer training classes that give nurses CE (Continuing Education) credits for attending these lectures and presentations. The wireless world is no different. There are many wireless conferences, such as WLPC, WIFI Trek (CWNP), Cisco Live and Atmosphere (Aruba). All these conferences have presentations, Boot Camps and breakout discussions about new products, technologies, and best practices. Just as with other professional organizations, Certified Wireless Network professionals need CE credits to keep current with our certifications. These CE credits can be obtained by either going to formal classes, teaching classes or attending these conferences.

New topics

Reading about new wireless topics is something we all need to do to keep up with new technologies. Reading articles is the 1^st step, but you really need to go beyond the articles and dive deeper to fully understand these new topics. You need to talk about these technologies and bounce these ideas off your colleagues to obtain a deeper understanding. You need to understand how others have implemented these ideas. These conferences offer you a way to do this in a unique way. At these conferences, you will meet and interact with people of all levels, some who have been in the industry for many years and there are others who are just starting out but are hungry to learn. When topics are presented at these conferences people ask questions you never thought of or they ask the questions in ways that you would have never thought of. These questions lead to deeper discussions that grow into conversations over meals or even later at the bar. These conversations will lead to broader topics that will be discussed later through blogs and Twitter feeds and possibly grow into topics for next year’s conferences. These conferences allow you to add to the conversations and to interact with professionals in a way you would never have gotten by simply reading articles.

Creating professional contacts

The contacts you develop at these conferences can prove to be useful throughout the year. Whether you are attending vendor-specific shows or vendor-neutral shows you are interacting with people from every major vendor. These men and women represent sales, marketing, engineering, service and different levels of support.

These contacts can become useful during the year if you run into an issue or problem with their products. Many of the people who you meet are from backline teams of these vendors. By attending these conferences, you have access to these professional that you would never get over the phone. There is no way to quantify these leads, but they can save you weeks of going through the endless loop of grabbing logs and explaining the issues two and three times to different levels of support. These relationships that are developed at these conferences with different vendors may offer quicker solutions or they may help to push issues along in their organizations.

Team development

The information and knowledge learned at these conferences can be shared with teammates throughout the year. You don’t have to send everyone on the team to every conference but each person that attends a conference will be able to share his/her experiences and lessons learned with the whole team. Conferences also give the newer or junior members of the team something to attain. Management can create incentives for your team; if teammates achieve this level cert, then management could reward them by sending them to this or that conference.

Presenting at these conferences

Presenting at these conferences can pay dividends in two unique ways sharing your knowledge with others, getting your name out there as a thought leader in each wireless topic or technology. Sharing your knowledge with others helps those you are teaching by introducing them to a new idea, technology or procedure, but it also helps you understand the topic more deeply. No matter how prepared you are there will always be someone to ask a question that gives you and the those attending a deeper understanding.

Getting your name out there as a thought leader will help you reach more people on Twitter and Slack. This can help promote your current business, project, product or even your future employment.

Product promotion

What better way to spread your company’s story, philosophy and be seen as an industry leader than having a presence at these conferences. A major presence at these shows and conferences will help you spread this story and gain valuable feedback from industry-leading experts. Exposure at these conferences can lead to broader acceptance of your product throughout the industry. Feedback from participants could help drive improvements to your products or procedures.

Top Wireless conferences

There are quite a few Wireless Conference. Here is a list of 4 of the biggest.

Wireless LAN Professional Conference (WLPC)

Started and run by Keith Parsons of Wireless LAN Professionals http://wlanpros.com

WIFI TREK

Created and run by the CWNP group https://www.cwnp.com/

Cisco Live

https://www.ciscolive.com/

Atmosphere run by HP/Aruba https://www.arubanetworks.com/atmosphere/

Thank you for reading this blog. I hope reading this blog encouraged you to attend a conference. Feel free to share this with your boss if he is on the fence about sending you to any of these conferences. Please leave comments and continue this discussion on Twitter and Slack. If you haven’t followed me on Twitter please use this link to follow me.

Multicast on a Cisco Wireless Network

This is not meant to be a definitive guide to multicast. There are more detailed documents and white papers from Cisco and others on this subject. This is just an attempt to give a basic understanding and encourage you to learn more about this subject.

This is a two-part blog. The 1^st blog named “Settings that can improve Multicast on a Wireless Network” which discussed the settings needed to optimize a Wireless/Wired network for multicast traffic. This blog will discuss more about settings and troubleshooting on a Cisco Controller based wireless network.

I work for a wireless communications vendor that uses multicasts as an integral part of the product. I have been onsite and on conference calls with customers trying to troubleshoot multicast issues. The issue almost always turns out that multicast packets are being blocked somewhere on the network. There seems to be a lot of confusion about what happens to multicast packets and how to prevent them from being blocked on your network. This blog will try to explain the paths the multicast packets take on the wireless and wired network.

The topics I will cover in this blog are multicast packets on a controller-based network, configuring multicast on a Cisco Controller, IGMP snooping on the controller, troubleshooting multicast issues, troubleshooting using Multicast Hammer, Cisco commands and some links to blogs and articles I found helpful.

Background

The Cisco network uses IGMP (Internet Group Messaging Protocol) to manage the multicast traffic. When a multicast session is started a client or server will send an IGMP join message to a certain multicast address. Any clients that want to be part of this group will send a join message to the same multicast address. These join messages will get recorded on your local network’s router as well as the Rendezvous point (RP). If your local router sees traffic for this multicast address it will pass the traffic to your local network. If the router sees multicast for a different address it will dump these packets. When IGMP snooping is enabled on the switch, it will record which ports need multicast traffic.

Terms discussed in this blog

Multicast Group ID (MGID) is created by the controller and passed to each AP. The MGID is the ID number which maps multicast source, the multicast address and the VLAN. This helps the controller and APs to keep track of multicast groups.

Delivery Traffic Indication Map (DTIM) is an informational element in a beacon that will inform a station if there is any multicast traffic the AP has for the station.

Rendezvous Point (RP) is a router in a multicast network domain that acts as a shared multicast tree. There can be multiple RP on any given network.

Configuring Multicast on Cisco Controller

There are two modes you can use on your controller; Multicast-Unicast and Multicast-Multicast. If you use Multicast-Unicast, then the controllers will make a copy of every multicast packet and sends these packets out as unicast packets to every AP. This would work OK for a smaller network but in a larger network, this would create too much traffic. In larger networks Multicast-Multicast mode is much more efficient use of bandwidth.

When selecting the Multicast-Multicast option on the controller you will need to choose a multicast address. This address must be different on every controller on your network.

Screenshot courtesy of mrn-cciew

When an AP connects to a controller, the controller will tell the AP to join this multicast address you have chosen. All the APs will send a join message to this multicast address. When the controller receives a multicast packet it sends out one packet and all the APs who have joined the multicast group will receive this packet. Multicast can be best described as one to many, where unicast is described as one to one.

IGMP snooping on the Controller

When IGMP snooping is enabled on the controller, it creates a Multicast Group ID (MGID) table, which keeps track of the clients and what multicast groups they have joined. The controller sends this MGID table to all the APs that are connected to it. When multicast packets are sent to the APs, the APs will check the MGID table to see if they have any clients that have joined this multicast session. If they have a client, the AP will send the traffic. If the AP doesn’t have a client, the AP will discard the traffic.

If IGMP snooping isn’t enabled on your controller all APs that have the same VLAN where the multicast traffic had been requested (even by a client on another AP), will receive these multicast packets and will send them out. This means every AP will be sending out multicast packets even if they do not have a client for this traffic. IGMP snooping will limit the multicast packets that are sent by the APs.

Multicast Packets on a Controller based network

When the wireless client sends an IGMP join message to the AP, the AP sends this join message through the CAPWAP tunnel to the controller. The controller absorbs this join message and sends a new join message to the local router on the VLAN of the client using its own IP address (not the IP address of the client). The router then adds this multicast group to the interface creating a (*,G) entry.

When multicast packets are sent from the wired side of the network, the router which is acting as Rendezvous Point (RP) will send these packets to the controller. The controller receives these packets and encapsulates them in its multicast address. The controller then sends these multicast packets to all the APs on that controller. The AP strips the controller’s multicast address and sees the original multicast address. The AP checks its MGID table to see if it has a client for this multicast address. If the AP has no clients that have subscribed to the multicast, then the AP drops the packets. If the AP has clients that have subscribed to the multicast address, then the AP sets the AID of that client in the DTIM section of the beacon. The AP then sends the packets down to the client immediately after the beacon. The AP cannot hold multicast packets longer than the DTIM value, the AP sends these packets even if the client is sleeping. This is different from unicast packets where the AP will hold onto them until the client requests the packets.

When multicast packets are sent from a wireless client, the wireless client sends the packets to the AP as unicast packets to the multicast address. The AP then sends these unicast packets through the CAPWAP tunnel to the controller. The controller then makes two copies. One copy is sent out to the locally connected LAN where the router will forward these packets to the RP. The second copy the controller encapsulates in its multicast address and sends these multicast packets to all the APs on that controller. The AP strips the controller multicast address and sees the original multicast address. The AP checks its MGID table to see if it has a client for this multicast address If the AP has no clients that have subscribed to the multicast then the AP drops the packets. If the AP has clients that have subscribed to the Multicast address, then the AP sets the AID of that client in the DTIM section of the beacon. The AP then sends the packets down to the client immediately after the beacon.

Troubleshooting Multicast issues

When troubleshooting multicast issues there are many settings you should look for in the Wireless controller and on your switches and routers. These settings are discussed in greater detail in my blog “Settings that can improve Multicast on Wireless Networks” which can be found here.

Most multicast issues are caused by not having PIM set up correctly on your network. Two ways you can troubleshoot this are; 1) check all the VLANs where the multicast traffic will traverse or 2.) check to see if the join messages are being recorded on your router and switches (if you have snooping enabled).

Protocol-Independent Multicast (PIM) needs to be enabled or set on all your VLANs where multicast traffic will traverse. The VLANs you need to enable it on are the management VLAN, AP management VLAN (if different from the management VLAN), AP VLAN, the VLAN of the sending device and the VLAN of the receiving device. The management VLANs are very important since the controller sends multicast packets to the APs using either the management VLAN, AP management VLAN or the AP VLAN. These VLANs are often overlooked. Checking all the interfaces and VLANs where traffic will traverse always seems to cause Network Admin the most trouble. They usually ask me to list out all the interfaces where PIM needs to be enabled. This is difficult for them but impossible for an outsider with no direct knowledge or access to their network. We always recommend opening a case with Cisco (or your wireless vendor) to help find all the VLANs and interfaces where the multicast traffic may traverse.

If you need to verify that join messages are making it through your network, you will need to SSH to all routers and switches in the path and make sure you see the join messages from the clients. If you get to a router or switch where you no longer see join messages, you probably have found the issue.

Another common issue is multicast packets getting stuck at the core. If the multicast packets are flowing over the core, make sure the VLAN the EtherChannel/Port Channel have PIM enabled on them. I have seen issues where one EtherChannel had PIM enabled the other EtherChannel did not. This caused one multicast session to work and the next multicast session to fail.

After checking the VLANS for PIM and checking to see if the messages are traversing your network you should check other settings including DTIM, TKIP, RP, IGMP snooping, multicast buffering and roaming.

DTIM should be set to 1 especially if you are using multicast for voice. You can check this either on the GUI of the controller, in the controller config file or a wireless capture. The DTIM will be in the beacons of the wireless capture under the Traffic Indication Map. If DTIM count is set to 0 then you are seeing a DTIM beacon if the DTIM period is set to 1 then the next beacon will also be a DTIM beacon (see below).

We all know TKIP has been deprecated but you may still have it lingering on your network, if you have TKIP and AES on the same SSID this will cause issues with multicast. You can check this either on the GUI of the controller, the controller config file or you can look at the beacons in a wireless capture. The capture below shows AES in the Pairwise Cipher suite list. If TKIP was enabled, you would see it in the same section.

Multiple Rendezvous Points (RP) can cause issues with multicast if you have devices on multiple VLANs and each VLAN is directing you to different RPs. This will cause your devices on one VLAN to get the multicast traffic and the other devices on a different VLAN will never get the multicast traffic. If you have two RPs, they must communicate and update each other or better yet have one RP for the entire network.

If you are having issue with delivery of multicast packets you should verify you have IGMP snooping set on your switches. To verify if IGMP snooping is enabled on the switch run the command show ip igmp snooping

If it is not enabled on the switch you should set it globally, then you can set it per VLAN. Enabling it globally, run the command ip igmp snooping enable to enable it on a VLAN 2 you would use the command ip igmp snooping vlan 2 enable

If you have higher DTIM values (which causes the AP to hold on to multicast traffic for longer periods of time) and your network experiences a high volume of multicast traffic, you may experience issues where some multicast packets are being dropped. This may be caused by your multicast buffers being over-run. Each radio can handle 50 Multicast packets at any given time. These are shared equally across all SSIDs. You can verify the Multicast buffers by running the command show controller dot11radio0 | begin –\ In-Prog . You can enable a WLAN to use more than 50 using the command config wlan multicast buffer enable (30-60) <wlan-id> Increasing the Multicast buffer size will allow the AP to hold on to more multicast packets.

Roaming can cause issues with multicast especially if your client doesn’t send a new join message after each roam. This issue is more common with Autonomous APs or even cloud based AP. Cisco controllers will prompt the client to send a join request or they will send a new join message on behalf of the client after a roam. In Autonomous APs or even cloud based APs if a new join message is not sent and you have igmp snooping enabled on your switches the multicast packets might get delivered to the wrong AP.

Troubleshooting using Multicast Hammer

Multicast Hammer is a free tool that can help you troubleshoot multicast issues. You can download Multicast Hammer installer and setup instructions from the internet. It is a simple program to use and install that was created by Nortel (maybe the only thing left of Nortel in use these days). Multicast Hammer simulates multicast traffic on your network. It is a valuable tool that will remove questions about certain applications and show you raw multicast traffic (or lack of it) on your network. You should run MC Hammer on two machines that are on the same WLAN. Set one up as a server and one as a client. Run the test to see if data is flowing between machines. Once you see data you should move one of the machines to another network and retest. This will help you find out where multicast traffic is being blocked.

I won’t go through the install of Multicast Hammer (or as Vocera has dubbed it MC Hammer….can’t touch this!!!!) but I wanted to show you two screen shots one set up as server and one and client.

Server

The set-up is rather simple. You want to make sure you have the server radio button selected, choose your network interface, and then choose an available Multicast address (not the MC address on your controller). After you hit start on the server and client you will see data flowing. If you only see the data on the server then you know multicast traffic is being blocked somewhere on your network.

Client Side

The set-up is rather simple. You want to make sure you have the Client radio button selected, choose your network interface and then choose the same Multicast address as you chose in the server side of the application. After you hit start on the server and client you will see data flowing. If you only see the data on the server then you know multicast traffic is being blocked somewhere on your network.

Cisco Multicast Troubleshooting commands

show ip pim interface

show ip mroute

show ip igmp

Debug bcast * enable

Debug ip igmp

show ip igmp groups

On the controller verify multicast mode

show network

On the controller check L2 and L3 MGIDs

show network multicast mgid summary

show network multicast mgid detail <mgid>

Links to Multicast articles, videos and blogs

https://www.youtube.com/watch?v=Gjt2L9jAYNA From Kevin Wallace Cisco Multicast Routing for CCNA, CCNP, and CCIE candidates

https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/7-4/vocera_config_guide/vocera_config_guide/vocera_config_guide_chapter_01011.pdf Cisco guide on how to configure multicast for Vocera

https://supportforums.cisco.com/document/56511/multicast-and-wireless-lan-controller-wlc This is from Stephen Rodriquez 7 years ago but still good info in there.

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_0/troubleshooting/configuration/guide/n1000v_troubleshooting/trouble_14mcast.html

https://community.cisco.com/t5/wireless-mobility-documents/understanding-multicast-in-unified-wireless-networks/ta-p/3125021 This a power point Understanding Multicast in Unified Wireless Networks by Jeff Keown Cisco Wireless TAC

http://www.labminutes.com/wl0025_wlc_multicast_videostream_1 excellent video on setting up your controller for multicast.

https://mrncciew.com/2012/11/17/configuring-multicast-on-wlc/ everything on mrc-cciew site is awesome and I learn a ton every time I visit

Thank you for reading this blog. I hope reading this blog gives you more insight into multicast on a Cisco network. Please leave comments and continue this discussion on Twitter and Slack. If you haven’t followed me on Twitter please use this link to follow me @wifi_nc

Settings that can improve Multicast on a Wireless Network

This is a two-part blog; this blog will go over settings that will improve multicast on your network. The next blog “Multicast on a Cisco Wireless Network” will go over more troubleshooting on a Cisco Network.

I work for a wireless communications vendor that uses multicast as an integral part of the product. There are certain settings on the wireless/wired network that when implemented will improve multicast.

The issues and settings we will discuss in the blog are; enabling multicast on the router and VLANs, Which VLANs do you enable PIM on, the purpose of DTIM and Beacon settings, basic and mandatory data rates, issues using TKIP and AES on the same SSID, Issues with Rendezvous Points (RP), IGMP snooping on switches, roaming issues with multicast and lastly issues with multicast buffers.

Enabling Multicast on the Router and VLANs

To enable multicast routing on your routers and VLANs you will need two commands. The first command you need to issue on your router (or layer 3 switches) is ip multicast-routing. The second command is the pim command (Protocol Independent Multicast), which enables multicast routing on your VLANs. You can set this command as dense-mode, sparse-mode or sparse-dense-mode. Dense mode is good to use if you have a small network, but the PIM sparse-dense-mode will allow the router to use both sparse-mode and dense-mode. The differences between sparse-mode and dense-mode center around Rendezvous Points and how multicast traffic and multicast routes are updated in the network. Most networks I work with use sparse-dense-mode. The command pim sparse-dense mode needs to be issued on all the VLANs where you want multicast traffic to flow.

Which VLANs do you enable PIM on?

This is the million-dollar question that can cause a lot of confusion. The VLANs you need to enable multicast on using the pim sparse-dense mode are the management VLAN, AP management VLAN (if different from the management VLAN), AP VLAN (if different from the management VLAN) and all the VLANs of the sending and receiving devices. The management VLANs are very important since the controller sends multicast packets to the APs using either the management VLAN or the AP Management VLAN.

If the multicast packets are flowing over the core, make sure the VLAN of the EtherChannel/Port Channel have PIM enabled on them if they are different from the management VLAN. I have seen issues where one EtherChannel had PIM enabled the other EtherChannel did not. This caused one multicast session to work and the next multicast session to fail.

The purpose of DTIM and Beacon settings

If you are using multicast to deliver voice packets you must set the DTIM to 1 and the beacons to 100ms. These settings tell the AP how often to set either a Traffic Indication Map (TIM) information element or a Delivery Traffic Indication Map (DTIM) information element inside the beacon. There are no TIM or DTIM beacons per se. There are only Information Elements inside the beacon (but for ease of use I will use terms TIM beacons and DTIM beacons). The TIM beacon will tell the client if the AP has unicast packets buffered for that client. The DTIM beacons will tell the clients they have multicast packets about to be delivered (as well as unicast packets buffered). If you set the DTIM to a higher value to either 2 or 3 then the AP will only deliver the multicast packets to the clients every 200ms or 300ms. Most VOIP clients will have between a 90ms and 150ms buffer. If the client gets multicast packets every 200 or 300ms then, the user will hear choppy audio.

Some device manufacturers want you to set the DTIM to the higher value, giving the devices more time to sleep. If the devices know the DTIM will only come every 200, 300 msec or more then the client device can sleep that much longer. This saves battery life and is somewhat of a valid concern but when Voice is being delivered over multicast packets the DTIM needs to be set to 1 or the user will hear choppy audio. I said this is somewhat of a valid concern but the fact of the matter it is not mandatory that the client wakes up every DTIM. Before adjusting your DTIM check with your device manufacturer to see if the device wakes up for every DTIM, you might be presently surprised to find the devices don’t wake up every beacon. Some devices will stay asleep longer than the DTIM. You can test this by pinging the device. While the device is idle ping it. You may find the device only responds every 500msec or so (or maybe longer). You can then ping the device while on an active call and see how often it responds and then compare the two values.

Basic and Mandatory Data rates

Cisco recommends using 2 basic data rates 12Mbps and 24Mbps. When you have two basic data rates set, management traffic will go out at the lower data rate, but Cisco will send multicast traffic at the higher data rate. This can cause issues for clients that have rate shifted down to 12Mps or lower. If the AP is sending multicast traffic out at 24 Mbps and the client is only able to receive at 12 Mbps your client may miss multicast packets. This will be very difficult to troubleshoot since some devices will get the multicast packets and others will not receive them. Trying to replicate the issue would prove difficult. I would always recommend setting only one Basic Data rate to help offset this issue.

Issues with using TKIP and AES on the same SSID

I have seen issues with multicast where TKIP and AES are enabled on the same SSID. When you have both enabled on the same SSID the AP must send multicast packets out using TKIP. If your clients are using AES they will have issues decrypting the multicast packets. Hopefully, everyone is using AES instead of TKIP (especially since TKIP has been deprecated) but if you need TKIP then it is better to have only one encryption per SSID. Of course, I strongly recommend only using AES.

Issues with Rendezvous point (RP)

There are two ways you can use Rendezvous points. You can assign a router as a Rendezvous point or you can let the network assign one for you. You can program multiple RPs on your network, but this may cause issues. When a client sends a join message routers in the path will create a (*,G) entry on the interface so the router knows what interface has clients that have subscribed to this multicast address. These join messages will eventually make it to the RP. When the RP gets this join message, it will build a path back to each client/network segment.

If you have multiple RPs you may find an issue where one client may get the multicast traffic and one client will not. This happens if two devices are on different VLANs and each device sends the join message to a different RP. In this case, one device or network segment will get the multicast traffic and one will not. Having multiple RPs might be by design but if you have multiple RPs you should ensure that the RPs share information of all related VLANs.

IGMP snooping on switches

When IGMP snooping is enabled on a switch, the switch can send the multicast packets out the right interfaces. When a switch sees a normal packet, it will look up the MAC address in its CAM table, if the switch has the MAC address of the client it can forward these packets the right interface. If the MAC address is not in the CAM table, it will flood the packet out all interfaces. The same is true of the multicast packets if the switch has IGMP snooping enabled. The switch will keep track of all the join messages sent by clients/APs. The switch then records what interfaces need the multicast packets. When a multicast packet is sent to the switch it looks in its table and sends the traffic only to those interfaces that need the packets. This cuts down on multicast packets flooding the network. If the switch does not have information on a multicast address, then the switch will send the packets out on all ports.

Roaming issues with Multicast

When the clients roam from AP to AP the controller will request the device to send a new join message, so the controller, AP, router, and the network knows the client has moved APs. If your clients fail to send a new join message, the controller will not update its MGID table and the new AP that your client is connected to may drop multicast traffic because the AP will not know there are any clients who have subscribed to these multicast groups.

This can be a real issue in an Autonomous network or even cloud based where the client doesn’t send a join message on a roam and there is no controller to request a new join message. If your client doesn’t send a new join message you will lose Multicast session as you roam. The fix this I would contact the device manufacture to see if there is a firmware update that will fix this issue.

Issues with Multicast Buffer

The multicast buffer is shared across all BSSIDs on the AP. If there are a high number of SSIDs on your network, you may experience issues where the buffers fill up and the AP starts dumping multicasts packets. This may cause choppy audio on your multicast sessions. If your SSIDs have a higher DTIM value, the APs/Controllers will need to store packets for a longer period. When you are experiencing issues with multicast traffic you may need to increase your multicast buffer size and then limit which WLANs can use this buffer. Multicast traffic is often crucial to voice clients and other clients/WLANs may never use multicast packets. If you limit which WLANs can use the multicast buffer there will be available space for applications that have a critical need for multicast.

It is important to note that the AP can only buffer multicast packets for the length of the DTIM value. When this value has expired the AP will inform the clients and immediately send the multicast packets whether the client is listening or not. This, of course, is different from the way unicast frames are delivered. If the AP has unicast frames for the client, the AP will set the clients AID in the Partial Virtual Bitmap. The AP will buffer these frames until the client wakes up and requests these frames.

Links to Multicast articles, videos, and blogs

https://www.youtube.com/watch?v=Gjt2L9jAYNA From Kevin Wallace Cisco Multicast Routing for CCNA, CCNP, and CCIE candidates

https://supportforums.cisco.com/document/56511/multicast-and-wireless-lan-controller-wlc This is from Stephen Rodriquez 7 years ago but still good info in there.

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_0/troubleshooting/configuration/guide/n1000v_troubleshooting/trouble_14mcast.html

http://www.labminutes.com/wl0025_wlc_multicast_videostream_1 excellent video on setting up your controller for multicast.

Thank you for reading this blog. I hope reading this blog gives you more insight into multicast and the settings needed on your network. Please leave comments and continue this discussion on Twitter and Slack. If you haven’t followed me on Twitter I am at @wifi_nc. Stay tuned for my next blog in this series called “Multicast on a Cisco Wireless Network”. That blog will go into more details and troubleshooting multicast on Cisco Networks.

CAC (Call Admission Control)

Is CAC fair to your clients that don’t support it?

I support a voice product that does not support CAC. Is it right for me to ask the Wireless Network Administrator to disable it because my device doesn’t support it? Is CAC fair? Why does it supersede WMM? I will attempt to answer some of these questions in this blog.

Cisco uses CAC (Call Admission Control) that enables access points to maintain controlled quality of service (QoS). CAC is also tasked with the ability to ensure there is a limited number of voice clients per AP.

How does CAC maintain control of QoS?

The AP will send a beacon frame out on each SSID, usually every 100ms or so. In these beacon frames, the AP will tell what features it will support for that particular SSID. Inside the beacon frames under the Vendor Tag: Microsoft: WMM parameters the AP tells the clients which WMM Access Category that CAC has been enabled on (see example 1 below). When a device associates to the AP (and the device doesn’t support CAC) the device will choose the highest level of WMM that doesn’t have CAC enabled on (see example 2 below). If CAC is enabled on AC_Voice, but not on AC_Video, AC_Best Effort or AC_Background then the client will choose AC_Video even if the client is expecting to use Voice grade WMM or even when the SSID and VLAN are set up to use Platinum QoS.

Why is this an issue?

WIFI is a contention-based shared media. The AP and clients need to know that no one else will be transmitting at the same time they are. If another device does transmit at the same time it will cause collisions and the packets will have to be resent. In order to avoid collisions, the clients and APs uses Physical Carrier Sense and Virtual Carrier Sense. A device or AP will use both Physical and Virtual Carrier Sense while trying to access the wireless medium.

Physical Carrier sense happens when the station listens to the wireless medium to see if there is RF energy on the medium. If there is, the device will then know that the medium is being used. This is called Clear Channel Assessment (CCA). Virtual Carrier sense is where the station reads the Duration/ID field and sets its own NAV (Network Allocation Vector) timer. While the NAV is still active the station will not transmit. When the NAV timer goes to 0 the station waits DIFS (Disturbed Coordination Function Interframe space), which is set per PHY that you are using. When the DIFS expires the station will choose a random number from the Contention Window (CW) range and multiply it by the slot time of the PHY you are using. After all the timers have ended the device will do another CCA and then transmit.

The Access Category gives the client a range called the Contention Window (CW). This range is called the CWmin and CWmax values (see chart below). The device will choose a random number in the CW range and will multiply this with a set number based on the PHY. The client will wait this random amount of time and then will do another Clear Channel Assessment (CCA) to make sure no one else is transmitting at that time. Each client will choose a different value in the Min/Max times. This gives the AC categories with the lower CW values a better chance to transmit, but it is only a probabilistic chance. The lower Categories will get a chance to transmit. When the lower priority clients hear a transmission in the middle of a count/hold sequence they will pause the count/hold, look into the Duration/ID field and sets its NAV timer. When the NAV timer expires and the air is clear the client will resume the hold sequence from where it left off. So eventually it will transmit even while the higher category might be counting down.

The CW values per AC Categories are below.

Category CWmin CWmax

AC_Voice 3 7

AC_Video 7 15

AC_Background 15 1023

AC_Best Effort 15 1023

When a client is sending voice packets the client expects to send these packets using the Platinum level of QoS to avoid latency or jitter. If the client does not support CAC and it has to choose the next WMM parameter that doesn’t have CAC support (in this case it was Video) the client will possibly get a much higher CWmin and CWmax time then it should. If the controller set up CAC on Video then the client would choose Background. This would give the client an even worse CWmin and CWmax range to work with. This not only affects upstream, but the packets are labeled as video which would further delay the packets through the wired network.

On the return traffic, the network may further strip the QoS level down to Best Effort. In a busy network, this can be problematic for voice clients.

Given all of this, is it right for me to ask the wireless guy at the hospital to change the CAC settings because my device does not support CAC? Or should I push back on my own engineering team to fix our client to support CAC? Or should I do both? I can see the wireless guys ponder this as I ask them to remove CAC. Most people in the wireless field are very accommodating especially when you show them the results. Our device is not seen as just another device needing access. This device is usually pushed by C Suite and the nurses on the floor. Wireless guys realize that our product if given the best environment to work in, will help caregivers communicate more effectively and will ultimately help patients. So, if you see me coming, be forewarned I don’t like CAC, DTIMs set to 2 or higher, FRA or RRM (with no limits set). I might ask for things others don’t, but when I do I will back it up with facts and will always be appreciative of your willingness to work with us.

Example 1 Beacon showing Voice is using ACM (CAC)

Example 2: Data packets showing Client chose QoS of Video

Example 3: Screenshot from the Wireless Controller Config showing the WLAN has the QoS set to Platinum

(Cisco Controller) >show wlan x

WLAN Identifier……………………………. x

Profile Name………………………………. xxxxxxxxx

Network Name (SSID)………………………… xxxxxxxx

Status……………………………………. Disabled

MAC Filtering……………………………… Disabled

Broadcast SSID…………………………….. Disabled

AAA Policy Override………………………… Enabled

************************Data Removed*********************

Quality of Service…………………………. Platinum

Example 4: Screenshot from the Wireless Controller showing CAC and ACM set on the Voice AC

Call Admission Control (CAC) configuration

Voice AC:

Voice AC – Admission control (ACM)………… Enabled

Voice Stream-Size……………………….. 84000

Voice Max-Streams……………………….. 2

Voice max RF bandwidth…………………… 75

Voice reserved roaming bandwidth………….. 6

Voice CAC Method ……………………….. Load-Based

Voice tspec inactivity timeout……………. Disabled

CAC SIP-Voice configuration

SIP based CAC ………………………….. Disabled

SIP Codec Type …………………………. CODEC_TYPE_G711

SIP call bandwidth ……………………… 64

SIP call bandwith sample-size ……………. 20

Video AC:

Video AC – Admission control (ACM)………… Disabled

Video max RF bandwidth…………………… Infinite

Video reserved roaming bandwidth………….. 0

Video load-based CAC mode………………… Disabled

Video CAC Method ……………………….. Static

CAC SIP-Video Configuration

SIP based CAC ………………………….. Disabled

Best-effort AC – Admission control (ACM)…… Disabled

Background AC – Admission control (ACM)……. Disabled

Maximum Number of Clients per AP Radio……….. 200

Cisco’s Flexible Radio Assignment (FRA)

I have heard about Cisco FRA for a while but I am only starting to see this out in the field. This technology offers great advancements over statically assigned Radios.

There are two modes of operation in FRA Macro/Macro cell and Macro/Micro cell. I will only be discussing the Macro/Micro mode in this blog. The Macro/Micro cell will have a large cell and a smaller cell inside which will increase capacity on your 5 GHz network.

The theory behind FRA is if you design a network for 5 GHz then you will more than likely have too much 2.4 GHz coverage. This is why FRA is only run against the 2.4 GHz radios.

There are only two AP models that work with FRA. They are the 2800/3800. When the AP creates a Micro cell, the power will always be set to the minimum power of the AP. In the case of the 3802, this would be 2 dBm.

How it Works

FRA uses the Neighbor Discovery Protocol (NDP) from RRM to figure out if there is too much coverage on the 2.4 GHz band. The output of this calculation is called Coverage Overlap Factor (COF). You can set the threshold for the COF at Low 100%, Medium 95% and High 90%. When FRA sees too much coverage based on these thresholds values, it will mark the radio as redundant. Once it is marked redundant it can be assigned another role. There are three states (roles) these radios can be in 2.4GHz/5GHz/Monitor Mode. Depending on the COF the controller will either leave it at 2.4GHz, change it to 5 GHz or put it in Monitor Mode. When the controller puts an AP in Monitor mode the only way to fix this is to reset the AP.

Probe Suppression

The AP can suppress Probe responses from one of the radios. When the APs receives Probe requests on both the Macro and Micro cells within a short period of time from a client who is not associated, the AP can suppress the Probe Responses on the radio which it doesn’t want the device to join. When a client is associated to either radio on the AP, the AP will suppress the Probe Response from the other radio. This should help prevent the client from roaming between radios. The Probe Suppression option is disabled by default on the controller.

FRA will monitor the cells and keep devices that are similar on the same radio. This will help improve throughput. FRA will use 802.11v, 802.k and Probe Suppression to keep the same type of clients on the same radio.

Pros and Cons of FRA

Pro

- - FRA will give you more capacity in the 5 GHz band.
  - FRA eliminates of fixes the balance between 5 GHz and 2.4 GHz radios on your wireless network.
  - The controller will limit how many devices can be on the Micro cell.

Con

If your device authenticates to the Micro Cell and moves away from the Micro cell area. This could force it to roam to the Macro cell, which would increase roaming. These additional roaming events force the device to stay awake more which will affect battery life. Cisco has safeguards against this but just like RRM, it doesn’t always work.
If you have 2.4 GHz clients your network, the coverage area after FRA runs could change dramatically. Depending on how often you have FRA run, this can lead to a less stable network. I know Devin Akin (@DevinAkin) would say that 2.4 GHz is dead and probably should be at this point especially for voice clients, but I just did a job last week where they insisted using 2.4 GHz for voice.

My Road to CWNE and study habits

There are two reasons I started this blog. The first being to help pass on the knowledge I have learned and the second is to help ensure I know what I am reading. We all learn by asking questions and by other people asking the questions we are afraid to ask. So please comment on my blog, other’s blogs, and Twitter. The Wireless World needs you. It is like a good friend of mine always says “no one is born knowing”.

I am not the best student. I can be lazy and it can take reading things multiple times before I understand the material.

Typically the best course of studying for me is reading, listening, applying and then explaining it to someone else. In the past, I have skipped the listening portion, but hearing always helps. Hearing it really helps cement what I have read. I do enjoy the hands-on portion of my training…knowledge seems to go through my fingers directly to my brain. Explaining the material I have studied is where I take it from theory to actual useful knowledge, which is the reason I started this blog.

Formal classes

IT classes can be worth taking but they can be hit or miss depending on the instructor. I took MCSE classes at a training center in Cary, NC back in 1998. The first few classes were good because the trainers knew the topics. The more advanced classes were taught by the same trainers but they clearly didn’t know the material as well. One of the instructors made it clear to me that I would have to study a lot more before taking the test. This is true with most Certs and classes but it makes the classroom type class a bit of a waste (unless you have a stellar instructor). These days I try to study the book myself as a first step and see how far that takes me.

In my time at Hill-Rom, I ran a few training courses. My training philosophy was always to teach to the top level of the class. This seems different to most corporate trainers who want to teach to the middle or lower level of the class. Personally, if I am paying for a course (even if work pays for the course) I want to be challenged. I want the course to stretch my knowledge. I also want there to be plenty of handouts and documentation so I can go over it afterward to reinforce what I have learned.

In 2008 I took an Aigmagnet course through CWNP in Atlanta. Rick Murphy (@rickMurphyWiTS) taught this course. It was the best IT course I have ever taken. He was incredibly knowledgeable and he knew how to reach all of us. He stretched my understanding and gave lots of handouts. The other day I went through those materials, I am still learning from them (funny enough the coursework was written by Keith Parsons). I would like to take more Wireless classes especially taught by Keith Parsons, Devin Akin, Blake Krone and Lee Badman. In July 2017 Devin Akin taught a CWNA course for Vocera that I was scheduled to attend but, when I passed my CWNA in April 2017 I decided to give up my spot up for a colleague. I heard the class was amazing and I look forward to one day attending a Devin Akin class.

Rules for Studying

Remove distractions

Have a daily goal, a weekly goal, and a monthly goal.

Use multiple sources

Make sure you are prepared to go into the tests

Build a home lab

Remove distractions

So how does this lazy student who really needs the reading, learning and then doing model start self-studying for my CWNA, CWAP, CWSP and the CWDP? And what kind of advice can I offer to those who are reading this blog? The first step is to remove distractions from your life. I am not talking about your wife, kids and family they are your life and you need them more than anything else in this world. My distraction was the TV. Yours might be watching sports, golfing or going out to the bars. This revelation came to me during Lent 2017 when I gave up TV. I have done this in previous Lents but when Easter rolled around I went right back to the boob tube. This time I realized how much time I wasted and how much studying I can do with the TV off. I have wasted too much time watching useless TV, so now, for the most part, the TV in my hotel room never goes on. When I am at home I will watch some TV with my wife and kids but I am really trying to avoid the TV as much as possible.

Have a daily goal, a weekly goal, and a monthly goal.

I am by nature, not a planner. Benjamin Franklin’s famous quote “If you fail to plan you are planning to fail”, never meant much to me, but as I have planned and mapped out my studying I can see his wisdom. I plan on reading 25 pages a day. This allows me to finish most tech books in 30 days or so. This might be a low number to some of you but I use it as a guideline. Some days I get so busy with work or home life that I realize I missed a day or two. Other days I get so stuck into what I am studying that I read 50 -75 pages a night. The chapters that totally elude my comprehension I go back, reread and take detailed notes. I spend the next month researching the topics online and reading over my notes. When I feel I am ready I will take two weeks and do the practice exams. After the exam, I start the process all over again.

Use multiple sources

When studying for the CWNP exams I always use the book they recommend. Sometimes this is the SYBEX books, sometimes it’s the CWNP books. I have found the SYBEX books have more details and seem to be laid out a bit better but this is a matter of opinion. I always use the CWNP practice tests which are very valuable for honing my knowledge. I will use online articles and blogs of my favorite wireless guys. Websites I am always on are CWNP.com, http://www.cleartosend.net, gcatewifi.wordpress.com, Keith Parson’s wlanpros.com, Lee Badman’s wirednot.wordpress.com. Andrew Von Nagy’s http://www.revolutionwifi.net and my good friend and colleague from across the pond Andrew McHale’s mac-wifi.com. There are a ton of Wireless Blogs out there and most of them have blogrolls that list other WIFI bloggers. Connecting to the Wireless community on Twitter and Slack Channel has increased my knowledge as well. I find Twitter and Slack are the best places to follow all of your favorite WIFI guys and girls.

Make sure you are prepared going into the tests

This goes without saying but sometimes life gets in the way. I was ready to take my CWAP exam in late June but never got around to scheduling it. In July I had a 10 day job I was doing in NYC and after that I knew life was going to get busier, I scheduled my exam while in NYC. I was prepared for weeks beforehand, but that week I had not done much studying. I felt so unprepared going in. I assumed I would fail it. As it turns out my, Prep was still valid and I passed with over 80% (which was my lowest score of all the tests). Bottom line, make sure you are prepared going in to the exam. Life is a lot less stressful when you know the material.

Build a home lab

You can read until you are blue in the face, but you really need to get hands-on experience. The best way to do this is with a home lab. When you study and have access to your own lab, it will reinforce everything you have read in the book. There is no replacement for experience and although the lab is not the real world it will teach you the tools you need to use out in the real world. Even if you have equipment at work, or even if you are lucky enough to take a lot of classes, nothing can help you learn like a home lab.

I started building mine a few years ago (before I got back into Wireless). My equipment is made up of a variety of Cisco routers, switches, a CUCM server and a few IP phones. I added an HP DL380 G7 which I use as my ESXi server. Recently I have added a vWLC and a few 1140 APs which has expanded my Voice lab into a growing wireless lab.

Don’t let the fear of high prices stop you. You can start fairly cheaply and keep adding to it each quarter. I would strongly recommend viewing Tom Carpenters CWNP video on starting your lab. It is a great video on what equipment you need and where to get that equipment. In a future blog, I will write more about my lab and what equipment you should definitely have in yours.

What Certs do I have now and what Certs do I plan on attaining?

As of this writing, I have my CWNA, CWAP, CWSP and I just passed my CWDP. I am hoping to take the Ekahau (ECSE) course sometime soon but 2018 will be all about Cisco. I am planning on taking my CCNA, CCNA Wireless and then CCNP wireless. I hope to have these by the end of the year. Years ago, I had my CCNA but unfortunately, I let it lapse. It has been hanging over my head for years and I look forward to getting that one knocked off.

Now with all the CWNP tests done, I have to focus some time on the CWNE application. I am not a big writer so getting all of the details of the application will be a challenge, but one I am looking forward to working on.

Please check back on this blog to see what happens and you can always follow me on Twitter @WIFI_NC