How does my PC know if a destination is on the same network?

Expand an IPv4 address into bits to see the network boundary↑

We write 192.0.2.34 as four numbers separated by dots, but a device processes it as a 32-bit value. Each number represents an eight-bit octet, ranging from 0 to 255. Dotted notation is for people to read; bit positions define the network boundary.

An address alone does not show where its network portion ends. A /24 prefix, or 255.255.255.0 subnet mask, tells you that the first 24 bits form the network portion.

For example, in 192.0.2.130, the last octet 130 is 10000010 in binary. With a /25 prefix, the first bit of that last octet belongs to the network; the remaining 7 bits are the host portion. Thus, 192.0.2.130/25 belongs to 192.0.2.128/25. The prefix boundary in the bits determines network membership, not the appearance of the dotted numbers.

Interpret the same address with /24 and its network address is 192.0.2.0; with /26, it is 192.0.2.128. This is why comparing IP addresses alone cannot tell you whether two endpoints are on-link. Always record the address and prefix together in configurations and incident records. Writing only 192.0.2.130 leaves out half the information needed for forwarding. In router and host route output, read the address and its prefix as one value.

The network-at-the-front, host-at-the-back explanation looks straightforward only when the prefix boundary falls between octets. With a boundary inside an octet, as in /27, the last octet itself contains both network and host bits. Read the full 32 bits with the prefix length instead of relying on the dotted numbers. Record the address and prefix as a pair when documenting calculations too.

Sources for this section IETF RFC 791 · IETF RFC 4632

Reading the diagram The four octets of the IPv4 address 192.168.10.15 are expanded into 32 bits. Compare each octet's binary digits with the positional weights shown as powers of two to see how they produce the decimal address value.

Endpoints AND their IP addresses with their subnet masks to identify their networks↑

The endpoint combines its address and mask with bitwise AND. Where the mask has a 1, the address bit is retained; where it has a 0, the result is 0.

My address 192.0.2.34    /24
Mask 255.255.255.0
AND result 192.0.2.0     ← My network

Apply the same operation to the destination and compare the results. With the same prefix length, matching network addresses indicate an on-link destination; different results indicate a remote one.

For 192.0.2.130/26, the mask is 255.255.255.192. In the last octet, 130 is 10000010, and the mask value 192 is 11000000. AND them to get 10000000, or 128, making the network address 192.0.2.128. Destination 192.0.2.190 gives the same result, but 192.0.2.200 gives 192.0.2.192.

The operating system uses this calculation to install a connected route for destination lookups. You do not calculate binary values for every packet, but the route entry 192.0.2.128/26 reflects that calculation. During troubleshooting, do more than verify the arithmetic: check that the actual interface prefix and connected route cover the same range. That confirms whether the setting is reflected in forwarding behavior.

The route table may contain this directly connected prefix, more-specific routes, and a default route. Prefix comparison is a useful starting point for explaining a host's decision, but prefix comparison alone is not the whole story. Policy routing, a VPN, or a host route can affect the actual transmission. Check the final route lookup too.

Sources for this section IETF RFC 1122 · IETF RFC 4632

Reading the diagram Compare the host IP address 192.168.10.130 with the /26 subnet mask: their bitwise AND produces network ID 192.168.10.128. Read the last octet of the address, mask, and result side by side to identify the network bits and the 192.168.10.128–191 range.

For a remote destination, why skip the server and look up the gateway's MAC address?↑

For 198.51.100.20/24, the network result is 198.51.100.0, different from the local prefix. The endpoint does not look for the server's MAC address. It queries the configured default gateway, 192.0.2.1, for its MAC address using ARP.

Ethernet destination Gateway MAC
IP destination 198.51.100.20

The gateway receives the frame, removes the old Layer 2 header, and looks up a route for the IP destination. For the next link, it creates a new Layer 2 header and forwards the packet.

Even if the remote server is several routers away, the client needs only one MAC address: that of its first gateway. The client keeps the IP packet's destination at 198.51.100.20, while the Ethernet destination is 192.0.2.1's MAC address. The gateway recognizes its own MAC address in the frame, removes the Layer 2 header, and uses the IP destination for a route lookup. The next link gets different source and destination MAC addresses in a new frame.

It is therefore normal for the remote server's MAC address to be absent from the client ARP cache. If a remote server IP triggers repeated ARP requests, suspect the client's mask or an on-link route. Even after the gateway MAC is learned successfully, the gateway may lack an onward route: an ICMP unreachable may return, or the packet may be dropped. Successful ARP is evidence of preparation for the first hop, not end-to-end reachability.

The distinction illustrates a central rule: the IP address identifies the end-to-end destination, while the MAC address identifies the next receiving device on the current link. Each router replaces source and destination MAC addresses for the new link and reduces the TTL. In ordinary routing, the final IP destination stays unchanged unless a separate function such as NAT intervenes.

Sources for this section IETF RFC 1122 · IETF RFC 826

Reading the diagram Apply the same mask to source and destination, then compare the two network IDs. Follow the on-link and off-link branches to the ARP target and Layer 2 destination MAC. The local destination is 192.168.10.42; the next forwarding target for the remote destination is gateway 192.168.10.1. Use the two frame boxes below to distinguish the final destination IP from the destination MAC on the current link.

Connection failing? Compare the endpoint's ARP target and route lookup↑

Scenario: The 192.0.2.34 endpoint cannot connect within the same VLAN to the 192.0.2.130 server.

1. Check both endpoints' prefixes. Does one use /25 and the other /24?
2. Capture each endpoint's choice between the peer and the gateway as its ARP target.
3. Check the local route and default route, including their installed prefixes.
4. Align the DHCP options and manually configured masks with the same design values.
5. Refresh the ARP cache, then retest communication in both directions and the return path.

Start with the operating system's route lookup. Does destination 192.0.2.130 match a connected route or use the default route? Next, inspect the actual ARP target IP in the capture: the peer or the gateway? If the calculated branch and observed packets disagree, look for a more-specific host route, a VPN route, or policy routing that takes precedence over the basic interface prefix.

Do not stop at temporarily widening one endpoint's mask. Align the VLAN design prefix, gateway interface, DHCP scope, static host settings, and network monitoring targets. Then test between two endpoints in the same subnet and toward a destination in another subnet. Together, those tests confirm that local ARP and gateway forwarding follow the intended branches again.

The key question is not simply why ping failed. It is whose MAC address the endpoint looked for and whether that choice matched the address plan. That understanding also connects subnet size calculations to the actual forwarding range.

Sources for this section IETF RFC 1122 · IETF RFC 826