The nbtstat Command

The nbtstat Command
As was touched on earlier, Windows systems can also use WINS (NetBIOS) to resolve names
into IP addresses. In these cases the ipconfig /displaydns command will not show these
associations. In order to view this information you need to use the nbtstat command. The
options that are available for this command are listed in the following example:
C:\>nbtstat /?
Displays protocol statistics and current TCP/IP connections using NBT
(NetBIOS over TCP/IP).
NBTSTAT [ [-a RemoteName] [-A IP address] [-c] [-n]
[-r] [-R] [-RR] [-s] [-S] [interval] ]
-a (adapter status) Lists the remote machine's name table given its name
-A (Adapter status) Lists the remote machine's name table given its IP
address.

-c (cache) Lists NBT's cache of remote [machine] names and their
IP addresses
-n (names) Lists local NetBIOS names.
-r (resolved) Lists names resolved by broadcast and via WINS
-R (Reload) Purges and reloads the remote cache name table
-S (Sessions) Lists sessions table with the destination IP addresses
-s (sessions) Lists sessions table converting destination IP
addresses to computer NETBIOS names.
-RR (ReleaseRefresh) Sends Name Release packets to WINS and then, starts
Refresh
RemoteName Remote host machine name.
IP address Dotted decimal representation of the IP address.
interval Redisplays selected statistics, pausing interval seconds between
each display. Press Ctrl+C to stop redisplaying statistics.
The two options that you will most likely use in a troubleshooting situation are the -c and
-R options. The -c option is used to display the current name resolution cache, and the -R option
is used to clear this cache. Sample output from both of these commands is displayed here:
C:\>nbtstat -c
Local Area Connection:
Node IpAddress: [10.1.1.1] Scope Id: []
NetBIOS Remote Cache Name Table
Name Type Host Address Life [sec]
------------------------------------------------------------
MICHELE <20> UNIQUE 10.2.2.2 570
NERMAL <20> UNIQUE 10.100.100.100 580
NERMAL <00> UNIQUE 10.100.100.100 575
PICASO <42> UNIQUE 10.8.8.8 415
ALEX <20> UNIQUE 10.9.9.9 582
LEAH <20> UNIQUE 10.10.10.10 492
\Device\NetBT_Tcpip_{D84EDBA9-F40F-4AFF-8409-24613C6A325B}:
C:\> nbtstat -R
Successful purge and preload of the NBT Remote Cache Name Table.

1091

The ipconfig Command

The “Creating an End-System Network Configuration Table” section earlier in this chapter
introduced the ipconfig command used with the /all option. While this option is useful for
gathering information on a system, other options in the ipconfig command are helpful
for troubleshooting purposes.
The first of these options are the /release and /renew options, which are used to release
and renew DHCP addresses. Here are two examples:

C:\>ipconfig /release
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 0.0.0.0
Subnet Mask . . . . . . . . . . . : 0.0.0.0
Default Gateway . . . . . . . . . :

C:\WINDOWS\system32>ipconfig /renew
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 10.22.5.3
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.22.5.1
The next option useful in troubleshooting is the /displaydns option. It allows you to see the
DNS-name-to-IP-address cache that is on the workstation. The following output is from an XP
machine right after pinging www.cisco.com:
C:\>ipconfig /displaydns
Windows IP Configuration
ns1.cisco.com
----------------------------------------
Record Name . . . . . : ns1.cisco.com
Record Type . . . . . : 1
Time To Live . . . . : 86227
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 128.107.241.185
1.0.0.127.in-addr.arpa
----------------------------------------
Record Name . . . . . : 1.0.0.127.in-addr.arpa.
Record Type . . . . . : 12
Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
PTR Record . . . . . : localhost

ns2.cisco.com
----------------------------------------
Record Name . . . . . : ns2.cisco.com
Record Type . . . . . : 1
Time To Live . . . . : 86227
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 192.135.250.69
www.cisco.com
----------------------------------------
Record Name . . . . . : www.cisco.com
Record Type . . . . . : 1
Time To Live . . . . : 86227
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 198.133.219.25
Record Name . . . . . : ns1.cisco.com
Record Type . . . . . : 1
Time To Live . . . . : 86227
Data Length . . . . . : 4
Section . . . . . . . : Additional
A (Host) Record . . . : 128.107.241.185
Record Name . . . . . : ns2.cisco.com
Record Type . . . . . : 1
Time To Live . . . . : 86227
Data Length . . . . . : 4
Section . . . . . . . : Additional
A (Host) Record . . . : 192.135.250.69
localhost
----------------------------------------
Record Name . . . . . : localhost
Record Type . . . . . : 1

Time To Live . . . . : 0
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 127.0.0.1

In addition to the local DNS cache on the machine, Internet Explorer (IE) keeps its
own name resolution cache. By default, names are cached in Internet Explorer
versions 4.0 or higher for 30 minutes, and for 24 hours in IE versions below 4.0.
Shutting down Internet Explorer and restarting it will refresh this cache.
The final option for the ipconfig command that we will discuss is /flushdns, which is complementary
to the /displaydns option. The /flushdns option clears out all entries in the DNS
cache on the workstation. This works out well for troubleshooting stale DNS entries. The output
of the command is shown here:
C:\>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
C:\>
1089

The netstat Command

