The Problem: Network-Blindness

Derick Winkworth (@CloudToad) and Jeremy Schulman (@nwkautomaniac) gave an interesting presentation exploring the nature of a network as a single logical construct rather than individual pieces of hardware. Derick started off by describing a condition called “face-blindness.” Those suffering from face-blindness have difficulty organizing the images of facial features into an entire face. They can see the individual components, but they can’t see the logical construct the arrangement of these images creates – a face.

He explained that some see the network in the same way, calling the phenomenon “network-blindness.” In other words, the network doesn’t exist in and of itself; it’s actually an ideal state that exists in our minds. A network is a logical construction of various components such as cables, hardware, and configurations, and we expect it to behave a certain way. Unfortunately, those suffering from network-blindness aren’t always aware of the network as a logical whole and instead focus on its individual components.

This may sound esoteric, but it makes sense to me, and I feel it’s important to flesh this out because it forms the foundation of what Apstra is doing. What Derick focused on was context, and I really enjoyed hearing a fellow networking geek think about networks this way. Think of it like this: alone, each individual router, switch, cable, and line of code is not a network. However, each component is part and parcel of the greater context of the network in which it participates.

He elaborated by saying that many large networks are so complex that it’s just too difficult for an engineer to have an accurate big picture. I know from experience that Derick is right about that. Networking folks really do get lost in the weeds configuring devices and features in one small part of the network and [unintentionally] forget the big picture. We want to maintain the vision of the big picture, but it’s hard to do that when troubleshooting why DSCP markings aren’t treated properly on some switch somewhere.

Jeremy explained that Day 2 troubleshooting is probably 70% of the problem with networks. Almost immediately after an initial install, the network is going to be different than the original design. How does an engineer know the true state of the network at any given time? And probably more importantly, how does the current state differ from the expected state?

The Cure: Situational Awareness

From a technological perspective, the Apstra Operating System maintains what Jeremy Schulman calls “situational awareness.” This means AOS knows the big picture. It knows what the engineer expects of the network, so it can therefore detect when something isn’t right based on how the current state differs from expected state. What we expect from the network is the intent, and this is how Apstra cures network-blindness.

Under The Hood

Under the hood, AOS breaks up a particular service into its components with regard to configuration and expected state. AOS continually collects network state information, validates configuration, and ultimately performs device configuration.

The impression I got was that Apstra is taking the methods to create a programmable infrastructure that we’re already familiar with and packaging them into an extremely easy-to-use graphical user interface. Then AOS takes abstraction to the next level by providing all the built-in logic for the intent-engine. This is an overlay approach, not device-level programmability, and is what I feel SDN has been promising for years.

Picture a single piece of software that has all your Python scripts, Ansible playbooks and Chef cookbooks all rolled into one. In this case Chef is a good analogy because each network device needs an AOS agent installed in order to be managed.

Rather than use SNMP, AOS uses this agent-based method to collect network data, perform those often-forgotten validation checks, and configure devices. This is different than other vendors’ solutions because not only does AOS not use SNMP, but it’s also vendor agnostic.

During the first demo, Jeremy pointed out that the interface was so straightforward that a facilities person would be able to identify and fix a cabling problem in the data center. In the screenshot below, notice the two red cables and the alarms.

This means that AOS knows what the network is supposed to be like, and this is the context that Derick referred to. This implies there is either a large  number of build templates that comes with AOS, or I’ll be spending a lot of time configuring my own. Maybe I need to stop configuring snowflakes, but as the platform matures, I wonder how the AOS intent-engine will reconcile and validate built-in templates with custom configurations.

AOS also validates running configuration in even a multi-vendor network. That means the folks at Apstra built so much logic into their software that you can swap out switches from different vendors and AOS would find the diffs automatically applying the necessary changes to produce the intended state. That’s just amazing. Even if you’re a one-vendor-shop, this is still utterly amazing.

Take a look at the screenshot below. The validation process alone is huge and something I would require before even attempting to integrate AOS into my network.

AOS utilizes pools of built-in resources to build configurations based on the parameters a network engineer sets for a service. The system uses a series of config files using extendable Quagga and Jinja templates, for example. When a device enters inventory, information about the device is gathered in order to make it available for use as a resource. Currently, version 1.0 supports 26 platforms including hardware running Cisco NXOS, Arista EOS/vEOS, Cumulus Linux, and CVX.  Version 1.1 should be coming out very soon and support more platforms.

Minor Concerns

Something important to note is that the AOS configs are automatically generated using what Apstra considers best practice for a particular service. They determined these by speaking with the various networking vendors, but this does affect your ability to use certain proprietary features. Jeremy addressed this by explaining that AOS doesn’t really abstract device level mechanisms and instead abstracts entire network services comprised of smaller network services.

