Network Automation and Orchestration for Multi-Site Enterprise
A multinational enterprise with 150 sites (offices, factories, warehouses) is moving to a network automation and orchestration strategy. Currently, each site is managed individually via CLI, with inconsistent configurations and slow change management (average 2 weeks to deploy a VLAN change). The company has standardized on Aruba CX switches and Aruba APs, managed by Aruba Central. They want to adopt infrastructure-as-code (IaC) and CI/CD pipelines for network changes. The network team has limited programming experience but is willing to learn. The company also uses ServiceNow for IT service management and wants to integrate network changes with change requests. The network has a mix of MPLS and internet links, with SD-WAN at the edge. Security policies require that all changes be approved and audited. The company is considering using Ansible, Terraform, or Aruba Central APIs. They also want to implement automated compliance checks to ensure configurations meet security baselines. The goal is to reduce change deployment time to under 1 day and improve consistency.
1. Recommend an automation architecture and toolchain that fits the company's constraints and goals. Justify your choices.
Read the worked answer
Given limited programming experience, start with a low-code approach using Aruba Central's native automation features (templates, workflows) and gradually introduce IaC. Recommended toolchain: 1) Aruba Central as the single source of truth for device management and configuration templates. Use Central's APIs for programmatic access. 2) For IaC, use Ansible (agentless, YAML-based, easier for network engineers) to automate configuration pushes via Central APIs or directly to devices. Terraform could be used for infrastructure provisioning but is less mature for network devices. 3) Integrate with ServiceNow using webhooks or APIs: when a change request is approved, trigger an Ansible playbook via CI/CD (e.g., GitLab CI or Jenkins). 4) Use Git for version control of configurations and playbooks, enabling audit trails. 5) Implement automated compliance checks using a tool like Batfish or custom scripts that compare running config to golden configs; integrate into CI pipeline to block non-compliant changes. 6) For SD-WAN, use Aruba's SD-WAN orchestration (or Central) to manage policies. 7) Provide training and start with small, low-risk changes (e.g., VLAN provisioning) to build confidence. 8) Ensure role-based access control and logging for audits. This approach leverages existing investments, minimizes new tools, and scales to 150 sites.
2. How would you design the CI/CD pipeline for network changes, including approval and audit requirements?
Read the worked answer
Design a pipeline with stages: 1) Request: Change request created in ServiceNow; upon approval, it triggers a pipeline in GitLab/Jenkins via API. 2) Validation: Pipeline pulls the intended configuration from Git (e.g., VLAN definition in YAML), runs syntax checks and compliance validation (e.g., using a linter or custom script against security baseline). 3) Pre-check: Query current network state via Central API to ensure no conflicts (e.g., VLAN ID not in use). 4) Approval gate: Manual approval in the pipeline (or automatic if pre-approved by ServiceNow) to proceed. 5) Deployment: Ansible playbook applies changes via Central API or directly to devices, with idempotency. 6) Post-check: Verify configuration applied correctly and network health (e.g., ping tests, API checks). 7) Rollback: If failure, automatically revert to previous config from Git. 8) Audit: Log all steps, approvals, and changes to a central logging system (e.g., Splunk) and update ServiceNow change record. Ensure segregation of duties: the person approving is different from deployer. Use Git commits as audit trail. For security, store credentials in a vault (e.g., HashiCorp Vault) and use short-lived tokens. This pipeline reduces deployment time to hours and ensures consistency and compliance.