The netstat command is used to display current connections to the end system. This can be useful
in a troubleshooting scenario to assist in the verification of connectivity. In addition to the IP
addresses of the connections, the netstat command also shows the port the connections are
using. The Windows NT/2000/XP options and sample output of the command are shown here:
C:\>netstat /?
Displays protocol statistics and current TCP/IP network connections.
NETSTAT [-a] [-e] [-n] [-o] [-s] [-p proto] [-r] [interval]
-a Displays all connections and listening ports.
-e Displays Ethernet statistics. This may be combined with the -s
option.
-n Displays addresses and port numbers in numerical form.
-o Displays the owning process ID associated with each connection.
-p proto Shows connections for the protocol specified by proto; proto
may be any of: TCP, UDP, TCPv6, or UDPv6. If used with the -s
option to display per-protocol statistics, proto may be any of:
IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6.
-r Displays the routing table.
-s Displays per-protocol statistics. By default, statistics
are shown for IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, and
UDPv6; the -p option may be used to specify a subset of the
default.
interval Redisplays selected statistics, pausing interval seconds
between each display. Press CTRL+C to stop redisplaying
statistics. If omitted, netstat will print the current
configuration information once.
C:\>netstat -n
Active Connections
Proto Local Address Foreign Address State
TCP 10.12.1.11:3718 10.215.198.192:80 ESTABLISHED
TCP 10.12.1.11:3719 10.215.198.153:80 ESTABLISHED
TCP 10.12.1.11:3722 10.215.198.6:80 ESTABLISHED
TCP 10.12.1.11:3724 10.12.1.100:139 ESTABLISHED
TCP 10.12.1.11:3726 10.255.37.1:23 ESTABLISHED
The Unix version of the command is very similar to the Windows version. Its options and
sample output are as follows:
unix1% netstat -help
usage: netstat [-adgimnprsDMv] [-I interface] [interval]
unix1% netstat -n
TCP
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
----------------- ----------------- ----- ------ ----- ------ ------
10.4.132.58.32891 10.4.132.58.162 57344 0 57344 0 ESTAB
10.4.132.58.162 10.4.132.58.32891 57344 0 57344 0 ESTAB
10.4.132.58.53074 10.4.128.10.1960 24820 0 8760 0 ESTAB
10.4.132.58.38090 10.104.108.13.1960 62780 0 8760 0 ESTAB
...
...

1086

The route Command

