You Inherited a Network Nobody Documented: Building an IP Inventory from Scratch

The documentation says the network has nine subnets. Four of them no longer answer a ping, two segments carrying real traffic appear nowhere on the page, and the person who wrote it left the company eighteen months ago. Anyone who has taken over from a departed predecessor, started a new job as the only network person, or absorbed an environment through an acquisition knows this moment. The network works. Payroll runs, printers print, the Wi-Fi holds. And nobody, including the person now responsible for it, which is to say you, can explain more than half of what is on it.

The temptation is to wait for the network to force the issue, and it will, at the worst possible time. An outage on an undocumented network turns into a scavenger hunt: which subnet is that, what else lives on it, and is 10.20.40.17 safe to reassign or is it the badge-door controller? The alternative is to spend a few deliberate days building an IP (Internet Protocol) inventory before anything breaks: the subnets that exist, the addresses in use inside each one, and enough context per address to know what happens if it disappears. The work is smaller than it looks, because a running network documents itself, involuntarily and continuously. Every router holds a routing table, every DHCP (Dynamic Host Configuration Protocol) server holds its leases, every switch remembers the hardware addresses it has seen, and every DNS (Domain Name System) zone records the names someone once cared enough to assign. None of those sources is complete on its own, and none of them can lie the way a wiki page can. Rebuilding the inventory means collecting the fragments, reconciling them, and writing the result down somewhere that outlives you. Every step is read-only, which matters when you are new and everything is production: nothing in this guide changes a single line of configuration.

Start at the default gateway, because the router that moves traffic between subnets has to know about all of them to do its job. The routing table is the skeleton of the network, and on most equipment one command dumps it. What you care about first are the connected routes, the entries the router knows because one of its own interfaces sits directly on that subnet. Each connected route is a segment that physically exists right now, with a prefix that records exactly how big someone intended it to be. Static routes, the entries an engineer typed in by hand, are a different kind of evidence: each one points at another router that was worth reaching on purpose, which usually means another site, another firewall, or another chunk of network hiding behind the hop.

The routing table on the core switch

core-sw# show ip route
Codes: C - connected, S - static, O - OSPF

C    10.20.10.0/24   directly connected, Vlan10
C    10.20.20.0/24   directly connected, Vlan20
C    10.20.30.0/27   directly connected, Vlan30
C    192.168.8.0/24  directly connected, Gi0/2    ← not on the wiki page
S    10.99.0.0/16    via 10.20.10.254             ← who is .254?
O    172.22.0.0/16   via 192.168.8.1              learned from another router

Read the table like a dig site. The connected /24s on named VLAN (virtual LAN) interfaces are your user and device segments, and the interface names are themselves hints about how the network was carved; if the prefix lengths read as noise, our visual guide to CIDR (Classless Inter-Domain Routing) notation covers what a /27 means and why someone chose it. The static route pointing at 10.20.10.254 is an invitation: log into that device and dump its routing table too, because networks are graphs, and every router you find adds edges to yours. Repeat until the routes stop leading anywhere new. Along the way, expect to meet address ranges that look odd on purpose. A block inside 100.64.0.0/10 or a stray 169.254 entry each means something specific, and our guide to the reserved IP ranges sorts out which of those discoveries are deliberate design and which are symptoms.

The DHCP server is the next stop, and it holds two different documents. The scope definitions record intent: which subnets hand out addresses automatically, where each pool starts and stops, and, by omission, which slice of each subnet was set aside for static assignment, since the addresses outside the pool boundaries are exactly where the routers, servers, and printers were meant to live. Our guide to DHCP, static addresses, and reservations explains that carving in detail. The lease table records reality: a census of every device that asked for an address recently, complete with hostname, MAC (Media Access Control) address, and expiry time. Reservations are the best entries of all, because each one marks a device that mattered enough for someone to pin its address, and a reservation with a descriptive name is the closest thing to genuine documentation you will find all week.

Routing tables show you subnets, and DHCP shows you the devices polite enough to ask for an address. The ARP (Address Resolution Protocol) cache shows you everyone else. ARP is how a router maps an IP address to the hardware address of the machine that owns it, so the router's ARP table lists every device that has exchanged traffic through it recently, static assignments included, whether or not a record of them exists anywhere else. On the core router, show ip arp covers every connected segment at once. The MAC addresses carry information of their own: the first three bytes are the OUI (Organizationally Unique Identifier), a vendor code you can look up, so a segment where every entry resolves to Axis or Hikvision has introduced itself as the camera network without anyone having to tell you.

Passive sources only reveal devices that have talked recently, so round out the picture with a gentle active sweep. A ping scan with nmap, the standard free network scanner, asks every address in a subnet to answer and reports who does. The value is in the cross-check as much as the count.

A ping sweep, cross-checked against ARP

