Network automation becomes useful when it removes repetitive risk, not when it creates a second uncontrolled way to break the fabric. A realistic starting point for a small data center team is simple: use Git as the source of truth for intended changes, Ansible to render and push configuration, and a repeatable verification checklist before and after each change.
This guide uses a concrete scenario: an 8-leaf / 2-spine EVPN/VXLAN fabric that supports virtualization, backup, storage and a small AI/GPU rack. The team needs to add new application networks frequently, but every manual VLAN/VNI change touches multiple switches and is easy to mistype.
Problem: manual data center changes do not scale
Imagine this fabric: 10/25 GbE server access, 100 GbE leaf-spine uplinks, two border leaves, about 120 hypervisors and a separate 4-node GPU pod. The business asks for a new analytics segment:
- VLAN 130 for application servers
- VNI 10130 in the EVPN overlay
- Anycast gateway 10.130.0.1/24 on all relevant leaves
- Firewall policy allowing HTTPS to the API tier and backup traffic to a backup VLAN
- No reachability from IoT, management or test networks
Doing this by hand means logging into many switches, pasting similar commands, checking BGP EVPN state, then hoping the firewall rules match the intended segmentation. The common failure is not lack of CLI knowledge; it is configuration drift.
Diagnosis: what should become automated?
Do not begin by automating every protocol knob. Start with changes that are frequent, repetitive and easy to verify. In a small EVPN/VXLAN fabric, the first good candidates are VLAN/VNI creation, SVI/anycast gateway parameters, descriptions, interface membership, BGP EVPN route-target consistency and basic validation commands.
Keep low-frequency risky operations manual or semi-automated at first: underlay routing redesign, spine replacement, major OS upgrades and multicast/replication mode changes. Automation should make the boring changes safer before it attempts the dangerous ones.
Design options: scripts, Ansible or full source of truth?
| Option | Best for | Risk | Typical cost |
|---|---|---|---|
| Python script with CSV/YAML | Small labs, one-off reports, config rendering | Easy to grow into undocumented tooling | Free, engineer time |
| Ansible + Git | Repeatable data center changes with review and dry-run | Templates must be tested carefully | Free/community tooling or paid automation platform |
| Nautobot/NetBox + CI/CD | Teams that need inventory, IPAM, approvals and audit trails | More moving parts to maintain | Free OSS plus VM/DB/backup cost; commercial support optional |
| Controller-only workflow | ACI, SDN fabrics, vendor-managed policy | Lock-in and API/version dependency | License/support dependent |
For many small data center teams, the sweet spot is Ansible + Git today, with Nautobot or NetBox added when inventory and IP address management become painful.
Practical repository layout
A simple repository should separate intent, templates and verification. For example:
dc-fabric-automation/
inventory/
hosts.yml
group_vars/
fabric.yml
intent/
vlans.yml
tenants.yml
templates/
nxos_vlan_vni.j2
nxos_svi_anycast.j2
playbooks/
render.yml
deploy.yml
verify.yml
reports/
The intent file for the new analytics segment can stay readable enough for peer review:
vlans:
- name: APP_ANALYTICS
vlan_id: 130
vni: 10130
vrf: PROD
gateway: 10.130.0.1/24
leaves: [leaf01, leaf02, leaf03, leaf04]
allowed_to:
- api_https
- backup_repository
The pull request should show the generated diff before anything is pushed. A reviewer can check whether VLAN 130 maps to VNI 10130 everywhere, whether the VRF is correct and whether only the intended leaves receive the configuration.
Change workflow: from request to deployment
- Create a ticket or change note with VLAN, VNI, subnet, firewall intent, owner and rollback requirement.
- Create a Git branch and edit the intent YAML, not raw switch configuration.
- Run local checks: YAML lint, duplicate VLAN/VNI detection, subnet overlap detection and template rendering.
- Open a pull request with the generated configuration diff attached.
- Run Ansible in check/diff mode against lab or maintenance-window targets.
- Deploy in batches: border leaves first only if policy requires it, otherwise one leaf pair, verify, then continue.
- Save evidence: command output, telemetry screenshots, ping/iperf results and rollback notes.
Verification checklist for EVPN/VXLAN changes
The useful part of automation is not only pushing config. It is also proving that the network reached the expected state. For VLAN 130 / VNI 10130, use a checklist like this:
- Config state: VLAN exists on the intended leaves only; VNI is mapped once; SVI is up where required.
- BGP EVPN: route type 2 MAC/IP routes appear after a test VM connects; route type 5 prefixes appear if using symmetric IRB with prefix advertisement.
- Underlay: leaf-to-spine ECMP remains stable; no new OSPF/IS-IS/BGP adjacency flap during the change.
- Reachability: ping default gateway, ping same VLAN across leaf pairs, then test allowed application flows.
- Performance: run
iperf3between two test hosts. For 25 GbE servers, first target should be line-rate minus normal host overhead, not a random 2-3 Gb/s result. - Segmentation: confirm denied flows fail. A blocked ping from management or IoT to 10.130.0.0/24 is a success if that is the policy.
- Monitoring: check interface errors, drops, buffer counters, EVPN neighbor state and syslog for template mistakes.
| Test | Command or check | Pass condition |
|---|---|---|
| Render | ansible-playbook playbooks/render.yml --check | No duplicate VLAN/VNI, config diff matches intent |
| EVPN routes | show bgp l2vpn evpn route-type 2 | MAC/IP routes learned from expected VTEPs |
| VNI state | show nve vni 10130 | VNI up on selected leaves |
| Loss | 300 pings across leaf pairs | 0% loss after convergence |
| Throughput | iperf3 -P 4 -t 60 | Expected host/network throughput for 10/25 GbE |
| Policy | Firewall log and denied-flow test | Allowed flows pass; denied flows are logged or dropped |
Rollback that actually works
Rollback is not "remove whatever was added". It needs the previous rendered configuration, a clear blast radius and a decision point. For the example above, rollback may mean removing VLAN 130 from only four leaves, withdrawing VNI 10130, deleting firewall policy objects and confirming that no server team already attached production workloads.
Tag the repository release before deployment. Store pre-change command output. If the change fails during the first leaf pair, stop and revert only that batch. If the application test fails but the network checks pass, do not automatically roll back the fabric; hand the evidence to the server or firewall owner.
Shopping list / bill of materials
This topic is mostly process and tooling, but a small team still needs a place to run it. Neutral starter options:
- Budget lab, €0-€300 / $0-$300: GitHub/GitLab free tier, local Python virtual environment, Ansible, containerlab or vendor virtual images if licensed.
- Small production workflow, €300-€1,500 / $300-$1,500: dedicated mini-PC or VM for automation runners, backup storage for repositories and reports, simple monitoring integration.
- Team workflow, €1,500-€5,000+ / $1,500-$5,000+: Nautobot/NetBox VM, CI runner, secrets manager, commercial Git hosting or support, monitoring and log retention.
Do not store switch passwords in Git. Use SSH keys, a vault/secrets manager and role-based accounts. The cheapest automation platform is still expensive if it leaks credentials.
Where AI agents fit
AI tools are useful around the workflow, not as an uncontrolled direct path to production. Good tasks include summarizing change evidence, drafting implementation plans, explaining failed Ansible output, generating documentation from sanitized configs and building blog/lab notes from verified results. Bad tasks include letting an agent invent commands for a live fabric without review, or pasting private customer data into tools that are not approved for that data.
For Network freak readers experimenting with Hermes Agent or similar assistants, the safe pattern is: use the agent to prepare documentation, validate checklists and analyze sanitized outputs; keep deployment guarded by Git review, CI checks and human approval.
Summary
A practical network automation workflow is not magic. It is a disciplined chain: intent in Git, generated configuration, reviewable diffs, controlled Ansible execution, verification and rollback evidence. For data center and AI infrastructure, this matters because fabrics change often: new VLANs, GPU pods, telemetry exporters, storage networks and application segments. The more often a change repeats, the more value you get from making it boring, reviewed and measurable.
Related reading
- Start Here: networking topics
- Useful Resources
- Data Center articles
- Automation articles
- AI-Ready Leaf-Spine Network: Practical Guide for Small GPU Clusters
- EVPN VXLAN Troubleshooting: Common Problems and Fixes
If you are building a small EVPN/VXLAN fabric or trying to introduce Git and Ansible into network operations, leave a comment with the scenario: number of switches, vendors, link speeds and what change scares you the most.
Post a Comment