DWRNetworking
AIDC DBD · Design · Build · Deploy

AI data centers, designed and built from one blueprint.

From a single pod to a multi-site estate, AIDC DBD 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
295K GPUsdesigned · 117K verified
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 DBD

Design · Build · Deploy

One design definition, three parts. The Fabric Designer turns a GPU count and platform choice not just into a topology, but into an estate. The DC Layout Builder turns the same definition into the floor plan, rack elevations, power plan and cable order. The Deployment Console installs every device from it and tracks the build through acceptance. 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 DBD
Fabric DesignerBack end, front end, out-of-band, edge
DC Layout BuilderHall, cabinets, power, cabling
Deployment ConsoleZero-touch install, tracking, acceptance
One design definition, checked against written standards
You receive
  • Fabric designTopology, addressing, ASNs
  • Day-0 configsEvery device, ZTP and DHCP
  • Cable matrixEach cable once, with 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
  • Cable matrix (each cable once, with lengths) 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 DEMO-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 Deployment 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 matrix

Every cable listed once, under the leaf, switch or PDU it plugs into, in build order: power, out-of-band, Edge PoP, front end, back end. Each row has the far end and cabinet, speed, media, run length and orderable length, with a how-to-read note. Excel or PDF for the whole site, per device for a crew at one switch.

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

16 HGX racks, from a rack count to a data hall. 512 H100 GPUs at 400G per GPU, 4 racks per pod, front-end plane on. Five steps in the designer, with nothing re-entered between them.

The designer with HGX 8x400G, 4 racks per pod and 16 racks entered. A red note beside the rack count says the box says 16 but the model has 2, click Build.
1 · Set the count. Pick the fabric (HGX 8×400G), the pod size (4 racks) and the rack count (16), then the platforms for each tier. Until you click Build, the page flags that the model still holds the previous design, so nothing downstream is drawn from stale inputs.
Click a screenshot to enlarge it; Esc closes.

Every view comes straight from AIDC DBD. The step-by-step demo and both topology tabs are one 16-rack, 512-GPU HGX H100 build; the Design to Deploy Demo follows site DEMO, a 16-rack HGX B300 build, as do the floor plan, rack elevation, cable matrix and config. The table and the config are excerpts.

How it compares

Other tools give you a slice. AIDC DBD 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 DBDFabric Designer, DC Layout Builder and Deployment ConsoleVendor 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 lengthsEach cable once: 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
Telemetry built inEvery device set up to report from first power-on, collector setup includedFullPartialOwn vendor onlyNot offeredPartialSupported switches onlyNot 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
11 of 12
2 of 12
1 of 12
2 of 12
2 of 12

Full Partial Not offered Handed over

Day 2 belongs to your team. AIDC DBD 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

From one pod to a hyperscale campus.

The same design definition takes a 4-rack, 256-GPU cluster to a 4,096-rack site, then to multi-site regions, without starting over: the back end grows in scaling units, and each plane is built for its own job.

Scaling units

Sized in scaling units, grown without redesign.

A back end starts at a single pod and grows in scaling units, each added beside the last as a pod of one three-tier fabric, never by rewiring it. Verified to 117,000 GPUs in one site (1,625 Vera Rubin NVL72 racks: 360.5 MW of IT load, 487 MW of facility power, 44 data halls) and designed to 295,000 (4,096 racks). Past the hyperscale template, a site takes a mega-site address block and ASN range of its own.

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.
Vera Rubin NVL72 in scaling units of 16 racks (1,152 GPUs), one site, front end on
Scaling units · racksGPUsIT load · facility at PUE 1.35Status
1 SU · 16 racks1,1523.57 MW · 4.82 MWVerified
4 SUs · 64 racks4,60814.7 MW · 19.9 MWVerified
8 SUs · 128 racks9,21629.6 MW · 40.0 MWVerified
16 SUs · 256 racks18,43259.3 MW · 80.0 MWVerified
32 SUs · 512 racks36,864118.5 MW · 160 MWVerified
≈102 SUs · 1,625 racks117,000360.5 MW · 487 MWVerified44 data halls, 216 power blocks
128 SUs · 2,048 racks147,456≈454 MW · ≈613 MWDesigned
256 SUs · 4,096 racks294,912≈909 MW · ≈1.23 GWDesigned

Figures from the builder; ≈ marks loads scaled from the 1,625-rack design (compute at 210.1 kW per rack, network at its 1,625-rack share). A larger site draws slightly more than its units added up, for the super-spine tier. On HGX, one site's addressing reaches approximately 65,000 GPUs; beyond that, sites join through a data center interconnect hub.

Platforms

Multi-vendor by design.

AIDC DBD is platform-neutral. Pick the GPU platform, its cooling and a vendor per role, storage included, and the configs, optics, cabling and BoM follow.

