Network Field Day 21 – Amy Engineer

Large scale networks means large scale configuration and change management testing. Or at least it should.

But device expense, power costs, and space limitations mean full scale physical network labs don’t happen. We, the engineers, get to roll-out complex network changes based on limited tests and what we hope is a well thought out, bulletproof rollback plan. We often risk significant loss of revenue for the company and significant loss of sleep for ourselves if changes go poorly.

This is not just a big shops problem either. Even – or perhaps especially, small to medium enterprises lack full scale physical labs to simulate changes. I’ve known one engineer that used to have a Nexus 5K on his desk (I’m looking at you @that1guy_15), but most of us are lucky to have a few pieces of equipment to cobble together to give us the general gist of the impact of a potential network change.

With the cloud eating everything, it’s about time that it started giving back to engineers – and that is what Tesuto seeks to do. Tesuto leverages cloud to perform large scale emulation of networks, while allowing engineers to leverage modern automation tools and testing along the way.

Tesuto spins up emulation devices in Google Cloud or Digital Ocean, with support coming soon for Azure, AWS, and private cloud as well. These spun-up devices have full L2 connectivity with each other and are running the actual vendor images, giving engineers emulations that can accurate reflect control plane functionality for configuration and change testing at the scale your network demands.

It’s worth noting that if you want to test ASIC specific functionality or throughput testing, this is not the platform for those types of tests. Emulations are ideal for control plane and connectivity testing, such as making BGP routing changes and seeing what neighbor relationships you hosed up, but not so ideal for how many packets per second a device can spit out.

So why not use GNS3, which offers device emulation as well? Resource scale, ease of use, Rapid Initialization*, and the ability to tie into modern automation configuration and testing tools such as Ansible, NAPALM, etc…, are just a few reasons why cloudifying your network emulations with Tesuto starts to make sense.

Personally, I found the interface to be pretty intuitive, creating a few routers from different vendors, connecting them, and logging into the Tesuto provided jumpbox was quick and painless. Uploading licensed images for some vendors is required, so be prepared to BYOI (bring your own image).

The ability to run built in NAPALM validation tests takes a bit more finesse and experience, as does integrating Tesuto into your automated change management pipeline if you have one. With a bit of additional work, though, you can create your own validation tests, you are not limited to the built in tests or to NAPALM.

Tesuto brings a ton of additional features to network emulation, as you can see from the chart below. I recommend watching both NFD21 presentations, especially this demo in which a lot of questions you don’t even know you have yet are answered, and be sure to check out pricing information here for details on their pay as you go plan or monthly commit plan.

*Tesutos’s Rapid Initialization is a feature which significantly decreases boot time of the devices after first power on, so that MX router that takes 25 mins to boot the first time in an emulation takes only 5 mins on future boots.

Disclaimer: While Networking Field Day, which is sponsored by the companies that present, was very generous to invite me to the fantastic NFD21 event and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.

Published 10/13/2019

What’s a pirate’s favorite switching platform?

Arr-cus. 😂

And before I make a joke about networking ship-sets (too late), I’ll move onto what Arrcus is and why you should be checking them out!

Arrcus manufactures white box switches running ArcOS, their latest generation of switches leveraging the Jericho-2 chipset.

Touting a microservices architecture, multi-tenancy at scale, and open integration across multiple ODM vendors, ArcOS offers up a hardware agnostic platform that finds it home in data center fabrics, large scale peering/edge deployments, and cloud deployments.

With support for OpenConfig and YANG, Arrcus intends for users to leverage APIs for operations and management in modern fashion, no slumming it with old school CLI (although there is one should you choose to use it).

With claims of up to 100 million (that’s 100 meeeeellion) BGP paths and carrier grade class hardware, the OS also provides streamed telemetry data for multiple purposes, including monitoring device health and workload mobility. Arrcus also takes advantage of streaming telemetry in BGP route validation, comparing real time data with RPKI lookups and sending notifications to operators of potentially hijacked routes.

Support for BGP-LSVR is also part of the ArcOS platform. Which if you don’t live in carrier land, you might have just said “huh?” (because that’s what I said as well). BGP-LSVR is a IETF draft standard for augmenting BGP with Shortest Path Dijkstra algorithm behavior in an attempt to handle massively scaled out data centers and sneak around IGP flooding scale limitations. I know what you’re thinking:

But BGP-LSVR has the advantage of the underlay and overlay both being BGP, as well as improved convergence times. And possibly dinosaurs wreaking havoc on humanity, but we’ll save that for the sequel.

For more Arrcus goodness, I recommend watching the Network Field Day 21 Arrcus videos, especially the demo presentation below. I’ve also included some handy dandy research links for both Arrcus and BGP-LSVR if you’d like to learn more about either or both!