Back
Lesson 6 of 6

Enterprise Automation Journey

Objective

Plan your automation journey from traditional CLI automation to NETCONF and finally gNMI, and practice the initial on-device enablement steps that let you safely transition to modern APIs. In production networks this matters because automation tools must be introduced gradually: start with safe read-only automation via the Guest Shell and CLI bindings, add NETCONF for transactional configuration, then adopt gNMI for high-performance configuration and telemetry. Real-world scenario: an enterprise rolling out a telemetry collector and automated configuration pipeline across hundreds of IOS‑XE devices — you will harden device access, enable read-only programmatic access, and validate the environment before moving to full gNMI control.

Quick Recap

Reference the topology from Lesson 1 (unchanged). This lesson does not add new devices or IPs; it focuses on on-device preparation and policy to support automation clients (collector, orchestrator) that live off-box.

Device Table

DeviceRole
Rtr1IOS‑XE network device (management plane)
CollectorAutomation/telemetry collector (external)
AdminPCOperator workstation used for tests

Note: In earlier lessons you established management connectivity to the devices (management interface and VLAN 1). This lesson uses those existing management paths; no new IPs are added here.

Key Concepts

  • Guest Shell and On‑Box Automation

    • Theory: Guest Shell provides an isolated Linux environment inside IOS‑XE to run Python and tooling. It creates a safe place to run automation that can call IOS XE APIs through the provided Python cli module.
    • Packet/behavior: Guest Shell itself does not change control-plane packets; it issues commands through the IOS CLI API functions exposed by the device.
    • Why it matters: It’s the fastest way to bootstrap automation on a device without exposing additional management plane services.

  • cli.cli / cli.execute / cli.configure (Guest Shell Python API)

    • Theory: These Python functions are the bridge between on-box Python and IOS XE. Use cli.cli() for interactive-style commands that return output text, cli.execute() for single EXEC commands, and cli.configure() for configuration mode commands.
    • Behavior: When you call these functions, IOS XE parses and executes the commands through the same parser used by an operator at the console — predictable and consistent.

  • NETCONF vs gNMI

    • Theory: Both are programmatic interfaces using YANG models, but NETCONF provides XML-based RPCs (transactional edits), while gNMI uses gRPC, protobufs, and supports high-performance GET/SET and SUBSCRIBE for streaming telemetry.
    • Packet/behavior: gNMI commonly runs over gRPC/TLS and can be used in Dial‑In (collector connects to device) or Dial‑Out (device initiates) modes.

  • gNOI and GNXI (gRPC ecosystem)

    • Theory: gNOI is a set of gRPC microservices for operational tasks; GNXI is tooling and service framework used to secure gNMI/gNOI access.
    • Why it matters: In production, you’ll use these to perform image installs, certificate management, and other ops via automation.

  • RBAC / NACM on YANG management

    • Theory: NACM (Netconf Access Control Model) restricts create/update/delete operations; you can populate read-only rules so automation clients can safely query device state without making changes.
    • Real-world: Use NACM to give monitoring tools read-only access while limiting accidental writes.

Tip: Think of the automation journey like upgrading a car — start with cruise control (CLI scripts) to learn the road, then install lane-assist (NETCONF) for transactional behavior, and finally add adaptive cruise + telemetry (gNMI) for high-speed, data-rich automation.

Step-by-step configuration

Step 1: Enable Guest Shell

What we are doing: Enable the on‑box Guest Shell so you can run Python automation and call the IOS XE Python cli functions. This is the safe initial step for on-device automation.

iosxe# guestshell enable
iosxe# guestshell run bash

What just happened:

  • guestshell enable starts the Guest Shell container and prepares an isolated Linux environment.
  • guestshell run bash drops you into the Guest Shell interactive shell so you can run Python and other tools. This allows you to use the device-local Python APIs to interact with IOS XE without opening extra management services to the network.

Real-world note: In production, Guest Shell is often enabled temporarily during initial automation bootstrap and then locked down or disabled once off-box automation is established.

Verify:

# From the Guest Shell interactive Python test:
python3 -c "from cli import cli; print(cli('show version'))"

Expected (representative) output:

Cisco IOS XE Software, Version ...
BOOTSTRAP: System returned show version output
<complete show version text as produced by device>

Explanation: The Python call uses the on-box cli module to execute show version via the device CLI parser; full device output indicates the Guest Shell → CLI bridge is functioning.

Step 2: Execute CLI automation primitives (cli.execute / cli.configure)

What we are doing: Demonstrate how automation scripts interact with the device operational and configuration planes using the provided Python APIs. This is an important proof-of-concept before introducing NETCONF or gNMI clients.

python3
from cli import cli, execute, configure
# Read-only example via cli()
output = cli('show running-config | section hostname')
print(output)
# Single EXEC command via execute()
exec_out = execute('show processes cpu | include CPU')
print(exec_out)
# Configuration example via configure()
configure(['interface GigabitEthernet0/0/0', 'description Configured by Guest Shell'])
exit()

What just happened:

  • cli() returns complete show output as if run in an operator session. Use it for complex parsing or retention.
  • execute() runs a single EXEC command and returns output; useful inside loops or for concise queries.
  • configure() pushes configuration mode commands programmatically. These calls go through the IOS XE parser, so validation and error handling match manual CLI behavior.

Real-world note: Use cli() for telemetry acquisition and configure() only after you’ve validated the change in a test environment — configure() modifies running config immediately.

Verify:

