Month: August 2018

Long Live the Controller!

Lately, it appears that every time I turn around, I read somewhere where everything, and I mean EVERYTHING is moving to the cloud.  Maybe I am an “old geezer” in this respect, but I believe that not everything belongs in “The Cloud.”

In this particular post I want to focus on the heart of WLAN infrastructure, the venerable WLC.  Now granted, there are situations and the always present “It Depends” that can call for a controller in the cloud, or offsite controller, or controller-less, or mesh, or whatever the vendor is calling it this week, but sometimes, in some situations, having a physical, on-site good old fashioned controller just can’t be beat.

In my current employment, I work at a facility that covers 53 square miles.  Granted, not all of that space if covered in buildings and facilities that have Wi-Fi, or network connectivity (although we have received that request more than once) but we do have facilities that are pretty well spread out.  While I don’t want to spell out all the details, we also have a massive fiber infrastructure that allows us to do some pretty cool things all in house, and we don’t rely on leased lines, or ISP’s, for anything other than our internet connectivity.

Hopefully, at this point, you get the idea of where I am coming from when I say that in an environment like mine, having a centralized, on-premises, good old fashioned chunk of metal and electronics programmed to be a Wireless LAN Controller is a great thing!

Look, I get it.  Not every customer is going to be.  Not every customer can provide their own dedicated fiber between buildings miles apart to get sub-millisecond latency between hardware, but I can.  Not every customer benefits from centralized forwarding, and that’s fine.  I’m not saying that all of the other solutions are not warranted, and don’t have their advantages; they really do.  I can think of a myriad of customers and/or situations where either fully cloud based or a hybrid solution is definitely the way to go.  Companies that have a large central office with branch offices spread across the country immediately springs to mind of a situation where either a full cloud based or hybrid solution would be, and should be, the solution of choice.

Everybody can agree that when it comes to RF coverage, AP placement and AP count, that it all depends on the requirements of the space.  The same thing applies to selecting how the WLAN will be managed and controlled and which type of solution is eventually installed.  Requirements should be the first decision, then cost.  Whether or not your chosen vendor has just rolled out a new shiny cloud based solution should NEVER factor into that decision making process.  I get that sometimes cost will over-ride everything, I’ve been on that side of the fence before, but please don’t immediately jump there, give hardware a chance!

Let me give you some examples in my argument for centralized forwarding to an on-site controller.  Sorry, I can’t bring myself to call in “on prem” or “on premises” or whatever marketing calls it this year.

  1. Configuration of my access layer switch ports has been standardized to a single configuration.  Since I only need an access port with a single VLAN, the wired network team now knows how to configure a switch port where an AP is being installed without the wireless “team” getting involved.  You would be surprised how confusing WLAN technology can be to wired guys who have never dealt with it in the past.  If I need to do a flex connect type scenario, it’s rare enough that I don’t mind dealing with it personally.
  2. VLAN segmentation is much, MUCH easier.  I currently have 28 active VLAN’s off of my WLC’s, and only having to deal with them on a couple of switches relieves a lot of stress, questions and mis-configurations from the wired team.
  3. Security is easier to implement.  I run a Cisco WLAN, so there is an encapsulated (not encrypted) CAPWAP tunnel between the AP and the WLC.  In my environment we added an additional routing “feature” around the CAPWAP to keep it locked down.  That was a one-time configuration challenge that we haven’t had to go back and touch, no matter how many VLAN’s I have added to the WLC.
  4. Using the CAPWAP functionality allows me to “get around” network segmentation on the logical network.  In certain circumstances, it can be very advantageous to have 2 devices 10 miles apart but on the same subnet since they both terminate at the same location.  Yes, concentrators can be used to achieve the same thing but if I have to add hardware onsite, why add just that?  A concentrator will add complexity and another point of failure to deal with, so now I need to add in redundancy.
  5. I have full control over when and how my upgrades are done.  Yes, in theory this shouldn’t be an argument since it is your cloud instance, but how many times have you had a service in the cloud have an update or reboot done simply by accident?  As the engineer/architect on record, I am always the first one blamed.  This leads to the next point.
  6. Troubleshooting during outages is frustrating.  Even when things are in the cloud we are blamed for outages, and in our group alone we have spent countless hours trying to show that issues with reaching an offsite service is an ISP problem, not ours or the cloud data center’s fault.  What ends up happening is we point the finger at the cloud provider, the cloud provider points the finger at us.  Eventually we point a finger at an ISP.  Ever try to get two different ISP’s working together to solve a problem?  It’s bad enough when you are paying them for service and you need them to work for you, let alone work with a different ISP to figure out routing problems between themselves.  It’s a nightmare, and as the customers technical people we are always left holding the bag.

