Structuring an IPAM Document

From Record-Keeping to Network Design

Before we start building our document structure, it's important to distinguish between simply recording what you've configured and proactively designing the network on paper first. The latter is a more disciplined approach that pays dividends on large-scale projects.

Let's explore this idea of "Design-Focused IPAM."

As you can see, our goal is to create a design-focused plan. The IPAM document is the tangible output of this planning process. It's the source of truth that will guide your CLI configurations, not the other way around.

The Essential Columns of an IPAM Document

An effective IPAM document needs to capture all the critical information about each network segment. While a simple spreadsheet can work for learning, we'll design a structure that could be implemented in a spreadsheet or a dedicated IPAM tool like NetBox.

Here are the essential fields (columns) your IPAM structure should include. We'll build this out logically.

1. VLAN Information: This links directly back to your VLAN plan.

   • VLAN ID: The number (e.g., 10, 20, 30).
   • VLAN Name: A short, descriptive name (e.g., CORP_USERS, SERVERS_PROD).
   • Description/Purpose: A more detailed explanation of the VLAN's function (e.g., "Corporate user workstations and laptops").

2. Subnet & Addressing Information: This is the Layer 3 information mapped to the VLAN.

   • Subnet (CIDR): The network address and prefix length (e.g., 10.1.10.0/24).
   • Network Address: 10.1.10.0
   • Broadcast Address: 10.1.10.255
   • Usable Host Range: 10.1.10.1 - 10.1.10.254
   • Gateway IP: The IP address of the SVI for this VLAN (e.g., 10.1.10.1 or 10.1.10.254).

3. Context and Lifecycle Information: These fields are vital for managing a large network over time.

   • Location/Site: Which building or campus this segment serves. This is crucial for your multi-building architecture.
   • VRF: The Virtual Routing and Forwarding instance this subnet belongs to. We'll discuss this in detail shortly.
   • Status: The current state of the subnet (e.g., Active, Reserved, Deprecated).

This structure provides a comprehensive, at-a-glance view of your entire addressing plan. The image below shows an example of a spreadsheet-based IPAM document that uses many of these principles.

Designing for Hierarchy and Meaning

For a large network, a flat list of subnets is not enough. A good IPAM structure reflects a logical hierarchy. This often means embedding meaning into the IP addresses themselves, a practice that greatly simplifies operations for anyone working on the CLI.

For example, using the 10.0.0.0/8 block, you could devise a scheme like 10.[SITE].[VLAN_ID].HOST.

• The second octet represents the physical site (e.g., 10.1.x.x for Building 1, 10.2.x.x for Building 2).
• The third octet represents the VLAN ID (e.g., 10.1.10.x for VLAN 10 in Building 1).

This creates a self-documenting address plan. When you're troubleshooting and see an IP like 10.2.30.55, you immediately know it's in Building 2 and belongs to VLAN 30.

This hierarchical thinking is at the core of professional IPAM tools. They don't just store a flat list; they organize IP space into nested blocks.

• Aggregate: The largest block of addresses you own or have been assigned (e.g., 10.0.0.0/8).
• Prefix: The individual subnets you carve out of the aggregate for specific purposes (e.g., 10.1.10.0/24). A prefix can also be a "container" for smaller prefixes.

Incorporating Your Specific Requirement: VRFs

You specifically mentioned needing to use Virtual Routing and Forwarding (VRF) to separate internet traffic. VRFs are essentially virtual routers inside your physical L3 switch, each with its own independent routing table. This is perfect for securely isolating traffic, such as separating a corporate network from a guest network.

Your IPAM document must account for this. By adding a VRF column, you explicitly document which routing domain each subnet belongs to. This is critical because VRFs allow you to have overlapping IP addresses. For example, you could have a 10.1.1.0/24 subnet in the CORP VRF and another 10.1.1.0/24 in the GUEST VRF, and they wouldn't conflict.

So, your IPAM table might look something like this:

Without the VRF column, this would look like a critical addressing error. With it, the design is clear.

Putting It All Together: The Final Structure

Let's summarize the structure of a robust IPAM document. Whether you build this in a spreadsheet for planning or directly into a tool like NetBox, these are the data points you need to capture for each and every subnet.

This structure provides a complete, unambiguous "source of truth" for your network's addressing plan.

Conclusion

In this lesson, you've learned how to design the architecture of an IP Address Management document. This is a critical step that elevates you from simply configuring devices to engineering a scalable and maintainable network.

Key Takeaways:

• An IPAM document is a design-focused tool that serves as the single source of truth for your network's intended state.
• A robust IPAM structure includes columns for VLAN info, detailed subnet calculations, location, status, and the assigned VRF.
• Designing with a hierarchy (e.g., 10.SITE.VLAN.HOST) makes the address space self-documenting and easier to manage.
• Dedicated IPAM tools like NetBox enforce this structure and provide powerful features for automation and validation that are essential for large networks.

You now have the template for your network's master plan. In the next lesson, Populate an IPAM document by mapping a VLAN plan to a VLSM allocation, you'll take the requirements from your VLAN plan and use your VLSM skills to start filling in this document with real, non-overlapping subnets.