Systems send protocol data units (PDUs) to one another, and each level of the OSI model has
its own type of PDU. Figure 36.4 shows the PDU names for all seven OSI layers. For example,
the Application layer’s PDU name is layer 7 PDU. Although this convention can be used for all
layers, some layers use other names as well. For instance, a layer 3 PDU is called a
packet
and
a layer 2 PDU is called a
frame
. When a system sends data to another system, the data has to
be fragmented so that it fits the MTU (maximum transmission unit). Therefore, several frames
may be needed to transfer the original data. Connection-oriented protocols assign a sequence
number to each outgoing and incoming PDU. This is
sequenced data transfer
.
Figure 36.5 shows you how sequencing works. There is a possibility that the destination system
will receive the PDUs out of order. If this happens, the protocol on the destination system
uses the sequence numbers to put the PDUs back into the correct order so that the original data
is obtained. 1101
IT Certification CCIE,CCNP,CCIP,CCNA,CCSP,Cisco Network Optimization and Security Tips
Connection-Oriented Protocols
Connection-oriented protocols
contain inherent functions that control the connection as well as
data transfer. These functions are very detailed in the procedures that are followed to enable
reliable and error-free data transfer. When a source open system needs to transfer data to a destination
open system, the connection-oriented protocols actually establish a communication
pipe. The
pipe,
as it is called here, is nothing more than a logical connection between two open
systems. A great deal of information is used to establish this communication pipe, however.
In order to establish a connection, the two open systems must share certain information that
allows them to negotiate terms and finally establish a link. The information includes the common
protocol that will be used, required resources, and available resources. Look at Figure 36.3. This
figure shows the steps taken as communication is established between two open systems when
using TCP, a connection-oriented protocol.
The originating system first sends a connection request to the destination system. This
request contains information that the two systems need to agree upon before the connection can
be established. Some of the information includes the common protocol, protocol parameters,
and required resources.
Protocol parameters
are the window sizes and other possible parameters.
The
window size
is the amount of data that a station can transmit before needing an
acknowledgment from the destination system that all the data was received without error, or
that errors existed and part of the data will need to be retransmitted.
Required resources
can
include necessary bandwidth, specific port numbers, and other network resources.
The destination system receives this connection request; if it can accommodate the common
protocol, protocol attributes, and required resources, it replies with a connection accept. If, for
some reason, the destination system cannot accommodate any of the requirements sent by the
originating system, the destination system responds with a connection deny. A denied connection
can result from a blocked port on the destination system, insufficient bandwidth between
the systems, or other unavailable requested resources.
Assuming that a connection is established between the two systems, data and control information
is exchanged during the life of the connection. This data exchange can be considered a
dialog
. First, the originating system sends data until the window size is reached. That system
then waits for a response from the destination system. The destination system sends control
information that informs the originating system what needs to happen next. The transmission
can be an acknowledgment that all data in the transmission was received without error and that
the originating system can send the next batch of data. In addition, the destination system can
send a message informing the originating system that some of the data was missing, corrupted,
or had other errors that require the data to be retransmitted.
The foregoing procedure can be summarized with the description of three processes. You will
learn more about each of these processes in the following sections:
Sequenced data transfer
Each packet of a session is assigned a sequence number.
Flow control
Acknowledgments are required after a specified amount of data has been sent.
Error control
Verification of contiguous and nonerroneous packets.
contain inherent functions that control the connection as well as
data transfer. These functions are very detailed in the procedures that are followed to enable
reliable and error-free data transfer. When a source open system needs to transfer data to a destination
open system, the connection-oriented protocols actually establish a communication
pipe. The
pipe,
as it is called here, is nothing more than a logical connection between two open
systems. A great deal of information is used to establish this communication pipe, however.
In order to establish a connection, the two open systems must share certain information that
allows them to negotiate terms and finally establish a link. The information includes the common
protocol that will be used, required resources, and available resources. Look at Figure 36.3. This
figure shows the steps taken as communication is established between two open systems when
using TCP, a connection-oriented protocol.
The originating system first sends a connection request to the destination system. This
request contains information that the two systems need to agree upon before the connection can
be established. Some of the information includes the common protocol, protocol parameters,
and required resources.
Protocol parameters
are the window sizes and other possible parameters.
The
window size
is the amount of data that a station can transmit before needing an
acknowledgment from the destination system that all the data was received without error, or
that errors existed and part of the data will need to be retransmitted.
Required resources
can
include necessary bandwidth, specific port numbers, and other network resources.
The destination system receives this connection request; if it can accommodate the common
protocol, protocol attributes, and required resources, it replies with a connection accept. If, for
some reason, the destination system cannot accommodate any of the requirements sent by the
originating system, the destination system responds with a connection deny. A denied connection
can result from a blocked port on the destination system, insufficient bandwidth between
the systems, or other unavailable requested resources.
Assuming that a connection is established between the two systems, data and control information
is exchanged during the life of the connection. This data exchange can be considered a
dialog
. First, the originating system sends data until the window size is reached. That system
then waits for a response from the destination system. The destination system sends control
information that informs the originating system what needs to happen next. The transmission
can be an acknowledgment that all data in the transmission was received without error and that
the originating system can send the next batch of data. In addition, the destination system can
send a message informing the originating system that some of the data was missing, corrupted,
or had other errors that require the data to be retransmitted.
The foregoing procedure can be summarized with the description of three processes. You will
learn more about each of these processes in the following sections:
Sequenced data transfer
Each packet of a session is assigned a sequence number.
Flow control
Acknowledgments are required after a specified amount of data has been sent.
Error control
Verification of contiguous and nonerroneous packets.
Global Protocol Classifications
As mentioned, each layer of the OSI model utilizes specific protocols that enable the layer to perform
the necessary functions and communicate with adjacent layers. Each protocol has specific
properties based on the functions that it needs to accomplish. Throughout all seven layers, there
are two major protocol classifications: connection-oriented and connectionless. 1098.2.
the necessary functions and communicate with adjacent layers. Each protocol has specific
properties based on the functions that it needs to accomplish. Throughout all seven layers, there
are two major protocol classifications: connection-oriented and connectionless. 1098.2.
The OSI Reference Model
This section is a review of the OSI model, which was originally discussed in
CCNA: Cisco Certified
Network Associate Study Guide, 4th ed
., by Todd Lammle (Sybex, 2004). The
OSI model
(the Open Systems Interconnection reference model) is the template used to design applications
or protocols that allow nonhomogenous computers or networks to communicate with one
another. The ISO (International Organization for Standardization) developed the OSI model.
The OSI model consists of seven layers. Each layer communicates directly with its adjacent layers,
as well as with the corresponding layer of the destination system (depicted in Figure 36.1).
Communication between layers facilitates the transfer of data up and down the OSI model. Communication
between the corresponding layers of the source system and the destination system
enables two heterogeneous networks or computers to understand each other.
The OSI template defines the services and roles that each layer is to provide. Because each
layer provides different services and functions, the layers need to communicate so that the data
can be transmitted up and down the seven layers and onto the destination system. The following
list summarizes the responsibility of each of the seven layers, starting from the Physical layer
and working up to the Application layer:
Physical
This layer sends and receives bits with values of 1s and 0s. The Physical layer is
in charge of determining how it sends these values. If the physical connection between two
machines is fiber-optic, then the Physical layer has to use light to transmit the 1s and 0s. If
the connection is electrical, then electrical signals are sent to represent the 1s and 0s.
Data Link
This layer takes all the data that is accumulated as packets are handed from one layer
to the next and then packages it into frames. The Data Link layer equates the Network layer address
(IP address) to a data link address, or MAC address, of the next hop. Once the physical address is
known, the frame is sent to that address. The receiving interface uses the Data Link layer to extract
the packet from the frame, discards the frame, and then sends the packet up to the Network layer.
Network
This layer defines the topology of the network through the use of logical addressing.
Routing protocols use this information to route packets.
Transport
This layer takes care of end-to-end communications. It is responsible for the
connection to the destination system, as well as for packet segmentation and assembly. The
Transport layer includes both connection-oriented and connectionless protocols (for example,
TCP and UDP).
Session
This layer is responsible for coordinating communication among applications, which
it does through dialog-control methods.
Presentation
This layer negotiates syntax, so it is responsible for the proper method of presenting
the data to the Application layer. Some of the Presentation layer functions are compression/
decompression and encryption/decryption of data.
Application
This is the user and application interface. The Application layer is responsible for
data exchange and job management. It also handles file, print, message, database, and application
services.
You saw how the logical data flow of the OSI model works, but look at Figure 36.2, in
which you can see the actual data flow. This figure depicts data that is handed from the Application
layer all the way down to the Physical layer. At that point, the data is transmitted
across any variety of physical media to the next hop, or destination system. Once the 1s and
0s arrive at the Physical layer of the destination system, the information is sent to layer 2 (the
Data Link layer). This layer discards the frame, and then the extracted packet is handed up
to the Network layer. The network packet header is stripped off, and the resulting packet is
handed up to the Transport layer. This process is repeated for each layer until it arrives at the
Application layer.
Now that each layer of the OSI reference model has been explained briefly, you need to
focus on the functions of each layer in detail. This detail provides the necessary background
and information to effectively troubleshoot network problems that occur within specific layers
of the OSI model.
CCNA: Cisco Certified
Network Associate Study Guide, 4th ed
., by Todd Lammle (Sybex, 2004). The
OSI model
(the Open Systems Interconnection reference model) is the template used to design applications
or protocols that allow nonhomogenous computers or networks to communicate with one
another. The ISO (International Organization for Standardization) developed the OSI model.
The OSI model consists of seven layers. Each layer communicates directly with its adjacent layers,
as well as with the corresponding layer of the destination system (depicted in Figure 36.1).
Communication between layers facilitates the transfer of data up and down the OSI model. Communication
between the corresponding layers of the source system and the destination system
enables two heterogeneous networks or computers to understand each other.
The OSI template defines the services and roles that each layer is to provide. Because each
layer provides different services and functions, the layers need to communicate so that the data
can be transmitted up and down the seven layers and onto the destination system. The following
list summarizes the responsibility of each of the seven layers, starting from the Physical layer
and working up to the Application layer:
Physical
This layer sends and receives bits with values of 1s and 0s. The Physical layer is
in charge of determining how it sends these values. If the physical connection between two
machines is fiber-optic, then the Physical layer has to use light to transmit the 1s and 0s. If
the connection is electrical, then electrical signals are sent to represent the 1s and 0s.
Data Link
This layer takes all the data that is accumulated as packets are handed from one layer
to the next and then packages it into frames. The Data Link layer equates the Network layer address
(IP address) to a data link address, or MAC address, of the next hop. Once the physical address is
known, the frame is sent to that address. The receiving interface uses the Data Link layer to extract
the packet from the frame, discards the frame, and then sends the packet up to the Network layer.
Network
This layer defines the topology of the network through the use of logical addressing.
Routing protocols use this information to route packets.
Transport
This layer takes care of end-to-end communications. It is responsible for the
connection to the destination system, as well as for packet segmentation and assembly. The
Transport layer includes both connection-oriented and connectionless protocols (for example,
TCP and UDP).
Session
This layer is responsible for coordinating communication among applications, which
it does through dialog-control methods.
Presentation
This layer negotiates syntax, so it is responsible for the proper method of presenting
the data to the Application layer. Some of the Presentation layer functions are compression/
decompression and encryption/decryption of data.
Application
This is the user and application interface. The Application layer is responsible for
data exchange and job management. It also handles file, print, message, database, and application
services.
You saw how the logical data flow of the OSI model works, but look at Figure 36.2, in
which you can see the actual data flow. This figure depicts data that is handed from the Application
layer all the way down to the Physical layer. At that point, the data is transmitted
across any variety of physical media to the next hop, or destination system. Once the 1s and
0s arrive at the Physical layer of the destination system, the information is sent to layer 2 (the
Data Link layer). This layer discards the frame, and then the extracted packet is handed up
to the Network layer. The network packet header is stripped off, and the resulting packet is
handed up to the Transport layer. This process is repeated for each layer until it arrives at the
Application layer.
Now that each layer of the OSI reference model has been explained briefly, you need to
focus on the functions of each layer in detail. This detail provides the necessary background
and information to effectively troubleshoot network problems that occur within specific layers
of the OSI model.
Protocol Attributes
THE CCNP EXAM TOPICS COVERED IN THIS
BLOG INCLUDE THE FOLLOWING:
Verify network connectivity.
Use the optimal troubleshooting approach in resolving
network problems.
Minimize downtime during troubleshooting.
Use Cisco IOS commands to identify problems.
Determine the layer or layers on which a problem is occurring.
As you know, to successfully troubleshoot network problems, it is
important to have a good understanding of how network components,
including PCs and servers, communicate with each other.
Without this basic knowledge, troubleshooting a network problem is like trying to read a book in
a foreign language. The information is there, but it just isn’t comprehensible. Although the troubleshooting
model discussed in Chapter 33, “Troubleshooting Methodology,” provides the method of
retrieving all the necessary information, the data is useless without an understanding of the information
presented.
This chapter is a review of the protocols used by layers 2, 3, and 4 of the OSI model. We briefly
review the seven layers of the OSI model, and then discuss how they communicate with one another.
We then discuss layer 2 and layer 3 protocols. More specific information on some of the material
covered here can be found in later chapters and is cross-referenced here where appropriate.
BLOG INCLUDE THE FOLLOWING:
Verify network connectivity.
Use the optimal troubleshooting approach in resolving
network problems.
Minimize downtime during troubleshooting.
Use Cisco IOS commands to identify problems.
Determine the layer or layers on which a problem is occurring.
As you know, to successfully troubleshoot network problems, it is
important to have a good understanding of how network components,
including PCs and servers, communicate with each other.
Without this basic knowledge, troubleshooting a network problem is like trying to read a book in
a foreign language. The information is there, but it just isn’t comprehensible. Although the troubleshooting
model discussed in Chapter 33, “Troubleshooting Methodology,” provides the method of
retrieving all the necessary information, the data is useless without an understanding of the information
presented.
This chapter is a review of the protocols used by layers 2, 3, and 4 of the OSI model. We briefly
review the seven layers of the OSI model, and then discuss how they communicate with one another.
We then discuss layer 2 and layer 3 protocols. More specific information on some of the material
covered here can be found in later chapters and is cross-referenced here where appropriate.
End-System Documentation and Troubleshooting Exam Essentials
Know what end-system network configuration tables are and the information they contain.
End-system network configuration tables are used to record key settings of end systems in the
network. Items commonly included in an end-system network configuration table are system
name, system manufacturer/model, CPU speed, RAM, storage, system purpose, media type,
interface speed, VLAN, IP address, default gateway, subnet mask, WINS, DNS, operating system
(including version), network-based applications, high-bandwidth applications, and lowlatency
applications.
Know what end-system network topology diagrams are and the information they contain.
End-system network topology diagrams are graphical representations of the network and are
usually built with many of the same components as the end-system network configuration
tables. Some common components of the end-system network topology diagram are system
name, connection to the network, system purpose, VLAN, IP address, subnet mask, and network
applications.
Know the commands to discover information and troubleshoot end systems. There are Unix
and Windows versions of the discovery and troubleshooting commands, and many of them correlate
directly to Cisco IOS commands. Some of these commands are arp, ifconfig, ipconfig,
netstat, ping, route, telnet, and traceroute.
End-system network configuration tables are used to record key settings of end systems in the
network. Items commonly included in an end-system network configuration table are system
name, system manufacturer/model, CPU speed, RAM, storage, system purpose, media type,
interface speed, VLAN, IP address, default gateway, subnet mask, WINS, DNS, operating system
(including version), network-based applications, high-bandwidth applications, and lowlatency
applications.
Know what end-system network topology diagrams are and the information they contain.
End-system network topology diagrams are graphical representations of the network and are
usually built with many of the same components as the end-system network configuration
tables. Some common components of the end-system network topology diagram are system
name, connection to the network, system purpose, VLAN, IP address, subnet mask, and network
applications.
Know the commands to discover information and troubleshoot end systems. There are Unix
and Windows versions of the discovery and troubleshooting commands, and many of them correlate
directly to Cisco IOS commands. Some of these commands are arp, ifconfig, ipconfig,
netstat, ping, route, telnet, and traceroute.
End-System Documentation and Troubleshooting Summary
End-system documentation is just as important as the network documentation in terms of the overall
documentation strategy. The two main components that make up end-system documentation are
the end-system network configuration table and the end-system network topology table.
End-system network configuration tables are documents that show the key configuration
parameters in place on the end systems in the network. Some of the common items in an endsystem
network configuration table are the system name, system manufacturer/model, CPU
speed, RAM, storage, system purpose, media type, interface speed, VLAN, IP address, default
gateway, subnet mask, WINS, DNS, operating system (including version), network-based applications,
high-bandwidth applications, and low-latency applications. The specific items included
on the end-system network configuration table depend on the purpose of the documentation. In
most cases, the end-system table is kept in a spreadsheet or database format. As is the case with
all the documentation covered in this book, be sure to keep hardcopies of the documents to use
in the event of a network outage.
End-system network topology diagrams are graphical representations of the end systems in
the network. In many cases, they are just additions to the network topology diagram; however,
they can be their own entity. The data included in an end-system network topology diagram is
usually a small subset of that maintained in the end-system network configuration tables. The
topology diagrams are meant to make the network administrator better able to visualize the
path across the network. Some of the standard items that go into an end-system network topology
are system name, connection to the network, system purpose, VLAN, IP address, subnet
mask, and network applications.
Finally, in this chapter we covered a number of commands that can be used to effectively
troubleshoot problems on end systems. These commands include ping and its record route
option, traceroute, arp, route, nbtstat, netstat, and ipconfig. All of these commands
have Windows NT/2000/XP and Unix equivalents, and most have a direct relationship to a
Cisco IOS command.
documentation strategy. The two main components that make up end-system documentation are
the end-system network configuration table and the end-system network topology table.
End-system network configuration tables are documents that show the key configuration
parameters in place on the end systems in the network. Some of the common items in an endsystem
network configuration table are the system name, system manufacturer/model, CPU
speed, RAM, storage, system purpose, media type, interface speed, VLAN, IP address, default
gateway, subnet mask, WINS, DNS, operating system (including version), network-based applications,
high-bandwidth applications, and low-latency applications. The specific items included
on the end-system network configuration table depend on the purpose of the documentation. In
most cases, the end-system table is kept in a spreadsheet or database format. As is the case with
all the documentation covered in this book, be sure to keep hardcopies of the documents to use
in the event of a network outage.
End-system network topology diagrams are graphical representations of the end systems in
the network. In many cases, they are just additions to the network topology diagram; however,
they can be their own entity. The data included in an end-system network topology diagram is
usually a small subset of that maintained in the end-system network configuration tables. The
topology diagrams are meant to make the network administrator better able to visualize the
path across the network. Some of the standard items that go into an end-system network topology
are system name, connection to the network, system purpose, VLAN, IP address, subnet
mask, and network applications.
Finally, in this chapter we covered a number of commands that can be used to effectively
troubleshoot problems on end systems. These commands include ping and its record route
option, traceroute, arp, route, nbtstat, netstat, and ipconfig. All of these commands
have Windows NT/2000/XP and Unix equivalents, and most have a direct relationship to a
Cisco IOS 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.
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.
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:\>
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:\>
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
...
...
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
...
...
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.
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 [[ -
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.
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.
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% 1081
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
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.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.
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.
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.
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.
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.
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
inet 127.0.0.1 netmask ff000000
hme0: flags=863
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
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
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.
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 salmon 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
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
Network Documentation salmon Summary
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.
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.
Items from the switch configuration table
The following are examples of the output of each command:
salmon#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
marlin Ser 0/0 172 R 3640 Ser 0/0
069017443(switch_a) Eth 0/0 141 T B S WS-C5500 2/13
10.254.254.0/24
Network
VLAN 45
Server Segment
E0/0 Salmon
S0/0 S0/0
FA0/1
FA1/1
FA0/0
7/2
Trunk
E0/0 - 10.254.254.1/24
S0/0 10.10.10.1/30
FA0/1 - 10.20.20.1/24
S0/0 10.10.10.2/30
Management Interface VLAN 2
10.40.40.2
FA0/0.2 - 10.440.40.1/30
FA0/0.45 - 10.45.45.1/24
FA0/0.46 - 10.46.46.1/24
FA1/1 - 10.20.20.2/24
Marlin
Tuna
Core_Switch
EIGRP 200
OSPF 21
Device Name,
Model Location FlashDRAMCATOS
Mgmt
IP
VTP
Domain VTP Mode Port Speed Duplex VLAN(s)
STP State
(Fwd/Block)
Portfast
(Yes/No)
Trunk
(Yes/No
core_switch,
6509
Dover,
DE 16 64 6.4(3) 10.40.40.2 dover_coreTransparent 1/1 1000 Full 1,2,45,46 Fwd No Yes
1/2 1000 Full 1,2,45,46 Block No Yes
3/1 100 Full 45 Fwd Yes No
3/2 10 Half 45 Fwd Yes No
3/3 A-100 A-Full 45 Fwd Yes No
salmon#show cdp neighbors detail
-------------------------
Device ID: marlin
Entry address(es):
IP address: 10.10.10.2
Platform: cisco 3640, Capabilities: Router
Interface: Serial0/0, Port ID (outgoing port): Serial0/0
Holdtime : 160 sec
Version :
Cisco Internetwork Operating System Software
IOS (tm) 3600 Software (C3640-JS56I-M), Version 12.1(2), RELEASE
SOFTWARE (fc2)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Thu 08-Dec-00 04:50 by phanguye
-------------------------
Device ID: 069017443(switch_a)
Entry address(es):
IP address: 10.254.254.102
Platform: WS-C5500, Capabilities: Trans-Bridge Source-Route-Bridge
Switch
Interface: Ethernet0/0, Port ID (outgoing port): 2/13
Holdtime : 130 sec
Version :
WS-C5500 Software, Version McpSW: 4.5(5) NmpSW: 4.5(5)
Copyright (c) 1995-1999 by Cisco Systems
Because these commands are available in both routers and switches, you can
effectively move across the network one device at a time, documenting each
neighbor along the way.
One final recommendation: Accuracy is the key to any successful documentation strategy. As
things change in the network, your documents must be updated to reflect these changes. It is
usually best to get in the habit of changing your documents as a normal part of changing the network,
not as an afterthought. (This applies to scheduled changes as well as after troubleshooting!)
In this manner, you are less likely to get involved in other tasks and forget to update the
documentation.
salmon#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
marlin Ser 0/0 172 R 3640 Ser 0/0
069017443(switch_a) Eth 0/0 141 T B S WS-C5500 2/13
10.254.254.0/24
Network
VLAN 45
Server Segment
E0/0 Salmon
S0/0 S0/0
FA0/1
FA1/1
FA0/0
7/2
Trunk
E0/0 - 10.254.254.1/24
S0/0 10.10.10.1/30
FA0/1 - 10.20.20.1/24
S0/0 10.10.10.2/30
Management Interface VLAN 2
10.40.40.2
FA0/0.2 - 10.440.40.1/30
FA0/0.45 - 10.45.45.1/24
FA0/0.46 - 10.46.46.1/24
FA1/1 - 10.20.20.2/24
Marlin
Tuna
Core_Switch
EIGRP 200
OSPF 21
Device Name,
Model Location FlashDRAMCATOS
Mgmt
IP
VTP
Domain VTP Mode Port Speed Duplex VLAN(s)
STP State
(Fwd/Block)
Portfast
(Yes/No)
Trunk
(Yes/No
core_switch,
6509
Dover,
DE 16 64 6.4(3) 10.40.40.2 dover_coreTransparent 1/1 1000 Full 1,2,45,46 Fwd No Yes
1/2 1000 Full 1,2,45,46 Block No Yes
3/1 100 Full 45 Fwd Yes No
3/2 10 Half 45 Fwd Yes No
3/3 A-100 A-Full 45 Fwd Yes No
salmon#show cdp neighbors detail
-------------------------
Device ID: marlin
Entry address(es):
IP address: 10.10.10.2
Platform: cisco 3640, Capabilities: Router
Interface: Serial0/0, Port ID (outgoing port): Serial0/0
Holdtime : 160 sec
Version :
Cisco Internetwork Operating System Software
IOS (tm) 3600 Software (C3640-JS56I-M), Version 12.1(2), RELEASE
SOFTWARE (fc2)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Thu 08-Dec-00 04:50 by phanguye
-------------------------
Device ID: 069017443(switch_a)
Entry address(es):
IP address: 10.254.254.102
Platform: WS-C5500, Capabilities: Trans-Bridge Source-Route-Bridge
Switch
Interface: Ethernet0/0, Port ID (outgoing port): 2/13
Holdtime : 130 sec
Version :
WS-C5500 Software, Version McpSW: 4.5(5) NmpSW: 4.5(5)
Copyright (c) 1995-1999 by Cisco Systems
Because these commands are available in both routers and switches, you can
effectively move across the network one device at a time, documenting each
neighbor along the way.
One final recommendation: Accuracy is the key to any successful documentation strategy. As
things change in the network, your documents must be updated to reflect these changes. It is
usually best to get in the habit of changing your documents as a normal part of changing the network,
not as an afterthought. (This applies to scheduled changes as well as after troubleshooting!)
In this manner, you are less likely to get involved in other tasks and forget to update the
documentation.
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.
Router Ethernet
connection
Switch Token Ring Token Ring
connection
Network that is not being
Network documented as part of this diagram
Serial/WAN
connection
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.
Router Ethernet
connection
Switch Token Ring Token Ring
connection
Network that is not being
Network documented as part of this diagram
Serial/WAN
connection
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.
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.
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.
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.
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.
Switch Network Configuration Table
Now that the router network configuration table is complete, let’s move on to the switch
version of this table. More information on switches and switch commands is provided in
Chapter 41, “Troubleshooting Switched Ethernet.” As stated in the preceding section, in this
example we are assuming that there are about 20 switches in the network for which we are creating
documentation. In addition, we are working with switches that have only layer 2 functionality.
Based on this arrangement, we have decided to include the following list of items in
our switch network configuration table:
Device Name
Model #
Location
Flash
DRAM
CatOS Version
Management Address
VTP Domain
VTP Mode
Port Number
Port Speed
Port Duplex
VLAN
Spanning Tree Protocol (STP) State
Portfast Status
Trunk Status
The beginning of the switch network configuration table is shown in Figure 34.2.
As was the case with the network configuration table for routers, just a few commands are
needed to populate the table produced for the switches. Specifically, these commands are
show version
show interface
show vtp domain, show port
show trunk
show spantree vlan
Note that the preceding are CatOS commands. The IOS equivalents of these
commands are show version, show interface, show vtp status, show
interface, show interfaces trunk, and show spanning-tree vlan, respectively.
More information about the differences between CatOS and IOS are
covered in Chapter 41.
The first of these commands, show version, operates similarly to the same command in the
router. It produces a number of the elements that are needed in order to populate the switch network
configuration table:
core_switch> (enable) show version
WS-C6509 Software, Version NmpSW: 6.4(3)
Copyright (c) 1995-2003 by Cisco Systems
NMP S/W compiled on Apr 10 2003, 17:33:25
System Bootstrap Version: 5.3(1)
Hardware Version: 2.0 Model: WS-C6509 Serial #: SCA123456F
PS1 Module: WS-CAC-1300W Serial #: SON01234564
PS2 Module: WS-CAC-1300W Serial #: SON01234569
Mod Port Model Serial # Versions
--- ---- ------------------- ----------- ----------------------------
1 2 WS-X6K-SUP1A-2GE SAD05430RPV Hw : 3.2
Fw : 5.3(1)
Fw1: 5.1(1)CSX
Sw : 6.4(3)
Sw1: 6.4(3)
WS-F6K-PFC SAD05430LYJ Hw : 1.1
3 48 WS-X6248-RJ-45 SAD04330N7Z Hw : 1.2
Fw : 5.1(1)CSX
Sw : 6.4(3)
7 24 WS-X6324-100FX-MM SAD0234523C Hw : 1.3
Fw : 5.4(2)
Sw : 6.4(3)
8 8 WS-X6408A-GBIC SAL43566W9J Hw : 2.0
Fw : 5.4(2)
Sw : 6.4(3)
DRAM FLASH NVRAM
Module Total Used Free Total Used Free Total Used Free
------ ------- ------- ------- ------- ------- ------- ----- ----- ----
1 65408K 48425K 16983K 16384K 9568K 6816K 512K 310K 202K
Uptime is 55 days, 11 hours, 28 minutes
level of the switch, as well as the flash and DRAM information.
The next command, show vtp domain, reports both the VTP domain and the VTP mode of
the switch. (VTP [VLAN Trunk Protocol] is covered in more detail in Chapter 41.)
core_switch> (enable) show vtp domain
Domain Name Domain Index VTP Version Local Mode Password
----------------------- ------------ ----------- ----------- ----------
dover_core 1 2 Transparent -
Vlan-count Max-vlan-storage Config Revision Notifications
---------- ---------------- --------------- -------------
13 1023 0 enabled
Last Updater V2 Mode Pruning PruneEligible on Vlans
--------------- -------- -------- -------------------------
10.40.40.2 disabled disabled 2-1000
Once you have obtained the VTP data, the next piece of information needed is the management
interface IP address. This address is included as part of the output from the show interface command.
Notice that on a switch, the command displays far less information than for routers and
focuses only on the management interfaces, not on the user ports.
core_switch> (enable) show interface
sl0: flags=51
slip 0.0.0.0 dest 0.0.0.0
sc0: flags=63
vlan 2 inet 10.40.40.2 netmask 255.255.255.252 broadcast 10.40.40.3
By using a separate VLAN for the management VLAN, we ensure that management
traffic to or from the switch will not be directly affected by user traffic, and
vice versa. For further protection, a separate uplink instead of a common trunk
can be used for the management VLAN, as is shown in this example.
The next command that is used to populate the switch network configuration table is the show
port command, which provides a substantial amount of fairly concise information about each port
on the switch. Be aware, however, that the output can get very lengthy if there are a large number
of ports on the switch. For the purpose of the switch network configuration table, the port numbers,
VLAN (for nontrunked ports), duplex, and speed information can be obtained from this output:
core_switch> (enable) show port
Port Name Status Vlan Duplex Speed Type
----- ----------------- ---------- --------- ------ ----- -----------
1/1 core_switch_2 connected trunk full 1000 1000BaseSX
1/2 core_switch_2 connected trunk full 1000 1000BaseSX
3/1 server1 connected 45 full 100 10/100BaseTX
3/2 mgmt_tool1 connected 45 half 10 10/100BaseTX
3/3 server3 connected 45 a-full a-100 10/100BaseTX
3/4 notconnect 45 auto auto 10/100BaseTX
3/5 notconnect 45 auto auto 10/100BaseTX
3/6 notconnect 45 auto auto 10/100BaseTX
...
...
The output removed from the foregoing show port command includes more
than just additional port numbers, names, status, VLAN, duplex, speed, and
type. It contains packet statistics, error rates, security parameters, and much
more. This information was not shown here because it does not directly relate
to the switch network configuration table.
Because the VLAN information is not included in the output of a show port command for
a trunked port, we need to get this data in another manner. There are a couple of ways to get
this information, but the usual method is via the show trunk command:
core_switch> show trunk
* - indicates vtp domain mismatch
Port Mode Encapsulation Status Native vlan
-------- ----------- ------------- ------------ -----------
1/1 nonegotiate dot1q trunking 45
1/2 nonegotiate dot1q trunking 45
Port Vlans allowed on trunk
-------- -------------------------------------------------------------
1/1 1-2,45-46
1/2 1-2,45-46
Port Vlans allowed and active in management domain
-------- -------------------------------------------------------------
1/1 1-2,45-46
1/2 1-2,45-46
Port Vlans in spanning tree forwarding state and not pruned
-------- -------------------------------------------------------------
1/1 1-2,45-46
1/2 1-2,45-46
The VLANs that traverse the trunk are shown in the Vlans allowed on trunk section
of this output. If a VLAN is not listed in this section, then it will not be permitted on
the trunk.
The final command necessary to complete the information in the switch network configuration
table is the show spantree vlan command. In our case, we need information regarding
VLAN 45, the VLAN in which our servers reside.
core_switch> show spantree 45
VLAN 45
Spanning tree mode PVST+
Spanning tree type ieee
Spanning tree enabled
Designated Root 00-d0-f6-bc-aa-aa
Designated Root Priority 49152
Designated Root Cost 3004
Designated Root Port 1/1
Root Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec
Bridge ID MAC ADDR 00-d0-f6-bc-7e-00
Bridge ID Priority 49152
Bridge Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec
Port Vlan Port-State Cost Prio Portfast Channel_id
---------------- ---- ------------- --------- ---- -------- ----------
1/1 45 forwarding 4 32 disabled 0
1/2 45 blocking 4 32 disabled 0
3/1 45 forwarding 19 32 enabled 0
3/2 45 forwarding 100 32 enabled 0
3/3 45 forwarding 19 32 enabled 0
3/4 45 not-connected 19 32 disabled 0
3/5 45 not-connected 19 32 disabled 0
3/6 45 not-connected 19 32 disabled 0
...
...
Notice that this command provides the necessary information to complete the STP State and
the Portfast configuration columns of the table.
When both the router and switch network configuration tables are complete, we can move
on to creating the network topology diagrams.
version of this table. More information on switches and switch commands is provided in
Chapter 41, “Troubleshooting Switched Ethernet.” As stated in the preceding section, in this
example we are assuming that there are about 20 switches in the network for which we are creating
documentation. In addition, we are working with switches that have only layer 2 functionality.
Based on this arrangement, we have decided to include the following list of items in
our switch network configuration table:
Device Name
Model #
Location
Flash
DRAM
CatOS Version
Management Address
VTP Domain
VTP Mode
Port Number
Port Speed
Port Duplex
VLAN
Spanning Tree Protocol (STP) State
Portfast Status
Trunk Status
The beginning of the switch network configuration table is shown in Figure 34.2.
As was the case with the network configuration table for routers, just a few commands are
needed to populate the table produced for the switches. Specifically, these commands are
show version
show interface
show vtp domain, show port
show trunk
show spantree vlan
Note that the preceding are CatOS commands. The IOS equivalents of these
commands are show version, show interface, show vtp status, show
interface, show interfaces trunk, and show spanning-tree vlan, respectively.
More information about the differences between CatOS and IOS are
covered in Chapter 41.
The first of these commands, show version, operates similarly to the same command in the
router. It produces a number of the elements that are needed in order to populate the switch network
configuration table:
core_switch> (enable) show version
WS-C6509 Software, Version NmpSW: 6.4(3)
Copyright (c) 1995-2003 by Cisco Systems
NMP S/W compiled on Apr 10 2003, 17:33:25
System Bootstrap Version: 5.3(1)
Hardware Version: 2.0 Model: WS-C6509 Serial #: SCA123456F
PS1 Module: WS-CAC-1300W Serial #: SON01234564
PS2 Module: WS-CAC-1300W Serial #: SON01234569
Mod Port Model Serial # Versions
--- ---- ------------------- ----------- ----------------------------
1 2 WS-X6K-SUP1A-2GE SAD05430RPV Hw : 3.2
Fw : 5.3(1)
Fw1: 5.1(1)CSX
Sw : 6.4(3)
Sw1: 6.4(3)
WS-F6K-PFC SAD05430LYJ Hw : 1.1
3 48 WS-X6248-RJ-45 SAD04330N7Z Hw : 1.2
Fw : 5.1(1)CSX
Sw : 6.4(3)
7 24 WS-X6324-100FX-MM SAD0234523C Hw : 1.3
Fw : 5.4(2)
Sw : 6.4(3)
8 8 WS-X6408A-GBIC SAL43566W9J Hw : 2.0
Fw : 5.4(2)
Sw : 6.4(3)
DRAM FLASH NVRAM
Module Total Used Free Total Used Free Total Used Free
------ ------- ------- ------- ------- ------- ------- ----- ----- ----
1 65408K 48425K 16983K 16384K 9568K 6816K 512K 310K 202K
Uptime is 55 days, 11 hours, 28 minutes
level of the switch, as well as the flash and DRAM information.
The next command, show vtp domain, reports both the VTP domain and the VTP mode of
the switch. (VTP [VLAN Trunk Protocol] is covered in more detail in Chapter 41.)
core_switch> (enable) show vtp domain
Domain Name Domain Index VTP Version Local Mode Password
----------------------- ------------ ----------- ----------- ----------
dover_core 1 2 Transparent -
Vlan-count Max-vlan-storage Config Revision Notifications
---------- ---------------- --------------- -------------
13 1023 0 enabled
Last Updater V2 Mode Pruning PruneEligible on Vlans
--------------- -------- -------- -------------------------
10.40.40.2 disabled disabled 2-1000
Once you have obtained the VTP data, the next piece of information needed is the management
interface IP address. This address is included as part of the output from the show interface command.
Notice that on a switch, the command displays far less information than for routers and
focuses only on the management interfaces, not on the user ports.
core_switch> (enable) show interface
sl0: flags=51
slip 0.0.0.0 dest 0.0.0.0
sc0: flags=63
vlan 2 inet 10.40.40.2 netmask 255.255.255.252 broadcast 10.40.40.3
By using a separate VLAN for the management VLAN, we ensure that management
traffic to or from the switch will not be directly affected by user traffic, and
vice versa. For further protection, a separate uplink instead of a common trunk
can be used for the management VLAN, as is shown in this example.
The next command that is used to populate the switch network configuration table is the show
port command, which provides a substantial amount of fairly concise information about each port
on the switch. Be aware, however, that the output can get very lengthy if there are a large number
of ports on the switch. For the purpose of the switch network configuration table, the port numbers,
VLAN (for nontrunked ports), duplex, and speed information can be obtained from this output:
core_switch> (enable) show port
Port Name Status Vlan Duplex Speed Type
----- ----------------- ---------- --------- ------ ----- -----------
1/1 core_switch_2 connected trunk full 1000 1000BaseSX
1/2 core_switch_2 connected trunk full 1000 1000BaseSX
3/1 server1 connected 45 full 100 10/100BaseTX
3/2 mgmt_tool1 connected 45 half 10 10/100BaseTX
3/3 server3 connected 45 a-full a-100 10/100BaseTX
3/4 notconnect 45 auto auto 10/100BaseTX
3/5 notconnect 45 auto auto 10/100BaseTX
3/6 notconnect 45 auto auto 10/100BaseTX
...
...
The output removed from the foregoing show port command includes more
than just additional port numbers, names, status, VLAN, duplex, speed, and
type. It contains packet statistics, error rates, security parameters, and much
more. This information was not shown here because it does not directly relate
to the switch network configuration table.
Because the VLAN information is not included in the output of a show port command for
a trunked port, we need to get this data in another manner. There are a couple of ways to get
this information, but the usual method is via the show trunk command:
core_switch> show trunk
* - indicates vtp domain mismatch
Port Mode Encapsulation Status Native vlan
-------- ----------- ------------- ------------ -----------
1/1 nonegotiate dot1q trunking 45
1/2 nonegotiate dot1q trunking 45
Port Vlans allowed on trunk
-------- -------------------------------------------------------------
1/1 1-2,45-46
1/2 1-2,45-46
Port Vlans allowed and active in management domain
-------- -------------------------------------------------------------
1/1 1-2,45-46
1/2 1-2,45-46
Port Vlans in spanning tree forwarding state and not pruned
-------- -------------------------------------------------------------
1/1 1-2,45-46
1/2 1-2,45-46
The VLANs that traverse the trunk are shown in the Vlans allowed on trunk section
of this output. If a VLAN is not listed in this section, then it will not be permitted on
the trunk.
The final command necessary to complete the information in the switch network configuration
table is the show spantree vlan command. In our case, we need information regarding
VLAN 45, the VLAN in which our servers reside.
core_switch> show spantree 45
VLAN 45
Spanning tree mode PVST+
Spanning tree type ieee
Spanning tree enabled
Designated Root 00-d0-f6-bc-aa-aa
Designated Root Priority 49152
Designated Root Cost 3004
Designated Root Port 1/1
Root Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec
Bridge ID MAC ADDR 00-d0-f6-bc-7e-00
Bridge ID Priority 49152
Bridge Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec
Port Vlan Port-State Cost Prio Portfast Channel_id
---------------- ---- ------------- --------- ---- -------- ----------
1/1 45 forwarding 4 32 disabled 0
1/2 45 blocking 4 32 disabled 0
3/1 45 forwarding 19 32 enabled 0
3/2 45 forwarding 100 32 enabled 0
3/3 45 forwarding 19 32 enabled 0
3/4 45 not-connected 19 32 disabled 0
3/5 45 not-connected 19 32 disabled 0
3/6 45 not-connected 19 32 disabled 0
...
...
Notice that this command provides the necessary information to complete the STP State and
the Portfast configuration columns of the table.
When both the router and switch network configuration tables are complete, we can move
on to creating the network topology diagrams.
Subscribe to:
Posts (Atom)