9 Network Automation Capstone

Design the automation workflow

A complete network automation workflow turns an approved change into a tested, auditable deployment and checks whether the network reaches its intended state. A campus VLAN rollout illustrates the approach, which also applies to interfaces, routing policy, access controls, and other network services.

Separate the workflow responsibilities

Intent and version control store the desired network design in reviewed files. The design can specify VLAN IDs, names, sites, and device groups; secrets should remain outside the repository.

Infrastructure as code (IaC) manages resources exposed by a supported provider, including controller-side objects when the provider supports them. Terraform follows a workflow of writing configuration, inspecting a proposed plan, and applying approved changes. Its state maps declared resources to real objects.

Network controller and APIs provide the deployment interface when a controller owns a network service. The controller translates service intent into device changes, and its APIs are often vendor-specific. At device level, NETCONF and RESTCONF provide model-driven interfaces: RESTCONF exposes YANG-modeled data using HTTP methods, while NETCONF provides RPC operations and configuration datastores.

An Automation controller, such as Ansible Automation Controller, runs approved jobs against inventories and can store credentials and job history centrally. Validation and monitoring check the resulting configuration and service behavior, alert on drift, and preserve logs and backups.

Define configuration ownership

Choose a single owner for each configuration domain. If a network controller is authoritative for a fabric, Terraform or a device-level playbook should not independently change the same fabric settings. Instead, use IaC and APIs to submit intent through the controller, then verify the resulting network state.

This ownership boundary determines which interface and automation tool should perform a change. It helps prevent multiple systems from independently managing the same settings.

Implement changes safely

A reliable deployment proceeds through review, controlled execution, verification, and recovery:

1. Validate input. Check required fields, allowed VLAN ranges, naming conventions, target sites, and device compatibility before deployment.

2. Review the change. Run formatting, schema, and policy checks. Generate an IaC plan where applicable, and require approval for production changes.

3. Deploy progressively. Start in a lab or at a canary site, then expand in controlled batches. Use the controller’s documented transaction, preview, or rollback features when available; their behavior varies by platform.

4. Verify results. Compare observed configuration with intended configuration, then test service reachability and relevant operational indicators.

5. Record and recover. Save job results, API responses, change identifiers, and backups. If validation fails, stop or roll back using a recovery method supported by the controller or platform.

Use model-driven APIs securely

RESTCONF requests use HTTP operations on YANG-defined resources. Use HTTPS, validate server identity, authenticate callers, and grant only the permissions required for the change. The precise resource path and JSON or XML payload depend on the YANG modules and API implementation supported by the device or controller.

Configure and verify VLANs with Ansible

The following playbook applies two VLANs to Cisco IOS devices using an Ansible network resource module. It assumes the devices are intentionally managed directly by Ansible, or that the playbook is run by an automation controller. Do not use it to change VLANs that an SDN controller exclusively owns.

In production, define desired VLAN data once and pass it to the playbook rather than duplicating it across jobs. Inventory identifies target devices, protected credentials supply authentication, and a review gate limits who can launch changes. Ansible network modules execute from the control node and can use supported connections such as CLI over SSH, NETCONF over SSH, or HTTP-based APIs, depending on the platform and module.

After deployment, gather VLAN state and assert that VLANs 120 and 130 exist with their intended names. Then perform service-level checks. For example, verify that a test host on each VLAN obtains the expected connectivity while remaining isolated from networks it should not access. Successful configuration alone does not establish that the service works.

Protect and operate the pipeline

Protect automation jobs and their credentials with code review, least-privilege service accounts, encrypted secret storage, verified TLS certificates, and protected remote IaC state. Avoid logging passwords, tokens, or sensitive configuration.

API clients should use timeouts, bounded retries, and clear failure handling. Distinguish authentication, validation, conflict, and transport errors rather than blindly repeating every request. Test changes against representative devices or in a lab before production. Teams should pin tested tool and collection versions and keep an auditable record of who approved and ran each change.

An effective workflow connects version-controlled intent to IaC and APIs, uses the proper controller or device interface for each configuration domain, and checks both configuration and service outcomes. Clear ownership, staged deployment, protected credentials, drift checks, and tested recovery are as important as the automation code.

• Ansible resource modules