Configuring switches and routers, in theory, is a simple thing. In my case, it was the first “real” thing I did outside of fiddling with the desktop PCs of my childhood. A family friend ran a dial-up ISP out of our basement, and I somehow ended up learning about BGP routes, and troubleshooting T1 connectivity problems in the middle of the night. I was hooked, and I’ve been working with networks and servers ever since.
Fast-forward 20-years later, to present day. For a technology that so rarely changes, you would think that network devices would have been the first piece of the IT stack to get automated on a large scale. Things that rarely change are usually at the top of list. Yet, believe it or not, the ol’ reliable method that I mastered in the late-90s — copy/pasting from docs and spreadsheets — is still the main source of network automation.
But…why?
Every Network is Different
If you’ve ever attempted network automation before, then you know all too well why it’s so often a mind-numbingly frustrating effort: every vendor, every model, every device type…each has totally different commands, configurations, language/syntax, and firmware/operating systems.
Every network, and every device in those networks, is a hodge-podge combination that’s unique and often vastly different from place to place. In general, networks are logistical nightmares with a seemingly infinite set of random devices generating random output.
Take Cisco IOS, for instance. If you start going back a few years, you’ll eventually end up with older versions that begin having slightly different command syntaxes, standard output, and terminal lengths. And outdated SSH versions further complicate matters, as that requires you to subvert basic connection security.
And that doesn’t even include the challenges of identifying inventory sources and establishing a network source of truth. To have even that simple starting point for an automation project is often enough to fold hardened developers who aren’t already familiar with the ins and outs of network infrastructure.
Either way you cut it, your configuration and implementation options will be slightly different between each device, on each OS, on each firmware version, on each platform, etc… You need a tool that can connect to all of them, and give you standardized configurations and outputs for each of these different network devices.
How Did I Get Here?
A few years ago, I started a project to establish a network automation platform for a huge company. They had 15,000+ routers, switches, firewalls, and load-balancers. This particular network was spread across the globe in a combo of datacenters, support centers, offices, stores, warehouses…it could reliably be anything, anywhere, running any version of who knows what.
Although I started my tech career doing networking, I ended up becoming a Linux engineer after a fateful bait-and-switch with a government job back in 2010. That worked out quite well, actually, as it was a cool gig that introduced me to all sorts of things I’d have never done otherwise. Incidentally, I fell in love with Linux, and ended up finding Ansible a few years later.
Through the years, I ended up being able to blend my career into a combo if Linux, VM/containers, and network architecture. Anything and everything infrastructure. So when I got my first chance to tackle that huge network automation project, I was terrified and excited both. I dreaded the idea of nearly endless variance in gigantic networks, but I couldn’t wait to see what my time as a Linux engineer had taught me about automating network devices.
I knew that the sheer scale and variety of devices was going to be insane. But that’s where Ansible comes in! And let me tell you, it was an amazingly fun and challenging endeavor. I still remember the giddy feeling of running my first command against every device at the same time. And things have only gotten easier since then!
So Why Ansible?
So why Ansible? It’s lightweight and easy to learn. You can have it up and running in less than five minutes. There’s no agent to install or manage. It does its configuration over SSH and HTTPS. Blah blah blah.
I may get in trouble for saying this, but Ansible is as close to a replacement to programming as you can get. It’s automation for everyone. From people who don’t know how to program, to people that do…and to people who don’t want to know how to program!
Imagine, if you will, that you’re me from 20 years ago — new to tech and new to the idea of automation. For people like me, who want to start automating their everyday things, I’ll likely want to start with all the stuff I’m copy/pasting from a Word doc into a device terminal. Nobody should need to learn a new programming language just to start automating things.
IT tools for the masses are all but dead in the water if they require in-depth programming knowledge to even begin understanding how they work. Puppet is borderline, with its nightmare learning curve. And don’t even bother thinking about Chef unless you already fully competent with Ruby. I say this having been a former user/developer with both — never again!
The beauty of Ansible is that you can have an entire team of people pick it up and start using it in almost no time, regardless of how new or experienced they may already be. If you want to quickly learn how to automate things, look no further!
Getting Started with Ansible
Ansible doesn’t have a steep learning curve and it doesn’t require any sort of programming background to use. You can begin running commands against your network inventory in no time at all. And I can prove it!
This next section will overview how to start using Ansible. Download and install it, make an inventory, and then run a playbook against your network — in less than five minute!
Part Two:
http://www.landoman.com/2020/02/07/getting-started-with-network-automation-part-2/
2 Replies to “Automating Networks with Ansible – Part 1”