Modular IOS-XE Configuration Generator

Problem

Building IOS-XE configurations for multi-site deployments is a manual, error-prone process. The typical workflow: copy a base template, open the IP plan spreadsheet, substitute hostnames, loopback addresses, WAN IPs, VLAN IDs, VRF names, BGP ASNs, and ACL prefixes for the new site. Repeat across 8 config sections. Do it for every site in a large venue deployment.

Errors compound in predictable ways: a stale IP from the wrong site’s column, a VLAN ID that didn’t get updated, a BGP neighbor address copied from the template site that now points at the wrong peer. The config passes syntax validation but fails in production because the values are wrong, not the structure.

The other failure mode is configuration drift — site 7 gets a security fix that never propagates to sites 1 through 6, because there’s no single source of truth for what a correct config looks like.

Solution

Built a modular config generator where each configuration section — hostname and domain, interface addressing, OSPF, BGP, VRF definitions, ACLs, NTP/AAA/SNMP, and more — is a toggleable module with its own Jinja2 template and YAML metadata defining required variables, optional variables, and dependencies on other modules.

Engineers select which modules apply to a given site type, fill in site-specific variables through a form UI, and get a complete rendered config with live preview. IPAM integration pulls real IP assignments directly from the team’s Google Sheets IP plan, eliminating the copy-paste step and the IP errors that come with it. Profiles stored in SQLite let engineers save per-site and per-device variable sets for reuse across maintenance windows.

Architecture

Svelte Frontend
    ├── Module selector (toggle switches per section)
    ├── Variable form (dynamically generated from YAML metadata)
    ├── Live config preview (updates on every keystroke)
    └── Profile manager (save/load per-site variable sets)
            │
            ▼
FastAPI Backend
    ├── GET /modules → list available modules + YAML metadata
    ├── POST /render → Jinja2 template rendering + validation
    ├── GET /ipam/lookup → Google Sheets API → IP assignments
    └── SQLite → profile CRUD (per-site, per-device)

Module structure (per config section):
    modules/
        ospf/
            template.j2     ← Jinja2 config template
            metadata.yaml   ← variables, defaults, dependencies
        bgp/
            template.j2
            metadata.yaml
        ...

The frontend generates variable input forms dynamically from each module’s YAML metadata — field types, validation rules, and default values come from the module definition, not hardcoded UI components. Adding a new module requires only a template and a metadata file; no frontend changes needed.

Key Decisions

Jinja2 over a custom template syntax. Network engineers writing automation already know Jinja2 from Ansible. Using the same syntax means the templates are readable and maintainable by the team that uses the tool, not just the person who built it. Custom template syntax would require documentation, editor plugins, and re-learning for every new team member.

YAML metadata per module. Each module is self-describing. The metadata file defines what variables the template needs, which are required vs. optional, what types they expect (IP address, CIDR prefix, integer, string), and which other modules must also be enabled (e.g., BGP peer module requires VRF module). This makes the module system extensible without modifying backend code — add a module directory, the API discovers it automatically.

Google Sheets for IPAM integration. Most network teams already maintain their IP plans in a spreadsheet. Building IPAM integration against a tool they already use means zero adoption friction. A custom IPAM database would require migrating existing data and changing team workflows. Sheets integration meets teams where they are.

SQLite profiles for multi-site reuse. Variable sets for each site get saved as named profiles. The BGP ASN, loopback address, site code, and VLAN ranges for “Site-ATL-01” are stored once and reloaded every time that site needs a config update. This also enables bulk generation — render configs for all saved profiles in one operation.

Results

• 12+ config modules: hostname/domain, management interface, loopback, WAN interfaces, OSPF, BGP, VRF, ACLs, NTP, AAA, SNMP, logging
• Live config preview updates as variables are filled in, before rendering is requested
• IPAM integration pulls live IP assignments from Google Sheets (no copy-paste)
• SQLite profile storage for per-site and per-device variable sets
• Dynamic form generation from YAML metadata — new modules require no frontend changes
• Bulk config generation across all saved profiles with single API call
• Jinja2 templates are readable and editable by network engineers without code changes

How This Scales

• Compliance validation — Post-render, pass the generated config through a compliance checker (CIS benchmarks, internal standards) and highlight violations before the config ever reaches a device.
• Git integration — Commit generated configs to a repository per site with each render, providing a full history of config changes tied to the profile state at generation time.
• CI/CD pipeline mode — API-only rendering triggered from a pipeline: pull updated IP assignments from Sheets, render all site profiles, diff against current deployed configs, open change tickets for diffs that exceed a threshold.
• Multi-platform expansion — The module system is platform-agnostic. NX-OS, IOS-XR, and Arista EOS modules could be added alongside IOS-XE, with platform selection as a top-level profile attribute.

Tech Stack

• Backend: Python, FastAPI, Jinja2 (template rendering)
• Frontend: Svelte (dynamic forms, live preview)
• Templates: Jinja2 (.j2) with YAML metadata per module
• Database: SQLite (profile storage via SQLAlchemy)
• IPAM: Google Sheets API (IP assignment lookups)
• Config: YAML (module metadata, variable definitions)