I’ve always been someone who has advocated for buying your own tools to test and troubleshoot things. This applied when I was working primarily as a network engineer focused on route/switch, datacenter, and security technologies and it still applies today, now that I’m primarily focused on wireless. In my experience, some companies and/or management are better than others with regards to buying tools for their employees so you cannot always rely on them for help. Investing in yourself and your learning is critical in my opinion so don’t let that deter you. It’s also nice to be able to take those tools with you if you decide to move on to “greener pastures” one day. Unfortunately, not all tools are what I consider to be affordable for the average person, especially if they are somewhat frugal like myself. Just do the best you can, when you can.Continue reading
This morning, I tweeted the message below without much context:
With the 280 character limit of Twitter (hard to believe it used to be 140), sometimes it’s difficult to fully express an idea or the context behind it and instead of trying to create a messy, multi-threaded tweet, I just left it there as food for thought. But here on my blog, I can elaborate further on why this situation stood out to me and how it applies to you, the reader, who’s most likely in an IT related role.Continue reading
This is not meant to be a bash post or anything like that, but more of a “public service announcement” for anyone who might have to deal with this scenario in the future and cannot find a ton of info online; I know I couldn’t.
I was on a work-related call today regarding a project to bring in a vendor that was going to leverage the 5 GHz Wi-Fi channels that we typically leave out of our channel plans for their own autonomous Wi-Fi network to provide connectivity for their client devices. Those unused channels are in the UNII-2e (or UNII-2C for the initiated) band, specifically 112-132. That’s not a small amount of spectrum that we give up, but we do it as part of our partnership with vendors who need the spectrum in order to provide their own networks for their solutions. I know what you’re thinking… We picked those specific channels because traditionally they’ve been known to have more problems than others with DFS events, but I can neither confirm nor deny that! Those channels were selected before my time here so I’ll claim plausible deniability on that one :). Anyway, nothing new for us there and back to the story…
It was noted on the call that Meraki does not allow channels 116-132 to be used and my antennas (wireless pun) immediately went up. “Hold up, flag on the play! That CAN’T be right. Are you sure?” is what I was thinking to myself. Admittedly, while I have worked on some Meraki tasks and troubleshot a few things since starting here, I have not completely delved into the world of Meraki to say much, if anything, definitively about their solution. So I kept my mouth shut and scrambled to log into our Meraki dashboard, trying to confirm what was said by someone who wasn’t even on our team; surely they had to be mistaken. And then I saw it…
I’ve been doing less and less Python development since moving to a new company back in June. At my previous employer, I worked on Python command-line scripts and a custom-built web app fairly often that assisted with daily, monotonous tasks as well as troubleshooting. I really enjoyed the process of learning more about Python and developing tools that helped not just myself, but also my team.Continue reading
So you’ve got that fancy new AP from VendorX with all the speeds and feeds, including multi-gigabit capability. Are you taking advantage of the increased speeds? How do you keep track of all your APs and the speeds they are linked up at? I found this interesting tidbit about LLDP when I was doing some investigation on an infrastructure insight that RUCKUS Analytics provides…