If an end station has multiple interfaces, it can be useful to know which of these interfaces is
being used for particular destinations. In theses cases, for both Windows NT/2000/XP stations
and Unix stations, you can use the route command. The following are the options and the syntax
for displaying the routing table for Windows NT/2000/XP:
C:\>route /?
Manipulates network routing tables.
ROUTE [-f] [-p] [command [destination] [MASK netmask] [gateway]
[METRIC metric] [IF interface]
-f Clears the routing tables of all gateway entries. If this is
used in conjunction with one of the commands, the tables are
cleared prior to running the command.
-p When used with the ADD command, makes a route persistent across
boots of the system. By default, routes are not preserved when
the system is restarted. Ignored for all other commands, which
always affect the appropriate persistent routes. This option
is not supported in Windows 95.
command One of these:
PRINT Prints a route
ADD Adds a route
DELETE Deletes a route
CHANGE Modifies an existing route
destination Specifies the host.
MASK Specifies that the next parameter is the 'netmask' value.
netmask Specifies a subnet mask value for this route entry. If not
specified, it defaults to 255.255.255.255.
gateway Specifies gateway.
interface The interface number for the specified route.
METRIC Specifies the metric, ie. cost for the destination.
All symbolic names used for destination are looked up in the network Database
file NETWORKS. The symbolic names for gateway are looked up in the host name
database file HOSTS.
If the command is PRINT or DELETE. Destination or gateway can be a wildcard,
(wildcard is specified as a star '*'), or the gateway argument may be omitted.
If Dest contains a * or ?, it is treated as a shell pattern, and only matching
destination routes are printed. The '*' matches any string, and '?' matches
any one char. Examples: 157.*.1, 157.*, 127.*, *224*.
Diagnostic Notes:
Invalid MASK generates an error, that is when (DEST & MASK) !=
DEST.
Example> route ADD 157.0.0.0 MASK 155.0.0.0 157.55.80.1 IF 1
The route addition failed: The specified mask parameter is
invalid.
(Destination & Mask) != Destination.
Examples:
> route PRINT
> route ADD 157.0.0.0 MASK 255.0.0.0 157.55.80.1 METRIC 3 IF 2
destination^ ^mask ^gateway metric^ ^
Interface^

If IF is not given, it tries to find the best interface for a
given gateway.
> route PRINT
> route PRINT 157* .... Only prints those matching 157*
> route CHANGE 157.0.0.0 MASK 255.0.0.0 157.55.80.5 METRIC 2 IF 2
CHANGE is used to modify gateway and/or metric only.
> route PRINT
> route DELETE 157.0.0.0
> route PRINT
C:\>route print
=======================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ... 00 04 f2 cd 65 1f...... NVIDIA nForce MCP Networking Adapter -
➥Packet Scheduler Miniport
=======================================================================
=======================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.12.1.1 10.12.1.11 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
10.12.1.0 255.255.255.0 10.12.1.11 10.12.1.11 20
10.12.1.11 255.255.255.255 127.0.0.1 127.0.0.1 20
10.12.1.255 255.255.255.255 10.12.1.11 10.12.1.11 20
224.0.0.0 240.0.0.0 10.12.1.11 10.12.1.11 20
255.255.255.255 255.255.255.255 10.12.1.11 10.12.1.11 1
Default Gateway: 10.12.1.1
=======================================================================
Persistent Routes:
None
For the Unix side of things, the options and sample printout are as follows:
unix1% route
usage: route [ -fnqv ] cmd [[ - ] args ]
unix1% route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.12.1.0 0.0.0.0 255.255.255.0 U 0 0 0 hme0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.12.1.1 0.0.0.0 UG 0 0 0 hme0

In addition to printing out the routing table, the route command can also be used to add or
delete static routes if they are needed. 1085

The arp Command

Although the arp command was covered in the earlier discovery section, it is being repeated
here because it can be a very meaningful part of the troubleshooting process. As is the case on
the routers, sometimes it is necessary to verify that the layer-2-to-layer-3 translation is working
as expected on the end system. In both Unix and Windows NT/2000/XP systems, the command
to display this information is arp -a. The command options and sample output from an XP box
are as follows:
C:\>arp /?
Displays and modifies the IP-to-Physical address translation tables
used by address resolution protocol (ARP).
ARP -s inet_addr eth_addr [if_addr]
ARP -d inet_addr [if_addr]
ARP -a [inet_addr] [-N if_addr]
-a Displays current ARP entries by interrogating the current
protocol data. If inet_addr is specified, the IP and Physical
addresses for only the specified computer are displayed. If
more than one network interface uses ARP, entries for each ARP
table are displayed.
-g Same as -a.
inet_addr Specifies an internet address.
-N if_addr Displays the ARP entries for the network interface specified
by if_addr.
-d Deletes the host specified by inet_addr. inet_addr may be
wildcarded with * to delete all hosts.
-s Adds the host and associates the Internet address inet_addr
with the Physical address eth_addr. The Physical address
address is given as 6 hexadecimal bytes separated by hyphens.
The entry is permanent.
eth_addr Specifies a physical address.
if_addr If present, this specifies the Internet address of the
interface whose address translation table should be modified.
If not present, the first applicable interface will be used.
Example:
> arp -s 157.55.85.212 00-aa-00-62-c6-09 .... Adds a static entry.
> arp -a .... Displays the arp table.
C:\>arp -a

Interface: 10.12.1.11 --- 0x2
Internet Address Physical Address Type
10.12.1.1 00-06-5a-23-06-f9 dynamic
Similar output from a Unix machine is shown next.
unix1% arp
Usage: arp hostname
arp -a
arp -d hostname
arp -s hostname ether_addr [temp] [pub] [trail]
arp -f filename
unix1% arp -a
Net to Media Table
Device IP Address Mask Flags Phys Addr
------ -------------------- --------------- ----- ---------------
hme0 10.12.1.1 255.255.255.255 00:06:5a:23:06:f9
hme0 10.12.1.68 255.255.255.255 00:04:f2:cd:65:1f
hme0 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00
In addition to displaying information about the translation from layer 2 to layer 3, the arp
command can also be used to add and delete entries to the ARP table.

Traceroute

Similar to the record route option of the ping command, the traceroute command is used to
determine the path that the packet is taking through the network. However, traceroute uses a
different approach than the ping command. Specifically, the traceroute command starts by
sending out a packet with a time to live (TTL) of 1. The TTL of this packet will expire at the
first router, and therefore this device will send back a TTL expiration message. The address
from which the TTL expiration comes is then recorded, and a second packet is sent out with a
TTL of 2. The second-hop router then replies back with a TTL expiration message. This process
continues until the destination is reached.
The traceroute command operates in the Unix and Windows environment in the same manner
as the trace command in the Cisco router.
Though the functionality is the same, it is worthy of note that in the Cisco and
the Unix versions of traceroute, a UDP packet on port 33434 is used for the tracing,
whereas Windows stations use an ICMP echo instead.
In Windows, the syntax for the traceroute command is tracert. The options for the command
are shown in the following output, which is followed by a sample trace:
C:\>tracert /?
Usage: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name

Options:
-d Do not resolve addresses to hostnames.
-h maximum_hops Maximum number of hops to search for target.
-j host-list Loose source route along host-list.
-w timeout Wait timeout milliseconds for each reply.
C:\>tracert 10.5.5.5
Tracing route to 10.5.5.5 over a maximum of 30 hops
1 7 ms 1 ms 1 ms 10.21.2.1
2 84 ms 83 ms 84 ms 10.45.45.3
3 88 ms 85 ms 83 ms 10.10.10.67
4 87 ms 86 ms 88 ms 10.5.5.5
Trace complete.
When looking at the preceding trace, there are a couple things to note. First, Windows by
default sends out three traces for each TTL value. The times listed to the left of the IP address
are the times for each of the TTL expiration messages from these packets to return.
Also, when comparing the output from a recorded ping to the output of the traceroute command,
be aware of a couple of noteworthy differences. Ping records the exiting interface on the
router, whereas traceroute in general records the interface on which you enter. Another difference
is that when using a traceroute, you only get the path taken to the end device; you do not
see the return path.
As is the case with many of the commands discussed here, there are some subtle differences
between Unix and Windows in terms of both syntax and output. Here are the Unix command
options and a sample output:
unix1% traceroute
Usage: traceroute [-dFInvx] [-f first_ttl] [-g gateway | -r] [-i iface]
[-m max_ttl] [-p port] [-q nqueries] [-s src_addr] [-t tos]
[-w waittime] host [packetlen]
unix1% traceroute 10.5.5.5
traceroute to 10.5.5.5 (10.5.5.5), 30 hops max, 40 byte packets
1 10.21.2.1 (10.21.2.1) 1.046 ms 1.878 ms 1.880 ms
2 10.45.45.3 (10.45.45.3) 82.487 ms 84.850 ms 83.378 ms
3 10.10.10.67 (10.10.10.67) 84.196 ms 86.057 ms 84.105 ms
4 10.5.5.5 (10.5.5.5) 89.133 ms 88.664 ms 88.597 ms
unix1%

Ping

The ping command was covered in some detail earlier in this chapter, so you can refer back to
the section “Creating an End-System Network Configuration Table” for the ping basics. Here
we will focus on some of the options available under the ping command that are helpful in your
troubleshooting activities.
One of the most common ping options is the continuous ping. These pings send a continuous
stream of packets to the destination address. Setting up a continuous ping to an end system that
is having connectivity problems is a good way to see when the end system is once again reachable
over the network. In Windows systems, the flag to send a continuous ping is -t, and in the
Unix environment the flag is -s.
Another frequently used ping option used for troubleshooting is the record route option.
This records the path the packet is taking through the network and stores this information in
the IP header of the ping packet.
The record route option does require that the intervening routers and the
end station retain this information in the packet, and the hop count is limited
to nine.

In a Windows station, record route can be enabled with the -r #_of_hops_to_record
option. In the following example, the route will be recorded for up to nine hops, which is the
maximum value allowed:
C:\>ping -r 9 10.5.5.5
Pinging 10.5.5.5 with 32 bytes of data:
Reply from 10.5.5.5: bytes=32 time=86ms TTL=251
Route: 10.45.45.1 ->
10.10.10.66 ->
10.5.5.1 ->
10.5.5.5 ->
10.16.16.18 ->
10.10.9.56 ->
10.10.7.23 ->
10.56.21.3
Reply from 10.5.5.5: bytes=32 time=86ms TTL=251
Route: 10.45.45.1 ->
10.10.10.66 ->
10.5.5.1 ->
10.5.5.5 ->
10.16.16.18 ->
10.10.9.56 ->
10.10.7.23 ->
10.56.21.3
Reply from 10.5.5.5: bytes=32 time=85ms TTL=251
Route: 10.45.45.1 ->
10.10.10.66 ->
10.5.5.1 ->
10.5.5.5 ->
10.16.16.18 ->
10.10.9.56 ->
10.10.7.23 ->
10.56.21.3
Reply from 10.5.5.5: bytes=32 time=83ms TTL=251
Route: 10.45.45.1 ->
10.10.10.66 ->
10.5.5.1 ->
10.5.5.5 ->
10.16.16.18 ->


10.10.9.56 ->
10.10.7.23 ->
10.56.21.3
Ping statistics for 10.5.5.5:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 83ms, Maximum = 86ms, Average = 85ms
In Unix, the similar command option for record route is as follows:
unix1% ping -s -nRv 10.5.5.5
PING 10.5.5.5 (10.5.5.5): 56 data bytes
64 bytes from 10.5.5.5: icmp_seq=0. time=123. ms
IP options: 10.45.45.1, 10.10.10.66, 10.5.5.1,
10.5.5.5, 10.16.16.18, 10.10.9.56, 10.10.7.23,
10.56.21.3


1079

End-System Troubleshooting Commands

As you learned earlier in this chapter in the section “Creating an End-System Network Configuration
Table,” there are many occasions when you need to execute commands on the end system
in order to get a clear picture of what is going on in the network. This is true not only for
the discovery of network information but also for the troubleshooting of network behavior.
Because the basic commands used for discovery were discussed earlier in the chapter, here in this
section we will focus specifically on the troubleshooting commands. You will notice that many
of the same commands are used for both troubleshooting and discovery.
In this section, the Unix versions of the commands are used for the Unix, Linux,
and MacOS X end-system types. There can be slight variations between the
Unix and the Linux/MacOS X versions of the commands. However, most are
very similar and in some cases identical to their Unix counterparts.

Troubleshooting End-System Problems

In a perfect world, network administrators would be free to work solely on the network components
of the system, and the end systems would be taken care of by someone else. The reality
is that we do not live in such a place, so network administrators frequently must help troubleshoot
problems on the end systems. The assistance provided may be simply checking connectivity,
or it may involve the complete rebuilding of the end system! We are not going to get into
the rebuilding of a Windows server from scratch. In this section, you will see how to diagnose
what is happening on an end system, and how to take some simple corrective actions when they
are needed.

In addition to running these commands directly, you can also have the end user run many of
these commands for you and tell you the results. This can be very helpful, especially when the
users are located in a remote location.
Some of the commands examined in this section are variations of the ones used in creating
the end-system documentation; others are new. But before we look at how to identify and correct
problems, we will spend a little more time on how to approach the problem.

Creating an End-System Network Topology Diagram

Now that an end-system network topology diagram has been explained, let’s go through the
steps to create one. Because most end-system network topology diagrams are built on the network
topology diagrams, the standard symbols set that was used in the network diagrams will
also be used here in the end-system network topology diagram. In addition, there will be symbols
to indicate servers, workstations, and other network attached end systems.
The other information added to the end-system network topology diagram is a subset of the
data in the end-system network configuration table. Figure 35.2 shows how this data maps to
the topology diagram.
As you can see in Figure 35.2, the servers entered in the network configuration are shown in
their appropriate place in the network. Only the key information on the servers was transferred
to the topology diagram to keep it from becoming too cluttered. Also, as mentioned earlier in
this discussion, notice in the upper-left of the diagram that a grouping of computers was used
instead of showing all 12 of the Seattle users’ computers. This simplifies the drawing without
sacrificing too much detail. If more detail is needed, specifically on the Seattle office, a new endsystem
network topology diagram could be created specifically for that office.
Well, after what seems like an eternity, you have completed your network configuration
tables, network topology diagrams, end-system network configuration tables, and end-system
network topology diagrams! Now you just have to make sure that you keep them accessible and
update them any time there’s a change in the network. Also, remember to print hardcopies regularly,
so that you will still have your documentation if the network is down.
1076

Windows Name Resolution

When working with Windows systems, it is important to know the process by which names are
associated to IP addresses. In a Unix system, this resolution is relatively straightforward and usually
involves the use of cached entries, a HOSTS file, or DNS. In a Windows environment, however,
there are a few other options available. All the options that are available are as follows:
Internal cache of recently used entries
Broadcast message to the local network
Local LMHOSTS file
Local HOSTS file
WINS server
DNS server
In addition to the local cache, the HOSTS file, and DNS are three other options: broadcast, LMHOSTS,
and WINS. The order in which these items are checked in a Windows system varies based on a
number of factors, but in general, the internal cache and broadcast message are the first items
used to try to resolve a name into an IP address.
Following this, the LMHOSTS and HOSTS files are used. Both these files are usually located in the
%SystemRoot%\System32\Drivers\Etc directory of each Windows end system. They are textbased
files that can be edited to provide static name-to-IP-address translation.
Next in the series is the Windows Internet Name Service (WINS) server, which is Microsoft’s
version of a NetBIOS name server. It dynamically updates the names of other Windows clients
that are on the network. The server can then be queried in much the same manner as a DNS
server for name-to-IP-address resolution.
The final item used by a Windows end system is a DNS server. As is the case with any station
using DNS, a Windows station sends a query to the DNS server, and the server responds with
the IP address or a notification saying it does not know the address.

End-System Network Topology Diagram

Now that the end-system network configuration table is complete, we will focus on the end-system
network topology diagram. Like the topology diagram for the network, the end-system diagram is

designed to give a graphical representation of the end-systems in the network, giving you a better
view of traffic flow and interdependencies. This view also allows for easier identification of potential
bottlenecks or significant points of failure. For example, you can easily see on the end-system network
topology diagram whether your users will need to cross a slow serial connection to get to new
servers that are being put in. You can also see if there is only one path available from these users to
the servers, and, if redundancy is required, alter the location of the servers or add another path.
In most cases, the end-system network topology diagram is just an extension of the network
topology diagram, with the information gathered for the end-system network configuration
table added. Because of the amount of information included in these diagrams, it is necessary
to ensure that only pertinent data is added. Adding too much data can quickly clutter up the diagram
and make it difficult to use.
Typical items in an end-system topology diagram are as follows:
System Name
Connection to the Network
System Purpose
VLAN
IP Address
Subnet Mask
Network Applications
At a minimum, the system name and connection to the network are needed on the topology
diagram. The exception to this rule is when you are including a large number of like-configured
end systems that serve a common purpose and exist on the same subnet. In this arrangement,
where it is impractical to include each separate machine in the diagram, they can be grouped
together and represented by descriptive text. An example of this grouping is shown in Figure 35.2
in the next section.

Creating an End-System Network Configuration Table

The easiest way to explain how to create an end-system network configuration table is to study
an example. In this example, we will look at creating the table for some servers. These servers
are used companywide for such processes as e-mail, system backup, and streaming video. All of
the servers are located in the Miami office of this company.
Based on this information, we have decided to include the following list of items in our endsystem
network configuration table:

System Name

System Purpose

Operating System

VLAN

IP Address

Subnet Mask


Default Gateway

DNS Servers

WINS Server

Network Applications

High-Bandwidth Network Applications

Low-Latency Network Applications
The start of the end-system network configuration table is shown in Figure 35.1, which
shows part of the information already entered for our example.
FIGURE 3 5 . 1
Sample end-system network configuration table
Unless you have an inventory management tool that can gather this information for you, a
lot of it will have to be collected manually. Depending on the system type, there are a number
of commands available to gather this information. As you will see in the “End-System Troubleshooting
Commands” section later in this chapter, many of these same commands can also be
used in troubleshooting when there is a problem in the network. Specifically, the commands
that we will examine are as follows:

For the Windows platforms:
ping
,
arp
,
telnet
,
ipconfig
,
and
winipcfg
.

For Unix, Linux, and Mac OS X systems:
ping
,
ifconfig
, and
cat /etc/resolv.conf
.
Most people are already familiar with the very useful
ping
command. This command is used
to send an ICMP echo and receive an ICMP echo reply over the network. The end-system implementation
of the
ping
command is very similar to that on Cisco routers and switches. Run in a
command window on an NT/2000/XP station, four Ping packets are sent out by default any time
the command is executed. Though it is primarily used for troubleshooting,
ping
can be used in the
discovery phase of documentation to verify which IP addresses on the network are in use.
The options of the
ping
command can be seen by executing the command
ping /?
, as
shown here:
C:\>
ping /?
Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
[-r count] [-s count] [[-j host-list] | [-k host-list]]
[-w timeout] target_name

Options:
-t Ping the specified host until stopped.
To see statistics and continue - type Control-Break;
To stop - type Control-C.
-a Resolve addresses to hostnames.
-n count Number of echo requests to send.
-l size Send buffer size.
-f Set Don't Fragment flag in packet.
-i TTL Time To Live.
-v TOS Type Of Service.
-r count Record route for count hops.
-s count Timestamp for count hops.
-j host-list Loose source route along host-list.
-k host-list Strict source route along host-list.
-w timeout Timeout in milliseconds to wait for each reply.
In the following output, the
ping
command in Windows NT/2000/XP shows not only the
results of the ping but a summary of the results, as well:
C:\>
ping 10.10.10.1
Pinging 10.10.10.1 with 32 bytes of data:
Reply from 10.10.10.1: bytes=32 time=136ms TTL=120
Reply from 10.10.10.1: bytes=32 time=136ms TTL=120
Reply from 10.10.10.1: bytes=32 time=138ms TTL=120
Reply from 10.10.10.1: bytes=32 time=137ms TTL=120
Ping statistics for 10.10.10.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 136ms, Maximum = 138ms, Average = 136ms
From a Unix, Linux, or MacOS X end system, the default values vary somewhat, but the general
concept is the same as a Windows end system. For example, from a Sun Solaris end system,
the options for
ping
are:
unix1%
ping
usage: ping host [timeout]
usage: ping -s[drvRlLn] [-I interval] [-t ttl] [-i interface] host
[data size] [npackets]

The output of the
ping
command can also vary based on the particular end system that is
being used. For example, the output could be four Ping packets as was the case with Windows,
or just a simple message stating the end system is alive, as is the case here:
unix1%
ping 10.10.10.1
10.10.10.1 is alive
unix1%
The help files in Unix are called man (short for manual) pages. These files can
be accessed by typing man command. So, to get more information on the ping
command, you would type man ping.
The arp command is used to show the current MAC-address-to-IP-address mappings on the end
system. These mappings can be used to determine which other end systems were recently contacted.
This can provide clues as to what applications are interdependent. The downside to the arp command
is that, because it is dependent on layer 2 information, it will only show the IP address of other
end systems on the same subnet. If network communication is with a device on another subnet, the
arp table will just show the IP address and MAC address of the default gateway.
Like the ping command, options for the arp command are displayed by adding a /? at the
end of the command.
C:\>arp /?
Displays and modifies the IP-to-Physical address translation tables
used by address resolution protocol (ARP).
ARP -s inet_addr eth_addr [if_addr]
ARP -d inet_addr [if_addr]
ARP -a [inet_addr] [-N if_addr]
-a Displays current ARP entries by interrogating the current
protocol data. If inet_addr is specified, the IP and Physical
addresses for only the specified computer are displayed.
If more than one network interface uses ARP, entries for
each ARP table are displayed.
-g Same as -a.
inet_addr Specifies an internet address.
-N if_addr Displays the ARP entries for the network interface specified
by if_addr.
-d Deletes the host specified by inet_addr. inet_addr may be
wildcarded with * to delete all hosts.

-s Adds the host and associates the Internet address inet_addr
with the Physical address eth_addr. The Physical address
is given as 6 hexadecimal bytes separated by hyphens. The
entry is permanent.
eth_addr Specifies a physical address.
if_addr If present, this specifies the Internet address of the
interface whose address translation table should be modified.
If not present, the first applicable interface will be used.
Example:
> arp -s 157.55.85.212 00-aa-00-62-c6-09 Adds a static entry.
> arp -a Displays the arp table.
And here is a sample output of the arp command using the -a option to list the current
translations:
C:\>arp -a
Interface: 10.9.9.9 --- 0x2
Internet Address Physical Address Type
10.9.9.1 00-06-22-fd-06-01 dynamic
10.9.9.100 00-e0-18-19-a8-19 dynamic
10.9.9.222 00-a0-cc-cb-64-c5 dynamic
The telnet command is used for the discovery of end systems in two different ways. First,
telnet can be used by the network administrator to log in to some of the end systems on the network
remotely. This functionality is enabled by default on most Unix and Linux servers but is not
by default available on Windows NT/2000/XP. Secondly, telnet can be used to verify that an
end system is indeed listening on a particular TCP port. For example, you can telnet to a web
server on TCP port 80. You will not see any meaningful data, but if a connection is established,
you have verified not only that the server is listening on port 80 but also that port 80 traffic is getting
through the network to the server.
Use caution when telnetting to a port. Though it is usually not a problem, some
custom applications do not respond well to these types of connections.
The options for Telnet on Windows NT/2000/XP are shown in the following command output:
C:\>telnet /?
telnet [-a][-e escape char][-f log file][-l user][-t term][host [port]]
-a Attempt automatic logon. Same as -l option except uses the currently
logged on user's name.
-e Escape character to enter telnet client prompt.
-f File name for client side logging

-l Specifies the user name to log in with on the remote system. Requires
that the remote system support the TELNET ENVIRON option.
-t Specifies terminal type. Supported term types are vt100, vt52,
ansi and vtnt only.
host Specifies the hostname or IP address of the remote computer to connect
to.
port Specifies a port number or service name.
The ipconfig command is the first command in the series discussed here that will go a long way
toward getting the data you need in order to complete the end-system network configuration table.
This command shows detailed information on the IP address, DNS servers, and WINS servers that
are configured on the Windows NT/2000/XP workstation. As is the case for all the commands covered
in this section, ipconfig is run from the command prompt on the Windows NT/2000/XP end
system. Some of the other command options will be explained in the “End-System Troubleshooting
Commands” section later in this chapter, but for the documentation process, the /all option is
what is primarily used. The entire list of options for ipconfig are shown here:
C:\>ipconfig /?
USAGE:
ipconfig [/? | /all | /renew [adapter] | /release [adapter] |
/flushdns | /displaydns | /registerdns |
/showclassid adapter |
/setclassid adapter [classid] ]
where
adapter Connection name
(wildcard characters * and ? allowed, see examples)
Options:
/? Display this help message
/all Display full configuration information.
/release Release the IP address for the specified adapter.
/renew Renew the IP address for the specified adapter.
/flushdns Purges the DNS Resolver cache.
/registerdns Refreshes all DHCP leases and re-registers DNS names
/displaydns Display the contents of the DNS Resolver Cache.
/showclassid Displays all the dhcp class IDs allowed for adapter.
/setclassid Modifies the dhcp class id.
The default is to display only the IP address, subnet mask and default gateway
for each adapter bound to TCP/IP.
For Release and Renew, if no adapter name is specified, then the IP address

leases for all adapters bound to TCP/IP will be released or renewed.
For Setclassid, if no ClassId is specified, then the ClassId is removed.
Examples:
> ipconfig ... Show information.
> ipconfig /all ... Show detailed information
> ipconfig /renew ... renew all adapters
> ipconfig /renew EL* ... renew any connection that has its
name starting with EL
> ipconfig /release *Con* ... release all matching connections,
eg. "Local Area Connection 1" or
"Local Area Connection 2"
The following is the output of the ipconfig /all command. The IP address, subnet, gateway,
DNS servers, and WINS servers are underlined:
C:\>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : Server1
Primary Dns Suffix . . . . . . . : fla.somecompany.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : fla.somecompany.com
somecompany.com
Ethernet adapter Local Area Connection 4:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : NVIDIA nForce MCP
Networking Adapter
Physical Address. . . . . . . . . : 00-cc-47-49-F4-32
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 10.9.9.9
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.9.9.1
DNS Servers . . . . . . . . . . . : 10.3.3.3
10.4.4.3
Primary WINS Server . . . . . . . : 10.5.5.3
Secondary WINS Server . . . . . . : 10.6.6.3

If the end system you are working on is Windows 9x or Windows ME, a different methodology
is used to discover this information. On these machines, there is a GUI tool that replaces the
ipconfig command-line command. The executable to start this tool is winipcfg.exe. This utility
shows all the same information as ipconfig, but it does so via the GUI instead of the command line.
Both ipconfig and winipcfg are available in Windows 98.
To get the IP information from a Unix, Linux, or MacOS X system, you use the ifconfig
-a command. This prints out the address information for each interface on the box. Here’s a
sample output:
unix1% ifconfig -a
lo0: flags=849 mtu 8232
inet 127.0.0.1 netmask ff000000
hme0: flags=863 mtu 1500
inet 10.7.7.58 netmask ffffff00 broadcast 10.7.7.255
As is the case in many routers, the loopback interface is an internal virtual interface. Because
the loopback is addressed with 127.0.0.1, it is only used for internal communication inside the
box. The hme0 interface is the interface that is connected to the network and is the one that goes
into the end-system network configuration table.
Because Unix, Linux, and MacOS X end systems do not use WINS, the only remaining bit of
IP information that you need to get from the end system is the DNS servers’ names. This is stored
in the resolv.conf file, which is most often found in the /etc directory on the system. To see the
DNS servers that are defined, all you need to do is to list the contents of the resolv.conf file
using the cat command, as shown here:
unix1% cat /etc/resolv.conf
domain fla.somecompany.com
search fla.somecompany.com somecompany.com
nameserver 10.3.3.3
nameserver 10.4.4.3
For the remaining information in the end-system configuration table such as the applications
on the system and which of these applications are high- and low-bandwidth and/or low-latency
applications, it is best to talk with the server administrators. They will have the best idea of what
is on each server and how it is used.

End-System Network Configuration Table

The general purpose of an
end-system network configuration table
, also referred to as an endsystem
configuration table, is to give a listing of the hardware and software components on the
end systems in the network. Much like the network configuration table was a listing of network
devices, the end-system network configuration table is a listing of the end systems in the environment
and key features about them. Depending on the size of your network, an end-system
network configuration table may contain all devices or just the servers and network management
stations.
Though it was mentioned in Chapter 34, it is worth repeating that there are five steps to
ensuring that you have good, effective documentation:

Determine the scope.

Know your objective.

Be consistent.

Keep the documents accessible.

Maintain the documentation.
These actions directly apply to the end-system documentation as well, so be sure to keep
them in mind as you are planning for and implementing your documentation strategy.
The specific items included in your end-system network configuration table will vary depending
on the purpose of the table. There will be vastly different information included if the table is going
to be used only for inventory purposes, as compared with the type of table maintained as a troubleshooting
tool. Therefore, in order to determine what you need to include in your end-system configuration
table, you need to start by defining the role of the table and choosing items for the table
that will achieve this goal. Some common items included in end-system configuration tables are
listed in Table 35.1.

One of the items you will immediately notice when looking at the table is the information
that is included on layer 7, the Application layer. Because one of the primary roles for servers
is to service applications, it is imperative that layer 7 information be captured somewhere. For
example, say you get a call from a user who cannot get to the XYZ database, but everything else
on their system is working fine. By looking at the end-system configuration table you can see
that the XYZ database exists on a single server. You have now greatly narrowed the scope of
the problem and can more effectively begin the troubleshooting process.
The end-system configuration table is typically compiled in either a spreadsheet or database
application. In addition to this electronic version, regular hardcopies of the end-system
configuration table must be made to ensure that the information is accessible in the event of
a network problem.
Now that we have defined what an end-system network configuration table is, the next section
will walk you through the process of creating one.

End-System Documentation and Troubleshooting

THE CCNP EXAM TOPICS COVERED IN THIS
CHAPTER INCLUDE THE FOLLOWING:

Create end-system documentation.

Know troubleshooting methodologies.

Verify network connectivity.

Use the optimal troubleshooting approach in resolving
network problems.

Develop a network documentation system.

Work with end users to diagnose and resolve network
problems.

Understand the document control process and
documentation standards.

Establish a baseline indicative of optimal network
performance.

Create a baseline monitoring methodology

You learned in Chapter 34, “Network Documentation,” that
detailed network information can be an invaluable tool in troubleshooting
network problems. However, many network problems
are a result of the end systems on the network, not the network itself. The purpose of this chapter
is to examine the documentation for these end systems so that you can effectively address network
problems in these areas. This chapter will also explore a new troubleshooting approach based on
the OSI model. Finally, this chapter will end with an overview of some of the commands that can
be used on end systems to assist in troubleshooting network problems.

Network Documentation

Documentation is essential in today’s increasingly complex networks. It provides vital information
that can greatly reduce network downtime. It also provides verification that the network
is operating correctly.
Baseline information on a network is information about the normal operating conditions of a
network. This baseline is used to determine whether a network configuration is set up in the manner
expected and whether it is operating normally. Some of the specific components of the network
baseline are the network configuration tables, the network topology diagrams, the endsystem
configuration tables, and the end-system topology diagrams.
Network configuration tables show the key configuration parameters that are in place on the
network devices. Some typical items included in a network configuration table are device name,
flash memory DRAM, IOS/CatOS, interface number, MAC address, speed, duplex, VLANs,
trunking, IP address, subnet, subnet mask, and routing protocol. Although these are some of the
standard items in a network configuration table, each table will vary based on a device’s type
and on the design of the particular network. In most cases this information is stored in a spreadsheet
or database format, but hard copies should be regularly printed so that information will
always be available in the event of a problem or failure.
Network topology diagrams are graphical representations of the network components, and
in most cases they contain a subset of the data maintained in the network configuration tables.
The topology diagrams are meant to make the network administrator better able to visualize the
path across the network. Some standard items that go into a network topology are device name,
connections between devices, interface name, VLANs, trunking, IP address, subnet mask, and
routing protocols. As is true for the network configuration tables, hard copies of network topology
diagrams should be regularly printed to ensure that information is always available when
the network goes down.
Exam Essentials
Know what a network baseline is and the major components that go into making it. A
baseline is a set of documentation that establishes normal operating conditions on the network.
Some of the key components of a baseline are the network configuration tables, the
network topology diagrams, the end-system configuration tables, and the end-system topology
diagrams.
Know what network configuration tables are and the information they contain. Network
configuration tables are used to record key settings of network devices, as well as other related
information. Some common items included in a network configuration table are device name,
flash information, DRAM, IOS/CatOS, interface number, MAC address, speed, duplex,
VLANs, trunking, IP address, subnet, subnet mask, and routing protocol.


Know what network topology diagrams are and the information they contain. Network
topology diagrams are graphical representations of the network; they are usually built from
many of the same components as the network configuration tables. Some common components
of network topology diagrams are device name, connections between devices, interface name,
VLANs, trunking, IP address, subnet mask, and routing protocols. 1064

Creating a Network Topology Diagram

Now that we have explained the purpose and suggested components for a network topology
diagram, let’s go through the steps to create one.
We will begin with an examination of the standard set of symbols used in such diagrams.
By now, most of you will have already seen and know these symbols; they are illustrated in
Figure 34.3. Employing a standard set of symbols for device types helps to ensure that any
new network administrators coming into the environment will be able to easily understand
the documentation.
FIGURE 3 4 . 3 Networking symbols
In most cases, a network topology diagram is created after the network configuration tables
are set up, because the topology diagram uses much of the information contained in the configuration
tables. Figure 34.4 illustrates a sample network topology diagram and its relationship
to some of the information used from the router configuration table.
Similarly, there is also a direct correlation between items on the topology diagram and the
switch network configuration table, as illustrated in Figure 34.5.
Because most of the information that is on the network topology diagram has already been
retrieved and placed in the network configuration tables, relatively few commands are needed
to generate the diagram itself. One command of great assistance is show cdp neighbors. The
Cisco Discovery Protocol (CDP) is a proprietary protocol that identifies directly attached Cisco
devices. This discovery is done at layer 2, so there is no need to have IP connectivity to see the
neighbors. The show cdp neighbor command shows the neighbors that have been learned via
CDP and gives their summary information. More detailed information can be found by using
the show cdp neighbors detail command.

Consistency and Simplicity Are the Keys

When creating network documentation, one goal that is frequently overlooked is the need to
make the documentation consistent and easy to read. Make an effort to apply the same structure
and methodology consistently to all the documentation. In this chapter we have discussed
the need for consistency when gathering the information and setting up a document, but it is
also important to maintain this uniformity from one document to the next.
One of the main purposes of your network documentation is its role in a troubleshooting
effort when the network is down. Because you can’t schedule when a problem will occur,
it is quite possible that you will be using your documentation to solve a problem in the middle
of the night, when you are not completely rested and are not operating at your peak
effectiveness. At such a time, you do not want to be saddled with documents that are
incompatible or so cluttered with information that they are difficult to read. Keep in mind
when and how the network documentation is going to be used, and take some simple steps
to make it easy to comprehend.
One of the first things you should do is ensure that the symbols used on all the diagrams mean
the same thing on each one. Do not use one symbol to signify a router on one diagram and a
different symbol to represent the same router on another.
Next, create a template for all your network configuration tables and topology diagrams. Earlier
in this chapter we discussed the template for a network configuration table, but templates for
network topology diagrams can be even more useful. For example, if you have multiple branch
locations, use an identical format and device-placement scheme on all the topology diagrams
so that similar information is always in the same spot on each diagram. This will save you time
in locating the facts you need.
Besides maintaining consistency, it is also important to avoid too much complexity. If the network
documentation contains extraneous information, that can make it difficult to find the
specifics that you need for your troubleshooting. The documentation should have enough
information to help you understand how things are connected and what the baseline of the
network is, without overwhelming you with data that may or may not be relevant.

1058

Components of a Network Topology Diagram

Like the network configuration table, the network topology diagram can contain a number of
items; its scope will depend on the complexity of the network involved. In its simplest form, a
network topology diagram will only include the devices and the connections between them.
However, in most cases, the diagram will contain much more information. Some common items
are as follows:
Device Name
Connections Between Devices (which can also include circuit numbers on WAN links)
Device Type
Interface Name
Speed
Media Type
MAC Address
VLANs
Trunk
Encapsulation
IP Address
Subnet
Subnet Mask
Routing Protocols
Unlike the network configuration tables, it is quite common for the network topology diagram
to depict a combination of layer 2 and layer 3 devices. This allows for a more complete
view of the interactions in the network and a better overall view of network connectivity. Just
as you do with network configuration tables, however, you need to be careful to incorporate
enough information into the topology diagram without adding too much. These are working
documents; if they become too overloaded with information, their maintenance will be more
difficult. On the other side, you don’t want to be hunting down information in the middle of an
emergency. There is a delicate balance between too much and not enough information.

Another point of note: Unless your network is small, you are not going to be able to fit it into
a single network topology diagram. Typically, you will need to make multiple topology diagrams
that cover separate aspects of the network. Depending on the drawing program you are
using to create the diagrams, you can also link each of these separate topology diagrams
together. In this manner, you can double-click a particular area to see more- or less-detailed
information or move to another segment of the network.

Network Topology Diagrams

Network configuration tables are great building blocks for your network documentation, but they
are not sufficient for getting a clear picture of how devices connect and interact within the network.
This is where the network topology diagram comes in. Simply put, a network topology diagram
is nothing more than a graphical representation of the network, allowing you to easily see
how components in the network are connected and how they interact. Arguably, it is the most
heavily utilized piece of documentation used in network troubleshooting and maintenance.