Yasin Engin · Network Automation

Automation starts after the first configuration succeeds.

Sending commands is the smallest part of the problem. The real work is making topology, intent, change, validation, and evidence repeatable enough that a second run is safer than the first.

My working definition

Network automation is a controlled path from declared intent to verified device state. It includes how the lab is rebuilt, how variables are modeled, how changes are delivered, how the result is queried, and how a failed run can be understood. A script that succeeds once is useful; a workflow that explains why it succeeded is engineering evidence.

The five-part workflow

1. Topology as dataNodes, links, roles, interfaces, and addressing belong in a rebuildable definition rather than a screenshot.
2. Intent outside the commandInventories and variables describe the outcome before a vendor-specific transport applies it.
3. Model-aware deliveryAnsible, YANG/gNMI, NETCONF, RESTCONF, or JSON-RPC are selected according to the state and interface being controlled.
4. Post-change validationOperational state is queried after the change; successful transport alone is not treated as success.
5. Evidence and recoveryOutputs, logs, diffs, and rollback assumptions make the workflow reviewable when behavior diverges.

What I have built

My main automation case study uses Nokia SR Linux and Containerlab to make virtual topologies disposable and repeatable. Ansible expresses configuration workflows, while YANG/gNMI and JSON-RPC concepts connect the lab to model-driven state. The work is intentionally laboratory-scale: its purpose is to make operational habits visible before applying them to larger environments.

• Network Automation Labs
  Topology, intent, configuration, and validation workflow.
• CCNP Enterprise Labs
  The routing and switching foundation beneath the automation.
• Network Inventory API
  A Go source-of-truth model for physical and logical network resources.
• Production checklist
  Small-environment reliability and operations questions.

Principles I carry into each lab

• Idempotence is a behavior to test, not a label to add to a playbook.
• Inventory quality limits automation quality.
• Desired state and observed state must be independently readable.
• Protocol choice should follow the data model and operational need.
• Manual troubleshooting knowledge remains essential because automation compresses both success and failure.

Where I am still growing

I am expanding the labs toward stronger CI validation, richer pre-change and post-change state capture, multi-vendor data models, and failure-injection scenarios. I am also studying how source-of-truth systems, orchestration services, and streaming telemetry can share clear ownership without creating another fragile control layer.