A data center fabric planned and deployed in at most 2 days

The challenge

The fabrics were built by an in-house Python tool that issued direct commands to each device. With no abstraction in between, nothing described the fabric as a whole, so nothing could be scaled, moved to other hardware or checked before the hardware arrived. Build configuration went stale within months, so hardware replacements relied on config backups. Replacing a 32×400G SONiC top-of-rack switch with another vendor’s still meant manual work, and fragmented toolchains with manual handoffs made every new topology slow to deliver.

What was at risk:

• Weeks to define each large topology, hardware choices tied to manual rework, and fabric designs that could only be proven once the hardware was on the floor

What we did

• Built a generic toolkit first, with a schema language, a model generator, a source-of-truth database, a northbound API and a message bus, and built the network orchestration on top of it
• Generated topologies from declarative patterns, so scaling a fabric means changing roughly four parameters
• Split the fabric into layered specs, one concern at a time: layout, IP addressing, routing and hardware platforms, with non-conforming specs rejected before deployment
• Kept one configuration model with per-hardware renderers, so supporting a new platform means adding a renderer
• Automated bring-up through zero-touch provisioning: each device fetches an agent and receives the configuration for its role and position in the topology
• Emulated the full topology as a digital twin, so the team tests designs and changes before any hardware is touched
• Shipped new business logic as microservices that start and stop with no schema migration and no impact on other apps

How it works

A fabric goes from a spec written by a network engineer to a production-ready device in five stages.

1. Toolkit A generic foundation holds the model: a schema language and model generator, a source-of-truth database, a northbound API generated from the schema, and a message bus between components. The orchestration apps sit on top, in three zones: core apps for topology, configuration and emulation, client-specific logic such as hostname resolution and VLAN subnet sync, and a slot for custom apps. The platform is written in Go.
2. Topology Engineers describe a fabric as specs. Layout, IP addressing, routing and platform specs each solve one concern, and a fabric spec combines a topology with a connection pattern to produce an abstract graph. Routing is role-based, and one IP pool can serve several roles. The team confirms the pattern on a small topology, then scales it by raising leaf and interface counts.
3. Configuration Every device’s configuration is derived into one unified model, built before any hardware is targeted. Platform specs bind the abstract graph to physical hardware: common facts such as port count, speeds and breakouts, plus a node profile that maps each abstract link to a physical interface. Constraints are validated, and a spec that does not conform is rejected.
4. Rendering Renderers turn the one model into configuration for each hardware type. Rendering happens at the very end, so small differences between SONiC flavors, such as extra parameters or different names for the same field, are absorbed there.
5. Bootstrap A device is racked and powered on, DHCP delivers the boot file, and SONiC ZTP downloads the platform’s agent onto the switch. The agent calls the backend API, which generates the configuration in real time for the device’s role and position in the topology. The device boots production-ready, and every node follows the same path, so the whole topology comes up zero-touch.

Digital twin. The whole topology is emulated, in GNS3 and a second, lighter emulator, to test designs and changes, including how FRR and the routing policies behave. The first three stages need no physical hardware, so the resulting configuration is visible before a device arrives.