Ansible for Network Automation

Ansible for Network Automation

Quick Answer: Ansible automates many devices from a control node using inventory, playbooks (YAML), and modules. It is agentless—typically SSH or APIs to network gear, no agent on the switch. Idempotent plays drive devices toward a declared state. Ansible runs off-box; OPS runs on-box.

After OPS, HCIA expects you to place the industry-standard off-box tool that appears in Huawei’s automation story: Ansible. You will not be graded as a Red Hat certified engineer; you will be graded on whether you understand how Ansible reaches devices, what a playbook is, and why re-running automation should be safe.

What Ansible is in one paragraph

Ansible is an automation engine. You describe the desired work in playbooks, list target machines in an inventory, and execute from a control node. For network devices, tasks often use network modules that issue CLI commands, structured config, or API calls. The control node orchestrates; the devices apply changes and return results.

Agentless architecture (exam favorite)

Why agentless matters for network gear: Installing third-party agents on every campus switch is operationally painful and often unsupported. SSH-based or API-based automation matches how engineers already manage Huawei devices.

Exam trap wording

• Correct association: Ansible → agentless → SSH/API from control node
• Incorrect association: Ansible requires a Python agent installed on every access switch (that confuses older server-automation mental models or other tools)
• Incorrect association: Ansible playbooks execute inside OPS on the data plane chip

Inventory: which devices

Inventory answers “who am I automating?” Simple inventories group hosts:

Variables can attach per group: management VRF name, NTP server, banner text, credential references. HCIA takeaway: inventory scopes the blast radius. A playbook aimed at access_switches should not accidentally rewrite the core.

Playbooks: what to do

A playbook is typically a YAML file describing plays. Each play maps hosts from inventory to a list of tasks. Tasks call modules with parameters.

Conceptual structure (read as structure, not a lab file to memorize line-for-line):

- name: Standardize campus access switches
  hosts: access_switches
  gather_facts: false
  tasks:
    - name: Ensure NTP server is configured
      # network module placeholder
      # commands or structured config toward VRP
    - name: Deploy standard ACL snippet
      # another task

You should be able to say: playbooks declare automation steps in YAML; they are not Python source files (though Ansible itself is implemented in Python, exam items about your artifacts mean YAML playbooks).

Modules for network devices

Modules encapsulate common operations so playbooks stay readable. Network-oriented modules may:

• Open SSH and run show/display commands
• Push configuration lines or templates
• Retrieve facts (hostname, OS version, interface list)
• Enforce a configuration block and report changed/ok/failed

Huawei ecosystems may use community or vendor-oriented collections in real projects. HCIA cares about the module concept, not a catalog of every collection name.

Idempotency: safe to re-run

Idempotency means applying the same automation repeatedly yields the same desired end state without unnecessary side effects. If the NTP server is already correct, a good task reports ok (no change) instead of appending a duplicate broken line every night.

Exam phrasing: Why can you schedule the same playbook daily? → Because well-written automation is idempotent and converges to the intended configuration rather than blindly stacking changes.

Idempotency is a goal of good automation design. Not every raw CLI command sequence is inherently idempotent; modules and careful task design improve the property.

Ansible workflow for a campus change

1. Define inventory — list management IPs / hostnames for target VRP devices; group them.
2. Write or reuse a playbook — tasks for the change (banner, ACL, VLAN batch concept, NTP).
3. Check connectivity — control node must reach SSH/API; ACLs on VTY must allow the automation source.
4. Run in check/diff mode when available — preview impact before production (operational best practice).
5. Execute playbook — review per-host results: ok / changed / failed.
6. Verify — still use display thinking; automation does not remove validation.
7. Save — ensure device startup config is updated per your change process (explicit task or operational step).

Prerequisites checklist (troubleshooting automation “failures”)

Notice the overlap with the VRP remote-management chapter: automation rides the same SSH path humans use, which is exactly why agentless SSH design fits network devices.

Ansible versus OPS versus controller (placement table)

Single sentence for H12-811: Use Ansible to push consistent configuration from a server across an inventory; use OPS when the device itself should run Python on an event.

Realistic multi-device example

Goal: ensure every access switch uses the same logging host and a standard login banner.

• Inventory group access_switches contains 40 management addresses.
• Playbook tasks: configure info-center log host parameters (concept), set header login / banner style text per VRP syntax used in your lab, optionally save.
• First run: 40 hosts changed.
• Second run the next day: 40 hosts ok if nothing drifted—idempotency demonstrated.
• One closet switch was offline: playbook reports failed/unreachable for that host only; others succeed—blast radius is per inventory host, not “all or nothing” by necessity.

What HCIA does not require

• Memorizing every Ansible module parameter
• Writing complex Jinja2 templates under time pressure
• Designing AWX/Tower cluster HA
• Claiming Ansible replaces NETCONF knowledge entirely—Ansible may use SSH/CLI or APIs underneath

Stay conceptual, accurate, and placement-focused.

Exam traps

• Agent required on switch — false for typical Ansible network automation; it is agentless.
• Ansible runs on the data plane ASIC — false; it runs on a control node.
• Playbooks are binary compiled programs — false; they are YAML automation descriptions.
• Idempotent means “runs only once ever” — false; it means safe/correct under re-application toward desired state.
• Ansible and OPS are interchangeable names — false; off-box vs on-box is the discriminating fact.
• Inventory is optional because Ansible broadcasts to the whole LAN — false; inventory selects targets.

Practice goals

1. Define agentless automation and name the common transport to network devices.
2. Map inventory, playbook, and module to one sentence each.
3. Explain idempotency with a re-run example (changed vs ok).
4. Contrast Ansible with OPS without using vague “both automate networks” wording.

Next, SNMP and Network Management Basics covers classical monitoring—manager, agent, MIB, Get/Set/Trap—and how it sits beside automation in FCAPS-style O&M.