I keep getting questions along the lines of “is network automation practical/a reality?” with arguments like:

Many do not see a value and are OK with just a configuration manager such as Arista CVP (CloudVision Portal) and Cisco DNA.

Configuration consistently is a huge win regardless of how you implement it (it’s perfectly fine if the tools your vendor providers work for you). It prevents opportunistic consistency, as Antti Ristimäki succinctly explained:

Without automation it would be also very difficult to enforce the desired configurations and would result in an opportunistic network where certain configurations are only applied if an engineer has remembered to, or cared to, configure them.

Having your network described as a set of well-defined parameters (aka Source of Truth) instead of device configurations scattered all over the globe is another huge win, so it’s no surprise that a lot of engineers include these concepts in their new projects. Here’s what Gaël Garcin recently sent me:

---

In my last project I implemented a new leaf and spine 100G Arista fabric with BGP-EVPN for our core network. After having learned how it works, I have also found Arista’s Ansible libraries to do a very clean job.

The result now is a 100% infrastructure-as-code core network, all starting from inventory files which generate all the fabric links and tenant configuration. The full router configurations are generated at each run and then pushed to Arista CVP which then does the change management, in particular with a “diff” print so we can see exactly what will be added or removed when we apply the change in production. It is a complete new way of working but so interesting! And I really don’t see a better time to do this change: it allows you to start slowly and migrate the production step by step while you get used to this new environment.

---

In a nutshell:

• Create a machine-readable high-level description of your network. It doesn’t matter (initially) if you use text files or something more complex;
• Create consistent device configuration templates, and use them as the sole means of creating device configuration (don’t forget to consider how to implement the Big Red Button)
• Use whatever workflow works for you to deploy the configurations
• Squeeze the most out of the vendor-supplied tools, but don’t be limited by their functionality.

Want to know more? Start exploring the automation webinars.