Your shopping cart is empty!
When you want to troubleshoot a TCP/IP networking problem, first check the TCP/IP configuration of the computer that is experiencing the problem.
NetBIOS over TCP/IP (NetBT) resolves NetBIOS names to IP addresses. TCP/IP provides many options for NetBIOS name resolution, including local cache lookup, WINS server query, broadcast, DNS server query, and LMHOSTS and HOSTS lookup.
Nbtstat.exe is a useful tool for troubleshooting NetBIOS name resolution problems. You can use the nbtstat.exe command to remove or correct preloaded entries. To use the nbtstat.exe command:
NetBIOS Connection Table
Local Name State In/Out Remote Host Input Output
DAVEMAC1 <00> Connected Out CNSSUP1<20> 6MB 5MB
DAVEMAC1 <00> Connected Out CNSPRINT<20> 108KB 116KB
DAVEMAC1 <00> Connected Out CNSSRC1<20> 299KB 19KB
DAVEMAC1 <00> Connected Out STH2NT<20> 324KB 19KB
DAVEMAC1 <03> Listening
If you are unable to contact to a remote server, there are two common tools that you can use. Use the ping command to verify that a host computer can connect to the TCP/IP network and network resources. Use the tracert command to examine the route taken to a destination.
You can use the ping command as a troubleshooting tool to sequentially test connectivity to various network resources. To ping a network host directly:
Tracert.exe is a route-tracing utility that you can use to determine the network path to a destination. To determine the path that a packet takes on the network and where that path may be ending:
PING is used to check for a response from another computer on the network. It can tell you a great deal of information about the status of the network and the computers you are communicating with.
Ping returns different responses depending on the computer in question. The responses are similar depending on the options used.
Ping uses IP to request a response from the host. It does not use TCP
.It takes its name from a submarine sonar search - you send a short sound burst and listen for an echo - a ping - coming back.
In an IP network, `ping' sends a short data burst - a single packet - and listens for a single packet in reply. Since this tests the most basic function of an IP network (delivery of single packet), it's easy to see how you can learn a lot from some `pings'.
To stop ping, type control-c. This terminates the program and prints out a nice summary of the number of packets transmitted, the number received, and the percentage of packets lost, plus the minimum, average, and maximum round-trip times of the packets.
Sample ping session
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=2 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=2 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=2 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=2 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=255 time=2 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=255 time=2 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=255 time=2 ms
64 bytes from 127.0.0.1: icmp_seq=7 ttl=255 time=2 ms
64 bytes from 127.0.0.1: icmp_seq=8 ttl=255 time=2 ms
64 bytes from 127.0.0.1: icmp_seq=9 ttl=255 time=2 ms
localhost ping statistics
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 2/2/2 ms
The Time To Live (TTL) field can be interesting. The main purpose of this is so that a packet doesn't live forever on the network and will eventually die when it is deemed "lost." But for us, it provides additional information. We can use the TTL to determine approximately how many router hops the packet has gone through. In this case it's 255 minus N hops, where N is the TTL of the returning Echo Replies. If the TTL field varies in successive pings, it could indicate that the successive reply packets are going via different routes, which isn't a great thing.
The time field is an indication of the round-trip time to get a packet to the remote host. The reply is measured in milliseconds. In general, it's best if round-trip times are under 200 milliseconds. The time it takes a packet to reach its destination is called latency. If you see a large variance in the round-trip times (which is called "jitter"), you are going to see poor performance talking to the host
NSLOOKUP is an application that facilitates looking up hostnames on the network. It can reveal the IP address of a host or, using the IP address, return the host name.
It is very important when troubleshooting problems on a network that you can verify the components of the networking process. Nslookup allows this by revealing details within the infrastructure.
NETSTAT is used to look up the various active connections within a computer. It is helpful to understand what computers or networks you are connected to. This allows you to further investigate problems. One host may be responding well but another may be less responsive.
This is a Microsoft windows NT, 2000 command. It is very useful in determining what could be wrong with a network.
This command when used with the /all switch, reveal enormous amounts of troubleshooting information within the system.
Windows 2000 IP Configuration
Host Name . . . . . . . . . . . . : cowder
Primary DNS Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Broadcast
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . :
WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-53-45-00-00-00
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 22.214.171.124
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 126.96.36.199
DNS Servers . . . . . . . . . . . : 188.8.131.52
Traceroute on Unix and Linux (or tracert in the Microsoft world) attempts to trace the current network path to a destination. Here is an example of a traceroute run to www.berkeley.edu:
$ traceroute www.berkeley.edu
traceroute to amber.Berkeley.EDU (184.108.40.206), 30 hops max, 40 byte packets
1 sf1-e3.wired.net (220.127.116.11) 3.135 ms 3.021 ms 3.616 ms
2 sf0-e2s2.wired.net (18.104.22.168) 1.829 ms 3.886 ms 2.772 ms
3 paloalto-cr10.bbnplanet.net (22.214.171.124) 5.327 ms 4.597 ms 5.729 ms
4 paloalto-br1.bbnplanet.net (126.96.36.199) 4.842 ms 4.615 ms 3.425 ms
5 sl-sj-2.sprintlink.net (188.8.131.52) 7.488 ms 38.804 ms 7.708 ms
6 184.108.40.206 (220.127.116.11) 6.560 ms 6.631 ms 6.565 ms
7 18.104.22.168 (22.214.171.124) 7.638 ms 7.948 ms 8.129 ms
8 126.96.36.199 (188.8.131.52) 9.504 ms 12.684 ms 16.648 ms
9 f5-0.inr-666-eva.berkeley.edu (184.108.40.206) 9.762 ms 10.611 ms 10.403 ms
10 f0-0.inr-107-eva.Berkeley.EDU (220.127.116.11) 11.478 ms 10.868 ms 9.367 ms
11 f8-0.inr-100-eva.Berkeley.EDU (18.104.22.168) 10.738 ms 11.693 ms 12.520 ms