Nmap Host Discovery: Ping Sweeps, ARP, and -Pn

Before you scan a single port, you need to know which addresses are actually alive. Blasting a full port scan at every host in a /24 wastes time on dead space and lights up any IDS in the path. Host discovery is the front door of every Nmap workflow: you find the live hosts first, then you scan the ones that answer. This article is part of the complete Nmap guide, and it covers exactly how Nmap decides a host is up, why that decision changes depending on whether the target is local or remote, and how to read the results like a network engineer auditing their own gear.

Why host discovery comes first

When you point Nmap at a range, its default behavior is a two-step job: discover which hosts are up, then port-scan only those. The discovery phase is the "ping scan" (sometimes called a ping sweep). Skipping straight to a port scan of the whole subnet means Nmap either wastes probes on empty addresses or, worse, silently drops hosts that did not answer the ping. Understanding the discovery phase is what keeps your inventory accurate.

The discovery-only flag is -sn (no port scan). It tells Nmap to find live hosts and stop. That makes it the fastest way to answer one question you ask constantly in the field: what is actually powered on and reachable in this subnet right now?

On a local subnet, -sn is an ARP sweep

Here is the detail most tutorials skip. When your target is on the same layer-2 segment as your scanner, Nmap does not send ICMP or TCP at all for discovery. It sends ARP. A host cannot answer an IP-layer probe without first answering ARP, so ARP is both faster and more reliable, and Nmap uses it automatically for local targets even if you asked for other probe types.

Here is a real ARP sweep of a lab /24 from the scanner, captured live on Cisco Modeling Labs:

