DWRNetworking
AIDC Blueprint & Builder

AI data centers, designed and built from one blueprint.

From a single pod to a multi-site estate, AIDC Blueprint & Builder produces the fabric design, the physical plant and a validated Day-0 package from one design definition, so the network you sign off is the network that boots.

Start a conversation Meet the platform
Up to 4,608GPUs per site, then multi-site
3 planesback end, front end, OOB
Day 0 → Day 1design through turn-up
ISPEDGE GATEWAYBORDER LEAFSPINELEAFHOSTDPU/HBNRAILSPINE FEF-BL01FEF-BL02EDG-BG01EDG-BG02FEF-SP01FEF-SP02FEF-SP03FEF-LF01FEF-LF02FEF-LF03FEF-LF04RK01-H01RK01-H02RK02-H01RK02-H02BEF-LF01BEF-LF02BEF-LF03BEF-LF04BEF-SP01BEF-SP02 EDGE PoPFRONT ENDBACK ENDPER-TENANT VRF ON THE HOST DPU · eBGP UNDERLAY · LOSSLESS RoCEv2 RAILS EDG-ER01EDG-ER02ISP AISP BInboundOutboundTenant ATenant BGPU-to-GPU
SheetFAB-01
PlaneFE + BE
Scale1 pod
RevB
Introducing

AIDC Blueprint & Builder

One design definition, two engines. The Fabric Builder turns a GPU count and platform choice not just into a topology, but into an estate. DC Layout turns the same definition into the floor plan, rack elevations, power plan and cable order. Change an input and every output changes with it. Every DWR engagement is designed and delivered on it.

You choose
  • GPU count and platformFrom a single pod to a multi-site estate
  • A vendor per roleNVIDIA, Arista, Cisco, Juniper, Nokia
  • Site and regionNaming, addressing and ASNs follow
  • TenantsHosts assigned per tenant; VRFs, route targets and filters follow
AIDC Blueprint & Builder
Fabric BuilderBack end, front end, out-of-band, edge
DC LayoutHall, cabinets, power, cabling
One design definition, checked against written standards
You receive
  • Fabric designTopology, addressing, ASNs
  • Day-0 configsEvery device, ZTP and DHCP
  • Cable matrixEvery port, orderable lengths
  • Floor plan and elevationsPlaced by rule
  • Power planPSU to PDU outlet
  • Bill of materialsAll planes, all vendors
  • Written standardsRequirement and rationale
  • Source of truthLoads into NetBox or Nautobot
Built from standards, not intuition.

Every fabric is built from a library of written standards that set the requirement, the reasoning and the check behind every decision. The design holds up in review, the next site matches the last, and your team inherits the reasons along with the configs.

What you get

One blueprint, four deliverables that agree with each other.

Every drawing, config and cable label comes from the same design definition. Change a pod count or a platform and the topology, the BoM, the rack elevations and the device configs change together.

NETWORK

Fabric design

  • Back-end, front-end and OOB topology
  • IP plan, ASN plan, VNI and route-target scheme
  • Tenancy and segmentation model
  • Multi-site DCI, regional hub holding the internet edge
PHYSICAL

Plant and power

  • Floor plan and rack elevations
  • Per-device cable matrix and optics BoM
  • Power plan, PSU to PDU outlet
  • Bill of materials by platform
DAY 0

Bootstrap package

  • Per-device configs for every role
  • ZTP, DHCP and the provisioning host, in one installer file
  • Secrets rendered on site, never in the design
  • Validated in a virtual lab before hardware
STANDARDS

Written design standards

A library, not tribal knowledge.

  • Requirement and rationale for each decision
  • Addressing, roles, hardware, cabling, power
  • Verification steps for turn-up
  • Your team keeps them after handover
Scope of an engagement

Design through turn-up, then a clean handover.

DAY 0 · DESIGN

Blueprint

Requirements, scale and platform choices settled into one design definition. Drawings, BoM, standards and the full config set come out of it, reviewed with your team before anything is ordered.

DAY 1 · BUILD

Turn-up

One installer file brings up the provisioning host with a single command. Devices then boot from the Day-0 package, receive their configs and join the fabric, and each plane is verified against the standards' checks before it carries traffic.

DAY 2 · YOURS

Operations

Monitoring and change control stay with your team. The source of truth arrives ready to load into NetBox or Nautobot, with the design definition, the standards and the configs, so nothing depends on DWR Networking after handover.

DAY 1 TURN-UP

One installer file, one command

The Day-0 package ships as a single installer file. Copy it to the provisioning host and run one command. It checks itself, keeps the previous package and installs DHCP, the bootstrap server and the build console, so the site is ready to build in minutes.