VendorOS / platformRoles
GPU compute
NVIDIAHGX H100, H200, B2008 GPUs per node, ConnectX-7 400G, 8 back-end rails; air-cooled
NVIDIA DEFAULTHGX B3008 GPUs per node, ConnectX-8 800G, 8 rails on two planes; air-cooled, or 4U liquid at 64 GPUs per rack
SupermicroSYS-422GS-NB3RT-LCCHGX B300 4U, direct liquid, 8 nodes per rack
NVIDIAGB300 NVL7272 GPUs per rack in one NVLink domain, ConnectX-8 800G; multi-plane back end, 2 planes at 400G or 4 at 200G; direct liquid or immersion
NVIDIAVera Rubin NVL7272 GPUs per rack in one NVLink domain, ConnectX-9 1.6T or ConnectX-8 800G; multi-plane back end, 4 or 8 planes; direct liquid or immersion; 16-rack scaling unit
Cooling
Rack OEM DEFAULTDirect liquid (cold plate)Liquid HGX and NVL72 racks, in-row CDUs
Customer choiceImmersion containersSingle-phase immersion for NVL72, sized to the container vendor's figures: tanks grouped per container, leaf and spine switches in the tanks
Network
NVIDIA DEFAULTCumulus Linux, HBNBack-end and front-end leaf and spine (Spectrum-X SN5610), border leaf, DPU
NVIDIASpectrum-6, Cumulus LinuxBack-end leaf and spine for NVL72: SN6600-LD, and SN6810-LD and SN6800-LD with co-packaged optics, in MGX racks
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
Storage
WEKA DEFAULTWEKApodStorage on the front end (WEKA protocol over UDP)
DDNEXAScaler AI400X3Storage: Lustre appliances over RDMA
VAST DataCNode + DBoxStorage: NFS over TCP, VIPs advertised over BGP
Pure StorageFlashBlade//EXAStorage: metadata chassis plus data nodes, pNFS

Product names are trademarks of their owners. Listing a product means AIDC DBD designs for it; it implies no partnership, certification or endorsement.

Power

Scaling units of 3.5 to 4.0 MW, verified to 487 MW, designed to 1.2 GW.

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.12 MW
  • Cooling and lossesPUE 1.350.69 MW
  • Headroomon a 4.0 / 3.5 MW feed1.33 / 0.83 MW
94%

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

383GPUs per MW

of facility power: 1,024 GPUs in 2.67 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.98 MW · 2.67 MW76% · 67%
HGX B300 4U, liquid8 nodes per rack, 105.6 kW1,024 GPUs · 16 racks1.83 MW · 2.47 MW71% · 62%
GB300 NVL72one system per rack, 135 kW1,152 GPUs · 16 racks2.36 MW · 3.18 MW91% · 80%4.0 MW feed recommended
Vera Rubin NVL72one system per rack, 210.6 kW1,152 GPUs · 16 racks3.57 MW · 4.82 MW138% · 120%needs a 5.5 MW feed

Scaling out (HGX B300 liquid, facility load at PUE 1.35)
4,608 GPUs · 72 racks · 12.4 MW9,216 GPUs · 144 racks · 24.7 MW18,432 GPUs · 288 racks · 49.6 MW

Scaling out (Vera Rubin NVL72, facility load at PUE 1.35)
4,608 GPUs · 64 racks · 19.9 MW9,216 GPUs · 128 racks · 40.0 MW18,432 GPUs · 256 racks · 80.0 MW36,864 GPUs · 512 racks · 160 MW117,000 GPUs · 1,625 racks · 487 MW294,912 GPUs · 4,096 racks · ≈1.23 GW

Figures from the builder for one scaling unit and for the larger sites, front end on; a larger site draws slightly more than the units added up, for the super-spine tier. Compute uses vendor node figures; network power is modeled from populated ports and optics, not datasheet typicals. Vera Rubin NVL72 draws about 56% more per rack than GB300, so its 16-rack unit needs a feed of about 5.5 MW. PUE 1.35 is the default and is set per site; the site electrical design gives the final numbers.

Telemetry

Telemetry, prefabbed into every config.

AIDC DBD writes the telemetry into every configuration it generates: streaming counters, drop and queue-depth visibility on every fabric switch, RoCE counters on every DPU, and a ready-made collector setup from the IP plan. The fabric reports from first power-on, with no separate monitoring project.

WhereWhat AIDC DBD configuresWhat you see
Every switchgNMI streaming over TLS, syslog, SNMPv3, sFlowPorts, BGP, optics, traffic mix; on the GPU and storage planes, PFC pauses, ECN marks and queue drops
Fabric switchesNVIDIA What Just Happened and queue-depth histograms, Arista LANZ, Nokia queue-depth sampling; Cisco and Juniper queue depth over gNMIWhich packets dropped and why, and how deep the queues ran: the microbursts behind a slow job
Every DPUDOCA Telemetry Service with a Prometheus endpointRoCE health per host link: congestion notifications, buffer drops, PFC
GPU hostsDOCA Telemetry Service with GPU metrics, as a documented optionNIC and GPU counters side by side
Your collectorsTelegraf configuration and a Prometheus scrape list, generated from the IP planEvery target labeled by site, build, pod and role, ready to load

DWR prepares every device to report; your NOC tooling collects, whether Prometheus and Grafana, NVIDIA NetQ or your own. Platform-specific features follow each vendor’s documentation for the release in service.

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 DBD 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 AIDC DBD fits your build and what an engagement looks like.

dross@dwrnetworking.com
San Ramon, California
Click the image for actual size. Esc or click outside to close.