Meet Juniper, our new cat we rescued via the SF SPCA!

One of my goals in writing this blog is to help other people in the operations field. It's not a point of bragging or telling other people how to do their job. It's just a helpful guide that isn't full of sales pitches. That said, I'm going to say something somewhat inflammatory. You're crazy if you still run 1U "pizzabox" servers as your web front ends. Seriously.

As operations employees, we should strive to reduce downtime (at a reasonable cost) whenever we can. Sometimes, it's the little things that can go a long way. Using PDU secure sleeves in your datacenter racks is a simple, low-cost method to prevent admin-induced outages when working on equipment.

PDU outlet tolerances and cabling tolerances don't always match up. If you've ever used a PDU that uses C14 or C20 connectors, you know what I mean. You plug something in, but the cable on the PDU side is a bit jiggly. It's in there but not snug. Not like what you expect from something plugged into a 110V 3-prong outlet. Luckily, there's a cheap, simple solution called secure sleeves.

Secure sleeves are plastic molds that simply slide over your existing power cables. When inserted into the outlet, the sleeves compress, and friction holds the plug in place. Brilliant! I've posted a quick video (below) showing how well they work.

We buy ours from Stay Online for 50 cents each. They even have the inserts for the other C13/C19 sides. Stay Online says that they only work with PowerFig or Yung Li cables; not a problem for us as we buy all of our PowerFig cables from them. You should check out the stuff at Stay Online, they've got good stuff at good prices. No, I don't get any referral money from them; I'm just a happy customer.

This post is short and sweet since it probably affects a narrow range of people. If you run Aruba wireless gear and your Android users have started to complain about connectivity issues, here's the fix. Set "no broadcast-filter arp" on your wlan virtual-ap.

The longer story is that Aruba gear (by default) will send ARP responses as unicast instead of broadcast. This is a trick to conserve RF network capacity and extend battery life for devices. The problem is that Android (and I'm guessing Linux) devices treat the responses as invalid. It sent a broadcast and receieved a unicast response.....that does seem kind of fishy. I don't know if this behavior is against some sort of RFC or is frowned upon or what. I think it sounds neat....until it breaks stuff.

No other devices we saw (Macs, PCs, iPhones) were affected by this. The Android phones would associate with a radio, join the network, get an IP, then go nowhere. No kind of network access would work. The tell-tale test was a basic ping from the controller to the device. That failed even with static ARP entries on the controller (because the client was ignoring ARP responses).

You want to use a RHEL 6/CentOS 6 server as an IPSec/VPN gateway?

Here's the tl;dr.... don't do it. Buy some Juniper SRX210's on eBay for $200/each instead.

The Linux kernel team massively broke IPSec performance somewhere between kernels 2.6.18 and 2.6.35. The good news is that it's supposedly fixed in 2.6.35. I haven't tested it, but reports are that it works OK. So if you must stay with RHEL or CentOS, compile your own kernel (I'd recommend doing that anyway).

So back to the long story.

Quick and dirty blog post for those people who are looking to get recent versions of ntop (5.x) running on CentOS 5.6. The main problem is that newer versions of ntop require Python 2.6 or later, and this requirement cannot be disabled compile-time. So the best solution is to simply build your own version of Python and install it.

This is all I had to do to get it working:

1. Download a newer version of the Python source (I chose 2.7.3 but anything recent should work).
2. Unzip/tar your python archive.
3. cd python-$version
4. export CFLAGS='-fPIC'
5. ./configure
6. make
7. sudo make install

You don't want to do a make altinstall or add an executable prefix as suggested in other places on the net. The ntop autogen.sh script simply won't detect those types of installs. You'd mainly do that to do a safe "side-by-side" install so that the RedHat/CentOS stuff (like yum) doesn't break with the new version of Python. That advice is outdated, and the Python guys now handle it automatically in the configure/make scripts. Python 2.7 gets installed as python2.7 in the system directory without anything fancy.

You do need the CFLAGS step in order to build Python modules that ntop can link against. Everything else with the ntop install is pretty straightforward in terms of solving dependencies. Happy netflowing!