I could go on, but I think you get the point.  Keep in mind, I am not here to say that cloud based controller solutions are the devil or should go away.  On the contrary, I think in the correct situation, cloud based is 100% the way to go, and all vendors should be able to support that model.  I am just here to argue that in that same vein of thought, in the correct situation, physical, on-site, metal chassis based controllers are still very pertinent and needs to be considered as a viable, if not the correct, solution for some solutions. And just like with cloud based controllers, all vendors should be able to support that model.  If not, in my mind, they will always be a second tier vendor since they can’t support ALL possible solutions needed for any given customer.

As Lee Badman reminded us in the #WIFIQ for 8/21/18, try and take emotions out of the discussion.  Emotion should never be part of the conversation when designing the correct WLAN solution for any customer.  Define the requirements and design the solution based on those requirements.  The solution will change based on other factors but to say that I won’t recommend a physical controller no matter what just isn’t fair, and isn’t in keeping with the spirit of designing the best Wi-Fi for any given scenario.

Let me know your thoughts on the subject, sometimes 288 characters just isn’t enough to make your argument.

P.S. – I also don’t think 2.4 GHz is dead and will argue that one until the end of time!  Maybe I am the old geezer who won’t change!

 

Advertisements

Setting Up Cisco wIDS/wIPS, Part 3

In Part 1 of my Cisco wIDS/wIPS adventure, found here, I covered trying to scale and scope what it is you need before trying to purchase a Cisco wIDS/wIPS.  If you haven’t read that one, you should go do that now and then move on to Part 2, the link is at the end of Part 1.

In Part 2, I covered how the information flows within the Holy Trinity and lessons learned that I think better explain what’s going on so when you tackle this mess you don’t waste as much time as me.  Assuming you got to Part 3 by reading Part 1 and skipping Part 2 somehow, it’s located here and I suggest you give that a glance before continuing.

OK – on to Part 3!  By this point you should have a WLAN that is up and running and passing traffic (admit it, videos of cats and people doing dumb stuff is much more fun than this so I hope got that working already) as well as a somewhat functioning Cisco Prime Infrastructure (here on out referred to as CPI, or “Sub-Prime” by a certain individual that will remain anonymous) and now a nice shiny new MSE with some expensive licenses and and not much else going on.  Feeling a little angry and cheated?  Good, that’s how I felt as well.  Now that your MSE is up and running, go ahead and forget about it for a while, it’s job is done.

We now get to work on CPI and the myriad of things it does.  I’m going to dangle the carrot here a second and show you what you are hoping happens if all goes well.  On CPI navigate to the menu and go to “Dashboard –> Wireless –> Security.”  What you want to see is something that looks like this:dashboard

Now, what shows up on your page will either be nothing (because you haven’t finished configuring it) or hopefully something similar  to the image on the right, because you haven’t tuned your system to match what I did.  Different environments should have different alert profiles.  Ideally, what you will see here is a whole host of alerts that then allow you to fine tune the alerts down based on the fine security policy that you created in Part 1.  If not, I will get to that in a minute.  If you don’t see any alerts, let’s get to work on CPI to get you something pretty to show management, and more importantly the project manager so they will leave you alone!

Navigate to the menu on CPI and go to “Services –> Mobility Services –> Mobility Services Engines.”  On this screen you should see your new shiny MSE listed with a name, device type, IP address, version, reachability and then the services running on it.  If no servers are listed, look in the upper right corner and using the drop down select “Add Mobility Services Engine” and select go.  After walking through the steps, and assuming you wrote down the information from the installation correctly, it should add the MSE to this page and give you a reachability status of “Reachable.”  If it’s not reachable check your firewall configurations (remember from Part 2?) or MSE configuration.  Remember, these 2 servers were designed to talk to each other and want to communicate so it’s not like you are linking an Apple product to your Windows laptop.  Also, from this screen, you can click on the device name (highlighted with blue letters) and it will take you to the MSE GUI log-in screen.  This helps when others want to access the MSE GUI later.  Don’t ask me why, my boss is nosy and yours might be as well.

