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: 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: Each new version