Square empowers growing restaurants and Airbnb simplifies split payments.
Here’s your weekly news roundup!
A recurring theme we hear from our customers is how they want to reduce the kind of errors that come with manually configuring their networks using the device CLI. From one device to the next, every command entered represents a potential outage. Indeed, upwards of 80% of network outages are caused by changes made at the device level via the CLI. The Apstra Operating System (AOS) can help reduce change-related outages by semantically validating changes before they are committed to the network.
Like many network engineers, I have been the cause of large scale outages. Even outages that made the newspaper. If there’s one thing I have learned over the years, it’s that networks are fragile. Worse, the devices that we use to build networks are also fragile. It’s no secret that the network operating systems (NOS) that drive these devices are usually riddled with bugs. If you want to see a network engineer get sweaty, just tell him or her to upgrade the NOS in the network. Finding a stable NOS that supports your needs can be a stressful, outage inducing event.
Bugs aside, as network engineers we have to keep an awful lot of stuff in our head in order to successfully execute a change. We have mental models of how the network is now, how the network will be, and any intermediate phases in between. If our models are flawed in any way, or we just make a typo, we could cause an outage.
Personally, I’ve gotten to the point where there are only two possible outcomes when I press the enter key: (1) The network works is as expected or (2) The network explodes. Even though I know there are states in between, I have been well seasoned to expect the worst as my right pinky finger descends upon the enter key. It’s almost as if it has an evil mind all it’s own, just waiting for the right time to strike.
AOS to the rescue!
AOS is an intent-based distributed operating system. With AOS, your network is modeled from a reference design. This design has rules against which changes in the network can be validated before they are committed.
The reference design requires specific features from the various NOS’s that run on network devices. During development, AOS is tested against various NOS releases to validate that the network will remain stable and operate as expected across the engineering lifecycle.
Lastly, AOS supports Role-Based Access-Control (RBAC) for the various activities it supports. From network design to operations, you can control the way users interact with AOS. Contrast this with the blanket “enable” or “configure” mode that most organizations default to on the device CLI, giving unlimited access to the engineers making changes to those devices.
Take the Next Step
There’s no question that the future of network implementation and operations will gravitate away from device-level CLI and the risk that comes with it. Engineers will interface with the network at a higher, more intuitive level to achieve the outcomes that match their intent. Apstra is leading the way on this journey.
To start your own journey, reach out to us today and schedule a demo so you can see for yourself what intent-based networking can do to help network engineers make better, more informed decisions in their day-to-day operations.
Click the related links to learn more about Apstra and AOS!
Apstra Operating System (AOS™) offers a great deal of flexibility when designing a network. When using Apstra’s flagship L3 Clos app, or leveraging AOS’s unparalleled extensibility features, network designers have a great deal of power at their fingertips. AOS allows network designers to customize their network for their business needs without sacrificing manageability. Are you a network designer? Let’s find out what Apstra can do for you!
Degrees of Freedom
Network designs are made up of simple yet powerful patterns offering a great deal of flexibility. AOS is a platform to express those patterns in what we call ‘reference designs.’ A reference design is the heart of an AOS application. In AOS’s L3 Clos data center app, there are two main network device roles: “spine” and “leaf.” Within a single L3 Clos, each leaf is connected to every spine. From this idiom, many different networks can be designed, deployed, and operated with AOS. Network designers have many degrees of freedom to help them build the network that is right for their business.
AOS allows you to customize the patterns for your specific business needs.
Of course, you can specify the number of spines and the number of leaves. However, beyond this you can also be very specific about the number of uplinks and their speeds. Further, in AOS you can create different types of racks and deploy networks that contain a mix of these types. Each rack type can be customized to support one or more leaves in the rack, with a specific number of uplinks and uplink speeds. Also, you can connect your network to the rest of the world via the spine, or via the leaves.
For hosts connected to the edge of the network, you can connect them to one or more leaves. You can connect them via layer 2, or via layer 3 running routing on the host. Further, you can establish multiple layer 2 (VXLAN) across racks to establish connectivity between groups of hosts.
A number of common host connectivity options are available in AOS.
Lastly, as always, AOS allows you to do all of this in a vendor-agnostic way. You can use whatever vendor and whatever device models you like to make these network designs real.
All of these degrees of freedom in your design are available independent of each other, which means you can customize your network in practically infinite ways. No matter what design you come up with using this palette, AOS will provide the same unmatched level of automation and validation that our users expect from it.
What if you need more from AOS, though? You might need specific telemetry, specific hardware support not available out of the box, or you might need other fundamental design idioms. AOS can be extended a number of ways to support all of this. In fact, there are development tools in AOS to help people with software development skills build and test such extensions.
We won’t cover extensibility too much in this post, as there will be a lot said about it in upcoming posts. Just know that extensibility is extremely important in AOS, and Apstra is committing the resources to it to make our platform the go-to platform for NetOps- and DevOps-minded folk.
Conclusion As you can see, AOS does indeed provide an enormous amount of flexibility to you, the Network Designer. Whatever your goals, AOS can put you on the path to accomplishing them. Want to find out more? Download the
AOS Architecture Overview white paper and the
AOS 2.0 Data Sheet. Finally, reach out today and
schedule a demo so you can see for yourself all of this in action!