This proof of concept validates a modern data centre fabric built around BGP EVPN VXLAN with Symmetric IRB, The goal was to prove that this architecture delivers predictable scalability, clean multi-tenancy, and a strong foundation for automation.

developed using Arista vEOS-lab version 4.33.1F, a major feature release that includes several EVPN/VXLAN and control-plane enhancements. Part of the reason for revisiting this build was to validate those improvements and assess how they impact large-scale EVPN fabrics.

The design remains aligned with Arista Validated Designs (AVD) and Cisco’s equivalent EVPN VXLAN model focused on scalable multi-tenancy and automation readiness.

Design Overview

The fabric design uses a structured three-plane model to separate responsibility and simplify automation.
Underlay uses OSPF area 0 to provide fast, deterministic IP reachability between VTEPs. Overlay connectivity is handled via VXLAN, and the control plane runs BGP EVPN with route reflectors. Each tenant is represented by a dedicated VRF and L3VNI for scalable inter-VLAN routing.

Fabric Design Summary

Underlay: OSPF area 0. Provides fast convergence and ECMP-based IP reachability. Overlay: VXLAN. Extends Layer 2 segments logically over the IP underlay.

Control Plane: BGP EVPN (iBGP with Route Reflectors). Distributes MAC and IP reachability information across the fabric.

Routing Model: Symmetric IRB. Isolates tenants using VRFs and L3VNIs, enabling scalable inter-VLAN routing.

MTU: 9150 underlay / 1500 overlay. Ensures headroom for VXLAN encapsulation.

Anycast Gateway: 192.168.X.1 (MAC 00:1c:73:00:00:99). Supports seamless host mobility and efficient ARP suppression.
Spines act purely as route reflectors and IP transit; leaves perform all routing and encapsulation as VTEPs.
The next stage will move toward an eBGP fabric using BFD for sub-second convergence and simplified fault isolation.

Control Plane - BGP EVPN

Each leaf peers with both spines using loopback interfaces. BGP advertises Type-2 (MAC/IP), Type-3 (multicast), and Type-5 (prefix) routes to distribute reachability and routing information across the fabric.

SW-2#sh run | sec bgp
router bgp 65000
   router-id 2.2.2.2
   neighbor EVPN-SPINES peer group
   neighbor EVPN-SPINES remote-as 65000
   neighbor EVPN-SPINES update-source Loopback0
   neighbor EVPN-SPINES send-community extended
   neighbor 10.0.0.14 peer group EVPN-SPINES
   neighbor 10.0.0.15 peer group EVPN-SPINES
   !
   vlan 10
      rd 65000:100010
      route-target both 65000:100010
      redistribute learned
   !
   vlan 20
      rd 65000:100020
      route-target both 65000:100020
      redistribute learned
   !
   address-family evpn
      neighbor EVPN-SPINES activate
   !
   vrf TENANT_A
      route-target import evpn 65000:100000
      route-target export evpn 65000:100000
      redistribute connected
   !
   vrf TENANT_B
      route-target import evpn 65000:200000
      route-target export evpn 65000:200000
      redistribute connected
SW-2#

Underlay Design

The underlay uses OSPF area 0 for loopback and point-to-point reachability. ECMP provides multiple parallel paths, making the fabric resilient and predictable.

SW-2#sh run | sec ospf 
interface Ethernet2
   ip ospf network point-to-point
   ip ospf area 0.0.0.0
interface Ethernet3
   ip ospf network point-to-point
   ip ospf area 0.0.0.0
interface Loopback0
   ip ospf area 0.0.0.0
router ospf 10
   max-lsa 12000
SW-2#

VXLAN Overview

VXLAN forms the overlay transport between VTEPs. Each leaf acts as a VTEP, encapsulating traffic from locally attached hosts and decapsulating traffic from remote leaves.
The outer IP header carries the VTEP loopbacks, and the inner Ethernet frame remains untouched, preserving original VLAN tags.

SW-1#sh run int vxlan1
interface Vxlan1
   vxlan source-interface Loopback0
   vxlan udp-port 4789
   vxlan vlan 10 vni 100010
   vxlan vrf TENNANT_A vni 100000
SW-1#

SW-2#sh run int vxlan1
interface Vxlan1
   vxlan source-interface Loopback0
   vxlan udp-port 4789
   vxlan vlan 10 vni 100010
   vxlan vlan 20 vni 100020
   vxlan vrf TENANT_A vni 100000
   vxlan vrf TENANT_B vni 200000
