Skip to main content

Infrahub demo-sp example

Welcome to the Infrahub demo-sp example — a service-provider bundle that shows how Infrahub manages a multi-vendor MPLS backbone and provisions customer-facing services end to end. It demonstrates Infrahub's core capabilities through a realistic SP workload:

  • Schema-driven data modeling for backbone and customer services
  • Generator-driven provisioning (VRF, RT, PE-CE interfaces, IP allocation, BGP)
  • Per-vendor configuration artifacts from a shared schema
  • Version-controlled changes with proposed-change diff review
  • A Streamlit Service Catalog for self-service L3VPN and SD-WAN provisioning

Whether you're a network engineer evaluating automation, a developer building on Infrahub, or an architect comparing infrastructure-data platforms, this demo gives you a hands-on view of how an SP team would model and operate a real backbone.

Documentation guide​

This documentation follows the Diataxis framework so you can find the right kind of page for what you need to do.

Getting started​

PagePurpose
Quick startStep-by-step instructions to clone the repository, configure .env, start Infrahub, and load the bootstrap data. Start here on your first run.

Tutorials​

PagePurpose
L3VPN service walkthroughEnd-to-end tour of the L3VPN service: how the catalog form drives ServiceL3Vpn creation, what the generator materialises (VRF, RTs, PE-CE links, eBGP), what each per-vendor template emits, and how the validation checks fit together.
SD-WAN service walkthroughCompanion tour of the SD-WAN service: vendor choice (Cisco Viptela vs Versa Networks), hub-spoke vs full-mesh topology, generator-created edge devices, and per-vendor edge configurations.
Deploy with containerlabTake the rendered MPLS backbone artifacts and bring them up in a virtual lab with containerlab. Cover Arista cEOS, Nokia SR Linux substitution, and how to reach the lab CLIs.

Topics​

PagePurpose
ArchitectureThe "why" behind the demo — backbone design choices, service modelling, generator vs catalog responsibilities, and the lifecycle of a customer service.
Schema referenceField-level documentation of every node (ServiceL3Vpn, ServiceSdwan, TopologyMplsBackbone, …), the resource pools, and the user-vs-generator split for each attribute.

Operations​

PagePurpose
TroubleshootingSymptoms and fixes for common issues — stuck repository sync, generator races, broken artifacts, and how to inspect live state when something looks off.

Quick start​

If you're ready to dive in:

  1. Follow the quick start to clone the repository, configure .env, and run uv run invoke init.
  2. Open the Infrahub UI at http://localhost:8000 and explore the seeded data — Devices, MPLS Backbones, Service Catalog → L3 VPNs and SD-WAN.
  3. Provision a new service from the Streamlit Service Catalog at http://localhost:8501.
  4. (Optional) Bring up the MPLS backbone in containerlab.
  5. Read the architecture and schema reference to understand the moving parts before you extend the demo.

What you'll learn​

Through this demo, you'll gain practical experience with:

  • Modelling SP services in Infrahub — ServiceL3Vpn / ServiceSdwan with uniqueness constraints, parent/child relationships, and lifecycle status.
  • Resource pools — vpn_id_pool, sdwan_id_pool, customer_asn_pool, pe_loopback_pool, backbone_p2p_pool, pe_ce_pool for deterministic allocation.
  • Generators — Materialising VRFs, route targets, PE-CE /30 allocations, eBGP sessions, and SD-WAN edge devices from a single user-facing object.
  • Per-vendor transforms — Rendering the same intent into Arista EOS, Cisco IOS-XR, Juniper Junos, Nokia SR OS, Cisco Viptela, and Versa VOS configurations.
  • Validation checks — Catching duplicate RDs, overlapping customer prefixes, exhausted interface pools, and missing iBGP sessions before merge.
  • Branch-based workflows — Catalog form → feature branch → generator → artifact regeneration → proposed change → review → merge.
  • Containerlab — Booting the rendered backbone in a virtual lab for hands-on testing.

Architecture at a glance​

Out of the box the financial dataset gives you the Sterling Financial MPLS backbone — eight Arista cEOS PEs (pe-01…pe-08) in a partial mesh, with four pre-provisioned Arista cEOS CE routers hanging off the two hub PEs — plus three seeded customer services — two L3VPNs and one SD-WAN — wired up end to end:

