RFC 1918 defines three private address ranges:

• 10.0.0.0/8 -- 16 million addresses
• 172.16.0.0/12 -- 1 million addresses
• 192.168.0.0/16 -- 65,536 addresses

For AI fabric deployments, 10.0.0.0/8 is the only range large enough. Use the full /8 and partition it cleanly between fabrics, pods, and device types. 172.16.x.x and 192.168.x.x are often already in use in the corporate network you are connecting to -- using them for the AI cluster creates the nightmare scenario where two default routes exist and traffic black-holes.

The recommended top-level partitioning for a multi-pod AI deployment:

10.0.0.0/8  --  ENTIRE AI CLUSTER
  |
  +-- 10.0.0.0/16   OOB management (BMC + switch mgmt0)
  |     10.0.1.0/24   DGX BMC addresses (BasePOD 1)
  |     10.0.2.0/24   Switch management addresses (BasePOD 1)
  |     10.0.3.0/24   UFM / monitoring servers
  |     10.0.10.0/24  DGX BMC addresses (BasePOD 2)
  |     ... /24 per pod, sub-allocated
  |
  +-- 10.10.0.0/16  Compute fabric loopbacks + server prefixes
  |     10.10.0.0/24  Switch loopbacks (BasePOD 1)
  |     10.10.1.0/24  Server host prefixes (BasePOD 1, rail 0)
  |     10.10.2.0/24  Server host prefixes (BasePOD 1, rail 1)
  |     10.10.10.0/24 Switch loopbacks (BasePOD 2)
  |     ... /24 per pod
  |
  +-- 10.20.0.0/16  Storage fabric
  |     10.20.1.0/24  DGX storage NICs (BasePOD 1)
  |     10.20.2.0/24  Storage appliance portals (BasePOD 1)
  |     10.20.10.0/24 DGX storage NICs (BasePOD 2)
  |
  +-- 10.30.0.0/16  EVPN tenant VRF subnets
  |     10.30.1.0/24  Tenant 1 GPU network
  |     10.30.2.0/24  Tenant 2 GPU network
  |     ... one /24 per tenant
  |
  +-- 10.100.0.0/16  Reserved for future SuperPOD expansion
  +-- 10.200.0.0/16  Reserved for interconnect to corporate network

This partitioning has three properties a network engineer cares about:

1. Summarisable: each pod's complete address usage fits in a small number of /16 or /24 aggregates. When you peer a BasePOD BGP fabric with a SuperPOD spine, you advertise 10.10.0.0/16 as a summary, not hundreds of /32 host routes. The corporate firewall policy stays manageable.

2. Non-overlapping by construction: OOB is always 10.0.x.x. Compute is always 10.10.x.x. Storage is always 10.20.x.x. There is no scenario where a DGX host confuses its BMC address with its GPU compute address because they are in different /16 blocks.

3. Pod-indexed: the third octet encodes the pod number. Pod 1 = .1.x, pod 2 = .10.x (leaving room within the pod for device type sub-allocation). When you see 10.10.1.45 in a log, you immediately know: compute fabric, BasePOD 1, server address.