Apstra Blog

Network, Redux

Updated Jul 30, 2016

Over the last couple of decades I’ve used or evaluated a lot of network related software tools. These included commercial products, open source projects, and language libraries. Ask any network engineer that’s been around for more than a few minutes and they would all agree: The vast majority of these tools haven’t been very useful to network engineers. This commonly understood fact has led many network engineers to be deeply cynical about such tooling.

“No tools for you!”

A few years ago I gave in to the “dark side” and started working for companies that build network related products. Since then I’ve gathered some insights into why software tools for network engineers are traditionally so awful. Let’s talk about these.

SDN has been focused on “revenue-generation,” not solving network engineers’ problems. These tools were built for and marketed to service-providers (telco, cloud, or otherwise) to help them deliver new revenue-generating services faster.

Many tools in the last two decades weren’t designed by people who understand network engineers and so both core features and the user-interface were severely lacking. Expensive QoS monitoring tools produced aesthetically beautiful, but ultimately pointless representations of network statistics. Network mapping tools that support a limited range of vendors produced “close enough” topology visualizations that were only occasionally displayed on a screen, for aesthetic reasons.

Many tools were designed, by people who never actually ran a network, to insert change management controls in the operational chain. These tools were actually designed to be an obstacle and as soon as that obstacle became a problem, a “workaround” or “backdoor” would be introduced and invariably everybody bypassed the use of these tools so they could just get stuff done.

Many tools were developed as an afterthought to increase pull-through of other products, such as network hardware.

Some SDN tools were even marketed as ways to eliminate or get around network engineers!

I could go on, but there is one dominating trait that all these tools share: They weren’t “for” network engineers. None of these tools were built with the aim of empowering them by solving their problems. They share other traits as well, such as having limited applicability with respect to the entire engineering lifecycle. Most of the time, they had limited applicability even within one stage of the lifecycle!

The Tediousness of Data

So what are a network engineer’s problems? Network Engineers are first and foremost data mungers. At every lifecycle stage we go through a tedious, error-prone process of gathering and analyzing data so that we can make the right decisions.

Do you want to design a network with one vendor for the leaves and another for the spine? Which models do you use? How should you cable it to account for different failure domains on various device models? What are the configuration limits for various features? What will the configs look like? What are the “gotchas?” There are many questions that need to be asked, and before you can recommend a design, you’ll need to engage multiple sales teams separate from each other just to get these questions answered. There will be proof-of-concept labs and many arguments about why you’re not going all-in on a single vendor. Operations folk will need training, most of the time very expensive, before they can even log into a box to see if an interface is up or down.

Once you have your design, then what? Well you’ll need to produce cabling instructions, translating from your design into a spreadsheet with mappings from each device’s ports to other devices’ ports. Then you need to verify by hand that things are cabled correctly. Even if you write a script yourself to assist, it won’t catch partial failures. This can be especially painful for network cutovers! How about getting the right OS, firmware, and config to each device? How about sacrificing another however many hours of your life shuffling devices that are louder than jet engines, plugging into console ports and getting everything prepped for racking.

So now the network is designed and deployed, what is the total expected state across the network that reflects its correct operation? How do you know when the actual state no longer reflects this? Even with modern tooling, we only get tiny clues that must be evaluated in context in order to figure out what is going on. We dig rabbit holes, one after another until we have an understanding of why something is wonky. Even the most seasoned network engineer can go in the wrong direction, only to be surprised when they find out their working theory was off the mark.

Throughout the entire engineering lifecycle, we collect and munge data. We make mistakes. We endure enormous stress. We even miss family events like our children’s birthdays! We spend weekends and late nights dealing with bugs, caveats, and poorly documented features. We network engineers are a special kind of animal. In spite of not having good tools, and working in an industry that seems to ignore its own users, we toil away for the love of making packets go on the “thing” that is the very heart of our organization’s infrastructure: The network.

Apstra: Tools for Network Engineers

Apstra was founded to build tools for network engineers that empower them and solve their problems throughout the entire engineering lifecycle. Tools that deal with the tedious parts of harvesting and munging all that data.

With AOS, our distributed network operating system, you can design a vendor agnostic network, with diagrams, cabling spreadsheets, IP address plans, and working configurations in a matter of minutes. Want to compare what that config would look like if it were a different vendor? Do it. Want to test that design out with virtual devices in a virtual topology? Do it!

When deploying your network, AOS will tell you if something is wrong, such as cabling or other issues on-the-fly in an easily understood visual format. Don’t worry about getting the right software, firmware, and configs on the boxes, either, we have tools that do that automatically!

AOS understands how you intend the network to operate as a whole, and even after the network is deployed, it’ll continue to monitor the state of the entire network across all layers to ensure it is operating as expected. From here, AOS makes it easy to add, remove, or upgrade devices in your network. You can even swap a switch from vendor “a” with a switch from vendor “b” without ever touching the CLI, in a matter of minutes!

Did I mention AOS gets streaming events and telemetry from the network devices themselves? No polling! I’ll get the gasoline, let’s set SNMP on fire together.

AOS isn’t the only tool in your box, either! We have more tools to ease deployment and on-going operations including integrations with stuff like Grafana or your favorite IPAM solution.

“Let them a journey new begin…”

Join us on this journey as we redefine what it means to create tools that help people design, build, and operate networks. Tools designed to be consumed the way you want to consume them, to solve your problems. Tools designed by network engineers, for network engineers. Even reluctant “surprise, you’re the network engineer now!” engineers!

Want to learn more about the awesome stuff Apstra is doing? Grab a cup of coffee and watch our webinar video

Now I gotta get back to some bit-wrangling… talk to you soon!

Follow Apstra

Follow Apstra


Subscribe to Email Updates


The Journey Towards Self-Operating Networks






Share this Post