Therefore the abstraction AOS provides utilizes whatever features are available to compose the overall service regardless of the proprietary technologies involved. This means you get the base configurations that get the job done (provides a particular network service) and allows you to pursue DevOps goals around the edges.

I can’t imagine how much programming has to be built into the system in order to accommodate the many services and vendors used in today’s networks, which is why I’m not surprised to hear that the platform technology is currently focused mainly on layer 3 data center Clos designs.

To that end, Apstra embraces the open network-developer community and welcomes community development of software to interface with their APIs. This should expedite the development of the platform and its relevance in actual production networks. I assume we’ll see a lot of third-party integration tools show up in time, so keep an eye on their GitHub page for more details.

I do wonder if relying on AOS build templates will be OK with higher level network engineers designing and building large data centers. I want to feel comfortable with that, but I admit that I’d probably feel compelled to scroll through all the configs myself after AOS did its magic.

So far, AOS is geared mainly for the data center, which I completely understand, but it’s also a sign of the platform’s immaturity. I don’t mean that to be negative; in fact, Jeremy explained that “the platform technology of AOS is adaptable for just about any kind of network application you want to use.” I have to assume that as AOS evolves beyond version 1.0, its relevance to the campus, WAN, etc. will also be developed and evolve. Apstra’s goal is to follow the example of the server world from years ago when hardware and software was decoupled giving engineers incredible choice and control over the infrastructure.

—

There are networking vendors that have a slick GUI to manage piles of their switches, but AOS is vendor agnostic, community-focused, and intent-driven. These are major differentiators and not trivial whatsoever.

I don’t know too much about the business side of things, and I know that companies are bought and sold regularly in Silicon Valley. But from a technical perspective, the logical conclusion of what Apstra is doing is incredibly compelling. In the near term, this will change data center networking. In the long-term, this will revolutionize the way we look at networking altogether.

Pay attention for their next release coming soon.

Managing the WAN through software means that serious intelligence can be added to path selection and link aggregation more than “legacy” routers have been able to do thus far. This also allows various devices such as routers, optimization appliances, and firewalls to be rolled into one device. A huge benefit is also the incredible cost savings a company can realize when eliminating expensive private MPLS circuits by aggregating inexpensive public internet circuits.

VeloCloud, a well-known name in the SD-WAN space, will be one of the presenting companies at Networking Field Day 13.  I’ve heard of VeloCloud before, but I’ve never really dug into what they do much until recently. I’ve been looking at SD-WAN solutions for my day job and am very interested in how they do per packet and per flow load balancing across several aggregated WAN links. How do they provide a similar performance and end-user experience load balancing an application over both broadband and LTE links, for example?

The real goal here is to provide private circuit reliability, security, and performance for applications running over the public internet. VeloCloud does that using what they call “dynamic multi-path optimization” along with a proprietary form of link and path monitoring to check for bandwidth, quality, and reliability issues.

I have recent production experience with a different SD-WAN company that provides a similar solution, so I have a particular interest in what differentiates VeloCloud. I’d like to hear more specifically about their pay-as-you-go model because I know from experience that enterprises don’t normally migrate a global network in one big cutover. Starting small, maybe just a few branch offices, is how multi-site organizations are moving from a traditional WAN to an SD-WAN solution.

Reading through their website, I learned a little bit about their appliance, the VeloCloud Edge, that can be deployed very quickly at a branch office by pretty much anyone who knows how to plug in a cable. This is expected, so I’d like to hear more about their cloud network of distributed gateways. I think I understand what they’re doing, but I’m really not 100% sure based on what I’ve read online. Maybe that doesn’t really matter, but I think when looking at what’s going on in the backhaul of various SD-WAN solutions we can identify those indicators that differentiate one SD-WAN company from another.

This is really cool stuff to me, but what I really like is how SD-WAN is relevant today. I’m looking forward to meeting the folks at VeloCloud next week and hearing more about how they make the magic happen.

I’m particularly interested in Apstra’s presentation on Thursday afternoon. I recently wrote an article about intent-driven networking, something of particular interest to me, so I’m really interested to hear what they have to say about their platform, the Apstra Operating System, or AOS.

Intent-driven networking is concerned with telling the network what you want it to do rather than how to configure services device by device. This is another level of network programmability but with more intelligence than simply device provisioning. Apstra boasts the ability to eliminate many of the repetitive configuration tasks common among various networking operating systems by providing programming to automate intent expressions made by a network engineer. AOS is then vendor agnostic and focused on the end-to-end network service rather than micro-configurations.

