A little while ago I posted about some issues seen with some new Aruba APs apparently putting out less power than the older model they replaced. The mystery has now been solved, and it isn’t all that mysterious.

Continue reading →

For a long time the general approach to Wi-Fi design has been about coverage – ensuring there’s an adequate signal level across the desired service area. That’s fine for some deployments but if you’re going to have 150 devices in a room it’s necessary to think about how much capacity your wlan can offer. Continue reading →

Recently we replaced the Wi-Fi APs in some college accommodation blocks and immediately received complaints. The years old 802.11n units should be easily bettered by the brand new 802.11ac wave 2 APs so what gives? Continue reading →

A handy little problem solving “wall-jack” switch from HPE called the NJ5000 has been discontinued. So I had a look around for alternatives and found few. Netgear make something that appears to fit the bill, so I got one. Here’s what I think of it. Continue reading →

EDIT – The conclusions of this article no longer apply to most environments as Bluetooth beacons have been arranged to avoid channels 1, 6 & 11 but will cause problematic interference with other 2.4GHz channels discussed here.

Many people say 2.4GHz is dead and whilst I view it as ‘best effort’ it isn’t going away and needs to be supported so I want it to be the best it can be. I use a four channel plan on our campus and my colleagues were recently informed this should never be done which inspired this post to explain the decision. This is quite lengthy but hopefully understandable. All comments and criticism welcome.

Continue reading →

I’m in the process of carrying out wifi improvement works on the campus, so I thought I’d write some pieces about our wifi equipment lifecycle and the processes I’m following.

Initial Survey
Pretty much everywhere has some wifi coverage. I’m therefore starting with an initial survey to find out what we currently have and inform what we need to change. Even if I know the coverage is terrible and I need to just start again, this survey is necessary to provide before and after documentation. It also shows how RF propagates through the building, which can help identify troublesome areas of attenuation that don’t show up on the plan. I try to identify where the available data points are at this stage, though it can be hard to be thorough about this.

Design
The design stage is predictive, though it’s sense checked using the initial survey information.

Deploy
Once there’s a new design, this gets deployed – this can be where some compromises occur as it turns out that ceiling cavity contains asbestos, or one of these data cables is damaged. Deployment is sometimes going to be done by me, sometimes by a contractor.

Validate
A repeat of the initial survey – validate the coverage is as expected, that APs are using sensible channels and we don’t have a Co-Channel Interference disaster, that 2.4GHz radios are on a sensible power setting or disabled as is appropriate. At this point there’s a loop back to design in the flowchart. If things are not looking as expected it’s back to the drawing board to find a remedy, then deploy physical or config changes and survey the area again. Recently I’ve carried out validation surveys in areas where I know an install compromise was made because the building structure wasn’t quite as expected. It was strangely satisfying to discover the original design was sound and the new AP position wasn’t working, so I had to come up with a different option.

Monitor
This is an ongoing process, but it’s worth confirming the throughput for group of APs is in the expected range (hasn’t dropped horribly for a building) and retransmissions are at acceptable levels. We use Aruba Airwave which makes it easy to group APs into an area for graphing of basic metrics. When wifi is improved in a building we expect to see an increase in client count and throughput but that isn’t always the case. Improving coverage in a lab means tablets can be used for note taking; that might be one or two more devices, not something that’s going to impact the graph.

I also talk to the users. Let them know there’s been a change, if they don’t already know. Ask for feedback and encourage them to tell you if there’s an device they need to use that doesn’t work so well in some parts of the building. Hopefully the design and validation accounts for this, but…..  I’ll more to day about that in another post.

Just over a week ago I completed my journey towards becoming a Certified Wireless Network Administrator… well, as much as anyone completes any journey in IT, there’s always more to learn.

When I started working in my current job and it became clear nobody understood WiFi, or knew how to solve the problems we were having, I quickly found the CWNP website and the numerous references to CWNA. A year later I was on a CWNA course with Peter Mackenzie. Probably the best aspect of the course was not how much I learned but how much it cemented what I’d already picked up through reading and lab work.

