Welcome to Random Short take #64. It’s the start of the last month of the year. We’re almost there.
Want to read an article that’s both funny and informative? Look no further than this beginner’s guide to subnetting. I did Elizabethan literature at uni, so it was good to get a reminder on Shakespeare’s involvement in IP addressing.
On a more serious note, data hoarding is a problem (I know this because I’ve been guilty of it), and this article from Preston outlines some of the reasons why it can be a bad thing for business.
Still on data protection, Howard Oakley looks at checking the integrity of Time Machine backups in this post. I’ve probably mentioned this a few times previously, but if you find macOS behaviour baffling at times, Howard likely has an article that can explain why you’re seeing what you’re seeing.
Zerto recently announced Zerto In-Cloud for AWS – you read more about that here. Zerto is really starting to put together a comprehensive suite of DR solutions. Worth checking out.
Finally, this article over at Blocks and Files on what constitutes a startup made for some interesting reading. Some companies truly are Peter Pans at this point, whilst others are holding on to the idea that they’re still in startup mode.
Disclaimer: I recently attended VMworld 2019 – US. My flights and accommodation were paid for by Digital Sense, and VMware provided me with a free pass to the conference and various bits of swag. There is no requirement for me to blog about any of the content presented and I am not compensated by VMware for my time at the event. Some materials presented were discussed under NDA and don’t form part of my blog posts, but could influence future discussions.
As part of my attendance at VMworld US 2019 I had the opportunity to attend Tech Field Day Extra sessions. You can view the videos from the Apstra session here, and download my rough notes from here.
More Than Meets The Eye
A lot of people like to talk about how organisations need to undertake “digital transformation”. One of the keys to success with this kind of transformation comes in the form of infrastructure transformation. The idea is that, if you’re doing it right, you can improve:
Application reliability; and
Apstra noted that “a lot of organisations start with choosing their hardware and all other choices are derived from that choice, including the software”. As a result of this, you’re constrained by the software you’ve bought from that vendor. The idea is you need to focus on business-oriented outcomes, which are then used to determine the technical direction you’ll need to take to achieve those outcomes.
But even if you’ve managed to get yourself a platform that helps you achieve the outcomes you’re after, if you don’t have an appropriate amount of automation and visibility in your environment, you’re going to struggle with deployments being slowed down. You’ll likely also find that that a lack of efficient automation can lead to:
Physical and logical topologies that are decoupled but dependent;
Error-prone deployments; and
No end to end validation.
When you’re in that situation, you’ll invariably find that you’ll struggle with reduced operational agility and a lack of visibility. This makes it hard to troubleshoot issues in the field, and people generally feel sad (I imagine).
Intent, Is That What You Mean?
So how can Apstra help? Will they magically make everything work the way you want it to? Not necessarily. There are a bunch of cool features available within the Apstra solution, but you need to do some work up front to understand what you’re trying to achieve in the first place. But once you have the framework in place, you can do some neat stuff, using AOS to accelerate initial and day 2 fabric configuration. You can, for example, deploy new racks and L2 / L3 fabric VLANs at scale in a few clicks:
Streamline new rack design and deployment;
Automate fabric VLAN deployment;
Closed-loop validation (endpoint configuration, EVPN routes expectations); and
Include jumbo frame configuration for overlay networks.
The idea behind intent-based networking (IBN) is fairly straightforward:
You can read a little more about IBN here. There’s a white paper on Intent-based DCs can be found here.
I don’t deal with complicated network deployments on a daily basis, but I do know some people who play that role on TV. Apstra delivered a really interesting session that had me thinking about the effectiveness of software solutions to control infrastructure architecture at scale. There’s been a lot of talk during conference keynotes about the importance of digital transformation in the enterprise and how we all need to be leveraging software-defined widgets to make our lives better. I’m all for widgets making life easier, but they’re only going to be able to do that when you’ve done a bit of work to understand what it is you’re trying to do with all of this technology. The thing that struck me about Apstra is that they seem to understand that, while they’re selling some magic software, it’s not going to be any good to you if you haven’t done some work to prepare yourself for it.
I rabbit on a lot about how technology organisations struggle to understand what “the business” is trying to achieve. This isn’t a one-way problem either, and the business frequently struggles with the idea that technology seems to be a constant drain on an organisation’s finances without necessarily adding value to the business. In most cases though, technology is doing some really cool stuff in the background to make businesses run better, and more efficiently. Apstra is a good example of using technology to deliver reliable services to the business. Whether you’re an enterprise networker, or toiling away at a cloud service provider, I recommend checking out how Apstra can make things easier when it comes to keeping your network under control.
Like a lot of people who work in IT as their day job, the IT situation at my house is a bit of a mess. I think the real reason for this is because, once the working day is done, I don’t want to put any thought into doing this kind of stuff. As a result, like a lot of tech folk, I have way more devices and blinking lights in my house than I really need. And I’m always sure to pile on a good helping of technical debt any time I make any changes at home. It wouldn’t be any fun without random issues to deal with from time to time.
Some Background – Apple Airport
I’ve been running an Apple Airport Extreme and a number of Airport Express devices in my house for a while in a mesh network configuration. Our house is 2 storeys and it was too hard to wire up properly with Ethernet after we bought it. I liked the Apple devices primarily because of the easy to use interface (via browser or phone), and Airplay, in my mind at least, was a killer feature. So I’ve stuck with these things for some time, despite the frequent flakiness I experienced with the mesh network (I’d often end up connected to an isolated access point with no network access – a reboot of the base station seemed to fix this) and the sometimes frustrating lack of visibility into what was going on in the network.
Enter Google Wifi
I had some Frequent Flier points available that meant I could get a 3-pack of Google access points for under $200 AU (I think that’s about $15 in US currency). I’d already put up the Christmas tree, so I figured I could waste a few hours on re-doing the home network. I’m not going to do a full review of the Google Wifi solution, but if you’re interested in that kind of thing, Josh Odgers does a great job of that here. In short, it took me about an hour to place the three access points in the house and get everything connected. I have about 30 – 40 devices running, some of which are hardwired to a switch connected to my ISP’s NBN gateway, and most of which connect wirelessly.
So What’s The Problem?
The problem was that I’d kind of just jammed the primary Google Wifi point into the network (attached to a dumb switch downstream of the modem). As a result, everything connecting wirelessly via the Google network had an IP range of 192.168.86.x, and all of my other devices were in the existing 10.x.x.x range. This wasn’t a massive problem, as the Google solution does a great job of routing stuff between the “wan” and “lan” subnets, but I started to notice that my pi-hole device wasn’t picking up hostnames properly, and some devices were getting confused about which DNS to use. Oh, and my port mapping for Plex was a bit messed up too. I also had wired devices (i.e. my desktop machine) that couldn’t see Airplay devices on the wireless network without turning on Wifi.
After a lot of Googling, I found part of the solution via this Reddit thread. Basically, what I needed to do was follow a more structured topology, with my primary Google device hanging off my ISP’s switch (and connected via the “wan” port on the Google Wifi device). I then connected the “lan” port on the Google device to my downstream switch (the one with the pi-hole, NAS devices, and other stuff connected to it).
Now the pi-hole could play nicely on the network, and I could point my devices to it as the DNS server via the Google interface. I also added a few more reservations into my existing list of hostnames on the pi-hole (instructions here) so that it could correctly identify any non-DHCP clients. I also changed the DHCP range on the Google Wifi to a single IP address (the one used by the pi-hole) and made sure that there was a reservation set for the pi-hole on the Google side of things. The reason for this (I think) is that you can’t disable DHCP on the Google Wifi device. To solve the Plex port mapping issue, I set a manual port mapping on my ISP modem and pointed it to the static IP address of the primary Google Wifi device. I then created a port mapping on the Google side of things to point to my Plex Media Server. It took a little while, but eventually everything started to work.
It’s also worth noting that I was able to reconfigure the Airport Express devices connected to speakers to join the new Wifi network and I can still use Airplay around the house as I did before.
This seems like a lot of mucking about for what is meant to be a plug and play wireless solution. In Google’s defence though, my home network topology is a bit more fiddly than the average punter’s would be. If I wasn’t so in love with pi-hole, and didn’t have devices that I wanted to use static IP addresses and DNS, then I wouldn’t have had as many problems as I did with the setup. From a performance and usability standpoint, I think the Google solution is excellent. Of course, this might all go to hell in a hand basket when I ramp up IPv6 in the house, but for now it’s been working well. Coupled with the fact that my networking skills are pretty subpar and we should all just be happy I was able to post this article on the Internet from my house.
I’m not a tech journalist, nor am I a product reviewer. And if you’ve seen my network at home you’ll know I’m not much of a network guy either. So I have no idea what makes for decent home gear, but I thought this project by Router Research on Kickstarter looked pretty cool. Unfortunately it doesn’t look like they’ll get the funding they’re after, so I have NFI what happens next. If nothing else, I like the concept.