$ nmap -sn 10.20.20.0/24
Nmap scan report for 10.20.20.1     gateway
Nmap scan report for 10.20.20.31
Nmap scan report for 10.20.20.44
...
Nmap done: 256 IP addresses (61 hosts up) in 3.20 seconds

Yesterday's ARP capture for this subnet: 58 entries.
Three devices answer a ping but appear in no other source. Find them.

Treat scanning with respect, even as the person responsible for the network. Announce it through whatever change process exists, stay with ping sweeps rather than port scans at first, and be especially gentle around building systems, lab equipment, and elderly printers, some of which respond to an aggressive scan by falling over. Run the sweep more than once and at different hours, because the 9 a.m. population of a subnet includes laptops that the 3 a.m. population lacks, and a mid-month scan misses the machines that only wake up for month-end processing. Absence from a scan is weak evidence; presence is strong.

DNS zones are the last major excavation. The forward zone maps names to addresses and preserves what people wanted to call things, which carries more meaning per byte than any other source; a record named backup-nas-old is a story in three hyphens. The reverse zone, the PTR (pointer) records that map addresses back to names, tends to be the most neglected corner of any network, and every stale entry is a small artifact. A name that resolves to an address that no longer answers is either a machine that sleeps or a record nobody deleted, and both possibilities earn a line in your notes. Where the DNS server logs queries, those logs surface one more population: clients that exist and resolve names all day but appeared in no other source.

If any part of the environment lives in a cloud, the provider consoles hold inventory that no on-premises tool will ever see. Each VPC (Virtual Private Cloud) on AWS and each VNet on Azure is a subnet allocation as real as anything in the server room, and the provider command-line tools will export every CIDR block, and the used addresses inside it, in a command per account. Collect those exports alongside the on-premises data rather than treating them as a separate world, because the overlap between a forgotten VPC and a campus subnet stays invisible until the day a VPN (virtual private network) tunnel connects them; our guide to multi-cloud and hybrid IPAM walks through that failure mode and the single-source-of-truth fix.

Each source has a blind spot, which is why the inventory needs all of them. The table below is the working checklist.

The inventory takes shape during reconciliation, when the sources start disagreeing in informative ways. A device present in both the ARP capture and the lease table is a healthy dynamic host, and the lease's hostname becomes its label. A device in ARP with no lease anywhere is a static assignment, and that list, the statics nobody wrote down, is the single most valuable output of the entire exercise, because those are precisely the addresses someone will eventually hand out twice. An address holding a lease but missing from ARP across several captures belongs to a device that left, on a lease that will quietly expire. And one IP address appearing with two different MAC addresses in captures taken a week apart deserves immediate attention, since it points to either a replaced machine or a duplicate assignment in progress; our guide to IP address conflicts shows how to chase that down while both devices are still reachable.

All of this produces a pile of exports, and the instinct at this point is to consolidate them into a fresh spreadsheet. Resist it, out of respect for the dead wiki page that started this story, which was also fresh once, also accurate once, and decayed because keeping it true depended on human discipline at exactly the moments discipline is scarcest. What the inventory needs from a home is the structure the network itself has: subnets nested inside parent blocks, addresses that belong to subnets, utilization you can see at a glance, and a search that answers "where is 10.20.30.4 and what is it" from one box. We've written before about what the spreadsheet workaround costs and the five signs a team has outgrown manual tracking, and an engineer who just spent days excavating a network has usually lived through all five of them personally.

This is the workflow IPCraft's CSV (comma-separated values) import was built for. Export your subnet list from the routing-table work and your address list from the lease and ARP reconciliation, hand both files to the import dialog, and the hierarchy assembles itself: every subnet lands under its parent automatically based on containment, overlapping ranges are rejected rather than silently recorded, and every address arrives inside the subnet that holds it with hostname, description, status, and owner attached. Custom fields carry whatever else the excavation produced, a verified-on date, the source that found the device, the switch port it hangs from. From there the whole inventory is full-text searchable, every subnet shows live utilization, and if the lease exports are big enough to deserve automation, the API can do the importing from a script instead.

The inventory is only finished in the sense that a garden is finished. It stays true if the next allocation flows through it: the next server gets its address from the record rather than from a ping-and-hope, the record updates in the same motion, and the activity log remembers who did it and when. That habit separates the network you inherited from the network you intend to hand over. Do the archaeology once, then let the system of record absorb the small daily changes that used to accumulate as undocumented drift.

There is a reward waiting past the drudgery. Once the inventory exists, you can finally see the design, or the absence of one, and judge it on the merits: subnets sized by reflex, ranges scattered with no aggregation, trust boundaries that exist only by accident. That assessment opens the network's next chapter, and it goes far better as a deliberate project, with our worked example of designing an IP plan from scratch and the case for right-sizing each subnet as references, than as a conclusion reached mid-outage. The engineer who inherits this network after you will still have questions. Now they will also have a place where the answers live.