Title: Verify Network Connectivity
Course: CIS 208: Linux/UNIX III: Intermediate System Administration, Networking, and Security ~ For IGNITE Review > Section: Learning Modules

Verify Network Connectivity

Since the higher layers depend on the lower layers, it is always best to start troubleshooting any connectivity issues starting at layer 1.  Since name resolution is important and it is not part of the OSI model, it will be included with the network layer.

1) The physical layer depends on having one or more network interfaces along with the proper driver for each.

- Run the "ifconfig -a" command to see all devices which are available.  If the desired device is not listed, check that it is installed properly and that the right driver has been loaded.
- Run "ethtool <dev>" to find the link status of each interface.  The output should be "Link detected: yes" for wired or wireless devices.  If no link is detected, check the cabling and ensure that all network equipment is powered on.  In rare cases, it may be necessary to unplug network equipment to ensure that it reboots properly.

2) The data link layer requires at least one more device on the network.

- First ping the local network, using the broadcast address.  For example, a host with IP 192.168.1.5 on 192.168.1.0/24 would run "ping -b 192.168.1.255".
- Next run "arp -a" which will return all known MAC addresses.  If at least one address is listed, the data link connection is good.

3) The network layer requires at least one more device on the network.

- The output of "arp -a" above also verifies that basic IP settings work.
- Run "nmap -P0 <IPaddr>" for one or more of the IP addresses.  If at least one port is either closed, blocked or open, basic IP connections can be made.
- If certain addresses cannot be reached, use the output of "route -n" to check the routing table.  Verify that the netmask for each network is accurate.  If there is a route for 0.0.0.0, run "nmap -P0 -p53 8.8.8.8" to test connections to Google's DNS server.  If the local network policy prevents this, select another port and IP address to test.  Work with your network or firewall administrators, if needed.
- Next, verify the DNS settings by running "cat /etc/resolv.conf".  If no nameservers are listed, check with the network administrator.  It is possible that a DHCP server is misconfigured.
- For each nameserver listed, run "host sample.com <IPaddr>".  If this does not return an IP address, there is a problem with the server.  Try running "nmap -P0 -p53 <IPaddr>" to ensure that a nameserver is  running at that address and that it is not blocked by a firewall.  It is possible that the nameserver is configured to ignore requests from your IP address or that it is not allowed to do recursive lookups.

4) To test the transport layer, a specific IP address and a port are required.  For example, to test connections to www.wcc.net, we would use the output of "host www.wcc.net" and port 80 to compose the test "nmap -P0 -p80 <IPaddr>".  If this test passes, we know that network connections are not being blocked, but we do not yet know if the website is functional.

5) To test the application layer, open the application for the specific resource to be tested.  For example, use firefox to open http://www.wccnet.net and the website should display properly.  If you are able to open other websites, this is a good indication that the problem is on the remote webserver.

What is missing from the above tests?  Two items.

1. First, the problem may be something that only a network administrator or your ISP can resolve.  This would typically happen when some connections work and others don't.
2. Second, the problem might only happen at specific locations.  For example, it is possible that firewall and/or DNS configurations can cause problems.  If you need to troubleshoot issues at a single location, it is often helpful to also test connections on a different device using another ISP.