From CLI to API: Practical Steps for Brownfield Network Automation

Most of us aren't living in a greenfield world. Our networks have years, often decades, of muscle memory built on the CLI. The idea of "automating everything" with APIs sounds great on a whiteboard, but in reality, moving a brownfield network from manual CLI operations to robust, API-driven automation is a marathon, not a sprint. Having run two marathons and over 10 half-marathons, I can tell you: the "middle miles" are where the real work happens it demands pragmatism, phased execution, and a clear understanding of the operational realities.

Step 1: Inventory and API Discovery – Know Your Battlefield

You can't automate what you don't know exists or how it behaves.

Audit your devices: Identify all network devices (routers, switches, firewalls, load balancers). Document their vendors, models, OS versions, and, critically, their current automation capabilities. Do they support REST APIs, NETCONF, gRPC, or something else entirely? Many modern devices offer more than just CLI.

Prioritize API-enabled gear: Start with devices that already expose robust APIs. This gives you early wins and builds confidence. Don't fight a battle trying to API-enable a device that barely supports SSH.

Look for management platforms: Do you have existing NMS, DCNM, or similar platforms? These often expose APIs that abstract away device-level complexities, providing a single pane of glass for automation. Leverage them.

Step 2: Start Small, Iterate Quickly – The Low-Risk Wins

Don't attempt to automate your core routing protocols on day one. Pick a low-risk, high-impact area.

Read-only operations: The safest first step. Use APIs to collect data (interface status, routing table entries, device health). This allows you to build dashboards, perform audits, and get comfortable with API calls without making any changes.

Example: Pulling interface statistics from Cisco IOS-XE using RESTCONF or collecting firewall rule counts from a Palo Alto Networks API.

Simple configuration tasks: Once comfortable with read operations, move to idempotent, non-critical writes. Think about tasks that are repetitive, error-prone, and have minimal blast radius if something goes wrong.

 Example: Updating banner messages, adding a new NTP server, or configuring a new VLAN on a single access switch.

Tooling choice matters: Python with requests, Nornir, Ansible (using network modules that can speak API), or event-driven platforms like StackStorm are excellent choices to start. They provide structured ways to interact with APIs.

Step 3: Secure Your Access – Don't Skip This

Dedicated automation users: Never use shared admin credentials. Create specific user accounts for your automation scripts with the minimum necessary privileges.

Token/API Key management: Store API keys and tokens securely, preferably in a secrets management solution like HashiCorp Vault, AWS Secrets Manager, or a similar platform. Avoid hardcoding credentials in your scripts.

Network segmentation: If possible, isolate your automation platform and its access to network devices on a dedicated management segment.

Step 4: Validate and Verify – Trust, But Verify

Automation isn't magic; it needs rigorous validation.

Pre-checks: Before applying any API-driven changes, perform checks to ensure the network is in the expected state. This prevents applying changes to an already broken environment.

Post-checks: Immediately after an automation run, verify that the changes were applied correctly and the network is functioning as expected. Don't assume success. Use read-only API calls to confirm configurations and operational status.

Idempotency: Design your automation to be idempotent. Running it multiple times should produce the same result without unintended side effects. This simplifies error recovery and rerun capabilities.

Rollback strategies: Always have a plan to undo changes. This could be a configuration backup, a terraform destroy (for IaC), or a manual rollback procedure.

Step 5: Treat Network Automation as Software Development (NetDevOps)

This is a cultural and process shift.

Version control everything: Store all your automation scripts, playbooks, API schemas, and validation logic in Git. This provides an audit trail, collaboration, and easy rollback.

CI/CD pipelines: Integrate your automation into a CI/CD pipeline. This means every change to your automation code is tested (linting, syntax checks, dry runs), peer-reviewed, and then automatically deployed (or approved for deployment) to your network.

Observability: Don't just monitor if your automation ran; monitor its impact. Are network metrics stable? Are applications performing as expected after a change? Integrate automation logs into your central observability platform.

The Operational Takeaway

Transitioning a brownfield network to API-driven automation isn't about replacing every CLI command overnight. It's about strategic wins, building confidence, and iterating on a solid foundation. Start small, secure your access, validate ruthlessly, and treat your network automation like the critical software it is. The journey from CLI to API is long, but each practical step makes your network more agile, reliable, and predictable.

#NetworkAutomation #NetDevOps #CLItoAPI #InfrastructureAsCode #Automation #DevOps #BrownfieldAutomation #NetworkEngineering #ITAutomation #DigitalTransformation #Cisco #Arista #Juniper #IaC #NetDevOps