$ sudo bash SJC-deploy-v476.run
[ok] package verified
[ok] previous package kept
[ok] unpacked 549 files
[ok] Kea started
[ok] 98 devices, 0 problems
→ https://172.16.16.10:8443

What the command does

  • Verifies the file against its SHA-256 before changing anything
  • Keeps the previous package, named by version and date
  • Installs Kea DHCP, the bootstrap server and the Estate Build Console
  • Asks before replacing another site’s install

Then the console builds the site

  • In order: OOB, edge, front end, back end
  • Each device matched by serial or MAC and served only its own files
  • Checks at each gate before the next plane opens
  • An as-built record and audit log for handover
DAY 2 HANDOVER

Source of truth, ready for NetBox and Nautobot

Import the whole design into NetBox, Nautobot, or both. Your source of truth starts from the same design definition as the configs, so the first audit finds nothing to reconcile. Every object loads as planned and goes active as the site is commissioned.

What it holds

  • Racks, devices, interfaces, power and console ports
  • Every cable, end to end
  • Prefixes, IP addresses on their interfaces, VRFs and route targets
  • VLANs and VNIs, tenants, ASNs and every BGP session

Where it goes

  • NetBox: CSV files in import order
  • Nautobot 2.x and 3.x: a loader script and a Nautobot Job, safe to re-run
  • Golden Config-ready platforms, BGP Models sessions
  • Ansible inventory for every device
DC Layout engine

The room, not just the fabric.

The same design definition lays out the data hall. Cabinets, rack units, power cords and cable runs are derived from the fabric, so the floor plan and the cable order can't drift from the configs.

Floor plan

Rows, cabinet classes and aisle widths derived from the pod count and cabinet dimensions. Drag a cabinet and every run length updates.

Rack elevations

Select any racked device to open its faceplate: each port mapped to its far-end device and port, with media, speed and run length, plus the model, rack units and power draw. Every device is placed by rule: heaviest lowest, a cable manager above each switch, reserved top units, unused space blanked.

Power to the outlet

PDU selection, per-side capacity against load, the cord for every PSU, phase balance and worst branch, and busbar segments for liquid-cooled racks.

Cable matrices

Every port on every device: far end, plane, speed, media, the derived run length and the orderable length. Export per device or for the whole site.

Length schedule

Site-wide cable quantities by plane and orderable length, rolled into the bill of materials.

Rule checks

Power, space and cabling rules checked across the whole hall. A newer design loads without losing the physical edits you made.

Demos

One site, from design to build. The same design for site SJC, carried from the builder to the provisioning host to a finished build, with nothing re-entered between them.

All five views come straight from AIDC Blueprint & Builder. The topology is a 128-GPU H100 build; the other four are from a 16-rack, two-pod HGX B300 build. The table and the config are excerpts.

How it compares

Other tools give you a slice. AIDC Blueprint & Builder gives you the whole pie.

GPU networking tools each do one part well: a vendor's fabric manager, a simulator, a fabric operator, a facility tool. None takes a GPU count to a multi-vendor design, configs, cable order, rack elevations and power plan from one definition.

CapabilityAIDC Blueprint & BuilderFabric Builder and DC LayoutVendor fabric managersApstra, Nexus HyperFabric AI, Arista AVD, Nokia EDADigital twinsNVIDIA DSX AirFabric operatorsHedgehog, Netris, Aviz ONESDCIM and facility toolsSunbird, Nlyte, Revit, ETAP
Multi-vendor designNVIDIA, Arista, Cisco, Juniper and Nokia from one definitionFullPartialOne vendor, or a short supported listPartialNVIDIA plus partner imagesPartialSwitch choice, their softwareNot offered
Sizes the fabric from the GPU countLeaves, spines, rails and oversubscription derivedFullPartialSome templates size; others need a hand-written modelNot offeredNot offeredNot offered
Back end, front end and OOB togetherThree planes in one designFullPartialMostly one fabric at a timePartialPartialNot offered
Day-0 configs for every deviceZTP, DHCP and provisioning host includedFullFullNot offeredTests configs you bringFullGenerated from their intentNot offered
Cable matrix with orderable lengthsEvery port, far end, media and lengthFullPartialCabling plan, no run lengthsNot offeredNot offeredPartialDocuments cables you enter
Floor plan and rack elevationsPlaced by rule from the fabricFullNot offeredNot offeredNot offeredFullDrawn by hand, not from the fabric
Power to the PDU outletCord per PSU, phase balance, busbarFullNot offeredNot offeredNot offeredFullNot tied to the network design
Bill of materials, all planesSwitches, optics, cables, PDUsFullPartialOwn catalog onlyNot offeredNot offeredPartialFacility side only
Written design standardsRequirement and rationale per decisionFullNot offeredNot offeredNot offeredNot offered
Validated in a virtual labBootstrap tested before hardwareFullPartialVendor lab imagesFullTheir core strengthPartialNot offered
Live Day-2 operationsMonitoring and change control after turn-upHanded overHanded over to your team or your toolsFullTheir core strengthPartialPre-change testingFullTheir core strengthPartialAssets and power
Full coverage
10 of 11
2 of 11
1 of 11
2 of 11
2 of 11

