Two CentOS Devices with IP Addresses in the Same Subnet Cannot Ping Each Other's MAC Address

It is technically impossible to ping a MAC address directly because the ICMP protocol operates at Layer 3 (Network) while MAC addresses exist at Layer 2 (Data Link). If two CentOS devices are in the same subnet and cannot communicate, the issue lies in ARP resolution, firewall filtering, or interface configuration, not in a broken "ping to MAC" command. This article explains how to correctly diagnose connectivity between local hosts using standard tools like ping, arp, and tcpdump.

Understanding the Protocol Mismatch

The core misunderstanding in this scenario is attempting to send an ICMP Echo Request to a hardware address. The ping utility sends packets to an IP address. When you ping an IP on the local network, your system first checks its ARP cache for the corresponding MAC address. If it is missing, it broadcasts an ARP Request. Only after receiving an ARP Reply with the target's MAC address does the system encapsulate the ICMP packet in an Ethernet frame destined for that specific MAC. You cannot pass a MAC address as the destination argument to ping. Doing so will result in an error such as "Destination Host Unreachable" or "Invalid argument." To verify if two devices can see each other at Layer 2, you must rely on the ARP process itself. If Device A cannot resolve the MAC address of Device B, they are isolated at the data link layer regardless of their IP settings.

Verifying ARP Resolution

The most critical step in troubleshooting local connectivity is ensuring that the Address Resolution Protocol is functioning correctly. On both CentOS devices, check the ARP table using the following command:

ip neigh show

Look for the entry corresponding to the other device's IP address. If the state is listed as REACHABLE or STALE, Layer 2 communication is possible. If the entry is missing entirely, or shows INCOMPLETE, the devices are not exchanging ARP frames. This indicates a problem with physical cabling, switch port configuration, or VLAN tagging that prevents broadcast traffic from crossing between the interfaces. If you suspect that ARP is being blocked, you can force a refresh by clearing the neighbor cache on one host:

ip neigh flush all

Then attempt to ping the remote IP again from the source machine. Watch the output of ip neigh show on both ends simultaneously. You should see the state transition from INCOMPLETE to REACHABLE if the network path is clear.

Checking Firewall Rules

CentOS systems typically use firewalld or iptables to filter traffic. Even if ARP works, the firewall may drop ICMP Echo Requests. By default, many CentOS configurations allow ICMP within trusted zones, but custom rules might block it. To check if the firewall is blocking ICMP, examine the active zones:

firewall-cmd --get-active-zones

Identify which zone your network interface belongs to. Then, list the services allowed in that zone:

firewall-cmd --zone= --list-services

If icmp or ping is not listed, the firewall is likely dropping the packets. You can temporarily disable the firewall to test connectivity, though this is not recommended for production environments:

systemctl stop firewalld

If ping succeeds after stopping the service, you need to add the appropriate rule permanently. For example, to allow ICMP echo requests:

firewall-cmd --zone= --add-service=icmp --permanent

Reload the firewall to apply changes:

firewall-cmd --reload

For more granular control, you can inspect iptables rules directly:

iptables -L -n -v

Look for any DROP or REJECT actions in the INPUT chain targeting ICMP protocol type 8 (Echo Request).

Detecting Packet Loss with Tcpdump

When visual inspection of logs fails, packet capture provides definitive evidence of where communication breaks down. Use tcpdump on both machines to observe the actual bytes on the wire. Run this command on the target machine while pinging from the source:

sudo tcpdump -i eth0 icmp

Replace eth0 with your actual interface name. If you see ICMP Echo Requests arriving but no Echo Replies leaving, the target machine is processing the request but failing to respond. This often points to a routing issue on the target or a local application blocking the response. If you do not see any ICMP traffic at all, the packets are not reaching the network interface. This could be due to a misconfigured bridge, as discussed in related networking issues involving virtual machines and NAT configurations. See our guide on IPTables: NAT Source Address Bridge Interface on Linux for insights into how bridged interfaces might interfere with local traffic flow. Additionally, ensure that the network interface is up and has the correct IP assignment. Sometimes, interfaces appear configured but are administratively down or have conflicting IPv6 settings that interfere with IPv4 operations. Refer to Doesn't ifconfig show IPv4 address? (IPv6 related) for troubleshooting display and configuration discrepancies.

Common Hardware and Configuration Errors

Beyond software filters, physical and configuration errors frequently cause local ping failures. First, verify that both devices are connected to the same logical network segment. If you are using managed switches, ensure that the ports are in the same VLAN. Trunk ports carrying multiple VLANs will drop untagged frames if the devices are not configured to tag their traffic appropriately. Second, check for IP conflicts. If another device on the network holds the IP address you assigned to your CentOS machine, ARP responses will be erratic. Use arping to send ARP requests specifically to an IP address to see who responds:

arping -I eth0 192.168.1.10

This tool bypasses the kernel's ARP cache and sends raw ARP probes, helping you identify duplicate IP assignments quickly. Finally, review the network interface configuration files in /etc/sysconfig/network-scripts/. Ensure that ONBOOT=yes is set and that the gateway and netmask values match your network topology. Incorrect netmasks can cause the system to believe the remote host is on a different subnet, leading it to route traffic through a gateway instead of sending it directly via ARP.

Frequently Asked Questions

Why can I ping an IP but not resolve its MAC address?

This usually indicates that the IP is reachable through a router, but the local ARP cache is stale or corrupted. Clearing the neighbor cache with ip neigh flush forces a fresh ARP request, which should populate the MAC address if the device is locally accessible.

Can I use ping to test Layer 2 connectivity?

No, ping tests Layer 3 reachability. To test Layer 2, you must verify ARP resolution. If ip neigh show lists the remote IP with a valid MAC address, Layer 2 connectivity is established, regardless of whether ICMP is permitted.

What if tcpdump shows no incoming packets?

If you see no packets on the target interface, the issue is upstream. Check physical cables, switch port status, VLAN assignments, and any intermediate firewalls or routers that might be dropping the traffic before it reaches the final destination.

How do I allow ping through firewalld without disabling it?

Add the ICMP service to your active zone using firewall-cmd --zone= --add-service=icmp --permanent and then reload the configuration. This allows ICMP Echo Requests while keeping other security policies intact.

Is it safe to disable SELinux for testing?

While disabling SELinux (setenforce 0) can resolve unexpected permission blocks, it is not a recommended long-term fix for network issues. Network problems are rarely caused by SELinux unless you are using custom policies that explicitly restrict network stack access.