Next step is to synchronize the MSE with the WLC’s.  Not sure why you do it from CPI, but it’s where you do it.  In Part 2 I showed you what it looks like when the synchronization is working, this is how you do it as well as what to do when it doesn’t work.  Top tip, it won’t show as working the first time so don’t panic.

On CPI navigate to “Services –> Mobility Services –> Synchronize Services.”  The first page that will appear will be the maps and buildings that you may or may not have built in CPI.  These are used for your other MSE (or CMX) and aren’t applicable here.  Don’t panic just look in the grey box on the left hand side and pick the second entry down, “Controllers.”  This will pull up a list of all network devices that CPI has identified on your wired network that report themselves as controllers.  I personally have some WLC’s that I think of as controllers(3504, 8510) and then some 3850 and 4507 catalyst switches listed as well.  If you have some weird issues with your WLAN infrastructure, looking here might give you some places to start figuring out why you have a Catalyst 3850 that still thinks it’s a WLC.  Luckily I have a couple of wired networking guys that help me with this, you might not be as lucky.

Anyways, select the controller(s) that you want to actually use by checking the box on the left side of it’s name and at the bottom of the list, select “Change MSE Assignment.”  This process might need to be repeated in the future and is handy when troubleshooting so it’s a good page to remember how to get to.  Once you select that button it will give you a list of functioning MSE’s and the service you want to assign.  Find your new shiny wIPS MSE in the name list and check the box to the right of it under “wIPS” and then select “Synchronize.”  It will take you back to the list of controllers and on the right hand side will show you the service, which MSE that service is running on and if it is synchronized.  In my experience, it won’t show you a good status at this point.  My suggestion is to go to lunch at this point, let it sit and come back in a little bit to check things.  It’s painful, but eating a good lunch is much better than banging your head on a table.

After lunch come back to the screen from before, refresh it and see if the status has changed.  If it’s working, great!  If not, select the blue entry next to the WLC and MSE that isn’t working named “NMSP Status.”  This is the only way I know to get to this screen, and it’s probably the best and most helpful place to look at your new MSE.  There is even a place to troubleshoot why the MSE and WLC aren’t synced.  For that look at the NMSP Status in the summary and click on the status (it looks like a doctors stethoscope.)

Keep in mind, this is what tells the WLC where to send the wIPS NMSP traffic in the first place, so it’s a critical step.  No data in, no data out.  In this scenario; no NMSP in, no SNMP traps out.  I will also point out that it might take a couple of attempts to get the sync to work.  Go back and select your WLC’s and change the MSE assignment to nothing (un-select the boxes) and sync again.  Go back and try synchronizing them again.  Another tip, NTP can be an issue here so verify you have a good time source.  In my experience, everything can be correct and it will take a couple of attempts to get them to talk.  Keep with it, it will happen.  After it’s synced up, move onto the profiles

PROFILES

This is a big enough step I wanted to highlight it as it’s own section.  It’s where you make alerts show up, and maybe don’t show up.  It takes some time, focus, and a good written policy before beginning.  It’s also going to take longer than you think, so be prepared.  While the steps are pretty straight forward, it’s just a bear to do.

On CPI, navigate to “Services –> Mobility Services –> wIPS profiles.”  You can use the default profile to play around with, but my suggestion is to build a profile based on the deployment, how many locations and WLC’s it will be deployed to.  It’s OK, you can base the new profile on a couple of different pre-built profiles, the default being one of them.  Using the drop down on the right hand side select “Add Profile” and select go.  Name your profile and select a profile to copy from.  If your type of environment is listed, or is close to one that is listed, I suggest choosing that here; it could save you a lot of time in the following steps.  Select “Save and Edit” and it gets you going.

On this next step it’s best to understand what this really is.  I went through it a couple of times before I read the note in the guide that says this really only applies to an overlay system.  If you selected an integrated system way back when, this section really doesn’t apply so you can skip it.  The AP’s reporting the wIPS stuff already know about what SSID’s them and their neighbors have so you don’t need to define it here.  This really only comes into play if you are managing an overlay system or multiple systems.  If you are doing a true overlay, take the time to read the manual on this step and build in the SSID’s you are really concerned about.  If this is for an integrated system, simply ignore everything and click next.