Full Partial Not offered Handed over

Day 2 belongs to your team. Blueprint & Builder hands over standard configs and written standards that your engineers, or any of the operations tools above, can run.

Ratings are by category, from each vendor's published material as of October 2026; individual products in a column vary. Product names are trademarks of their owners.

Scale

Sized in scaling units, grown without redesign.

A back end starts at a single pod and grows in 1,024-GPU scaling units: up to 4,096 GPUs at one site on HGX, 4,608 on NVL72. Each unit is added beside the last, not by rewiring it, and sites join through a data center interconnect hub.

1,024
2,048
3,072
4,096
4,608
Three planes

Each plane built for its own job.

BACK ENDGPU-to-GPU traffic only. Lossless RoCEv2, rail-optimized or Spectrum-X routed.
FRONT ENDMulti-tenant from the first hop: each tenant gets its own VRF on the host DPU, and the spines admit only that tenant's routes. Storage and ingress are shared by policy, with load balancing on BlueField-3.
OOBA separate management network with its own internet path, firewalls and remote access.
Power

One scaling unit, sized to a 3.5 to 4.0 MW site.

Power is the scarcest input in an AI data center and the costliest to leave unused. Every rack, switch and optic is rolled up to a facility load and checked against the utility feed before anything is ordered, so the megawatts you contract are the megawatts your GPUs draw.

1,024 HGX B300 GPUs on a 4.0 MW feed
  • Compute16 racks at 116 kW1.86 MW
  • Networkback end, front end, management0.11 MW
  • Cooling and lossesPUE 1.350.69 MW
  • Headroomon a 4.0 / 3.5 MW feed1.34 / 0.84 MW
94%

of IT power reaches the GPUs. Back end, front end and management networks together draw under 6%.

385GPUs per MW

of facility power: 1,024 GPUs in 2.66 MW, cooling and losses included.

67–76%of feed

Margin for a derate or a feed outage without stranding capacity. Past 90% the build is flagged; below half, the feed is flagged as oversized.

Platform and rackScaling unitIT load · facility at PUE 1.35Share of 3.5 MW · 4.0 MW feed
HGX B300, liquid8 nodes per rack, 116 kW1,024 GPUs · 16 racks1.97 MW · 2.66 MW76% · 67%
HGX B300 4U, liquid8 nodes per rack, 105.6 kW1,024 GPUs · 16 racks1.80 MW · 2.44 MW70% · 61%
GB300 NVL72one system per rack, 135 kW1,152 GPUs · 16 racks2.33 MW · 3.15 MW90% · 79%

Figures from the builder for one scaling unit, front end on. Compute uses vendor node figures; network power is modeled from populated ports and optics, not datasheet typicals. PUE 1.35 is the default and is set per site; the site electrical design gives the final numbers.

Platforms

Multi-vendor by design.

AIDC Blueprint & Builder is platform-neutral. Pick a vendor per role and the configs, optics and BoM follow.

VendorNetwork OSRoles
NVIDIA DEFAULTCumulus Linux, HBNBack-end and front-end leaf and spine (Spectrum-X SN5600), border leaf, DPU
NokiaSR OS, SR LinuxBorder gateway and edge router (7750 SR), leaf and spine
AristaEOSLeaf, spine, border leaf, border gateway, edge router
CiscoNX-OS, IOS XR, FTDLeaf, spine, border leaf, border gateway, edge router, firewall
JuniperJunos, Junos EVOLeaf, spine, border gateway, edge router, firewall (SRX)
F5BIG-IP Next for KubernetesIngress load balancing on BlueField-3
About

Built by a data center network architect.

DWR Networking is led by David Ross, a senior network architect with more than 30 years in networking, over 20 of them in data centers, most recently designing rail-optimized RoCEv2 GPU fabrics. AIDC Blueprint & Builder grew out of that work: one design definition that produces everything a build needs, checked against written standards.

Based in San Ramon, California, working with teams anywhere.

Contact

Planning an AI data center?

Tell us the GPU count, the number of sites and your preferred platforms. We will reply with how Blueprint & Builder fits your build and what an engagement looks like.

dross@dwrnetworking.com
San Ramon, California