IRIX Advanced Site and Server Administration Guide
This chapter provides information on how to manage a network after installation. Management includes maintenance, monitoring, and problem isolation. This chapter provides brief descriptions of the various network management tools, help in interpreting network statistics, a discussion on the factors that can impact network performance, and some of the network kernel configuration options. The following topics are covered:
The available tools for network management. See "Network
How to interpret network statistics. See "Interpreting
The various factors that affect network performance. See "Factors
Affecting Network Performance".
Setting up network servers. See "Network
Information on network packet sizes. See "Packet
Information on kernel settings that affect networking. See "Kernel Configuration".
This section describes a number of standard and some optional networking tools at your disposal for managing the day to day operation of your network. Except as noted, the standard networking tools reside in the /usr/etc directory. See the online reference pages for additional information.
These network management tools are available as options for use on any Silicon Graphics 4D-IRIS station:
The network management tools provide the network administrator with valuable information about the network. However, the presentation of these statistics can be overwhelming. This section illustrates how to use three of the most common management tools and how to interpret the network statistics generated by these tools.
The ping tool tests and measures general network performance. It tells you when there is a problem with your network. The most important piece of information provided by ping is the percentage packet loss. Ideally, you want to see 0% packet loss; however, anything under .01% is acceptable. This low packet loss threshold is required because many network applications transmit large packets. If 0.1% of a packet is lost, the entire packet must be retransmitted. This can cause a network to be saturated by retransmissions.
The following example uses ping in its simplest form, but the information obtained is very useful. The ping tool is testing and measuring traffic between the local station and the station testcase. See the reference page for more details about the many ping options.
/usr/etc/ping testcase PING testcase (184.108.40.206): 56 data bytes 64 bytes from 220.127.116.11: icmp_seq=0 ttl=255 time=0 ms 64 bytes from 18.104.22.168: icmp_seq=1 ttl=255 time=0 ms 64 bytes from 22.214.171.124: icmp_seq=2 ttl=255 time=0 ms 64 bytes from 126.96.36.199: icmp_seq=3 ttl=255 time=0 ms 64 bytes from 188.8.131.52: icmp_seq=4 ttl=255 time=0 ms ----testcase PING Statistics---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/0
The percentage packet loss is highlighted in bold. Again, 0% packet loss is the goal. Anything over 0.1% should be investigated further.
The ttcp tool provides a realistic measurement of network performance between two stations as it allows measurements to be taken at both the local and remote end of the transmission. This tool measures the network throughput. As with all network management tools, the statistics must be interpreted with the network configuration and applications in mind. For example, the statistics generated from a ttcp probe between two stations with routers in between results in lower throughput than if the stations were located on the same network. On the same note, users running applications that transmit large data structures see slower throughput than users running applications that transmit smaller data structures.
In any case, on a relatively quiet network, you should expect to see throughput in the 700 KB/sec or greater range. Throughput of 500 KB/sec or less is questionable, and 400 KB/sec or less may indicate a definite network problem.
The following example illustrates the statistics you might see if you ran a simple ttcp test between the stations sheridan and longstreet (two workstations) on a clean network. See the ttcp reference page for details about the many ttcp options.
On sheridan, give the command:
ttcp -r -s
You see the following output:
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ttcp-r: socket ttcp-r: accept from 184.108.40.206 ttcp-r: 16777216 bytes in 19.99 real seconds = 819.64 KB/sec +++ ttcp-r: 10288 I/O calls, msec/call = 1.99, calls/sec = 514.67 ttcp-r: 0.1user 3.4sys 0:19real 17%
On longstreet, give the following command:
ttcp -t -s sheridan
You see the following output:
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp -> sheridan ttcp-t: socket ttcp-t: connect ttcp-t: 16777216 bytes in 19.98 real seconds = 820.02 KB/sec +++ ttcp-t: 2048 I/O calls, msec/call = 9.99, calls/sec = 102.50 ttcp-t: 0.0user 2.3sys 0:19real 12%
The throughput statistics are highlighted in bold and are represented by KB/sec. The throughput on the station sheridan is 819.64 KB/sec and the throughput on the station longstreet is 820.02 KB/sec. Both throughput values indicate good network performance between the stations.
The netstat tool displays various network-related data structures that are useful for monitoring and troubleshooting a network. Detailed statistics about network collisions can be captured with the netstat tool. Collision rates anywhere between 5% and 20% indicate a problem with the network. The problem could be physical (bad tap, transceiver, loose terminator, and so on.) or there might be too much traffic on the network.
This example illustrates the statistics you might see on a station using netstat. See the reference page for details about the many netstat options:
netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll enp0 1500 b1-channels thumper 498690 937 1066135 3 4858 lo0 32880 loopback localhost 1678915 0 1678915 0 0
The collision rate is approximately 0.45%, well within the acceptable range.
A variety of factors can impact network performance, including hardware problems, network configuration, network applications, and packet size.
Hardware problems can cause a network to be slow or inoperable. These problems are usually in the form of packet loss or corruption. Both of these problems can cause increased network traffic to the point of unmanageable congestion. Items to check at the physical level are:
The network configuration or topology can also adversely effect network performance. Check for the following conditions:
Check network configuration to ensure that it is within the official
guidelines for the media and topology. Pay special attention to the number
and location of repeaters and bridges.
Consider work group affiliations when determining which network is best
suited for a particular station. Planning a network based on work group
affiliations can reduce the amount of intranetwork traffic. Put stations
that routinely share resources on the same net (NFS mounting, same NIS
domain, electronic mail, financial databases).
If connecting large subnets, use a dedicated router (station that performs routing function only) as the primary router. Ensure that there are at least two ways in and out of a network, because one of the routers will eventually fail. The router should also use appropriate filters to filter out unnecessary traffic.
Some network servers (rwhod, rtnetd, etc.) can have an undesirable affect on the network or network interface. For example, if a workstation is a multi-processor or is running real-time processes, the rtnetd daemon may be running on the station. This daemon is responsible for preempting incoming network packets to provide better response time for real-time processes. This is perfectly acceptable if the user is aware of the trade-offs between network processing and real-time processing. Some network servers should be evaluated individually.
Do not load rtnetd software on routers or other network intensive stations (mail servers, NIS and DNS servers, etc.).
The Maximum Transfer Unit (MTU) for data on the Ethernet is 1500 bytes. Network performance and efficiency increase with packet size up to the MTU for the medium. Packets that are larger than the media's MTU must be broken into smaller packets (fragmented) to fit within the medium's MTU. Applications and services must be configured to transmit MTU size packets.
You can change several parameters to customize network behavior for local configurations. The parameters listed Table 18-1 are in the /var/sysgen/master.d/bsd configuration file. For details on reconfiguring the kernel after changing this file, see Chapter 5, "Tuning System Performance." Some of these listed options are also discussed in Appendix A, "IRIX Kernel Tunable Parameters."
|These parameters determine the default amount of buffer space used by TCP (SOCK_STREAM) and UDP (SOCK_DGRAM) sockets. The tcp_sendspace and tcp_recvspace parameters define the initial buffer space allocated to a socket. The udp_sendspace parameter defines the default maximum size of UDP datagrams that can be sent. The udp_recvgrams parameter determines the number of maximally sized UDP datagrams that can be buffered in a UDP socket. The total receive buffer size in bytes for each UDP socket is the product of udp_sendspace and udp_recvgrams. A program can increase or decrease the send buffer and receive buffer sizes for a socket with the SO_SNDBUF and SO_RCVBUF options to the setsockopt(2) system call. Many older TCP implementations have problems with large TCP sendspace/recvspace values. This should be decreased from 60 to 24 in environments where older stations have problems communicating.|
For 4.2BSD compatibility, the IRIX system limits its initial TCP sequence numbers to positive numbers.
Many industry-standard personal computers with TCP/IP implementations experience difficulty connecting to Silicon Graphics workstations and servers. This is because of the increased size of the tcp_sendspace and tcp_recvspace variables in the IRIX file /var/sysgen/master.d/bsd.
To allow your personal computers to connect successfully, change the values of the above variables from the default (60 * 1024) to (24 * 1024) and reconfigure the kernel with the lboot(1M) command. For more information on reconfiguring these values, see Chapter 5, "Tuning System Performance."
Copyright © 1997, Silicon Graphics, Inc. All Rights Reserved. Trademark Information