Network Automation Readiness Evaluation

Let's learn what features to consider and how to evaluate our network for automation readiness.

Evaluate network readiness

Before writing playbooks or creating data models, take time to evaluate the network for automation readiness. Automating a poorly designed network is a much more difficult task than automating a well-designed network. In fact, it might not be possible to fully automate a network that lacks basic standards. After all, a big step in network automation is full configuration management that leverages dynamic templates.

A network without basic standards cannot be templated. The ability to automatically gather information and run one-time tactical playbooks exists. However, full configuration management may be difficult to achieve.

Some items to consider when determining network readiness:

  • Campus design: core, distribution, access layers

  • Layer 1:

    • Physical connectivity

    • Standardized interfaces for uplinks

    • Connection type: Copper or fiber connection

    • Connection speeds

  • Layer 2/Layer 3:

    • Boundary at the distribution layer

    • Standard VLANs

    • IP address scheme

    • Established patterns for buildings/floors on the campus access

    • Summarized IP address spaces

    • Meaningful IP addresses

    • Some standards for point-to-point links, routers, and routing tables

  • Naming conventions

  • Standardized servers for NTP, DHCP, DNS, syslog, and SNMP

  • IOS versions

  • QoS models

  • Standard port configurations:

    • SVIs

    • Physical ports

    • Port-channels

    • Access ports

    • Trunk ports

  • Access port standards:

    • Data and voice VLANs

    • STP toolkit

    • QoS

    • 802.1x

    • Port description

    • PoE

  • Trunk port standards:

    • Native VLAN

    • VLAN list

    • Port description

Network reconnaissance

Ironically, the first automated task may be using Ansible to perform the network reconnaissance to prepare the network for Ansible.

At this point, confirm that all the architectural components are in place and able to communicate with each other. If not, work with the network operations team or server administrators to help finalize the environment.

A final checklist

Assuming you used TFS as your source control tool, the final checklist will look something like this:

  • Microsoft TFS Server:

    • Configured and licensed

    • RBAC in place

    • Repository created for the environment

    • Link to repository published

    • Able to communicate with Git on developers’ workstations

    • Able to communicate with Linux/Git on the host running Ansible

    • Certificates and PKI

  • Linux host:

    • Can reach network devices through SSH

    • Can reach TFS via 8080/8443

    • Ansible installed

    • Repository cloned locally from TFS

  • Network:

    • Service account created for Ansible playbooks to authenticate

    • Ansible playbooks have a method of authenticating