Some people think that everything is better with Bluetooth. They’re clearly wrong; according to the ancient wisdom of product managers working for networking vendors, everything is better with a GUI.
Now imagine adding network topology visualizer and GUI-based device access with in-browser SSH to an intent-based infrastructure-as-code virtual network function labbing tool. How’s that for a Bullshit Bingo winner1?
Lívio Zanol Puppim published a series of blog posts describing a full-stack network automation, including GitOps with GitLab, handling secrets with Hashicorp Vault, using Ansible and AWX to run automation scripts, continuous integration with Gitlab CI Runner, and topped it off with a REST API and React-based user interface.
You might not want to use the exact same components, but it’s probably worthwhile going through his solution and explore the source code. He’s also looking for any comments or feedback you might have on how to improve what he did.
Would you happen to have your network connectivity data in a tabular format (Excel or similar)? Would you like to make a graph out of that?
Look at the Excel-to-Graphviz solution created by and Salman Naqvi and Roman Urchin. It might not be exactly what you’re looking for, but you might get a few ideas and an inspiration to do something similar.
- NSX-T manager virtual machines
- NSX-T uplink profiles and IP pools
- Transport zones and transport nodes (NSX-T modules on ESXi hypervisors)
- Edge clusters including BGP, EVPN and BFD
Once the infrastructure is set up, his solution uses a Terraform configuration file to deploy multiple tenants: external VLANs, tier-0 gateways, BGP neighbors, tier-1 gateways, and application segments.
While the infrastructure part of his solution might be fully reusable, the tenant deployments definitely aren’t, but they provide a great starting point if you decide to build a fully automated provisioning system.
netsim-tools release 1.1.4 includes a number of seemingly unrelated goodies; here’s the the reasoning (or story) behind some of them:
netlab clab tarball creates a tar package that can be deployed with containerlab without netsim-tools
Julio Perez wanted to create ready-to-use labs running Arista cEOS on containerlab. Requiring the users of his labs to deploy netsim-tools and Ansible just to configure the lab devices is a clear overkill considering the startup-config support in containerlab. What he needed was:
One of ipSpace.net subscribers sent me the following feedback on Ansible for Networking Engineers webinar:
The “Ansible for Network Engineers” webinar is of the highest caliber. I’ve taken Ansible courses with your CCIE peers, and though they are good, I objectively feel, that I get more of a total comprehensive understanding with network automation here at ipSpace. Also, I enjoy your professional care-free tone, and how you pepper humor into the subject matter.
I’ve setup a virtual lab with Ubuntu 18.04 LTS server, and am using both Aruba and Cisco switches/routers. Ansible has lots of nuances that will take me time to fully get a grip-on– but, that’s why I subscribe with the network pros like ipSpace.
netsim-tools release 1.1.3 brings a number of goodies, including:
- OSPFv3 support on a few platforms (we’re still looking for contributors to implement OSPFv3 on other platforms)
- EIGRP implementation of common routing protocol features (router ID, passive and external interfaces)
- Configurable address family support for IS-IS, OSPF and EIGRP
- Support for /31 IPv4 P2P links
- Configurable MTU for VyOS and RouterOS
If you’re building your own libvirt boxes, you might also appreciate:
Every other blue moon I get a question along the lines of “how could I contribute to netsim-tools”. The process is pretty streamlined and reasonably (I hope) documented in Contributor Guidelines; if you want to get started with an easy task, try implementing OSPFv3 for one of almost a dozen devices (vSRX implementation by Stefano Sasso is a picture-perfect example):
If you’re brand-new to Python and Ansible, you might be a bit reluctant to install a bunch of packages and Ansible collections on your production laptop to start building your automation skills. The usual recommendation I make to get past that hurdle is to create a Ubuntu virtual machine that can be destroyed every time to mess it up.
Creating a virtual machine is trivial on Linux and MacOS with Intel CPU (install VirtualBox and Vagrant). The same toolset no longer works on newer Macs with M1 CPU (VMware Fusion is in tech preview, so we’re getting there), but there’s an amazingly simple alternative: Multipass by Canonical.
A long-time subscriber with a knack for telling me precisely why something I’m doing sucks big time sent me his opinion on netsim-tools installation instructions:
I do not want to say it is impossible to follow your instruction but I wonder why the process is not clearly defined for someone not deeply involved in such tasks with full understanding of why to install from github, etc..
Many guys do not know if they want to use libvirt. They want to use the tool simple way without studying upfront what the libvirt is - but they see libvirt WARNING - should we install libvirt then or skip the installation?. But stop, this step of libvirt installation is obligatory in the 2nd Ubuntu section. So why the libvirt warning earlier?
I believe we should start really quickly to enjoy the tool before we reject it for “complexity”. Time To Play matters. Otherwise you are tired trying to understand the process before you check if this tool is right for you.
He was absolutely right – it was time to overhaul the “organically grown” installation instructions and make them goal-focused and structured. For those of you who want to see the big picture first, I also added numerous (hopefully helpful) diagrams. The new documentation is already online, and I’d love to hear your feedback. Thank you!
Julio Perez wrote a wonderful blog post describing how he combined netsim-tools and containerlab to build Arista cEOS labs.
Hint: when you’re done with that blog post, keep reading and add his blog to your RSS feed – he wrote some great stuff in the past.
A few weeks ago, Nick Buraglio and Chris Cummings invited me for an hour-long chat about netsim-tools on the Modem Podcast.
We talked about why one might want to use netsim-tools instead of another lab orchestration solution and the high-level functionality offered by the tool. Nick particularly loved its IPAM features which got so extensive in the meantime that I had to write a full-blown addressing tutorial. But there’s so much more: you can also get a fully configured OSPFv2, OSPFv3, EIGRP, IS-IS, SRv6, or BGP lab built from more than a dozen different devices. In short (as Nick and Chris said): you can use netsim-tools to make labbing less miserable.
One of the toughest hurdles to overcome when building your own virtual networking lab is the slog of downloading VM images for your favorite network devices and building Vagrant boxes1 in case you want to use them with Vagrant or netsim-tools.
You can find box-building recipes on the Internet – codingpackets.com has a dozen of them – but they tend to be a bit convoluted and a smidge hard-to-follow the first time you’re trying to build the boxes (trust me, I’ve been there).
Remington Loose sent me an interesting email describing his views on the right approach to network automation after reading my Network Reliability Engineering Should Be More than Software or Automation rant – he’s advocating standardizing network services and cleaning up your network before trying to deploy full-scale automation.
I think you are 100% right to start with a thorough cleanup before automation. Garbage in, garbage out. It is also the case that all that inconsistency and differentiation makes for complexity in automation (as well as general operations) that makes it harder to gain traction.