You are standing in front of a blank rack. Eight DGX H100 nodes in boxes. Four leaf switches. Two spine switches. A storage switch. An OOB switch. A UFM server. An allocation spreadsheet open on your laptop.
What goes in that spreadsheet?
Every chapter before this one assumed the fabric had working IP addresses. This chapter explains how those addresses were chosen -- and why a wrong choice made here will haunt you at 3am when a training job stalls because two pods share an overlapping range and the BGP session between them never came up.
IP addressing for an AI fabric is not complicated, but it is unforgiving. There are no spanning tree reconvergences to mask a bad design. There is no NAT to hide an overlap. Every address must be correct, unique, and consistently assigned before the first GPU sends a packet. A network engineer who understands why each range exists and how the pieces fit together can address a BasePOD in under an hour. One who does not will spend a week debugging mysteriously absent BGP routes.
This chapter takes you through every address family in an AI fabric -- loopbacks, P2P links, server prefixes, BMC ranges, storage ranges, VXLAN VNIs, VLAN IDs -- with a complete worked example for a BasePOD that scales cleanly to SuperPOD.