# Verify the configuration change was applied
python3 -c "from cli import cli; print(cli('show running-config interface GigabitEthernet0/0/0'))"

Expected output:

interface GigabitEthernet0/0/0
 description Configured by Guest Shell
 [other interface config lines]

Step 3: Enable GNXI secure password authentication

What we are doing: Turn on the GNXI secure password authentication mode that is required for using NACM read‑only population as referenced for gNMI/gNOI tooling. This security step ensures only authenticated automation clients can request YANG model data or invoke gNOI operations.

gnxi secure -password -auth

What just happened:

  • This command toggles GNXI secure password authentication, enabling a password-based auth mode for the gRPC-gNMI/gNOI framework. Enabling GNXI secure auth is a prerequisite for using NACM population tooling and for controlled programmatic access.

Real-world note: Always combine GNXI secure auth with strong TLS certs and RBAC to prevent unauthorized programmatic access to the device.

Verify:

python3 -c "from cli import cli; print(cli('show running-config | include gnxi'))"

Expected output (representative):

gnxi secure -password -auth

Explanation: The running config line confirms the GNXI secure authentication mode is present. If the line appears, gRPC tooling expecting this auth mode can proceed.

Step 4: Populate NACM with read-only rules (safe telemetry access)

What we are doing: Create a NACM read-rule so programmatic clients can query YANG models without being allowed to create/update/delete. This is a common production practice: allow collectors read-only access while preventing accidental modifications.

request platform software yang-management nacm populate -read-rule

What just happened:

  • This operation instructs the YANG management plane to populate NACM with rules that permit read operations while denying CUD (Create/Update/Delete) operations to the configured identities. The device will now enforce these restrictions for NETCONF/gNMI clients that authenticate and present matching identities.

Real-world note: In large estates, NACM read-only rules are used to safely grant monitoring teams and collectors access to operational data without risk of config drift from unauthorized writes.

Verify:

python3 -c "from cli import cli; print(cli('show running-config | section nacm'))"

Expected output (representative):

yang-management nacm
  read-rule populated
  [listing of NACM rules that permit read operations and deny create/update/delete]

Explanation: The presence of a NACM section with read-rule entries demonstrates that the device will now enforce read-only behavior for YANG/API callers.

Step 5: Plan the migration path — tests and staged rollout

What we are doing: Validate client connectivity and plan a staged migration from CLI scripts to NETCONF then to gNMI. This step is about operational practice: how to safely roll automation across the fleet.

# From Guest Shell test: run a full operational read via cli as a pre-check
python3 -c "from cli import cli; print(cli('show running-config | include hostname'))"
# (No on-box command to flip NETCONF or gNMI in this reference; planning actions are documented)

What just happened:

  • You ran a final on-box validation to make sure the CLI bridge and NACM state are consistent. The migration plan itself should include: (1) pilot devices with Guest Shell automation and NACM read-only, (2) add NETCONF for transactional changes on limited groups, (3) enable gNMI on the pilot group and validate telemetry and SET operations, (4) full fleet rollout with monitoring and rollback plans.

Real-world note: Always run an explicit rollback playbook for every automation play you introduce. In production, run changes during maintenance windows and capture before/after snapshots.

Verify:

python3 -c "from cli import cli; print(cli('show running-config | include hostname'))"

Expected output:

hostname Rtr1

Verification Checklist

  • Guest Shell enabled and responsive — verify by running a Python cli('show version') call and confirming full output.
  • Python CLI APIs work (cli, execute, configure) — verify by applying a benign, reversible config (interface description) and reading it back.
  • GNXI secure auth enabled — verify by checking running-config includes gnxi secure -password -auth.
  • NACM read-rule populated — verify by inspecting YANG management NACM configuration section and ensuring read-only rules exist.

Common Mistakes

SymptomCauseFix
Guest Shell command times out or fails to startGuest Shell not enabled on device or resources constrainedEnsure Guest Shell is enabled (guestshell enable) and check system resources before enabling on many devices
Python from cli import cli ImportError in Guest ShellGuest Shell environment not launched or wrong Python interpreterLaunch Guest Shell (guestshell run bash) and use the device-provided Python3 interpreter
No gnxi secure -password -auth in running-config after enablingCommand not committed or device image does not support GNXI in current feature setRe-run the GNXI enable command and verify via show running-config (or via `cli('show running-config
Automation client can still perform writes after NACM populationClient authenticates with an identity that has write privileges or NACM rules not appliedRe-check NACM rule bindings and identities; re-run request platform software yang-management nacm populate -read-rule and validate rule list

Key Takeaways

  • Start automation on devices with Guest Shell and the Python cli APIs for safe, fast iteration — this avoids adding external services too early.
  • Use NACM to restrict programmatic access to read-only while you validate clients (collectors, orchestrators) — think “allow observing before allowing control.”
  • GNXI / gNOI / gNMI are next steps: enable secure GNXI authentication and plan for TLS and RBAC before moving to gNMI SET or SUBSCRIBE operations.
  • Treat the migration as staged: CLI automation → NETCONF for transactional config → gNMI for high-performance telemetry and config. Each stage increases capability and complexity; test and rollback plans are essential.

Warning: Don’t flip on fleet-wide gNMI control without completed pilots, certificate management, and RBAC — modern APIs are powerful and must be governed.

This lesson should leave you with a reproducible on‑device baseline: Guest Shell enabled, Python CLI APIs validated, GNXI secure auth set, and NACM populated with read-only rules — the minimal safe posture for beginning an enterprise automation journey from CLI to NETCONF to gNMI.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security