Cisco MINT Field Blueprint: Migrating Distributed Multi-Site Switching and Wireless

Migrating enterprise switching and wireless infrastructure across dozens of distributed facilities requires deterministic execution. Under the Cisco MINT (Mentored Install Network Training) framework, the primary objective extends beyond hardware replacement: it builds automated provisioning, validation gates, and Day-2 operational capability directly within customer engineering teams.

Executing multi-site migrations without automated configuration pipelines and rollback safety mechanisms introduces configuration drift, site downtime, and operational reliance on external integrators.

Staging Pipeline and Pre-Configuration Architecture

Configuring access switches and wireless access points manually via local console during overnight cutover windows is a major source of deployment failure. A structured MINT deployment uses a centralised staging pipeline prior to equipment dispatch.

[Site Inventory Data (YAML)] 
           │
           ▼
[Jinja2 Template Pipeline] ────► [Validated Golden Configs]
           │
           ▼
[Pre-Staging Lab: ZTP / USB] ──► [Zero-Drift Pre-Provisioned Hardware]
           │
           ▼
[Packaged & Dispatched to Site]

Automated Image Verification and Zero-Touch Provisioning

Before applying site configurations, all Catalyst 9200/9300 switches are booted into a staging environment to standardise the software image.

Standardising on Cisco IOS-XE install mode:

# Verify active software packages and install mode
Switch# show version | include Installation mode
Installation mode: INSTALL

# Update and commit golden target image via CLI
Switch# install add source flash:cat9k_iosxe.17.09.04a.SPA.bin activate commit

Using DHCP Option 43 or Option 67 on the staging subnet enables switches to fetch startup scripts automatically, verifying licensing, cryptokeys, and management credentials without manual console intervention.

Template Parameterisation and Variable Modelling

Every site configuration is generated programmatically from a single Jinja2 template driven by a structured site inventory YAML file.

Site Data Model (site_inventory.yaml)

site_code: "LON-04"
management:
  vlan_id: 100
  subnet: "10.100.4.0/24"
  switch_ip: "10.100.4.2"
  default_gateway: "10.100.4.1"
vlans:
  data: 10
  voice: 20
  wireless: 30
  iot: 40
uplink:
  primary_port: "TenGigabitEthernet1/0/1"
  secondary_port: "TenGigabitEthernet1/0/2"
  channel_group: 1

Jinja2 Switchport and Uplink Macro Template (switch_template.j2)

hostname SW-{{ site_code }}

vlan {{ vlans.data }}
 name Corporate_Data
vlan {{ vlans.voice }}
 name Corporate_Voice
vlan {{ vlans.wireless }}
 name AP_Management
vlan {{ vlans.iot }}
 name Facilities_IoT
vlan {{ management.vlan_id }}
 name InBand_Mgmt

interface Vlan{{ management.vlan_id }}
 ip address {{ management.switch_ip }} 255.255.255.0
 no shutdown

ip default-gateway {{ management.default_gateway }}

interface Port-channel{{ uplink.channel_group }}
 description Core Uplink LACP
 switchport mode trunk
 switchport trunk allowed vlan {{ management.vlan_id }},{{ vlans.data }},{{ vlans.voice }},{{ vlans.wireless }},{{ vlans.iot }}
 switchport nonegotiate

interface {{ uplink.primary_port }}
 description Uplink Primary
 switchport mode trunk
 switchport trunk allowed vlan {{ management.vlan_id }},{{ vlans.data }},{{ vlans.voice }},{{ vlans.wireless }},{{ vlans.iot }}
 channel-group {{ uplink.channel_group }} mode active

interface {{ uplink.secondary_port }}
 description Uplink Secondary
 switchport mode trunk
 switchport trunk allowed vlan {{ management.vlan_id }},{{ vlans.data }},{{ vlans.voice }},{{ vlans.wireless }},{{ vlans.iot }}
 channel-group {{ uplink.channel_group }} mode active

template ACCESS_PORT
 switchport mode access
 switchport access vlan {{ vlans.data }}
 switchport voice vlan {{ vlans.voice }}
 spanning-tree portfast
 spanning-tree bpduguard enable
 service-policy input MARKING-IN

This template guarantees that security policies, QoS markings, and Spanning Tree settings remain completely consistent across all deployed sites.

Cutover Execution and Rollback Gates

During cutover, field engineers physically rack hardware and connect patch panels. Network engineers manage the cutover using strict rollback safety controls.

Automated Rollback Safety Mechanism

Before making critical trunk or core routing adjustments, enforce an automatic rollback timer:

Switch# archive
Switch(config-archive)# path flash:archive-config
Switch(config-archive)# write-memory
Switch(config-archive)# exit

# Schedule an automatic reload in case management connectivity is lost
Switch# reload in 30
System configuration has been modified. Save? [yes/no]: no
Proceed with reload? [confirm]

If the management link drops due to a trunk negotiation or VLAN mismatch, the switch reboots after 30 minutes, restoring the previous working configuration. If the cutover succeeds and connectivity is verified, cancel the timer:

Switch# reload cancel

Day-2 Operational Validation Script

Immediately following cutover, run an automated verification pass using a Python script interacting with the device via Netmiko or Scrapli:

#!/usr/bin/env python3
from netmiko import ConnectHandler

def validate_switch(host_ip: str, credentials: dict) -> None:
    device = {
        "device_type": "cisco_ios",
        "host": host_ip,
        "username": credentials["username"],
        "password": credentials["password"],
    }
    
    with ConnectHandler(**device) as net_connect:
        stp_out = net_connect.send_command("show spanning-tree summary")
        print(f"[{host_ip}] Spanning Tree Summary:\n{stp_out}\n")
        
        poe_out = net_connect.send_command("show power inline | include on")
        print(f"[{host_ip}] Active PoE Ports:\n{poe_out}\n")
        
        cdp_out = net_connect.send_command("show cdp neighbors | include AIR-AP|C91")
        print(f"[{host_ip}] Connected Cisco APs:\n{cdp_out}\n")

if __name__ == "__main__":
    creds = {"username": "admin", "password": "TargetPasswordHere"}
    validate_switch("10.100.4.2", creds)

Mentorship and Capability Transfer

The true differentiator of the Cisco MINT model is knowledge transfer:

1. Joint Engineering Labs: Customer engineers participate in template creation and pipeline execution rather than receiving a static handover document.
2. Troubleshooting Playbooks: Delivering exact CLI diagnostic procedures and automated rollback workflows tailored to the customer environment.
3. Day-2 Autonomy: The customer engineering team independently provisions subsequent branch locations using the automated pipelines established during the engagement.