Now for the fun, and time consuming part.  You are looking at a 2 “window” screen at this point.  The window on the left is all of the available alerts (roughly 260) and the window on the right will change based on which alert is selected.  The box next to the alert name indicates if that particular alert/alarm is included in the profile.  This is the step that tells the MSE what to care about and what should trigger an SNMP Trap to be sent to the trap receiver(s).  My only suggestion is bring a snack and a drink and expect to spend some time here.  Click on each alert name and read the corresponding window on the right.  The upper section will allow you to adjust certain parameters of the alert while the bottom section will explain the alert.  It’s fun to read through all of that only to get to a statement that says something like “Cisco WLAN knows about this and can deal with it so this alert isn’t needed.”  Make sure those alerts are un-selected on the left hand side and move to the next one.

Going to the way back machine, remember when I stated that having a written policy is crucial before doing this?  If you don’t have a written policy before this step, you will fully understand what I meant.  While technically some alerts make sense (like a dictionary attack,) most fall into the category of technically it doesn’t matter one way or the other, but what do others expect to see out of this system.  Not having a policy makes selecting alerts difficult, if not impossible.  Don’t worry, it’s been my experience that you will visit this list many times before everyone is happy and then sporadically in the future as alerts are found to be false positives or new alerts emerge.  Either way, expect to spend some time here and be patient, it’s at the heart of the system.

Once at the bottom of the list, click the “Save” button at the top.  It’s a no brainer, but it has bitten me in the past.  Click save before hitting next, don’t count on or expect the system to prompt you, though it might.  After clicking “Next” we are almost home!  Select the WLC’s that you want your new policy to apply to by checking the box  to the left of the WLC name you want included in this and then hit “Apply” at the bottom of that window.  You’ll see an alert/warning that’s it’s applying the profile, and you are done!  Pat yourself on the back, get up and stretch your legs and go get a drink!

Also, it will be at this point you realize that you can configure, and apply, different policies to different WLC’s based on what they do.  Going back and creating a new policy, defining the alerts and then applying the new policy to the different WLC is all it takes to care about Mi-Fi’s in one environment but not in a different one.  Unfortunately, I don’t know how to apply different policies to the same WLC but different AP’s.  I don’t think you can but I am open to being corrected.

Now, when you get back, navigate to “Dashboard –> Wireless –> Security” and you will now see your own list of crazy things happening in your environment.  Selecting the count to the right of the alert will give you a detailing listing of that alert.  It’s about this time you will realize that while this will suffice for just about any auditor, functionally it’s lacking.  This is where adding a second SNMP trap receiver, like Splunk, comes in handy.  You can either do that from the MSE GUI itself or from CPI on the page where the NMSP status link got you.  Adding it is simple and straight forward.  Realizing later that there isn’t a published MIB for the SNMP traps sent by the MSE makes you want to pull your hair out.

Side note here – if anyone figures that part out I would appreciate a link to a blog post.  I wasted too much time on figuring that out and had to move on without great results.

That’s it!  Your Cisco wIPS/wIDS is now functioning, and it’s just a matter of setting either more or less AP’s into wIPS mode and/or changing the alerts you are seeing.

My last input is this.  If you don’t have a written policy by this point, all of this was for naught.  These systems need to be cared for and updated.  There needs to be constant babysitting of the alerts generated and guidance on what to do about the alerts.  A lack of written, enforceable policy means the system you just built will exist only for the auditors, and that’s just depressing.

If you want to go back and read Part 1, click here.

If you want to go back and read Part 2, click here.

A link to official guide can be found here.

If you have any input or additional tricks, tips, or steps I forgot, please leave me a comment and I will make changes as needed.  Remember, this isn’t meant to replace the official Cisco guide (found here), just to tell my story and tips and tricks I learned along the way.  Thanks for hanging with me and getting to the end!

Until next time!

Setting Up Cisco wIDS/wIPS, Part 2

In Part 1 of my Cisco wIDS/wIPS adventure, found here, I covered trying to scale and scope what it is you need before trying to design and purchase a Cisco wIDS/wIPS solution.  If you haven’t read that one, you should go do that now and then come back here.

In Part 2, we are going to cover deploying your new and shiny Cisco wIPS solution, and then watch the magic start to pour in in Part 3!  I’m not going to get into how to install Cisco Prime Infrastructure or the MSE 8.0 with the wIPS licenses, the guides are pretty straight forward and self explanatory, that’s not what this is about.  The one lesson learned for this section, and I think it’s a lesson most of us have learned at one point in our career, is understanding where the enterprise firewall’s live, logically, in the intended architecture.  This will come in handy later when certain things just aren’t happening, or when it’s time to submit those request to get the firewall changed.

