Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

9 module online course

Start now!
back to overview

Creating Automation Source-of-Truth from Device Configurations

Remember the previous blog post in this sequence in which I explained the need for single source-of-truth used in your network automation solution? No? Please read it first ;)

Ready for the next step? Assuming your sole source-of-truth is the actual device configuration, is there a magic mechanism we can use to transform it into something we could use in network automation?

TL&DR: No.

I’ve seen tons of solutions (several of them available on GitHub) that tried to solve the problem once-and-for-all by parsing device configuration and extracting relevant bits from it. The first step of this idea works great for devices that can produce device configuration in machine-parseable format like JSON or XML (Junos, late IOS XE…); if you’re not so lucky you’ll have to write your own parser.

You might use one of the published solutions as a starting point, but you’ll probably have to adapt it anyway as nobody wasted their time implementing the parser for all the weird nerd knobs that someone in their infinite wisdom decided to use in your network.

OK, so now you have the relevant bits of information extracted from network devices. What’s next? This is where this approach becomes complicated. You might decide what you got is good enough for your needs and dump the collected information into YAML or JSON files (one per device). Congratulations, you replaced text device configuration with even-less-readable representation of what the device should be doing.

This approach might be perfectly viable if you have to replace platform A with platform B (example: migrating from IOS XE to Junos) assuming platform B has a superset of functionality used on platform A. I know of large organizations that decided it’s worth the effort to automate configuration translation. However, while they executed the transition flawlessly, it didn’t bring them any closer to having the network automated.

What we’re aiming for in a decent network automation solution is more than just device state in machine-readable format. In the ideal world, we’d like to have infrastructure- or service description in a high-level data model that ignores the irrelevant details. For example, instead of interface IP addresses and OSPF costs, we’d like to know about network nodes and links, and have IP subnets and routing protocol parameters derived automatically.

Having that goal in mind, the only way forward is to:

  • Take the parameters extracted from network devices and reverse-engineer the desired data model from those parameters (for example, having an interface in OSPF area 0 might indicate that the interface is a core link);
  • Recreate device configurations from the data model and standardized templates;
  • Compare desired device configuration with current device configuration;
  • Clean up the snowflake device configurations or enhance the data model and configuration templates until the two are in sync.
There are tools on the market (example: Cisco NSO) that can do most of the job for you. However, don’t expect them to be simple or cheap.

Is it worth the effort? After dealing with device configurations for ages and having seen the benefits of easy-to-generate standardized configurations I’d say the answer is a resounding YES, but it’s hard to believe me while standing in front of the Broccoli Forest of Despair.

Want to try? Need help along the way? Hundreds of your peers enjoyed our Building Network Automation Solutions course.

Please read our Blog Commenting Policy before writing a comment.

1 comment:

  1. Are there good open source models out there today? Does openconfig work?

    ReplyDelete

Constructive courteous comments are most welcome. Anonymous trolling will be removed with prejudice.

Sidebar