6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM
4+:9:':
The command is usually typed in lower case letters only (netstat). This reports the status
of the network interfaces and ports.
4+:9:':O
The command typed is netstat -i, a space is inserted before the hyphen and the following
letter (all letters in lower case only). These statistics relate to running totals from when
the system was last started. The total number of packets should be balanced between all
network interfaces on the network. The output and input errors for each of the interfaces
should be carefully examined. Output errors generally indicate hardware failures of the
local system. If the output errors increase to about a quarter of the total packet output, it is
time to replace the hardware.
Input errors are more difficult to analyze. These could result from any host on the
network – this being caused by faulty network hardware (network interface
card/cabling/noise) or the network device driver or an overloaded host.
The collision statistic indicates the number of collisions and should be looked at as a
percentage of the total number of packets transmitted and not as an absolute number.
The queue statistic indicates when the network is so busy and thus congested that the
Network interface has packets queued and waiting to be sent. It should be zero.
4+:9:':
The most important statistic here is the Send-Q, which should be zero. A non-zero value
indicates severe congestion.
4+:9:':TX
The command is usually typed in lower case, with a space before the hyphen and
following letters (netstat -nr). This gives information about the default gateway. This can
be useful for troubleshooting why packets don’t get to their destination.
6OTM
This provides an indication of connectivity between hosts on a network (or a series of
interconnected networks) and provides some measure of the time taken to traverse the
internetworks (the round-trip delay).
In pinging a host, if it times out, this could mean that either there is no connectivity
with the remote host or the subnet mask has been incorrectly set up. If it is possible to
ping a remote host but not to Telnet to a remote host, the intermediate routing tables
should be examined using ripquery or netstat -r. It may be that the time-to-live field in the
IP packet for the Ping protocol is set to considerably longer than for the Telnet packets.
:8')+85;:+
This indicates the route followed by a typical message sent over the interconnected
networks. Sending out packets with ever increasing UDP packets, which have
successively greater Time-to-live values, does it. The traceroute command will trace the
entire route up to a breakage point in the link.
'86
This provides the mapping between the MAC and IP addresses.
Entries within the ARP table are temporary. The length of time for each entry depends
on the arp program implementation. This can cause problems if duplicate IP addresses are
on the network. Each of the separate hosts will send out ARP request and response
:XU[HRKYNUUZOTM:)6/6
packets detailing different physical addresses for the same IP address. In this case it
would be worthwhile manually editing the specific ARP table entries.
8OVW[KX_
This allows the administrator to investigate the contents of a host’s routing table.
 +^GSVRKUL[YKULGLK]ULZNK[ZOROZOKYZUMKZNKX
If the error messages such as ‘network unreachable’, ‘host not responding’, or ‘network
host unreachable’ are received, the following procedure could be used to troubleshoot the
system.
First of all use the ‘ping’ utility to confirm a connection failure.
Analyze routing table contents by running ‘netstat –nr’
If no route is found, then manually enter the desired route to follow using the route
add command.
Alternatively if a route exists, use ‘traceroute’ to find out the precise point of failure.
Interestingly enough, it is a worthwhile exercise to ping both the IP address and the
domain name of the host. There is possibly a mismatch between the two addresses. This
may only be temporary but it is enough to cause a problem in establishing a connection.
 ;TXKROGHRKIUTTKIZOUTY
Intermittent problems are often more difficult to troubleshoot. Hardware problems such
as faulty cables or networking devices can be detected with cable testers. However by the
astute use of the TCP/IP utilities it is possible to identify whether the problem is hardware
or software related (i.e. it may be the operation of the networking protocols that are the
cause of the problem).
Typical steps to follow here would be:
• Use ping to check the connectivity of the remote host
• Use traceroute to check the route followed if ping indicates that there is
no connectivity
If ping indicates that there is connectivity, it is possible that the remote host has
performance problems. In this case use the ‘netstat -i’ utility to check the remote host. If
there are values recorded within the Queue field, it could mean that packets are being
delayed before being transmitted on this interface. The 0errs field should also be zero. If
non-zero there could be a physical problem on the interface. Similarly the 1errs field
should be zero. If this is not the case, potential problems could be the physical hardware
or the interface card device driver or the host is overloaded.
• Use ping -t (or the spray command) to keep up with a sustained data transfer
if you suspect the host is overloaded.
Finally check for overload on one of the network segments by examining the collision
field within the netstat command. If the number of collisions exceeds 5% of the total
number of messages it may be that one of the segments is overloaded.
 4KZ]UXQIUTMKYZOUT
If the network users report that the connections to a remote host seem slightly on the slow
side, the following procedure should be used:
• Use the ping command to check the connectivity
6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM
• Hereafter use the ‘traceroute’ utility to check the time for each section of the
route and compare this against the baseline statistics that have been recorded
• If a significant increase in response time between two gateways; remedial
action is indicated for this section
18
Satellites and TCP/IP
18.1 Introduction
There is a fairly vigorous debate at present over the merits of using TCP/IP over a
satellite-based communications channel. One of the greatest challenges with satellite-
based networks is the high-latency or delays in transmission and the appropriate solution
in dealing with this problem.
This chapter is broken up into the following sections:
• Introduction
• Overview of satellite communications
• Advantages of satellite communications
• Applications of satellite systems
• Review of TCP/IP
• Weaknesses of TCP/IP in satellite usage
• Methods of optimizing TCP/IP over satellites
18.2 Overview of satellite communications
Satellite communications has been around for a considerable time with the VSAT (very
small aperture terminal) system being very popular for general use. This system could
deliver up to 24 Mbps in a point-to-multi-point link. The alternative of a point-to-point
link would deliver up to 1.5 Mbps. Customers have traditionally bought very specific
time on a specific satellite. This is where the use of satellite communications
distinguishes itself – for predictable communications. Typical applications here have been
periodic uplinks by news providers. The more unpredictable Internet usage with surges in
demand that often requires a quick response is not very suited to the use of satellites.
NASA pioneered a satellite more focussed to personal usage such as for the Internet with
the launch of its advanced communications technology satellite (ACTS). This is
capable of delivering 100 Mbps of bandwidth using a Ka-band (20–30 GHz) spot-beam
geo synchronous earth orbit (GEO) satellite system.
256 Practical TCP/IP and Ethernet Networking
When a satellite is used in a telecommunications link there is a delay (referred to as
latency) due to the path length from the sending station to the satellite and back to the
receiving station at some other location on the surface of the earth. For a satellite in
geostationary earth orbit (or GEO) the satellite is about 36 000 km above the equator
and the propagation time for the radio signal to go to the satellite and return to earth is
about 240 milliseconds. When the ground station is at the edge of the satellite footprint
this one-way delay can increase to as much as 280 milliseconds. Additional delays may
be incurred in the on-board processing in the satellite and any terrestrial- or satellite-to-
satellite linking. The comparable delay for a 10 000 km fiber optic cable would be about
60 milliseconds.
Low earth orbit (LEO) satellites are typically located about 500–700 km above the
surface of the earth. At this height the satellites are moving rapidly relative to the ground
station and to provide continuous coverage a large number of satellites are used, together
with inter-satellite linking. The IRIDIUM system uses 66 satellites and GLOBALSTAR
uses 48 satellites. The propagation delay from the ground station to the satellite varies due
to the satellite position, from about 2 milliseconds when the satellite is directly overhead
to about 80 milliseconds when the satellite is near the horizon. Mobile LEO users
normally operate with quasi-omnidirectional antennas while large feeder fixed earth
stations need steerable antenna with good tracking capability. Large users need seamless
hand-off to acquire the next satellite before the previous one disappears over the horizon.
The main application where these satellite systems can be useful for is in providing
high-bandwidth access to places where the landline system doesn’t provide this type of
infrastructure. But the greatest challenge with satellite systems is the time it takes for your
data to get from the one point to the other. A possible solution to reduce this latency is the
use of low earth orbit (LEO) satellites. However, the problems with LEOs are the need to
provide a large number to get the relevant coverage of the earth’s surface. In partnership
with Boeing, Teledisc is targeting the provision of 288 LEO satellites. A further practical
problem with LEO satellites is they only last 10 to 12 years before they burn up in falling
to earth through the atmosphere. GEOs don’t have this particular problem as they are
merely ‘parked’ a lot higher up and left. A further challenge with Leo’s is tracking these
swiftly moving satellites, as they are only visible for up to 30 minutes before passing over
the horizon. A phased-array antenna comprising a multitude of smaller antennas solves
this antenna problem by tracking several different satellites simultaneously with different
signals from each satellite. At least two satellites are kept in view at all times and the
antenna initiates a link to a new one before it breaks the existing connection to the
satellite moving to the bottom of the horizon.
The probable focus on using GEO and LEO satellites will probably be as follows:
• GEO satellites – Data downloading and broadcasting (higher latency)
• LEO satellites – High-speed networking/teleconferencing (lower latency)
Two other interesting issues for satellites that have not been quite resolved yet are the
questions of security and the cost of the service. Theoretically, anyone with a scanner can
tune in to the satellite broadcasts; although encryption is being used for critical
applications. Also vendors claim that the costs of using satellites will be similar to that of
existing landline systems. This is difficult to believe as the investment costs, (e.g.
Iridium), in these systems have been extremely high.
A representation of the different satellite systems in use is indicated in the figure on the
next page.