One the the best tools I know of when beginning to troubleshoot a possible connectivity problem is the use of the ARP table. Every ethernet device that utilizes IP and ethernet has a ARP table and it is dead useful. By looking at the ARP table one can divide and conquer at the transition point between ethernet and IP.
ARPs are broadcasts generated by all ethernet/IP speaking devices (DTEs). Because of the layered nature of the TCP/IP protocol stack, a device needed a way to determine the IP addresses (Layer 3 on Network Layer) of devices utilizing a lower layer (Layer 2 or Link Layer). Devices request for IP addresses of other devices by sending MAC broadcasts over Layer 2 to all devices on a LAN saying, "If you know who has this IP address send it too me." A device with the IP address responses to the sender with an ARP reply containing its own MAC address and IP address. From the information learned from the ARP replies, the device builds a table of IP to MAC address bindings. Once the table has been built for the MAC to IP translations, frames can be forwarded without the need to ARP for an IP.
ARP give us the essential information of MAC address to IP address bindings that makes IP routing (and other protocols) work. If there is no entry in the ARP table for a devices MAC address there is no IP connectivity. Ethernet and IP connectivity can validated immediately at the router or the computer's gateway. This can give an engineer a point to begin troubleshooting the IP side of the network or the ethernet side of the network. If ethernet is the issue, we can begin to troubleshoot trunks, vlans, stp, etc or other link layer protocols and physical connectivity. If its determined to be an IP problem we can begin to looking at routing/forwarding tables, ACLs and other higher level protocols.