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% 1081

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

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.

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.

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.

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.

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.

Sample List of Network Configuration Table Items for End Systems
Classification Items
Miscellaneous information System name, system manufacturer/model, CPU speed,
RAM, storage, system purpose
Layers 1 and 2 Media type, interface speed, VLAN, network jack
Layer 3 IP address, default gateway, subnet mask, WINS, DNS
Layer 7 Operating system (including version), network-based
applications, high-bandwidth applications, and lowlatency
applications, special considerations