Find genuinely free IP addresses before you assign a static

A ticket arrives: “new NVR needs a static on the camera VLAN, can you give me an address by lunch?” The quick answer is to ping something that looks empty, get no reply, and hand it out. The trouble starts a week later when a laptop that was asleep during your ping wakes up with that same address, or a Windows server that silently drops ICMP turns out to have owned it all along. An address is only free when the record, the wire and the DHCP server all agree it is. This guide builds that agreement in a few minutes, using Angry IP Scanner as the sweeping tool and a handful of built-in commands to confirm.

Only scan subnets you administer or have written authorization to scan. Even a ping sweep of your own network can trip IDS alerts, so let whoever watches those alerts know first.

Why “no ping reply” is not enough

• Host firewalls commonly drop ICMP echo. Windows’ default firewall profile does this on many networks.
• Devices sleep, power-cycle, or are simply unplugged on the day you look.
• A DHCP server may have a lease or reservation for the address even if nothing is using it right now.
• The address may be excluded on purpose (future gateway, VRRP virtual IP, load balancer VIP) and only written down somewhere else.

So the method below checks four sources: live response, ARP on the local segment, DNS, and the DHCP server. Your IPAM record, if you have one, is the fifth.

Step 1: Start from the record

1. Look the subnet up in your IPAM or spreadsheet and list candidate addresses outside the DHCP pool.
2. Prefer addresses in a range your plan already reserves for statics (for example .10–.49). Picking from the middle of the dynamic pool is the fastest route to a conflict.
3. Write down three or four candidates, not one; some will fail the checks.

Step 2: Sweep the subnet with Angry IP Scanner

Angry IP Scanner is GPLv2, runs on Windows, macOS and Linux, and scans a range with many threads at once.

1. Choose the IP Range feeder and enter the subnet bounds, or type the start address and a netmask such as /24.
2. In the fetchers list, enable Ping, Hostname, MAC Address and MAC Vendor, plus Ports if you want a TCP check. The MAC fetchers only work when you scan from the same Layer 2 segment, because they rely on ARP.
3. Under preferences, add a few common TCP ports to the port list (for example 22, 80, 135, 443, 445, 3389, 9100). A host that ignores ping will often still answer on one of them.
4. Set the display to All rather than “Alive only” so you can see which candidates returned nothing at all.
5. Run the scan and export to CSV for the ticket.

For repeatable checks, the scanner also takes command-line arguments in the form [options] <feeder> <exporter>. The GUI opens pre-filled, starts, writes the file and exits:

ipscan -f:range 10.40.8.1 10.40.8.254 -o camera-vlan.csv -sq

Here -s starts scanning automatically, -q quits after exporting and -a would append to an existing file instead of overwriting it. The executable name differs by platform and packaging, so check the “Command-line usage” entry in the Help menu of your build.

Step 3: Confirm on Layer 2

A device that blocks every port still has to answer ARP to talk on the segment. From a machine on the same VLAN:

# Linux (iputils arping): duplicate address detection, exit 0 = nobody answered
sudo arping -D -I eth0 -c 3 10.40.8.37; echo $?

# Windows: send traffic, then read the neighbor cache
Test-Connection -ComputerName 10.40.8.37 -Count 2 -Quiet
Get-NetNeighbor -IPAddress 10.40.8.37 -ErrorAction SilentlyContinue

If the neighbor entry shows a MAC address in a Reachable or Stale state, something owns that address even though ping failed. If you are on a different subnet, ask the switch or router instead: show ip arp 10.40.8.37 on most Cisco-style CLIs.

Step 4: Check DNS and DHCP

Resolve-DnsName 10.40.8.37 -ErrorAction SilentlyContinue
Get-DhcpServerv4Reservation -ComputerName dhcp01 -ScopeId 10.40.8.0 |
  Where-Object IPAddress -eq 10.40.8.37
Get-DhcpServerv4Lease -ComputerName dhcp01 -ScopeId 10.40.8.0 |
  Where-Object IPAddress -eq 10.40.8.37

A PTR record pointing at an old hostname is a hint that someone used the address before, and a reservation means it is spoken for. On ISC Kea or dnsmasq, search the lease file and config for the address instead.

Step 5: Assign, record, recheck

1. Pick the first candidate that is silent in the scan, absent from ARP, unknown to DNS and outside every DHCP pool and reservation.
2. Write it into the record before configuring the device, with owner, hostname and ticket number.
3. If the address sits inside a DHCP scope range, add an exclusion so the server can’t hand it out later.
4. After the device is live, scan once more and confirm the MAC you see matches the device you configured.

Common mistakes

• Scanning from another subnet and trusting the MAC column. Across a router you see the gateway’s MAC or nothing at all.
• Using “Alive only” display. You lose the evidence that a candidate was actually probed.
• Checking only ping. Printers and IoT gear often answer on 80 or 9100 but not ICMP; servers often answer on 445 or 3389.
• Forgetting VIPs. HSRP/VRRP and load-balancer addresses may not show up the way hosts do. Check network device configs for the subnet.
• Not updating the record. The sweep is a snapshot; the record is what the next admin reads.

Related reading

The LizardSystems alternative is covered in Angry IP Scanner vs LizardSystems Network Scanner and in the LizardSystems Network Scanner review. If you run this check often, it is a sign the record should live in an IPAM that scans on a schedule; see moving IP tracking off the spreadsheet and the address discovery scanners category.