SW-2#
SW-3#sh run int vxlan1
interface Vxlan1
   vxlan source-interface Loopback0
   vxlan udp-port 4789
   vxlan vlan 20 vni 100020
   vxlan vrf TENANT_B vni 20000
SW-3#

SW-1#sh vxlan vni
VNI to VLAN Mapping for Vxlan1
VNI          VLAN       Source       Interface       802.1Q Tag
------------ ---------- ------------ --------------- ----------
100010       10         static       Ethernet3       untagged  
                                     Ethernet4       untagged  
                                     Vxlan1          10        

VNI to dynamic VLAN Mapping for Vxlan1
VNI          VLAN       VRF             Source       
------------ ---------- --------------- ------------ 
100000       4097       TENANT_A       evpn         
!
SW-2#sh vxlan vni
VNI to VLAN Mapping for Vxlan1
VNI          VLAN       Source       Interface       802.1Q Tag
------------ ---------- ------------ --------------- ----------
100010       10         static       Ethernet1       untagged  
                                     Vxlan1          10        
100020       20         static       Ethernet4       untagged  
                                     Vxlan1          20        

VNI to dynamic VLAN Mapping for Vxlan1
VNI          VLAN       VRF             Source       
------------ ---------- --------------- ------------ 
20000        4094                       evpn         
100000       4097       TENANT_A       evpn         
200000       4098       TENANT_B       evpn         

SW-2#
!
SW-3#show vxlan vni
VNI to VLAN Mapping for Vxlan1
VNI          VLAN       Source       Interface       802.1Q Tag
------------ ---------- ------------ --------------- ----------
100020       20         static       Ethernet1       untagged  
                                     Vxlan1          20        

VNI to dynamic VLAN Mapping for Vxlan1
VNI         VLAN       VRF             Source       
----------- ---------- --------------- ------------ 
20000       4097       TENANT_B       evpn         

SW-3#

0050.0000.0600 = Server6
0050.0000.0700 = Server7
0050.0000.0800 = Server8

Why Symmetric IRB

Asymmetric IRB forces each leaf to know every subnet in every tenant. That scales poorly as VLAN count grows.

Symmetric IRB solves this by introducing a dedicated VRF and L3VNI per tenant. Each leaf advertises only its locally attached prefixes using Type-5 routes, dramatically reducing control-plane load and making routing predictable.

It also aligns perfectly with multi-tenant use cases and automation workflows.

Next Steps

The next iteration will focus on:

1. Migrating from iBGP with route reflectors to eBGP with BFD for sub-second convergence.

2. Extending to a dual-site EVPN fabric with firewalls providing north-south traffic control.

3. Orchestrating configuration and verification through Ansible and CloudVision Studios.

4. Integrating streaming telemetry for continuous fabric health and visibility.

This proof of concept demonstrates how a modern EVPN VXLAN fabric can be modular, scalable, and automation-ready.

It aligns with production best practices and provides a reproducible baseline for the next phase: dual-site orchestration and operational automation.

Subscribe now

Leave a comment

When most of us started in networking, the CLI was king. You typed show ip interface brief, skimmed the columns, and quickly spotted which interfaces were up or down. That works fine for a human staring at one device. But what happens when you need to check hundreds of devices automatically? That’s where things break down.

The problem with CLI for automation

CLI output is built for humans, not machines. It’s full of quirks like: Inconsistent spacing between columns Extra headers and banners Vendor-specific differences Take this Cisco example:

Looks neat to the eye. But if you try to split this text in Python or feed it into Ansible, you’ll quickly run into spacing issues and unreliable parsing.

The solution: structured data

Now it’s easy to:

• Run consistency checks

• Compare pre-change vs post-change state

• Feed data directly into an Ansible inventory or Python script

Demo: parsing with Python

Here’s a minimal parser that converts raw CLI text into JSON. It’s not production-grade, but it shows the concept.

Connecting to Ansible

Now Ansible can load this YAML file directly into a playbook to validate configs, generate reports, or even drive remediation.

Key takeaways

Raw CLI ≠ automation-friendly

• Structured data (JSON/YAML) is the foundation for pipelines Even a simple Python script can make CLI data usable today

• Later, can replace custom parsing with tools like TextFSM, pyATS, or Batfish

Automation isn’t about abandoning the CLI. It’s about making the data behind the CLI useful at scale.

Subscribe now

Leave a comment

Config backups have always been part of running networks. Tools like RANCID solved the problem years ago by scraping configs and emailing diffs. That worked in smaller, slower-moving environments.