$ nmap -sn 10.10.10.0/24
Starting Nmap 7.95 ( https://nmap.org ) at 2026-06-28 05:49 UTC
Nmap scan report for 10.10.10.1
Host is up (0.0031s latency).
MAC Address: AA:BB:CC:00:5B:00 (Unknown)
Nmap scan report for 10.10.10.2
Host is up (0.0080s latency).
MAC Address: AA:BB:CC:80:5A:00 (Unknown)
Nmap scan report for 10.10.10.21
Host is up (0.012s latency).
MAC Address: 52:54:00:A2:2F:84 (QEMU virtual NIC)
Nmap scan report for 10.10.10.24
Host is up (0.0036s latency).
MAC Address: 52:54:00:BB:DC:36 (QEMU virtual NIC)
Nmap scan report for 10.10.10.25
Host is up (0.0041s latency).
MAC Address: 52:54:00:CF:69:0F (QEMU virtual NIC)
Nmap scan report for 10.10.10.10
Host is up.
Nmap done: 256 IP addresses (6 hosts up) scanned in 1.98 seconds

Six live hosts out of 256 addresses in 1.98 seconds. That speed is the ARP advantage: no routing, no three-way handshakes, just layer-2 request and reply. The .10 host at the end (Host is up. with no MAC) is the scanner itself.

Read the MAC OUI before you send a TCP packet

Notice what the sweep handed you for free: a MAC address per host. The first three bytes are the OUI (Organizationally Unique Identifier), and they tell you what kind of device you are looking at before you probe a single port. In this capture the pattern is obvious once you know it:

• AA:BB:CC:... on .1 and .2 are Cisco IOL burnt-in MACs, so those are the router (R1) and the switch SVI (SW1). Network gear.
• 52:54:00:... on .21, .24, and .25 is the QEMU/KVM OUI, so those are the Linux virtual hosts (the nginx web server WEB01, and hosts HOST01 and HOST02).

That is a real triage shortcut. On an unfamiliar subnet you can separate "infrastructure" from "endpoints" straight off the ARP sweep, and prioritize what to scan next. It is exactly the kind of inventory-first thinking that turns Nmap from a security tool into a network verification tool.

What -sn sends on a remote subnet

The moment the target is a router hop away, ARP is off the table (ARP does not cross a layer-3 boundary). Nmap switches to a default set of IP-layer discovery probes. As an unprivileged user it falls back to a TCP connect on 80 and 443, but run as root (which you normally are for scanning), the default remote discovery probes are:

• An ICMP echo request (a classic ping).
• A TCP SYN to port 443.
• A TCP ACK to port 80.
• An ICMP timestamp request.

Nmap fires all four and treats the host as up if any one of them draws a response. The mix is deliberate: a firewall that blocks ICMP echo often still permits TCP to 80 or 443, and the ACK probe slips past some stateless filters that the SYN probe cannot. Casting several probe types is what makes remote discovery reliable when a single ping would fail.

The discovery probe types you can choose

You are not stuck with the defaults. When a network filters the standard probes, you tune discovery with explicit probe flags. Here are the ones worth knowing, and what each one actually puts on the wire:

You can stack these on a single command. Here is a discovery-only scan of the real internet host scanme.nmap.org using SYN probes to three ports, an ACK probe to 80, a UDP probe to 53, and --reason so Nmap prints why it made its call:

$ nmap -sn -PS22,80,443 -PA80 -PU53 --reason scanme.nmap.org
Starting Nmap 7.95 ( https://nmap.org ) at 2026-07-05 15:06 PDT
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up, received syn-ack ttl 50 (0.016s latency).
Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2f
Nmap done: 1 IP address (1 host up) scanned in 0.54 seconds

received syn-ack ttl 50 is the tell: the SYN probe to one of the listed ports drew a SYN/ACK, so Nmap marked the host up. That is the whole point of stacking probe types. If ICMP had been the only probe and the perimeter dropped it, you would have missed a host that is clearly alive.

The -Pn problem: when discovery lies to you

Here is the trap. If a firewall drops every one of Nmap's discovery probes, Nmap concludes the host is down and never port-scans it. The host might be running a dozen services, but because it refused to answer a ping, it falls off your results entirely. This is the single most common reason a scan comes back empty when you know the target is up.

The fix is -Pn: skip host discovery entirely and treat every target as up. Nmap goes straight to port scanning:

$ nmap -Pn 10.10.10.21
Starting Nmap 7.95 ( https://nmap.org ) at 2026-06-28 07:02 UTC
Nmap scan report for 10.10.10.21
Host is up (0.017s latency).
Not shown: 999 closed tcp ports (reset)
PORT   STATE SERVICE
80/tcp open  http
Nmap done: 1 IP address (1 host up) scanned in 1.74 seconds

Use -Pn whenever you have good reason to believe a host is up but ping is being blocked. The cost is speed and noise (Nmap now port-scans every target in the range whether it is alive or not), so reserve it for the cases where discovery is actively working against you. Hosts blocking ping on purpose is exactly the kind of behavior covered in firewall and IDS evasion, and it cuts both ways: the same drop rule that hides an attacker from you also hides your own gear from your inventory scans.

List scan, DNS, and --reason

Sometimes you want the target list without touching a single host. The list scan, -sL, does exactly that: it prints every IP in the range (and their reverse DNS names, if resolvable) and sends no probes at all. It is a completely passive sanity check. Run it before a big scan to confirm you are aiming at the range you think you are, and to catch a fat-fingered CIDR before it hits production.

DNS behavior is worth controlling deliberately. By default Nmap does reverse DNS on live hosts, which adds useful context but also generates lookups. Two flags govern it: -n disables all reverse DNS (faster, and it keeps your scan off the DNS server logs), while -R forces reverse DNS even on hosts Nmap thinks are down. In the lab captures you will notice a warning that reverse DNS was disabled because the scanner had no DNS server configured, which is a reminder that Nmap only resolves names when it actually can.

Finally, get in the habit of adding --reason. It changes "Host is up" into "Host is up, received syn-ack ttl 50" and turns every port state into an explanation of the packet that produced it. When a discovery result surprises you, --reason is the fastest way to see whether a host answered with a SYN/ACK, a RST, an ICMP unreachable, or nothing at all.

Key takeaways

Host discovery is where you save time and stay accurate. On a local subnet, -sn is really an ARP sweep, and it hands you a MAC OUI per host so you can tell Cisco gear (AA:BB:CC here) from Linux VMs (52:54:00) before you send a single TCP packet. On a remote subnet Nmap casts a wider net with ICMP echo, a TCP SYN to 443, a TCP ACK to 80, and an ICMP timestamp, and you can tune that with -PS, -PA, -PU, -PE, -PP, and -PR. Remember the -Pn escape hatch for hosts that block ping, use -sL to sanity-check a range without probing, and reach for --reason whenever a result needs explaining. Once you have a confirmed list of live hosts, the next move is port scanning to find out what each one is actually running. For the full workflow and the rest of the cluster, start at the complete Nmap guide.