Before going much further, I want to highlight a drawing from the guide that I want to explain in detail, since no one really did this for me and it cost me some time trying to figure it out.  I know the quality is poor but I suspect it’s been copied and pasted more than once!Screenshot from 2018-08-19 15-13-49

With this layout I think you can see where the term “Holy Trinity” came from, and in a little bit you will really understand it.  As you can see, the WLAN hardware in the lower left centers on the WLC as this is a converged deployment.  I think you could do this in a different mode but at scale it might prove tough to manage.  Anyways, as you can see by the arrows, there are different communications protocols that happen within this trinity, and they all come into play when setting up and running a Cisco wIPS/wIDS system.

If there is one thing I need to impress at this point is while the MSE plays a significant role in the functionality of the system, other than the basic setup and configuration to get it to “talk” on your network, you actually don’t DO anything on the MSE server.  There is a couple of set up tasks that you can go back and add later (licensing and SNMP traps) but in a functioning solution, there isn’t any to see or do here.  Let me show you my live system to show you what I mean.  The main screen looks like this:

MSE Status

Not much to see, but it shows that something is happening.  The other screen to check is called the NMSP status page, and this gives you just that.  By referring to the trinity picture above, you can see that NMSP is the communication between the WLC and MSE, and it shows that information is indeed flowing INTO the MSE, which is step 1.  To give you an idea, this is what that looks like:

NMSP Status

As far as the MSE server goes, that’s about it.  There are a couple of other screens, but they are self explanatory (licensing and SNMP trap destinations) so I won’t cover them.  That and SNMP trap destinations can be done on Prime Infrastructure.  Biggest thing I learned over time, that no one pointed out to me and the one thing I want you to take away from this, almost ALL of the work is done on Cisco Prime Infrastructure (here on out referred to as CPI.)  Let’s break that down.

I know the picture above shows all three devices playing a part, and they do, but do you notice which server is at the top of the pyramid?  It’s CPI.  Assuming the WLC and Wi-Fi infrastructure is already up and running and you added CPI to give you some historical visibility into the system (and then they tried to tell you to do all the management of the system with CPI and you said no, just like me) the MSE is the last piece of this trinity.  It probably does the most work in a wIPS solution with the least amount of credit.

Using either a configuration template from CPI or manually selecting the option on the AP via the WLC, you are going to have wIPS information being sent from an AP configured in WIPS mode to the WLC via the CAPWAP tunnel and then from the WLC to the MSE server using the NMSP protocol.  The MSE is going to see that information as having come from the WLC (hence the NMSP status pages I just pointed out) but what it does with that information is controlled by CPI.  CPI is where the profile being used (basically what alarms you want to see) is configured and then pushed to the MSE via the SOAP/XML link link between the two.

Now when the NMSP traffic from the environment hits the MSE, it analyzes that traffic looking for different patterns that indicate known events happening.  When it sees a pattern that matches a known event, it triggers an SNMP trap from the MSE server to CPI.  During the configuration that is done for this solution on CPI, the IP address for CPI is inserted as the primary, and only SNMP trap destination in the wIPS MSE.  This is important since there isn’t anywhere on the MSE that you can actually tell that an alert has been triggered.  I spent a lot of time searching and there is no other way I can find that will show you this information.  It’s not in the syslog of MSE nor can you find anything great in the trap logs on the WLC.

Now, if you have turned on the mitigation part of wIPS there will be a coordinated effort from CPI to the WLC to deal with the offender, but only in certain circumstances have I ever heard of that functionality being enabled.  This is where the policy from Part 1 comes into play.  Accidentally doing a DDOS attack against a legitimate, neighbor AP can get you in trouble with the FCC so you better be sure your management has a written, approved policy that makes sense before turning that on.

To sum all this up, after initial configuration, it works like this:

  1. WIPS traffic from the WLAN is sent to the wIPS MSE using NMSP.
  2. WIPS MSE analyzes the data looking for specific patterns that match known “issues.”
  3. WIPS MSE identifies a known pattern and checks to see if it’s an issue that has been configred to alert on.
  4. If it is an alert-able pattern, MSE will send a SNMP trap to the destinations listed in it’s configuration (should be CPI by default, others can be added.)
  5. SNMP trap is logged on CPI, and others if configured, and depending on configuration can attempt to mitigate the offending device.

