Tag: network automation

One API to rule them all, and in the ether(net) bind them

While some APIs are more open than others, and some APIs are better documented than others (god bless ’em), APIs prevail. From basic network infrastructure elements to all the complex applications flowing across them, just about everything we deal with today in IT has an API. Pretty sure even that new fridge @netmanchris bought has an API. 😉

The sheer quantity and diversity among these APIs presents network engineers, who are just starting to get a handle on automation, with the additional challenge of wrangling umpteen different versions of APIs into cohesive, scalable, and maintainable processes that don’t make them hate their lives on a daily basis.

So what better to way to corral your herd of APIs than with another API?  To quote @scottm32768 in this grand networking quest, “One API to rule them all, and in the ether(net) bind them.”

Or to put it another way:

As an orchestrator of orchestrators, that’s where Itential comes in.  Their architecture takes modern API and abstraction focused principles, and leverages them toward solving this problem of API overload. All while providing a platform which itself is API accessible and automation ready.

Using adapters that consume and abstract the various input APIs of your multi vendor network, Itential provides a platform that allows you to build for various systems all in one place.  Sounds suspiciously like that single pain, err pane, of glass we’ve all been promised for years. So what’s going on under the hood?

Itential’s adapters are reaching into disparate systems, consolidating the data, and then normalizing it into a JSON schema.  The broker layer above the adapter layer performs the real magic by transforming the desired state configuration changes you want into the what each system needs to be told to do to make it happen.

Need to change a VLAN across a multi vendor environment?  No problem.  Need to validate similar configuration elements across multiple systems, each with the data accessible in a different format? No problem. Use Itential’s Automation Studio and Configuration Manager to design your workflows and manage your configuration changes. Then let Itential’s broker layer translate, while its adapter layer makes it happen.

What if you’re further along than most in the automation game and are sitting on a repository of your own network automation scripts? One, you get a cookie. Two, Itential allows you to bring those into the platform as well using their Automation Gateway.

The Automation Gateway also serves in cases where the vendor of your choice isn’t on the adapter list yet, but you still want some level of centralized automation.

If this commander of API armies, this chieftain of your automation islands, peaks your interest, I recommend checking out Itential’s fantastic Networking Field Day 21 video here that details the platform architecture along with an excellent demo (demo starts at 14 min mark). Also, be sure to check out their developer tool website, which has lots of great links and FAQs, and their additional NFD21 videos as well.

 

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/20/2019

 

Getting to know Cisco ACI…

Watching Cisco present on ACI at Networking Field Day 8 was a nice expansion to the introduction I received on the product almost a year ago at the ACI launch event in New York.  Now that APIC is shipping, companies can swap over from NX-OS mode to ACI mode and start playing with the magic that is application network profiles.

The basic components of ACI are the fashionable spine/leaf architecture that is all the rage these days, an APIC controller talking OpFlex southbound, and a switch operating system on Nexus 9Ks that interprets policy and forces it down to the endpoints.  Underneath the covers, each switch uses ISIS to build a routed topology from any VTEP (virtual tunnel endpoint) to any VTEP (basically from any leaf to any leaf). Rather than the controller programming routes and handling traffic forwarding, the controller focuses on pushing down policies that are understood and then implemented by the switches.

The concept of a self provisioning network also comes into play with the ACI solution, as does the concept of one big fabric to rule them all. The fabric can be zero touch provisioned, with the controller finding new switches brought online. The controller also acts as a single point of policy provisioning – the fabric itself scaling up to 12 spines, with multiple active controllers all sharing data for redundancy.

The heart of ACI really lies with the policy model and associated concepts.  ACI works by putting things into groups – usually done with identifiers like vlan/vxlan ID, subnet, 802.1q tag, or by physical/virtual port – and then these groups are assigned policy contracts which basically “turn on” connectivity between these groups, according to the rules of the policy assigned. The level of abstraction inherent in these contracts lend themselves well to automation and consistency in network policies, as well as allowing for a clean up process as applications are removed – therefore solving some of the what-the-heck-was-this-thing-nobody-remembers problems we engineers often encounter.

Application network profiles can be home brewed as well as provided in the form of device packages from vendors.  These device packages will automagically roll out the best practices for the application at hand, and if they are from an official partner, TAC will even handle support issues that arise from using the package. As Joe Onisick put it, “think of it as an automatically deployed Cisco validated design.”

There’s much more covered in the Networking Field Day 8 presentations, including service graphs – think service chaining but with flexibility for differing behaviors for various traffic groups, an API inspector that allows you to see the API code as you make calls through the GUI so you can create automation scripts from it, and atomic counters which allow for detailed health scores and packet tracking, but as I’m a sucker for a good demo, I’ll leave you with this, Paul Lesiak showing off APIC’s mad programmability skillz.

 

Published: 10/14/2014

For more links to ACI resources, you can check out my previous post, check out some excellent videos by both Lilian Quan and Joe Onisick on the subject (just go to youtube and seach for Cisco ACI), or check out Lauren Malhoit’s blog where there’s some good posts on getting to know ACI as welll.

Also, mucho bonus points to Lauren for not only being generally awesome all the time, but for also providing this ginger with a desperately needed Diet Coke as a caffeine source at this 8am presentation, an un-caffeinated ginger is a scary, scary thing.

Disclaimer: While Networking Field Day, which is sponsored by the companies that present, was very generous to invite me to this fantastic 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.