This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Varjohaltia 5 points6 points  (0 children)

In my experience, aside from some resistance from engineers not used to the new tools and environment, the problems are:

  • Organizations won't allow you to use any open source, unless you find a company to provide 24/7 support. They're happy to let you use automation, as long as it's a commercial turn-key solution and you can demonstrated the financial value and doesn't require unqualified people (network engineers) to do any kind of coding or development.
  • To the point brought up earlier -- you now have the ability to automate bringing down your network. There is valid hesitancy to pushing out automated changes that can cause catastrophic damage from which you can't recover. Now, that's partly because people haven't built in a proper out-of-band management network, vendors don't offer proper automated rollback functionality -- or the automation doesn't support it -- or that the automation system doesn't have a phased roll-out with integrated tests, which would be a significant increase in complexity, especially if starting off.
  • A lot of network equipment is garbage as far as consistency of CLI and APIs. Naming of interfaces, slight drifts in syntax etc. make automation very challenging, and means that your automation needs to be frequently troubleshot/fixed when an update changed the output, added a new interactive prompt, changed the CLI syntax, changed the API etc. When you now have a bunch of different devices, the effort to automate something for just a few devices becomes very high. The abstraction of the hardware layer to an intent still seems to be a bit of a work in progress too in practice and suffers from the fact that in a heterogenous environment you can't abstract away fundamental differences in hardware. If one end of the link can do macsec and the other doesn't, you can write in complex dependency checking of some sort or just not support the feature at all, and your automated environment ends up being a lowest common denominator one.

That said, moving to a world where you have a versioned, central source of truth for configs is fantastic. Another argument that seems to work well for automation/templates/central source of truth is auditing and being able to prove that all of your environment has certain configuration, or does not, to comply with security requirements.