In my career supporting financial trading and data center networks, I learned the hard way that this approach does not hold up under pressure. Backups need to be more than nightly snapshots — they must be structured, reliable, auditable, and fast. That is why I started building fabric-config-backup.

Incidents That Shaped My Approach

Drift detection too slow
During a trading floor maintenance window, an ACL line was removed on an edge firewall. The drift was only noticed hours later when FIX sessions began failing. By the time RANCID reported the config diff, orders had already been impacted. A pre/post snapshot pipeline would have caught this immediately.

Format fragility
On NX-OS 9.3(5), Cisco published CSCvu49769 where certain show run outputs omitted default interface commands. Tools scraping configs silently missed critical lines. This broke RANCID and other text-based systems, leaving blind spots in backups.

Rollback gaps
During a data center migration, configs needed to be rolled back. Only the previous night’s snapshot was available. This missed changes applied earlier in the day, forcing manual reconfiguration under pressure. With Git-integrated automation, a pre-change snapshot could have been taken seconds before the rollout

Building a Better Approach

I started simple: Python scripts with Netmiko and Scrapli. Over time, I expanded them to cover Arista EOS, Cisco NX-OS, and IOS. The goal was not just “get a file,” but to build a workflow:

• Multi-vendor coverage – Arista, Cisco NX-OS, Cisco IOS in a single inventory

• Git integration – every backup as a commit, signed and timestamped

• Pre/post snapshots – automatic before a change, and again after

• Error handling – no silent failures, every issue is logged

This is how fabric-config-backup was born.

Compliance and Governance

In critical industries, backups are compliance controls as much as operational safety nets.

• Audit trails – immutable Git history, not just email diffs

• Automated checks – parse configs into JSON/YAML to enforce standards (AAA, SSH v2, SNMPv3)

• Regulatory evidence – PCI-DSS and SOX require proof that configs are captured and recoverable

When an auditor asks for evidence, I can point to a Git repo rather than a mailbox.

Opportunities Beyond Backups

Once configs are versioned, new opportunities open up:

• CI/CD validation – policy checks, security scans, and linting before rollout

• Baseline enforcement – compare against golden configs automatically

• Event-driven triggers – back up on change, not just on schedule

• Scale – async Scrapli sessions snapshot entire fabrics in seconds

Lessons From the Field

• A migration rollback that used to take hours now takes minutes because snapshots are always there.

• Bugs that once silently broke backups now raise clear exceptions.

• Compliance audits are less stressful because history is verifiable and structured.

These lessons are the result of years in environments where downtime is not an option.

Config backups are no longer just insurance. They are a foundation for compliance, for operational resilience, and for automation-driven excellence.

Explore the project: git.packetninjalabs.com/fabric-config-backup

Subscribe now

Leave a comment

Automation only works if the source of truth is clean. That is why I am moving toward inventory as code. The idea is simple: every device has a file, written in YAML, stored in Git. That inventory then feeds Python scripts, Ansible playbooks, and eventually CI/CD pipelines.

Why “one device, one YAML”

Keeping one file per device makes it:

• Easy to read

• Easy to review in Git (a small diff shows the change)

• Easy to validate with a Python script or CI job

It also lines up with how I already think about production changes: controlled, traceable, peer-reviewable.

A basic example

Here is a YAML file for a lab leaf switch:

hostname: leaf1-lab
role: leaf
mgmt:
  ip: 10.0.0.21/24
interfaces:
  - { name: Eth1, peer: spine1, ip: 172.16.0.1/31 }
  - { name: Eth2, peer: spine2, ip: 172.16.0.3/31 }

And here is a short Python script that reads all device files and prints a summary:

import glob, yaml

for f in glob.glob("inventories/lab/devices/*.yml"):
    data = yaml.safe_load(open(f))
    print(f"{data['hostname']:12} {data['mgmt']['ip']:15} {data['role']}")

Output:

leaf1-lab    10.0.0.21/24    leaf

That is already useful. Instead of flipping through spreadsheets, I can generate a quick summary. Later I can build checks to catch duplicate IPs or missing fields.

Where this goes next…

• Python can use this data to generate configs or back up running configs.

• Ansible can consume the same inventory to drive playbooks.

• GitLab CI can lint these files and refuse a merge if something is invalid.

• Terraform can connect the same mindset to cloud networking.

This is how I see inventory as the first building block. Get it right, and everything else becomes easier.

Automation is not about replacing engineers. It is about making the data we already know repeatable and reliable. For me that starts with a simple rule: one device, one YAML.

Next I will show how I use Python to validate that inventory and stop bad data before it ever reaches production.

Subscribe now