Like most certifications getting a good score in the CWNA exam requires you to learn and remember stuff that in reality you’d look up. In the end I found the exam straight forward. I felt I knew pretty much all the answers (actually it turns out I didn’t know at least three of them), but this is not because it’s an easy exam. I’ve spent a lot of time reading the study guides, making sure I knew what was expected… and then, because I dithered so much between taking the course and sitting the exam CWNA-106 was retired…. so I started again with a new study guide. I was pleased with the end result, a score of 95%. Worth all that work.

I’d like to pursue more certifications, otherwise I’ll need to find something else to do with my evenings. Because I work almost exclusively with Aruba equipment at the moment, it makes sense to look at the ACMA and ACMP certs. I’m also going to go further with the CWNP certs, probably looking at the Analysis Professional next.

The fact CWNP is vendor neutral is particularly appealing. Whilst it’s great to have a certification in Cisco or Aruba wlan equipment (the only two I’d consider worthwhile), these can focus on platform specific commands, licensing requirements and model lineup. Whilst this is useful information it doesn’t teach you about WiFi. I much prefer the approach of understanding how a technology works, something I can apply to any platform, rather than being restricted to knowing how to do things with a particular vendor’s equipment.

Fundamentally, whilst all WiFi network vendors have their pros and cons, their specific technology solutions to problems, RF is RF and if you understand how 802.11 it helps enormously to make sense of why a vendor does something a certain way.

In my experience of the networking world people seem to fall into one of two categories: those that are all about the policy and those that are all about the user.

Actually it’s really IT folk in general and I’m very much in the latter camp. I have on IT worked in schools, non-profits and now at a university and something I’ve found almost all users have in common is they’re not interested in IT policy.

They have a job to do or something they want to achieve. If you start talking about IT policy, as a general rule, the user will see this as getting in their way.

In theory it shouldn’t be this way. Our carefully crafted ITIL compliant framework is all about ensuring users have what they need and a service catalog that’s makes it all clear.

The trouble is often what they want isn’t in the service catalog… so what then? Sure we can spend months developing a solution this fits and rolling it into the catalog, but by then the user has become deeply frustrated, rolled their own solution, or given up completely.

This comes up in our office from time to time. An excellent colleague I respect greatly will often voice something along the lines of “why can’t we just say that’s not supported?”.

Of course in some environments you can do just that. Tell the annoying user they can’t connect their stupid device to the network because it’s too crappy. Sometimes we do. There are some devices that we can’t support on our enterprise Wi-Fi network: Sonos, Philips Hue, chromecast, to name just a few and there are technical barriers to this.

However for the most part we don’t get to choose the device users buy, or control how it interacts with our network. More importantly what is our job? In the university environment we have to maintain a reliable, high performance network that supports the research and education aims of the institution. That means meeting the requirements of the academic departments, finding away to support what they need to do within the technical limitations….. and even working around those where we need to.

When dealing with people who are highly intelligent and resourceful if you don’t provide a way for them to do what they feel is necessary, they’ll find their own way. In doing so they might break things for other people and create a support nightmare further down the road.

I have spent hours messing about with crappy domestic printers bought on the high street on a credit card because I simply hadn’t dealt with issues around printing adequately.

I’m fortunate to work as part of an IT department that has an excellent reputation within our institution. It wasn’t always the case and not very long ago the standard answer to many requests was “no, we can’t/won’t do that”. It has taken years to unpick some of the systems built by departments when central IT couldn’t or wouldn’t help them and they had to find their own way.

I’m not going to suggest the user is always right because we know that’s nonsense. What I will say is put the user first. Your IT policy or administrative convenience is not more important than what the user needs to do.

Let me bring this back to Wi-Fi with an example. Our Aruba system uses centralised forwarding, where all client traffic is tunneled to controllers in the data centre. Some departments have a need for an SSUD that bridges to a local vlan. Right now we can’t support that, because we have to switch on control plane security – a major change. So we could say “no, can’t help” or find a way to do something with an additional controller or standalone AP, and that’s what I did.

You can bet that otherwise we’d see additional rogue APs popping up with departmental SSIDs that would screw with the RF space and be unsupportable. I’d much rather bend, or bin, the policy and keep better control of the network.