Backbone — Eight PE routers, all Arista cEOS (pe-01…pe-08), in eight EMEA sites. The topology is a partial mesh of 15 p2p links: pe-01 (London) and pe-08 (Zurich) are the degree-2 hub PEs carrying every customer attachment, and pe-02…pe-07 form the meshed core between them at degree 4–5. Over the top runs a full iBGP/VPNv4 mesh, ISIS for underlay reachability, and LDP for label distribution. (The isp dataset instead ships a four-PE, one-per-vendor backbone — see below.)

Customer edge — Four pre-provisioned Arista cEOS CE routers, two per customer, on the hub PEs: ce-trading-lon/ce-ib-lon on pe-01 and ce-trading-zrh/ce-ib-zrh on pe-08. Each has its own rendered configuration artifact, so the PE-CE eBGP session comes up for real in the lab.

L3VPN services — trading-floor-vpn (tenant markets-trading) and ib-advisory-vpn (tenant investment-banking), each with a London and a Zurich site, eBGP PE-CE sessions, and one /24 customer subnet per site in the 10.200.0.0/16 supernet. Each customer peers from its own AS, allocated from customer_asn_pool.

SD-WAN service (treasury-branch-sdwan) — Tenant treasury-ops, hub-spoke on Cisco Viptela cEdge-1000 edges at London (hub), Frankfurt and Amsterdam (spokes); LAN subnets in the 10.250.0.0/16 supernet.

An alternate isp dataset (Lumina Networks pan-European ISP) ships its own backbone — four PEs, one per vendor (pe-lon-arista, pe-fra-cisco, pe-ams-juniper, pe-par-nokia), full-mesh iBGP over six p2p links — plus eight customer tenants and a different default L3VPN and SD-WAN. Select it via the INFRAHUB_DATASET env var.

Key features demonstrated​

Schema-driven service modelling​

ServiceL3Vpn, ServiceL3VpnSite, ServiceSdwan, ServiceSdwanSite define not just object shape but uniqueness constraints, parent/child relationships, dropdown enums for vendor and topology, and lifecycle status. See the schema reference for the full field tables.

Generator-driven provisioning​

When a catalog form creates a ServiceL3Vpn or ServiceSdwan and the row joins the l3vpns or sdwans group, Infrahub auto-fires the matching generator. The L3VPN generator allocates a VRF, route targets, a customer AS from customer_asn_pool, a /30 from pe_ce_pool, sets up the PE interface, and writes the eBGP session on both ends of each site — the CE end too, when the site names a pre-provisioned CE router. The SD-WAN generator materialises one CPE per site, allocates the LAN address from the customer subnet, and adds the edge to the vendor-specific group so the artifact pipeline targets it.

Per-vendor configuration artifacts​

A single schema drives seven Jinja2 templates: Arista EOS (PE), Arista EOS (CE), Cisco IOS-XR, Juniper Junos, Nokia SR OS / SR Linux, Cisco Viptela cEdge (IOS-XE SD-WAN), and Versa VOS (FlexVNF). Each PE, CE, or edge ends up with a text/plain configuration artifact keyed by name__value, ready to feed into a CI/CD push. The default financial backbone is all-Arista, so it exercises the two Arista templates; the isp dataset, with one PE per vendor, exercises the full per-vendor set.

Branch-based workflows​

Every catalog submission opens a feature branch (l3vpn/<hex> or sdwan/<hex>), creates objects on the branch, polls the generator to completion, regenerates artifacts so the diff is meaningful, and opens a CoreProposedChange against main. Validation checks run on the PC before merge.

Containerlab integration​

The clab-mpls-topology artifact emits a containerlab YAML wiring the lab-deployable PEs and their backbone links, derived from the shared /31 addressing, plus every pre-provisioned CE and its PE-CE access link. For the default financial backbone that's eight Arista cEOS PEs, 15 backbone links, and four cEOS CEs that bring up real eBGP sessions against their PEs; for the isp dataset it's the Arista and Nokia PEs (Nokia SR OS substituted to SR Linux for the lab image). See the containerlab guide.

Community and support​

Next steps​

Ready to get started? Head to the quick start to set up your environment.