Like I said, the MSE does almost all of the work, but for all of that there isn’t much to actually see or do on the MSE.  If NMSP traffic is flowing and alerts are showing up on CPI and other trap receivers, then it’s working.

Coming up in Part 3 – Configuring and looking at these mythical wIPS/wIDS alerts.

If you missed it, Part 1 is here

Setting Up Cisco wIDS/wIPS, Part 1

Years ago, I was working with a contractor who was installing a bunch of conduit and pulling some Cat6 for a project we were working on. I commented about something to the effect of “I don’t care how or which way you run the conduit, I just need it to end here.” His response to me?

“You just want me to ‘Make it to work.'”

Based on the confused look on my face, he explained to me that he used to have a boss that would limit his instructions to “make it to work.” English wasn’t his first language and that was his way of telling the guys to just do what you have to do to make it work. He didn’t care how you did it, he just wanted it to work. We still use that term to this day, and it means “I don’t care how you make it work, just make it work.”

I was instantly reminded of this when, a couple of months ago, we started a project to implement Cisco wIDS / wIPS in our environment. It seemed like every time I asked around about doing this, I got the same answer “make it to work.” One response was much more detail, he explained that I needed to get my WLC, MSE, and Prime Infrastructure (PI) linked. When I asked him how I went about doing that and how things actually work, his response was “make it to work.” My problem stems from not finding a decent little write up explaining how you make it to work.

So here it is.

Useful Terms

Before we get started, it’s going to helpful to have a list of terms, or glossary, of what is about to happen. This will be handy for the rest of the story.

  1. WLC – Wireless LAN Controller
  2. CPI – Prime Infrastructure, Cisco
  3. MSE – Mobility Services Engine, Version 8.0
  4. NMSP – Network Mobility Services Protocol
  5. SNMP – Simple Network Message Profile
  6. MIB – Manufacture Information Base

Starting Off

Most of what I’m going to cover is a highlight of an official Cisco guide, with my own lessons learned, but giving credit where credit is due, here is the official guide that I have found to be most useful.

What I didn’t read in the guide but that I learned in my CWSP class is you first need to start off with an official policy. The Cisco wIPS profiles contain about 260 different alerts or alarms that can be customized with various settings and levels of alerts, assuming you have a policy to reference. I got stuck in the position of now triggering 260 different alerts in a guest heavy environment with almost zero guidance from the organization about what they actually want to see. This isn’t a “build it and they will come” type scenario, figure out what it is you want to see and start there. Turns out getting it to work technically was much easier than tuning the system with no guidance.

Also relying on my CWSP class and studies, start by figure out what type of system you want, or can afford. This means selecting an overlay system or an integrated system. That makes a lot of sense until you go to the guide and find out that they don’t use those words when describing their solution. Lesson learned here is the Enhanced Local Mode (ELM) is the traditional integrated system (Good) and the Monitor Mode is the overlay system (Better). Because this is Cisco, for the 3600 and 3700 series AP’s (and possibly 3800 series) they offer third solution which is an integrated module that is purchased and added to the AP which combines the overlay functionality (a radio dedicated to only wIPS) to a client serving AP. This is the “Best” Cisco solution because you can do it without running an additional network cable. The guide actually has a pretty good chart showing this, and some other goodies, that I borrowed to show you here:

Cisco_GBB_wips

Lesson learned here, and I learned it the hard way. That “Best” solution, over there on the right, looks really intriguing doesn’t it? Turns out that the Wireless Security Module (WSM) (which you will confuse with a WiSM2, especially since they now have a WSMv2, which I have) has some antennas built in to the module, and they are internal antenna only. Those of you that know me know that I love external antennas, and I use A LOT of them. You can’t use the WSM, either version, with external antenna model AP’s. The antennas from the module and the antennas from the client serving radios need to “see” the same RF environment or else lots of other bad things happen. It doesn’t mention that in the wIPS guide but it does in the RRM guide I referenced in my post about NDP, and in there is the link to the guide. Go to the chapter about RF Grouping and the section about WSM. It sounds like a good idea, but take my word and don’t add the module when using external antenna AP’s if the external antennas are more than the basic pencil atenna, it will never work right. Good news is you can combine the good and best configuration into one deployment so don’t get to discouraged.

