Skip navigation

Monthly Archives: March 2013

Oh, yeah!  Pie charts, baby!

Oh, yeah! Pie charts, baby!

While I still haven’t gotten many chances to really put it through its paces, I really love a lot of aspects of the MR12 Meraki sent me.  One of my favorite features is the ability to get a lot of granular detail on the network traffic clients are getting through the AP.  There are places where raw data is fine, but a lot of the time, I want a nice visual representation just so I can get a quick idea of what I’m working with.  This is especially true when we have weird hiccups or slowdowns on our network in certain areas.  Unfortunately, I don’t have Meraki APs everywhere, so I can’t just pull up a lot of sexy data and quickly figure out what’s up.  I’d really love to be able to do that, though.

So what does a sysadmin do when there’s a need but not a solution he knows?  Google, duh.

And what does google give me?  It gives me ntop.  If you are a knowledgeable user and not just a luser, you have probably used top before to find out what processes are using the most of your memory and processor at any given time.  Well, ntop is something like that, only for networks.  But, more than that, it can give you nice graphical representations of your data through a web interface.

Having just run across ntop this very hour, I haven’t dived into the man pages for it yet, but I have written a long command chain so that I can read the things without standing in front of my Linux terminal, and, because sometimes I just want to write a long command, here’s what I did:

man -t ntop > ntop_man.ps && ps2pdf ntop_man.ps && rm ntop_man.ps && scp -P 22 ~/ntop_man.pdf [user]@[lappy]:/Users/[me]/Documents

So there.

(Of course you can expect me to post more about ntop as I dive in and find out what it can do for me and, by extension, what it might be able to do for you.)

Happy Document Freedom Day, everyone!  I can stand at my desk all day and proselytize, and I’m sure I sometimes do, but today, I’d rather offer an anecdote that I hope better demonstrates the case for open formats and document freedom than any sermon could.

The other day, I was working at my desk when a panicked student came in to our office with a USB drive in hand, asking if we had a copy of iWork ’09.  This student was supposed to be in class right then giving a presentation, but they had created their presentation in iWork ’09 but couldn’t open it on the computer in their classroom because we only have iWork ’08 on all of our classroom and teacher Macs.  Luckily for this student, we have a machine in our office with iWork ’09 on it and were able to open the presentation and save it in iWork ’08 format, but they would not have been so lucky if we hadn’t encountered this problem once before and made sure that we had a copy of iWork ’09 installed against such an eventuality.

With the converted copy safe on their USB drive, the student ran off to give their presentation, but I hope that this made some impression on them–at least that student will hopefully check for compatibility in advance next time.  It may be a bit much to expect that this will be their rallying cry to switch to open formats, but I can always hope.  All of our campus computers have Open-Office or another FOSS office suite installed for those people who are already converted, but I have no usage statistics; my guess would be that they’re not used that often, though.

Free your documents, free yourself!

We recently deployed a new cart containing 20 of Samsung’s new $250 Chromebook.  If you haven’t been able to get your hands on one of these new machines, let me just say that they’re really quite nice, especially for the price.  Yes, the build-quality is a bit, well, plastic-y, but what can you really ask of a machine that costs that little?  We’re a Google Apps campus, so Chromebooks are a great choice for a lot of things, and if we need some software that doesn’t run on them, we have other laptop carts.

A day or so after we first deployed the cart, though, we ran into a pretty major (but avoidable) hiccup–they were killing our network.  Some students were able to log in but unable to get to the site they needed, while others weren’t even able to log in.  Worse, students with their own laptops were also unable to get online, or their connection speeds were about what you would expect if you dialed into AOL with your Pentium 2 PC.

Why did this happen, and how can it be avoided in the future, you ask?

