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.