I have a list of things I mean to blog about, and the Junos Apply-Path feature has been on there for way too long without being actions. As I said when I kicked off the “30 Blogs in 30 Days” Challenge, this would be an opportunity for me to blow some dust off my list of overdue posts, and this is certainly one that I am delighted to rediscover.
A quick post today. As you may recall, I run two Ruckus Wireless APs at home – a Zoneflex 7982 AP and a Zoneflex 7363 AP managed by a Zone Director 1106. The ZF7982 and ZD1106 were provided courtesy of Ruckus Wireless at NFD5, and have performed fantastically in my fairly large house – which is why I added my own ZF7363 to the mix! I also have a Cisco Meraki MR16 in the basement, but that’s another story.
This week I upgraded my MacBook Pro to OSX Yosemite, and my internet performance went down the toilet; it was awful. Cynicism fully engaged, I wondered whether my older Ruckus firmware (v18.104.22.168.50) might be part of the problem, so I checked for an update and found that v22.214.171.124.15 was available. I connected my laptop via the Meraki (which was running fine as it turned out), downloaded the code and uploaded it to the Zone Director.
Within a few minutes, the ZoneDirector had upgraded and rebooted and it began the process of upgrading the Zoneflex APs. 15 minutes from start to end and the upgrade of the controller and APs was complete. Shifting my WiFi connection back to the Ruckus, all was well again.
For good measure, I also found a firmware upgrade for the Meraki AP and scheduled it for an overnight installation where it wouldn’t interrupt anybody’s work.
So be warned – while it might have been tempting to blame Yosemite for the failure, it looks like it was an incompatibility between OSX and Ruckus which evidently was fixed one of the intermediate firmware updates. I don’t care which one, I’m just happy it’s all fixed! If you have deployed Ruckus APs and you have Mac users, you may want to upgrade your firmware.
30 Blogs in 30 Days
This post is part of my participation in Etherealmind’s 30 Blogs in 30 Days challenge.
Not content with digging into the A10 health monitors recently, I thought I should do the same for f5 LTM which has some slightly different setting and, it turns out, works really quite differently.
I hate to say it again, but there’s a good chance if somebody explained health monitors to you, they got it wrong or, at least, only told you half the story. The results presented here are relevant to f5 LTM version 11.3.
Some fun today. Juniper recently ran a competition they called the Junos Cup 2014. It was modeled after a world cup of sorts, with each challenge involving a country in the name, four Tournament and then – because in the real world there was a three-way tie – a final Sudden Death Challenge.
The whole thing was played out online, but Juniper decided to make a little book out of it all, and they were kind enough to send a copy to me, which I have been thoroughly enjoying reading.
I’ve mentioned before I think that on my home network, DHCP service is provided by a pair of ubuntu servers running ISC DHCP servers in a redundant configuration. Part of the reason for this is pure nerdiness, and the rest is because it’s easy to use scripts to manage the configuration files (and so I do, for both BIND and DHCP). Well, plus if I’m going to run some stupid overcomplicated system at home, it had better work even if a server fails, hadn’t it?
One afternoon, I couldn’t get an address on the home network. My iPhone was fine but my computer was repeatedly failing to get an address. Odd, but maybe it was just unlucky timing. I headed to a computer that was hard wired to the network (and had a fixed IP, natch) and looked at the logs on the primary DHCP server. Want to guess what I found?