Practical TCP/IP and Ethernet Networking- P55 docx

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. . 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. 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. 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