In this tutorial I will be going over some of the critical tools that can be used to test network communication on a network or even to troubleshoot an end device who is unable to access the network. Through the use of these tools you should be able to test full network connectivity or at least find where a particular issue is coming from. Since this is focused on end hosts I will be using tools readily available within Microsoft Windows Operating Systems.

IPCONFIG

IPconfig is the first tool that can be useful in resolving IP address issues or DHCP related issues as it shows the IP configuration applied to each interface on the end host. From here you want to be looking at the IP address given and whether or not it is in the valid range. Equally you want to be looking at whether or not DHCP is enabled. There can be some cases where you cannot access the network because you have enabled a blank static IP address configuration. For more advanced network topologies this will allow you to see what subnet mask has been configured. For example if the subnet allocated is 255.255.255.128 however the host has been configured with 255.255.255.0 you could essentially cut of communication to half a subnet.

There are a few syntax variants of IPconfig however you primary one would be to view all the information invovled to do so you would input this command into a command prompt (including spaces):

Code:
ipconfig /all
As an example I have attached my IPconfig below.


From this we can see that I have a wireless adapter that has an IP address of 192.168.0.30 and a default gateway and DNS configured for 192.168.0.1. Based on my environment this would be suitable and there is no configuration issues here. From the output we can also see that this is a static IP address configuration since no DHCP lease information is shown and from the following line:

Code:
DHCP Enabled. . . . . . . . . . . : No
PING

Ping (Packet Internet Groper) is a network tool that allows the generation of ICMP (Internet Control Messaging Protocol) messages that follow an echo and echo-reply function so round trip times and end to end connectivity can be tested. This should be your primary tool in initially testing network communication. Right, so this is a simple yet important tool however how do I use it? Well, the application of PING is just as important as knowing when to use it. If you want a granular testing of network communication you would first check that the end host can reach the default gateway. If the host cannot reach the default gateway then its not going to be able to get to the internet or a remote network. From a syntax perpective the use of ping simple:

Code:
ping {IP_ADD/HOSTNAME}
To put this into perspective the image below shows the use of ping to test connectivity to my default gateway.


Anytime you see a reply that means the full duplex communication (bi-directional communication) has happened and you have heard a reply from the destination device. Along with this you will also receive a round trip time. For good network connection this should never be over 200-300 ms at any one time. If it exceeds that then you may want to test a different host to see if it is the host causing the delay or if it is your connection.

Now that connectivity to the default gateway has been tested the next step to test internetwork connectivity would be ping a remote network. For internet connectivity I would advise sending a ping message to 8.8.8.8. This will help to test internet connectivity and can be useful to see if DNS (Domain Name System) is the culprit for internet access issues. The image below shows that I have partial network connectivity to the internet since replies were made.


To complete full testing of internet connectivity the last component would be to test DNS resolution of IP addresses to Hostnames. This could be tested also with nslookup which I will be covering also however you can use ping to resolve the address for you automatically. In the example below I decided to ping Google which automatically resolved the hostname.


TRACEROUTE

So you completed a ping request to a host and it failed. What do you do from there? Traceroute is a powerful tool that allows you to trace the path that your packets take to reach the given host and help you potentially identify where the issue may lie. This can help to determine if the reason the ping is failing is due to a mis-configured router or due to your end host configuration. To better put its use into perspective I am going to trace the router that my packets take on the internet to reach the destination IP address of 8.8.8.8.

Firstly, from a syntax perspective it is similar structure ping:

Code:
tracert {IP_ADD/HOSTNAME}

From the image above we do see some requests time outs but that is not necessarily an issue since a host may not respond to ICMP echo (traceroute) messages due to security reasons. Also from the syntax option I added a -d argument which is used to prevent DNS resolution of IP addresses in the path. Now that you have a rough idea of what traceroute does I am going to be showing you two scenarios where ping has failed however with the use traceroute can greatly help in determining where the issue is.


With this traceroute we can see that our device never actually reached the default gateway for routing off our network to our destination host. With this in mind I would then check IPconfig to see what default gateway is configured and whether or not that gateway is valid.


The second scenario had a similar symptom (Ping failed) however after doing a traceroute we can see that the results couldn't be more different. From this trace we can see that our traffic reached our default gateway and then from that ended up being routed in looping manner. The cause of this ping failure is a result of mis-configured routers who point to each other to reach 8.8.8.8 and therefore loop the traffic in an infinite circle. In terms of troubleshooting I would be confident in saying that our end host configuration is fine since our traffic was able to leave our network.

ARP TABLE

The ARP table is the table used to map MAC addresses to IP addresses so your computer can communicate on the local network. In terms of troubleshooting you can view this mapping table and use it as a potential way of finding out if a device does actually exist on the local network even though it does not respond to ping messages. Firstly, lets look at the ARP table.

To see the table the syntax is simple:

Code:
arp -a

From this we can see that my default gateway of 192.168.0.1 has a MAC address of 7C:4C:A5:0E:C8:78. Therefore if I wish to communicate with that device I would send a destination IP address and destination MAC address accordingly. Now to show the troubleshooting part.


In this scenario I have sent a ping message to the IP address of 192.168.0.23 and did not receive any responses. Initially we may decieve this as being a free IP address and no device owning it however behind the scenes ARP (Address Resolution Protocol) has already checked if there is a MAC address associated and populated the ARP table. Now when we look at the table again we can see that a device does own that IP address however is simply not responding to Ping messages.


Note   Note
This technique can only work on devices inside your own subnet/network since MAC addresses are not used during inter-network communication.


NETSTAT

Netstat is a huge tool and could have entire page of its own for all the bells and whistles it has and can do however for this tutorial I am simply going to show its primary role which is to view the various connections and network statistics that are being generated by your host. This is useful for troubleshooting intermittent connections for example, a skype call or spotify stream is still going yet the internet isn't "working". Netstat can help show if there is an issue with TCP/UDP or a particular issue higher up with the application in question. To view the active TCP sessions your host is making simply input the following:

Code:
netstat -a

An example of mine can be seen above. The top sessions from a source of 0.0.0.0 and 127.0.0.1 are sessions made internal to your device and can typically be ignored. For internet sessions you see the ones made in the red box and what servers they were made on and what ports were involved.

Should an issue be focused on a specific application you can input a slightly different command to see what process is responsible for each session.

Code:
netstat -b

As you can see, various applications make various connections and if I had an issue with say skype I could refer to this and see if any connections are being established if they were then I can troubleshoot further. If they weren't then I know there is a problem with making a session and might want to look further into any firewall rules that could block a session from being made.

NSLOOKUP

Nslookup (Name Server Lookup) is another simple tool that can be used to test DNS settings. For example, a DNS server may be shown in the IPconfig however how do you know that it is a good one and can resolve internet addresses? Nslookup allows this to be done. Nslookup is a sub configuration tool therefore to enter it simply input the following and press enter:

Code:
nslookup

Now that you have entered the application if you will, you can now input a hostname or IP address and see what the counterpart is. For example, if I input a website address I can see that it gets resolved to an IP address or multiple IP addresses.


Equally, I can input an IP address and have it resolved to a hostname. For example, consider the following image:


As you can see, the IP address of 8.8.8.8 has been resolved to its hostname. For more information on how to use NSlookup and the additional parameters that can change the server and type of records found please view this tutorial: http://www.sysnative.com/forums/netw...addresses.html

These are just some of the essential tools that can help in understand the flow of network communication and troubleshooting connectivity issues.

Hope This Helps,
Josh