Skip navigation

Category Archives: Meraki

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 > && ps2pdf && rm && 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.)

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.

Last week, I attended a webinar (I don’t like that word) presented by Meraki on the subject of BYOD solutions in a K-12 environment.  The presentation was interesting, certainly, but perhaps the best part was that, as a technology professional and as someone who makes purchasing recommendations for an organization with a budget for technology, I qualified for getting a free access point from Meraki.  Specifically, they sent me an MR12 access point and gave me a free several-year license for their cloud controller to go with it.

In case you don’t know Meraki’s deal, they make a full range of network hardware–APs, switches, and security appliances–which can be managed through the cloud from anywhere.  They also claim that, once you have your cloud controller set up, you can configure a new AP in as little as 15 minutes.  These are things that I like.  I also like getting free things to try out, so I was happy to get an opportunity to evaluate their hardware.

Simple packaging makes me happy.

Nothing superfluous here.

First of all, simple packaging makes me happy.  The box was just big enough for the AP, some mounting hardware, and a bit of padding to keep the thing safe.  No excess packaging.  There was barely any paper literature included in the box, either–just a single piece of paper listing the contents of the box and explaining, in short, that in this digital age, it’s stupid to print out documents that most people are going to throw away or lose anyway.  The access point itself seems to stick to this philosophy as well with a very spare aesthetic that I imagine would be next to invisible when deployed.

(Note, you don’t hear me talking in this unboxing video because I hate hearing my recorded voice and because narrating unboxing videos just seems awkward to me.)

So what happens after you get the thing out of the box?  Well, in my case, a lot of frustration to begin with.  My initial attempts to configure the AP as if it were any other of our APs, putting it on our control network with a static IP, putting it in bridge mode so that clients connected through it are on the LAN, and setting it up to authenticate against our RADIUS server, then making sure that the switch port it’s getting plugged into is associated with the right VLANs.

Then I plug it in and nothing works.  Sure, the power came on and I could see the AP on the cloud controller page, but the controller was reporting that the AP had never connected to the cloud controller, and the lights were flashing in a way that told me that it was getting a bad gateway.  That ain’t no good.

Well, I read through a lot of documentation, tried some things, and basically frustrated myself more working on it while during the afternoon when I kept on running off to attend to more urgent matters.

Wawa travel mug for scale (and because it was there first, and I'm not kicking it out of its home for some upstart AP).

Wawa travel mug for scale (and because it was there first, and I’m not kicking it out of its home for some upstart AP).

Today, after some more fiddling with the firewall and quiet swearing, I decided, what the hell, I’ll just plug it in to a regular network port, not trying to put the thing in Bridge mode, and just hoping that it would work as simply as I’d been promised.  Wouldn’t you know?  It worked.  It came on no problem.  The lights all went green (well, the power light started flashing orange after a bit, but that’s because it was updating the firmware for the first time, but after a reboot, it came back on no problem).  So now it’s sitting on my desk, plugged into the only network cable I had on hand, which is going through the switch in the back of my desk phone.  Maybe it’s not ideal, but I can finally start messing around with the cloud controller some more and really get an idea of what I’m working with and if I’m going to make the recommendation that we invest in Meraki hardware as we expand and upgrade our wireless.

Expect to see more about this hardware and probably some competing wireless solutions on here in the coming weeks.