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 multi-location 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 declaring its variables, render order, 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 (Quick Setup panel + YAML editor with computed-variable calculator)
    ├── 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 (published CSV) → IP assignments
    └── SQLite → profile CRUD (per-site, per-device)

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

Each module’s YAML metadata declares its variables, render order, and dependencies on other modules — the module selector and dependency handling are driven entirely by metadata. Adding a new module requires only a template and a metadata file; it appears in the UI with no frontend changes.

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 declares what variables the template needs, the order it renders in, 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-DEN-01” are stored once and reloaded every time that site needs a config update. Bulk generation is driven separately, from an imported CSV or Google Sheet — one API call renders every site’s config into a ZIP.

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
• Module auto-discovery — drop in a template + metadata directory and it appears in the UI with no frontend changes
• Bulk config generation from an imported CSV or Google Sheet — one API call renders every site’s config into a ZIP
• 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)
• IPAM: Google Sheets integration (published-sheet CSV export)
• Config: YAML (module metadata, variable definitions)