Gain insights into automating network reconnaissance, orchestrating repetitive changes, and transforming network configuration management. Discover CI/CD pipeline migration for full network automation.

ansibleFinal1.tar.gz

gitjob

CIPhosts

CIPhosts-copy

gather_info

gather_important_facts

facts_to_md

facts_to_csv_html

tools

frr01

frr02

first_gather_important_facts

​​Network automation begins with automating network reconnaissance. This is accomplished by gathering important information from network devices while building a library of dynamic on-demand utilities and generating living documentation. Starting small, the course exhibits the simplicity and elegance of network automation.

Next, you will learn how to automate larger changes that require a high number of repetitive steps. These changes will be executed serially in a specific orchestrated order, making them perfect for an automated solution. After gaining comfort with the new tools, you can fully transform network configuration management to an automated, intent-based, self-documenting system.

The final step is learning how to migrate to a continuous integration/continuous delivery (CI/CD) pipeline, thereby fully automating the network.

Automate Your Network

# Operations
NetDevOps will dramatically change network operations' role in the
organization. A library of canned, automated, Ansible playbooks develops
over time. Automated builds and deployments will trigger whenever
approved changes are merged into the repository. Operations are often
tasked with running the network day-to-day, and incorporating and deploying
the changes coming from projects or network engineers. Operations will
now learn to develop and use code.

If the deployment, network reconnaissance, and documentation aspects of
operations are automated, the operations team can focus
on the day-to-day aspects of the network management alongside the new
automated tools that gather the information needed to run the
network. With that said, the network may still require an NMS
for platform health monitoring. 

This is because there may be network appliances or
controllers that are not good candidates for automation. Or, there may be
non-SSH systems on the network that are non-automatable using Ansible.

# Intent-based
The human-readable nature of this methodology allows for a true
intent-driven model of the network. The configurations are abstracted
into the templates, so the focus can be put on the data models. The intent for
each device or group of devices can be expressed in a human-readable
form. 

Idempotent Ansible playbooks- combined with the check mode- can tell
exactly if a device's running configuration matches the intent and if the
Ansible playbook would have added code. Utilizing the differential
option (`--diff`) allows the operator to see what differs between the
two configurations. It can also be displayed indicating any commands
present on the device but missing from intent.

New appliance-based solutions that offer a GUI-driven intent system are available. Drag-and-drop intentions in the GUI are translated to
configurations that are automatically pushed to the devices. These new
intent-based appliances are the biggest competitor to Ansible network
automation. Either purchase and configure the appliance, hoping it does
everything advertised, or build an in-house Ansible automation
framework.

# Source of truth
Every network should have an authoritative artifact identifying what is
the correct, intended configuration for each device. The source of truth is
a trusted artifact that network engineers and operators can reference
with certainty. This can be an IP address, a static route, an ACL, or
a configuration command. It can be required when designing new solutions,
adding new devices (scaling), troubleshooting problems, or rebuilding a
device after failure.

Where is the network's source of truth? Is it a network management
system? Flat files in folders in a network share? A Microsoft SharePoint
site? The network device running-configuration itself?

A living source of truth can exist using the new NDLC. It is a rich repository of data models, templates, and Ansible playbooks,
which also stores the compiled, intent-based, dynamically generated
configuration files for each device. This repository can be used
as a reference for all future network designs and troubleshooting. It can also be a single, central, RBAC-controlled, source of truth for the network. 

Source of truth means browsing for data models or templates that create
the configuration or the compiled output showing the exact device
configuration, without ever needing to connect to the device CLI. Other
artifacts such as the routing tables or firewall rule lists can also be
stored in the source of truth as output from dynamic playbooks. This is not something every network can produce. However, it is
indispensable when designing new features, planning future changes,
dealing with network failures, or troubleshooting problems.

Let's learn about intentions, source of truth, and how operations will be impacted by network automation.

Introduction

What Is Network Automation?

Why Automate the Network?

How to Automate the Network

Where to Start with Network Automation

Repository Structure

Network Reconnaissance

Tactical Playbooks

Data Models and Dynamic Templates

Dynamic Intent-Based Documentation

Configuration Management

Continuous Integration/Continuous Delivery

Conclusion

Operations, Intentions, and Source of Truth

Operations