Understanding what type you need, and how many is a good step to take before getting into licensing. Which WLAN vendor doesn’t like licensing? Cisco will sell you all kinds of licenses without knowing why and what it does because they like to sell stuff. The ELM license is used for the Good and Best solution, and the monitor mode license is for just that. Use the chart to get your numbers, then talk about purchasing licenses. Doing it the other way around is confusing and will exponentially raise the cost of the project.

Last step is understanding the servers, or what we refer to as the “Holy Quint of Cisco Wi-Fi” It used to be the Holy Trinity but we knew that term wouldn’t fly, but then we added 2 additional servers to get to 5 and that problem was solved. Anyways, what you need to make this work is a Cisco WLC (highly recommended for this solution), Cisco Prime Infrasture (don’t get me started) and a wIPS MSE.

So you have a Cisco MSE running some version of 8.0 doing Clean Air (CAS) so you are covered on that? Think again! Turns out you can’t run CAS and wIPS on the same MSE! I told you Cisco liked to sell things! Read the official guide I linked to earlier and find the note between Table 1-1 and Table 1-2.

Bummer.

Now that you have figured out which type of wIPS you are doing (overlay or integrated with or without the WSM module) and the servers you are going to need to purchase, we can move on to Part 2, trying to make it to work.

You can find Part 2 here.

I’m Going To Disneyland!

If you have ever met me in person, or read any of my blog posts, you might have come to realize that I’m a little quirky and sometimes not ready to be let lose in the wild without a chaperon.  You might have also realized that I am a big dork who likes all things wireless.

This past February I went to WLPC in Phoenix and near the end my co-worker told me he was done and his brain had turned to mush and I just looked at him like he was crazy.  I was ready to go for a second full week and then maybe, just maybe, I would be done and ready to head back to the real world.

Unlike my co-worker, I love this stuff!  I have a commercial radio license from the FCC (aka as a GROL, General RadioTelephone Operators License) and an amateur radio license.  When I’m not doing wireless for work, I’m doing it as a hobby.  Back to the quirkiness, and the title of this post; I’m not really going to Disneyland.  Or Disneyworld, or any Disney typed themed resort.  I’m going somewhere better!

I’m going to Mobility Field Day as a delegate! MFD3 here I come!

For me, that’s better than Disney or Universal or any of that nonsense.  I’m going to talk wireless for three, count them THREE, straight days!  I get to focus on wireless and mobility for three days and geek out with some of the brightest minds in the business.  When I got the invitation to go, it was just like that guy on TV going up to the quarterback who just won the Super Bowl.

If you didn’t think I was quirky and weird before, I think this might have just cemented it for you.

Honestly, it is a privilege and an honor for me to be invited to be a MFD3 delegate.  It’s hard to believe what has happened in my  life since I got plugged into the Wi-Fi community and started the CWNP certification process, just a short 18 months ago!  I’m not sure that I could have scripted what has happened, there is no way I would believe it.

Now, just like with all of the Disney properties, of which I have never been to any of them, I have never been to Mobility Field Day, or Tech Field Day, as a delegate.  I’ve followed those who have, and have read the posts and discussions and it does leave me nervous.  What if I geek out too much?

In that spirit, I have decided to set some ground rules for myself.  If anyone thinks I am missing something that will keep me in line, feel free to let me know.

  1. I will not ask for autographs, unless someone else does first.
  2. I will not be the first one to jump up and down on my chair.
  3. Or the table.
  4. I will take good notes so I can blog about the whole experience.
  5. I promise to keep all my blog posts less than 5,000 words.
  6. I will take pictures, and occasionally, allow pictures to be taken of me.
  7. I will not come home and talk incessantly to my wife about everything that happened.  (Actually, she doesn’t read my blog and as I will probably break this rule, oh well!)
  8. I promise to have a great time!

Now, number 8 is pretty simple and guaranteed to happen, but I needed to throw that in there to finish up the list.

My plan is to blog about the run up, and then the days as best I can, and then the presentations will come separately as I get the technical details straight.  That’s my plan at least.

One thing you might have noticed that is missing in my rules, and I’m not adding in, is I will more than likely talk the ear off of the other delegates to the point that one will begin to question my parentage.

That, my friends, is a promise!