Apstra explains that AOS is not opinionated, or in other words, network engineers can still insert their intelligence into design and configuration. I’m very interested to hear more about their distributed intelligence model using agents on network devices interacting with a logically unified data repository. That sounds pretty cool, and I’d like to know more about how specifically the network can adjust itself during production without human intervention. They also seem to be completely data center focused, which is fine, but I am curious to hear about their plans for campus, WAN, and firewall implementations.

I agree with Ethan Banks who in a Packet Pushers podcast with Apstra said that intent-driven networking is sort of what we all thought SDN was going to be. This is why I also think we should all pay attention to what Apstra and other similar companies are doing in this space.

I’m a fan of Star Trek, and I love how Lt. Commander Geordi LaForge tells the U.S.S. Enterprise computers what to do with infrastructure pathways, and the computer just does it. I’m really interested to see where intent-driven networking takes us in the coming years.

Amidst discussion of SDN ambiguity at Networking Field Day 11, SD-WAN stood apart as something we understood, and I think that’s because we understood its use case very well.

Most of us in the room during Silver Peak’s presentation were network engineers building high quality, fault tolerant networks, and we were familiar with the pain SD-WAN seeks to address.

As a brief overview, Software Defined WAN reduces the complexity and improves the performance of the WAN edge by adding optimization, automation and measurement-based exterior routing.  This approach offers fault tolerance for all types of failures from the link itself through the public cloud. This means that the complexity associated with current technologies such as DMVPN, IP SLA, and PfR is largely eliminated.  This also means that a type of QoS can be delivered even on public WAN links.  And this means significant cost savings by eliminating expensive private MPLS links. Several vendors are already doing this, so the technology isn’t brand new. I wasn’t necessarily skeptical walking into Silver Peak’s offices, but I wasn’t expecting anything groundbreaking.

Their presentation was very compelling, though, and I was impressed with David Hughes’ ability to jump in, as Founder and CEO, and dig into the technology. He explained that the impetus to move to SD-WAN is the shift to cloud applications, and that their product delivers applications with high quality over whatever connectivity the user chooses. He also explained that their solution meets a specific use case: “to connect users to applications much more easily, efficiently and cost-effectively.” In David’s words, Silver Peak’s technology is more about “providing an overlay over whatever underlying technology you want to use for your connectivity…and making that overlay really easy to manage and deploy.” Flexibility and ease of use seem to be key to Silver Peak, which is, of course, a good thing.

Damon Enniss, Senior VP of Products, presented their Unity EdgeConnect  solution to easily harden the WAN edge and deliver path conditioning, latency mitigation and increased reliability. I’ve struggled with providing this level of cost-effective optimization and fault tolerance to the WAN edge. Especially in the small to medium sized business space, organizations can’t always afford the hardware or skillset to implement the design they need. Though their requirement for uptime and a quality connection is no less important, the cost can be prohibitive.

Silver Peak did a great job, but then again I’m already excited about this technology.  Zero-touch provisioning for highly resilient WAN edge devices? Sign me up! It makes sense, especially in the SMB space, because there’s an actual business use case for this.

The most compelling value proposition to me is that using this technology means I can get rid of all my private connections. I want to ditch my expensive private MPLS link and have a pair (or three) of public internet connections. My MPLS links can cost thousands of dollars per month each. Silver Peak says they can deliver performance, quality and resiliency and cut costs up to 90%, so the real value proposition is going with all public connections. Damon mentioned that only in passing, but I think it’s the most compelling reason to go SD-WAN with Silver Peak.

Over the last few years I’ve noticed ISPs improving their service delivery, and even though I still tease about Time Warner Cable going out when it rains, business internet connectivity has increased in quality and bandwidth and decreased in cost. There are parts of the country and world where internet connectivity is still very poor, but in the northeast where I live, I can run voice over the internet today when I wouldn’t dare 5 years ago.

I want to drop the hybrid solution and go SD-WAN with all public internet links. Cheaper, easier to deploy, and easier to switch ISPs if I want. To me that’s the real value of SD-WAN. Silver Peak didn’t make that specific case very strongly, and I think they should have. An organization may require a hybrid model for some particular reason, and I understand that. But by and large, Silver Peak’s technology can provide to even the smallest customer private line performance and reliability cheaper with public internet connections only. Win.

[Follow up edit: I believe my opinion that Silver Peak didn’t focus enough on an enterprise going all public internet links was based on a misguided  first impression. Over the last five weeks I’ve looked into Silver Peak’s public literature and kept an eye on their tweets. They are absolutely positioning Unity EdgeConnect to replace private MPLS links much more than I thought.]   

Disclaimer

I attended a Silver Peak presentation as an invited delegate to Network Field Day 11. The sponsors pay to present to the NFD delegates, and in turn that money funds my transport and accommodation while I am there. That said, I don’t get paid anything to be there, and I’m under no obligation to write anything, positive or negative, about any of the presenters.