Download Basic Network Connectivity Testing - Notes | CIS 238 and more Study notes Computer Science in PDF only on Docsity!
Basic Network Connectivity Testing
You will eventually find yourself trying to fix a network related problem which usually appears in one of two forms. The first is slow response times from the remote server, and the second is a complete lack of connectivity. These symptoms can be caused by: a variey of conditions.
Network Slowness
NIC duplex and speed incompatibilities Network congestion Poor routing Bad cabling Electrical interference An overloaded server at the remote end of the connection
No Network Connectivity
All sources of slowness can become so severe that connectivity is lost. First thing to do is check the link light on the NIC; no light, no connection. Additional sources of disconnections are: Power failures The remote server or an application on the remote server being shut down. Bad cabling or pathcord. The switch or router to which the server is connected is powered down. The cables aren't plugged in properly. NIC doesn’t not have the correct speed / duplex settings or doesn’t handle AUTOnegotiation well. In the case of a wireless network, your SSID or encryption keys might be incorrect. Incorrect type of cable; two basic types, straight through and crossover. Make sure you use the right one. A battery-operated cable tester is a good tool for testing cabling integrity. A basic model can be had for $30-$40. More sophisticated models in the market are used to determine location of a cable break or if an Ethernet cable is too long..
Testing Your NIC
It is always a good practice in troubleshooting to be versed in monitoring the status of your NIC card from the command line. The ifconfig command without any arguments gives you all the active interfaces on your system. Interfaces will not appear if they are shut down: ifconfig Interfaces will appear if they are activated, but have no link.
The ifconfig -a command provides all the network interfaces, whether they are functional or not. Interfaces that are shut down by the systems administrator or are nonfunctional will not show an IP address line and the word UP will not show in the second line of the output. This can be seen in the next examples: Shut Down Interface wlan0 Link encap:Ethernet HWaddr 00:06:25:09:6A:D BROADCAST MULTICAST MTU:1500 Metric: RX packets:2924 errors:0 dropped:0 overruns:0 frame: TX packets:2287 errors:0 dropped:0 overruns:0 carrier: collisions:0 txqueuelen: RX bytes:180948 (176.7 Kb) TX bytes:166377 (162.4 Kb) Interrupt:10 Memory:c88b5000-c88b Active Interface wlan0 Link encap:Ethernet HWaddr 00:06:25:09:6A:D inet addr:216.10.119.243 Bcast:216.10.119. UP BROADCAST RUNNING MULTICAST MTU:1500 Metric: RX packets:2924 errors:0 dropped:0 overruns:0 frame: TX packets:2295 errors:0 dropped:0 overruns:0 carrier: collisions:0 txqueuelen: RX bytes:180948 (176.7 Kb) TX bytes:166521 (162.6 Kb) Interrupt:10 Memory:c88b5000-c88b The ethtool command command will provide reports on the link status and duplex settings for supported NICs.
Network Errors
Errors are a common symptom of slow connectivity due to poor configuration or excessive bandwidth utilization. They should always be corrected whenever possible. Error rates in excess of 0.5% can result in noticeable sluggishness. The ifconfig command also shows the number of overrun, carrier, dropped packet and frame errors. wlan0 Link encap:Ethernet HWaddr 00:06:25:09:6A:D BROADCAST MULTICAST MTU:1500 Metric: RX packets:2924 errors:0 dropped:0 overruns:0 frame: TX packets:2287 errors:0 dropped:0 overruns:0 carrier: collisions:0 txqueuelen: RX bytes:180948 (176.7 Kb) TX bytes:166377 (162.4 Kb) Interrupt:10 Memory:c88b5000-c88b
NIC is be disabled or the remote server might be shut down The remote server might be running firewall software such as iptables or the Windows XP built in firewall. Typically in this case, you can see the MAC address but PINGs don’t respond. A dual homed server may have incorrect routing. Relevant commands: The ifconfig -a command shows you both the NIC's MAC address and the associated IP addresses of the server that you are currently logged in to. The arp -a command will show you the MAC addresses in your server's ARP table and all the other servers on the directly connected network. Make sure the IP addresses listed in the ARP table match those of servers expected to be on your network. If they don't, your server might be plugged into the wrong switch or router port. You should also check the ARP table of the remote server to see whether it is populated with correct values. General Network PING The ping (packet internet network groper) command sends ICMP echo packets that request a corresponding ICMP echo-reply response from the device at the target address. Because most servers will respond to a ping query it becomes a very handy tool for general network connectivity network testing. A lack of response could be due to: A server with that IP address doesn't exist, server might be down, or disconnected for the network The server has been configured not to respond to pings A firewall or router along the network path is blocking ICMP traffic. The network device doesn't have a route in its routing table to the destination network and sends an ICMP reply type 3 which triggers the message. The resulting message might be Destination Host Unreachable or Destination Network Unreachable. Source and/or destination device having an incorrect IP address or subnet mask. No default gateway. Check TCP/IP stack setup to make sure they host knows how to leave the local network (correctly). A classic symptom of bad routes on a server is the ability to ping servers only on your local network and nowhere else. Incorrect routing - routes and subnet masks on both the local and remote servers and all routers in between. Use traceroute to ensure you're taking the correct path. TRACEROUTE
The traceroute command (Linux – traceroute, Windows – tracert) output is a listing of all subnet gateways between your server and the target server. This will verify routing over intervening networks is correct. The traceroute command works by sending a UDP packet destined to the target with a TTL of 0. The first router on the route recognizes that the TTL has already been exceeded and discards or drops the packet, but also sends an ICMP time exceeded message back to the source. The traceroute program records the IP address of the router that sent the message and knows that that is the first hop on the path to the final destination. The traceroute program tries again, with a TTL of 1. The first hop, sees nothing wrong with the packet, decrements the TTL to 0 as expected, and forwards the packet to the second hop on the path. Router 2, sees the TTL of 0, drops the packet and replies with an ICMP time exceeded message. traceroute now knows the IP address of the second router. This continues around and around until the final destination is reached. There are a number of possible message codes traceroute can result Tracerou te Symbol Description
- Expected 5 second response time exceeded. Could be caused by:
A router on the path not sending back the ICMP "time exceeded" messages A router or firewall in the path blocking the ICMP "time exceeded" messages The target IP address not responding !H, !N, or !P Host, network or protocol unreachable !X or !A Communication administratively prohibited. A router Access Control List (ACL) or firewall is in the way !S Source route failed. Source routing attempts to force traceroute to use a certain path. Failure might be due to a router security setting TRACEROUTE and Connectivity Not all devices will respond to TRACEROUTE commands along a network path. This is not necessarily an indication of a network connectivity issue, just that the device may not respond to TRACEROUTE resulting in “* * *” along the path.
If there is nothing blocking your traceroute traffic, then the last visible router of an incomplete trace is either the last good router on the path, or the last router that has a valid return path to the server issuing the traceroute. TRACEROUTE and Network Performance Individual TRACEROUTE gateways may result in slow response. The following traceroute gives the impression that a Web site at 80.40.118.227 might be slow because there is congestion along the way at hops 6 and 7 where the response time is over 200ms: C:>tracert 80.40.118. 1 1 ms 2 ms 1 ms 66.134.200. 2 43 ms 15 ms 44 ms 172.31.255. 3 15 ms 16 ms 8 ms 192.168.21. 4 26 ms 13 ms 16 ms 64.200.150. 5 38 ms 12 ms 14 ms 64.200.151. 6 239 ms 255 ms 253 ms 64.200.149. 7 254 ms 252 ms 252 ms 64.200.150. 8 24 ms 20 ms 20 ms 192.174.250. 9 91 ms 89 ms 60 ms 192.174.47. 10 17 ms 20 ms 20 ms 80.40.96. 11 30 ms 16 ms 23 ms 80.40.118. Trace complete. C:> This indicates only that the devices on hops 6 and 7 were slow to respond with ICMP TTL exceeded messages, not that those links are slow. Slowness due to of congestion, latency, or packet loss is a valid deduction only if it existed all points past the first slow gateway also show high latency. Also Qulaity of Service (QOS) is common on many Internet routing devices that give very low priority to traceroute or ping in favor of revenue generating traffic. Also, the default action of TRACEROUTE is to resolve gateway IP addresses to DNS names. This can dramatically slow repsonse of TRACEROUTE results. And give the false impression that TRACEROUTE is slow. It’s not, only name resolution may be. If you don’t need the DNS names of the gateways, try a flag option that suppresses DNS name resolution or yields only numeric IP addressing. Note that sometimes resolving names to addresses is useful when diagnosing Internet performance problems between ISPs along diverse routing paths (asymmetric routing below).. TRACEROUTE and Asymmetric Routing It is always best to get a traceroute from the source IP to the target IP and also from the target IP to the source IP. This is because the packet's return path from the target is
sometimes not the same as the path taken to get there – asymmetric routing. Ideally, the path to a destination is the same path returning from the destination. This is especially critical in TCP/IP applications that require frequent ACKnowledgements (FTP). If congestion occurs along a different route between the source and destination, performance can suffer. Only bidirectional TRACEROUTEs can indicate this. TRACEROUTE Web sites Many ISPs will provide their subscribers with the facility to do a traceroute from purpose built servers called looking glasses. A simple web search for the phrase Internet looking glass will provide a long list of alternatives. Doing a traceroute form a variety of locations can help identify whether the problem is with the ISP of your Web server or the ISP used at home/work to provide you with Internet access. A more convenient way of doing this is to use a site like traceroute.org which provides a list of looking glasses sorted by country.
TELNET for Testing Network Connectivity
Even if a server doesn’t respond to PING or TRACEROUTE – common for Internet servers behind a firewall, an easy way to tell if a remote server is listening on a specific TCP port is to use the telnet command. By default, telnet will try to connect on TCP port 23, but you can specify other TCP ports by typing them in after the target IP address. For example, testing if server 192.168.1.102 is repsonding on SMTP: telnet 192.168.1.102 25 When using telnet troubleshooting, here are some useful guidelines to follow that will help to isolate the source of the problem: Test connectivity on the server itself. Try making the connection to the loopback address as well as the NIC IP address. If the server is running a firewall package such as the Linux iptables software, all loopback connectivity is allowed, but connectivity to desired TCP ports on the NIC interface might be blocked sometimes. Further discussion of the Linux iptables package is covered in a later section. Test connectivity from another server on the same network as the target server. This helps to eliminate the influence of any firewalls protecting the entire network from outside. Test connectivity from the remote PC or server. Remember that current LINUX distributions have the iptables firewall package installed by default. This is often the cause of many connectivity problems and the firewall rules should be correctly updated. In some cases where the network is already protected by a firewall, iptables might be safely turned off. You can use the /etc/init.d/iptables status command on the target server to determine whether iptables is running.
With Linux , the telnet command will abort the attempted connection after waiting a predetermined time for a response. This is called a timeout. In some cases, telnet won't abort, but will just wait indefinitely. This is also known as hanging. These symptoms can be caused by the one of the following reasons: The remote server doesn't exist on the destination network. It could be turned off. A firewall could be blocking and not rejecting the connection attempt, causing it to timeout instead of being quickly refused. An example: telnet 216.10.100.12 22 Trying 216.10.100.12... telnet: connect to address 216.10.100.12: Connection timed out With Windows ,, if there is no connectivity, the session will appear to hang or timeout. This is usually caused by the target server being turned off or by a firewall blocking the connection. C:>telnet 216.10.100.12 22 Connecting To 216.10.100.12.. Ctrl C may exit out of a hung seession or you may hace to wait for a timeout or just close the window.
The netstat command
netstat can be very useful in helping to determine the source of problems. netstat -an lists all the TCP ports on which the server is listening including all the active network connections to and from your server. You can also use netstat –an to check whether TELNETting to sa specific port on an IP adress worked.
netstat -an
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 :::80 :::* LISTEN tcp 0 1124 ::ffff:65.115.71.34:80 ::ffff:24.4.97.110:2955 ESTABLISHED Most TCP connections create permanent connections, HTTP is different because the connections are shut down on their own after a pre defined inactive timeout or time_wait period on the Web server. It is therefore a good idea to focus on these types of short-lived connections too. You can determine the number of established and time_wait TCP connections on your server by using the netstat command filtered by the grep and egrep commands, with the number of matches being counted by the wc command which, in this case shows 14 connections.
netstat -an | grep tcp | egrep -i 'established|time_wait' | wc -l 14
Other connectivity utilities
PING, TRACEROUTE, NETSTAT and TELNET are commands that come with most system. There are other more specific utilities suchas nmap and netcat (nc) that provide even deeper probing of servers for speicif ports; unauthorized use of these tools is referred to as network hacking. So caution is recommended is using these tools in a public network.