Leave a comment

Start simple, not complex

It is tempting to jump into full frameworks like Ansible or Terraform straight away. The problem is that without the basics those tools feel like magic. You copy code from somewhere else, it works once, and then it breaks when you try to adapt it.

The smarter path is to start with the foundations of Python.

• Lists and dictionaries to represent VLANs, IP addresses, or firewall rules

• Functions to wrap repeat logic into something reusable

• File handling to read device inventories from YAML or JSON, or export Palo Alto rules into versioned files

• Error handling to stop one offline device or one bad API call from crashing the whole run

A basic example

This is one of the first exercises I tried: generate VLAN config from a list.

vlans = [101, 102, 103]

for v in vlans:
    print(f"vlan {v}")
    print(f" name USER-{v}")

Output:

vlan 101
 name USER-101
vlan 102
 name USER-102
vlan 103
 name USER-103

Example 2: Representing firewall rules as data

rules = [
    {"src": "10.1.1.0/24", "dst": "10.2.2.0/24", "action": "allow"},
    {"src": "0.0.0.0/0",    "dst": "10.2.2.100", "action": "deny"},
]

for r in rules:
    print(f"set rule from {r['src']} to {r['dst']} action {r['action']}")

Output:

set rule from 10.1.1.0/24 to 10.2.2.0/24 action allow
set rule from 0.0.0.0/0 to 10.2.2.100 action deny

This is the same pattern. Instead of typing commands one by one, represent the intent in a list or dictionary and loop over it.

Example 3: Reading devices from YAML

import yaml

with open("devices.yml") as f:
    devices = yaml.safe_load(f)

for d in devices:
    print(f"{d['hostname']:10} {d['mgmt_ip']:15} {d['role']}")

devices.yml

- hostname: leaf1
  mgmt_ip: 10.0.0.21
  role: leaf
- hostname: spine1
  mgmt_ip: 10.0.0.11
  role: spine

Output:

leaf1      10.0.0.21      leaf
spine1     10.0.0.11      spine

Now the network is data first. That data can feed Python, Ansible, or Terraform.

The same idea applies to firewalls. Instead of VLANs in a list, imagine a list of security rules with source, destination, and action. Loop through them and you can generate Palo Alto rule syntax or API calls. One pattern, many uses.

if you are a network engineer wondering where to start with automation, start with Python basics. They are small enough to practice in an evening and powerful enough to carry you through the whole stack.

Next I will show how I build device inventories as code and why “one device, one YAML” is the foundation for everything that follows.

Subscribe now

Leave a comment

That world teaches discipline with change control and deep knowledge of protocols. The job market now expects something more. Network engineers are expected to bring automation into the picture. For me, Python is the natural first step.

Why Python?

I am not learning Python to become a software developer. I am learning it because I want to do familiar network tasks faster and with fewer mistakes.

• Turn device inventories into data I can reuse

• Parse CLI output without copy and paste gymnastics

• Automate repeat jobs like backups and interface checks

Python is also the base layer for the rest of the stack. Once I am confident with loops, data structures, and file handling, the same habits carry straight into Ansible for configuration management and Terraform for cloud networking.

A small first step

Here is the sort of script I started with. Nothing clever, just a loop through a list of devices to print their management IPs:

devices = [
    {"hostname": "spine1", "mgmt_ip": "10.0.0.11"},
    {"hostname": "leaf1", "mgmt_ip": "10.0.0.21"},
]

for d in devices:
    print(f"{d['hostname']:10} {d['mgmt_ip']}")

Output:

spine1     10.0.0.11
leaf1      10.0.0.21

It does not change the world, but it does something useful. I have turned information into structured data and looped over it. That is the foundation for every bit of network automation that comes next.

What I am aiming for

Short term:

• Build a clean inventory of devices in YAML

• Use Python to read it and check basics like IP addresses, roles, and neighbours

Medium term:

• Generate configs instead of writing them by hand

• Back up running configs automatically

• Wire this into GitLab CI so every change gets linted and validated

• Start using Ansible playbooks for standard tasks like backups and VLANs

Long term:

• Extend the automation mindset into cloud networking

• Use Terraform to build VPCs and other cloud infra, while keeping on-prem and cloud consistent with Ansible

• Add Kubernetes networking later on, because containers and CNI plugins are now part of the story for modern platforms

This blog is where I will document that journey. I know the networks, that has been my career. Now I am adding the automation skills that the market increasingly demands.

Next up I will share why network engineers should start with Python basics and not jump straight into heavy frameworks.

Leave a comment

Connect on LinkedIn