used to build a report. Such reports can then be
used to spot patterns and trends in network traffic, including
current and potential problems. Configuration of Syslog for
centralized logging is discussed in detail in Module 7.
Setting the real time clock
To make the logged
information more useful, network engineers should set the
real-time clock of the router and enable date and time stamps
for log messages. If messages are logged without the real time
clock of the device being set, the date and time stamp uses the
uptime of the router. The router real time clock can be
manually set or can use a Network Time Protocol source for its
information. Using an NTP time source is recommended for a
number of reasons: - The real time clock of the router
is reset when the router is rebooted.
- NTP time
sources are much more accurate.
- Having the real-time
clock of all devices synchronized can help trace traffic
patterns and trends through the network.
Unlike
much of the router configuration, setting the real time clock
is not done from global configuration mode. To manually set the
router real time clock from privileged mode, use the clock
set [hh:mm:ss] [Day of the month] [Month] [Year] command.
Note that the order of Day of the month and
Month does not matter. For example, the following two
commands have the same effect: Router#clock set 15:42:00 12
March 2005
Router#clock set 15:42:00 March 12
2005 Using Network Time Protocol
Network Time
Protocol servers are available for time queries on the Internet
and are arranged in a hierarchy of importance. A list of NTP
servers publicly available from the Internet is available from
http://www.eecis.udel.edu/~mills/ntp/servers.html.
Alternatively, Network Engineers can build their own internal
NTP servers or can purchase and use NT network appliances
(often synchronized to geo-synchronous satellites) to provide a
reliable and accurate time source for network host devices. To
configure the router to query an NTP time source, use these
commands from global configuration mode: Router(config)#ntp
peer [NTP server IP address]
Router(config)#ntp peer
authenticate Note that NTP sends traffic to and from UDP
port 123. This needs to be allowed when configuring the
firewall router access list. The network administrator should
also set the time zone local to the router so that the router
knows how far to adjust the UTC time signal received from the
NTP time source. Use these commands to configure the local time
zone of the router: Router(config)#clock timezone
[timezone-name] [hours-offset] [minutes-offset] This
command can also be used to uniquely identify log messages from
the router by specifying a unique time zone name. Note that the
timezone-name parameter is limited to eight characters. Figure
shows how to configure a router with NTP and a local time zone.
Enabling date and time stamps on logged messages
To
enable date and time stamps for logged messages, use the
following command from global configuration mode:
Router(config)#service timestamps debug datetime [localtime]
[msec] [show-timezone] The keywords localtime,
msec, and show-timezone can all be used to add extra
information to the logged messages. It is recommended that the
msec keyword is included, especially on busy routers.
Figure shows messages with the date and time stamp information.
Content 6.3 Troubleshooting
Transport Layer Issues on Network Hosts 6.3.1
Common transport layer issues with IP networks TCP window
size can dramatically impact the performance of the network. If
the TCP window size is too small, the result will be additional
network overhead from segment acknowledgments. A lot of time is
also wasted when the sending host waits for acknowledgments.
Increasing the window size allows the sending host to transmit
more than one packet at a time, increase network bandwidth
utilization and decrease the time spent waiting for
acknowledgements. Having a TCP window too large can also cause
problems, especially on a congested network. If the network is
dropping a lot of TCP packets and acknowledgements, the sending
host wastes a lot of time waiting for retransmit timers to
expire. The sending host also adds to the congestion problem by
sending large amounts of retransmission traffic. Making the
window smaller forces the sending host to send less data at
once, reduces its impact on the congestion, and improves the
chances of TCP packets and acknowledgements getting through the
network successfully. When operating correctly, TCP self-tunes
its behavior according to network conditions. Recall from
previous content that TCP window sizes are self-tuning. This
self-tuning mechanism can be seen in action when downloading a
large file from the Internet. When the download starts, the
rate of transfer is quite slow, as the initial window size is
relatively small. As the download proceeds, the rate of
download increases rapidly as the window size expands. As the
TCP window approaches its optimal size, the increase in the
download rate slows until the rate is almost constant. For the
remainder of the download, the window size self-tunes to suit
prevailing network conditions.
Content
6.3 Troubleshooting Transport Layer
Issues on Network Hosts 6.3.2 Gathering
transport layer information on Windows machines
Telnet
Although Telnet normally refers to an
application layer protocol and program, it can be a useful tool
for troubleshooting problems at other layers, particularly the
transport layer. The usefulness of Telnet in troubleshooting
comes from its ability to connect to a specific destination
port on a remote server, allowing it to be used to confirm
correct traffic flow from a client to remote server. Although
never intended as a troubleshooting tool, Telnet is
particularly useful for transport layer diagnostics. Telnet can
be run as either a command line utility or with a graphical
user interface (GUI). Figure shows the command line Telnet
application being used to confirm connectivity to a POP3
server. ipconfig command
The ipconfig /all
command can provide the network engineer with a lot of
information about the configuration of a Windows-based machine.
This information covers details from the MAC address at Layer
2, the IP address at Layer 3, NetBIOS information at Layers 4
and 5, to DNS information at Layers 6 and 7.
Content
6.3 Troubleshooting Transport Layer
Issues on Network Hosts 6.3.3 Gathering
transport layer information on UNIX machines There are many
variants of the UNIX operating system. The most common are
SunOS, FreeBSD, SCO, and Linux. All of these operating systems
have tools that can be used to troubleshoot network issues.
These tools have been covered in greater detail elsewhere in
this curriculum and are mentioned here in the context of
troubleshooting options for transport layer issues on UNIX
hosts. Note that while these tools often have the same name and
purpose, the command line options required to use them vary
greatly from platform to platform. Consult the online manual of
the local operating software, using the command man
[tool_name], to get more information about the
command line options of the tool to use. It is important to
note that almost all newer versions of UNIX variants support
native packet-filtering firewall features. When troubleshooting
transport layer problems with UNIX hosts, network engineers
should be aware of the possibility that the problem could be
caused by the local machine firewall configuration. There are
three common commands used to configure UNIX firewall features:
- On older UNIX variants using kernel version 2.0, use
the ipfwadm command
- On UNIX variants using
kernel version 2.2, use the ipchains command
- On newer UNIX variants using kernel version 2.4 or later,
use the iptables command
Each new version