These machines shipped with Chrome OS version 23-point-something, and the current production release of Chrome OS is 25-point-something.  The machines also needed a firmware update.  This accounted for something on the order of 300MB of data that each machine needed to pull down.  That would kill just about any AP.  While our machines are enterprise-enrolled and thus had gone on the network at least once before they were first used in class in order to get them enrolled in our domain, none of them had been online for more than 30 seconds.  In our domain management dashboard, we were able to set our machines to scatter automatic updates over a period of days to prevent this problem from recurring (the available range is 1-14 days), but, as a preventative measure before we did this, we pulled out the new machines two or three at a time and forced them to update.

As of this writing, I have received reports of 16 of the 20 Chromebooks being used at the same time by a class with no abnormal slowdowns in the network.

I must acknowledge the help and advice offered by members of the Chromium OS dev team who came to our aid quickly and helped us solve this issue in an afternoon.

So, after exchanging some ideas with myself over on Twitter, I decided that I should put up a formal poll here.  Your feedback, whether you’re a first-time reader or a repeat offender is appreciated and will absolutely be taken into consideration.

So I’ve got two different cloud-controlled AP in my office right now.  The Meraki is now hanging up on our equipment rack through creative use of the provided mounting hardware, and the Aerohive HiveAP 121 is sitting on the workbench, waiting on the authorization email from Aerohive that will get me set up with their cloud controller.  I really like the idea behind these things.  We have a fairly large campus, and it’s expanding to across the street, which is miles away as far as I’m concerned, so I’m really interested in the idea of being able to manage our hardware from anywhere, whether I’m in the office, at home, or even (if the need were to arise) on vacation, as long as I had web access.  There are some things that I find bothersome, though.  Chief among those things is how many of my resources I have to make security exceptions for in order for these cloud-controlled APs to work seamlessly with our existing system.  Maintaining a level of security is part of my job description, so I don’t like the idea of putting a path between the web and the closed-garden systems on my network.

My most recent frustration in this regard cropped up today, just after I thought I’d sorted my previous problems out.  Our traditional APs are all controlled from an internal-only VLAN, and they sit on trunked lines that give them access to our other networks for the business of actually accessing the internet wirelessly.  That model, I’d already figured out, wouldn’t work right out of the box for the Meraki AP because there needed to be a path to the outside world so the cloud controller could talk to the AP, so I put the AP on a different network that can get out without a fuss.  But then: problems.

As I think I’ve mentioned before, our student and instructional networks authenticate clients against a RADIUS server that we have on campus.  Well, I know how to set up an AP to authenticate against a RADIUS server, so I thought there wouldn’t be any differences when it came to hooking the Meraki up to the thing.

What I didn’t know was that the cloud controller needs to access the RADIUS server, which would mean putting a hole in the firewall for that purpose.  I’m not particularly excited about that prospect.  I can see how it would be nice to have the RADIUS server accessible from the outside–we could, for instance, set up a remote AP at a totally separate site and let users authenticate normally.  Still, in the context that I’m using, or trying to use these APs, which is to say as nearly-pnp devices that I can just drop into my existing network with a minimum of fuss so I can put them through their paces to see whether I really want us investing in this technology (and in theory, I really would like to deploy these things).  In practice, this just hasn’t been working as I’d hoped.

In the end, I may just grin and bear it if I have to open some holes in order to make things work the way I’d like, but I really wish that there was an option to let these APs work with our existing RADIUS server without making that server available to the outside world.  After all, except for the cloud controller itself, which is in a server-farm somewhere (probably in California), everything I’m working with is inside one discrete network, so all the hardware involved should be able to talk amongst themselves.

Look what just showed up in the office today.

image

I can’t really say anything about performance, since the thing just showed up just as I was leaving, so I haven’t done much more than take it out of the box.  I can say that, while I will give it a fair evaluation compared with the other hardware I have to test, I’m a little bit more inclined towards the Meraki unit at the moment just based on build quality.  This Aerohive unit just doesn’t feel as solid, partly because it lacks the metal backplate of its Meraki counterpart, and the plastic mounting brackets that it came with feel a bit flimsy.

Well, watch here for more information after I’ve had a chance to actually put this thing through its paces.