Chapter 4. Introducing Network Management
Prev |  | Next

## Chapter 4. Introducing Network Management

This chapter provides brief overview information on managing a network after installation. Indications for further reading are followed by a summary of the network initiation and shutdown process. Introductions to a few basic network management tools are followed by pointers to help in interpreting network statistics. These specific topics are covered:

- “Resources for Network Management”

- “About Network Startup and Shutdown”.

- “Network Management Tools”.

- “Interpreting Network Statistics”.

- “Troubleshooting Poor Network Performance”.

## Resources for Network Management

Network management is sufficiently complex an issue that a wide understanding of controls and “tuning knobs” is needed, far beyond any capacity to cover here. Suggested sources of background information include these books:

- DNS and BIND, by Paul Abitz and Cricket Liu, 2nd edition, O'Reilly and Associates.

- Internetworking with TCP/IP Volume 1, by Douglas E. Comer, 3rd edition, Prentice Hall, 1994.

- LAN Management with SNMP and RMON, by Gilbert Held, John Wiley and Sons, 1996.

- Managing Internetworks with SNMP, by Mark Miller, M & T Books, 1993.

- Managing NFS and NIS, by Hal Stern, 1st edition, O'Reilly and Associates, 1991.

- Network Management - A Practical Perspective, by Allan Leinwand and Karen Fang Conroy, 2nd edition, Addison Wesley, 1996.

- Routing in the Internet, by Christian Huitema, Prentice Hall, 1995.

- System Performance Tuning, by Mike Loukides, 1st edition, O'Reilly and Associates, 1990.

- TCP/IP Network Administration, by Craig Hunt, 1st edition, O'Reilly and Associates, 1992.

- TCP/IP Illustrated, Volume 1, by W. Richard Stevens, Addison Wesley, 1994.

Background reading should also include white papers and current periodicals on the subject because the field changes almost daily.

## About Network Management Functions

Network management ranges from maintenance, monitoring, and controlling network events to problem isolation. Basic necessary components in network management tools and strategies are:

- Fault management—Replacing or repairing managed devices when they fail, keeping network error logs, and swapping failed components. A few methods of detecting failure are introduced in “Troubleshooting Poor Network Performance”.

- Accounting management—Identifying users of network resources and assigning departmental charges. This aspect of network management is covered in IRIX Admin: Backup, Security, and Accounting.

- Configuration and name management—Planning, initializing and updating network software and hardware. Previous chapters have dealt with some of these issues.

- Performance management—Ensuring network components perform to expectations, that the network uses available bandwidth appropriately, perhaps rewriting protocols and developing administration tools. Many aspects of these issues are covered in the pertinent application manuals. For example: Performance Co-Pilot for ORACLE Administrator's Guide, Developer Magic: Performance Analyzer User's Guide, and IRIS HIPPI API Programmer's Guide.

- Security management—Protecting managed objects from intrusion or misapplication. For security-related issues see IRIX Admin: Backup, Security, and Accounting.

Because many networks are hybrid in design and contain multiple protocols and a wide variety of devices, network management is the only cohesive ingredient in maintaining functionality and preventing chaos. The following sections on network startup and shutdown give a simple summary of how the network operates:

- “Network Initialization Process”

- “Network Shutdown Process”

## About Network Startup and Shutdown

The main network script is `/etc/init.d/network`. Other scripts for other network applications (UUCP, mail, and so on) also reside in this directory, but are covered in their appropriate chapter in this guide. The `network` script is described briefly here.

The `network` master script is called during system startup and shutdown. It defines the system name and host ID, ensures that the system has a valid Internet address, starts networking daemons, and initializes the network interfaces. Previously, site-dependent configuration commands to start and stop local daemons, add static routes, and publish ARP entries were put in a separate shell script called `/etc/init.d/network.local`. Symbolic links were made from `/etc/rc0.d` and `/etc/rc2.d` to `/etc/init.d/network.local` so the `network.local` file could be called at system startup and shutdown (see “Creating a Local Network Script” in Chapter 3, for setup procedure). Currently this function is performed by `/etc/config/static-route.options`.

The `network` master script is linked to `/etc/rc0.d/K40network`, which is invoked from `/etc/rc0` during shutdown, and to `/etc/rc2.d/S30network`, which is invoked from `/etc/rc2` during startup. The script understands two arguments: start and stop. It can be run manually for testing and troubleshooting network-related problems without having to reboot the system.

### Network Initialization Process

During system initialization, the shell script `/etc/init.d/network` is called. These are the actions performed by the script at startup:

1. Checks hostname and Internet address to determine if system should be configured as standalone or networked. Checks `sys_id` and `hosts` files. If the network configuration flag is off, the system is configured for standalone operation.

2. Determines names and addresses or primary and router interfaces for typical configurations.

3. Obtains any site-dependent information for interfaces from the `netif.options` file.

4. If system is not diskless, the shell script flushes all old routes.

5. Configures all interfaces, including loopback, using the `ifconfig` command.

6. If configured for IP packet filtering, the shell script starts the IP packet filtering daemon (`/usr/etc/ipfilterd`). The `ipfilterd` daemon must be started before gateway interface initialization.

7. Initializes gateway interface.

8. Initializes additional interfaces specified in the `netif.options` file.

9. If specified, initializes the Hypernet interface according to the `ifconfig-hy.options` file.

10. Initializes the loopback interface.

11. Using the `chkconfig` command, determines daemon configuration and reads relevant daemon configuration files (`*.options`).

12. Sets default route for all IP multicast packets to the primary interface.

13. If NIS software is configured, defines and sets NIS domain name.

14. If NIS software is configured, starts appropriate NIS daemons.

15. If NFS software is configured, starts appropriate NFS daemons and mounts any NFS filesystems listed in the `/etc/fstab`.

16. If NFS software is configured, starts other NFS daemons if `autofs`, `cachefs`, or`lockd` is configured on with `chkconfig`.

17. If configured on with `chkconfig`, it starts standard daemons (`inetd`, `timed`, `timeslave`, `rarpd`, `rwhod`, `snmpd`, and so on).

### Network Shutdown Process

During system shutdown, `/etc/init.d/network` stops the daemons and disables the network devices. These are the actions the script performs at system shutdown:

1. Kills all network services that may be associated with a shell (`rlogind`, `rexecd`, `rshd`, `ftpd`, `telnetd`, and so on).

2. Kills some network daemons immediately (`inetd`, `bootp`, `tftpd`, `snmpd`, and so on).

3. If NFS is running, unmounts remote filesystems.

4. Kills all remote daemons.

5. If NFS is running, unexports exported filesystems. See the ONC3/NFS Administrator's Guide and the NIS Administration Guide for complete information about the optional NFS software.

6. Kills daemons that must be kept alive until the last minute (`portmap`, `slip`, `ipfilterd`).

7. Gracefully takes the system off the FDDI ring, if it is on the ring.

8. Stops the `ypbind` process of NIS.

## Network Management Tools

This section summarizes the most standard networking tools for day-to-day management of your network. Except as noted, these networking tools reside in the `/usr/etc` directory. See the online reference pages for explicit instructions on how these tools are used.These standard networking tools are described briefly in the following subsections: `ifconfig(1M)` ,`netstat(1)` , `arp(1M)` , rcpinfo`(1M)` , `ping(1M)` , `spray(1M)` , `rtquery(1M)` , `traceroute(1M)` , `route(1M)` , `rup(1C)` , `ttcp(1)` , and `netsnoop(1M)` . The optional SGI network management tool NetVisualyzer is also summarized.

`ifconfig(1M)` |  | The `ifconfig` command sets or checks the network interfaces to TCP/IP; it assigns IP addresses, subnet mask, and broadcast address to each interface. `ifconfig` is performed at boot time by the master network configuration script `/etc/init.d/network`. An example of modifying the`ifconfig-#.options` file is shown in Chapter 3. An example of using `ifconfig` to configure various interfaces is shown in TCP/IP Network Administration by Hunt. Also see the`ifconfig` (1M) reference page for details on how to use the various options to this command.
`netstat(1)` |  | The `netstat` command is used extensively to display which network interfaces are configured, which are available; `netstat` can also show whether a valid route to your destination is available. You can use netstat to display queue information (`-iq`), network memory (`-m`), and protocols (`-p`). For sample output of `netstat` see Collecting Network Statistics with netstat on page 79. Examples of the use of`netstat` are given extensively in TCP/IP Network Administration by Hunt. An analysis of using `netstat` in the measurement of collisions and network saturation can be found in Managing NFS and NIS by Stern. Also see the`netstat` (1) reference page for details on how to use the various options to this command.
`arp(1M)` |  | The `arp` command displays the contents of the ARP table which maintains dynamic translations between IP addresses and Ethernet addresses. This command can be used to detect systems on the local net that are configured with the incorrect IP address. `arp` options include `-a` for all entries, `-d` to delete an entry, `-s` to publish an entry and act as a server for this entry, and `-f` to pull information from a specified file instead of `/dev/kmem. arp`. The`arp` (1M) reference page describes the use of these options. An example of using the `arp` command to troubleshoot incorrect address resolution is given in TCP/IP Network Administration by Hunt. `arp` does not display the local station's Ethernet address. To get a local station's Ethernet address, use the `netstat` command with the `-ia` options. A discussion of using `arp` to diagnose intermittent failures is given in Managing NFS and NIS by Stern.
`rpcinfo(1M)` |  | The `rpcinfo` command queries Remote Procedure Call (RPC) servers and their registration with the portmapper; it is analogous to `ping` in that it verifies that the remote machine is capable of replying to an RPC request. `rpcinfo` can be used to detect and debug unresponsive servers, RPC client-server mismatches, and broadcast problems related to the RPC service. The information provided by `rpcinfo` includes a list of `rpc`-based applications (`portmapper`, NIS, `rstatd`, and so on), and the program number, version number, protocol (TCP/UDP), and associated port number. If you are running an RPC-based network application and cannot get a response from the remote station, use the rpcinfo tool to ensure that the remote station supports the desired application. A discussion of RPC mechanics can be found in Managing NFS and NIS by Stern. The`rpcinfo` (1M) reference page describes the use of available options.
`ping(1M)` |  | The `ping` command tests whether a remote host is alive and reachable from your system. It is based on the Internet Control Message Protocol (ICMP) and sends an ECHO_REQUEST soliciting an ECHO_RESPONSE, thereby creating a two-way stream. It provides general information about packet loss and round-trip time. A discussion of using ping to test basic connectivity can be found in TCP/IP Network Administration by Hunt. A case study using ping to diagnose network health and an analysis of the results is given in Managing NFS and NIS by Stern. See also “Testing Network Connectivity With ping ” and the `ping(1M)` reference page.
`spray(1M)` |  | The `spray` utility sends a one-way stream of packets to a station using consecutive packets of fixed length, making remote procedure calls to the`rpc.sprayd` daemon on the remote host to report how many packets were received, and the transfer rate. It roughly estimates network interface capacity both on individual hosts and through network hardware between hosts. Although it provides very limited information about general network performance, an example of using `spray` to gauge Ethernet interface capacity can be found in Managing NFS and NIS by Stern. See also the reference page for `spray` (1M).
`rtquery(1M)` |  | Sends a request to a designated station for information on the station's network routing tables (`routed` or `gated`). This tool can be useful for troubleshooting routing problems; it shows the number of routing response packets returned. For details see RFC 1058—Routing Information Protocol and the `rtquery` (1M) reference page.
`traceroute(1M)` |  | Track packets as they journey through the network with`traceroute`. This tool is very useful for isolating network and router faults in a large heterogeneous network. It displays the names and addresses of all the intermediary routers that support the Internet Protocol “time-to-live” (TTL) field. It also displays the amount of time the packet spends traveling to the router, on the router, and leaving the router. traceroute increases network load; this factor should be considered when testing a network with `traceroute`. See the`traceroute` (1M) reference page for an explanation of how this command uses options, and sample output.
`route(1M)` |  | Use the `route` command to add or delete entries in the network routing tables. Typically, the routing tables are handled automatically by the routed or gated daemon. However, route can be used to create, maintain, and delete static routing tables, to flush routing tables, and to show metric information about routes. To have static routes incorporated at startup, modify the file `/etc/gateways` and `/etc/config/routed.options`. For an example of building a static routing table using the route command see TCP/IP Network Administration by Hunt.
`rup(1C)` |  | Displays status information, including uptime and load average, about remote stations using Sun RPC broadcasts. If no specific station is specified, it uses broadcasting and returns information about stations on the local network; broadcasting does not go through routers. This tool is useful for isolating physical problems with a station or the network.
`ttcp(1)` |  | Used to test Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) performance. This tool provides a more realistic measurement of performance than the standard tests (`spray`, `rup`, `ping`). It allows measurements to be taken at both the local and remote end of the transmission. See “Measuring Network Throughput With ttcp”.
`netsnoop(1M)` |  | Captures packets and decodes network traffic, and in some ways acts as a network sniffer. You can either capture traffic to a file or watch real-time packets between any two machines. To capture or have a clear view of all traffic between two machines, `netsnoop` must be run on a third machine. In this way the view from the third machine will not be biased by what the sender thinks it is putting on the wire, but might not actually be getting there, nor by what the receiver is failing to receive from the wire. You can use `netsnoop` with a number of filters in realtime, or on a saved tracefile reactivated by the command `netsnoop`. You must be superuser to run `netsnoop` on a local network interface.`netsnoop` is a useful tool for analyzing damaged packets, and tracing problems. If network overload is indicated, NetVisualyzer (summarized below) includes tools such as netcollect that are designed to help in figuring out if subnetting is needed.

NetVisualyzer is network management tool available as an option for use on any SGI system. It is a passive network management product that offers a set of graphical traffic monitoring, diagnostics, planning, and performance analysis tools that provide network information and statistics for Ethernet or FDDI networks in a visually intuitive form. NetVisualyzer comprises six tools: NetLook, NetGraph, NetCPA, Analyzer, RouteQuery, and TraceRoute. NetVisualyzer allows you to view and monitor your network, collect network statistics and generate reports based on those statistics, and decode heterogeneous packets layer by layer.

## Interpreting Network Statistics

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:

- “Testing Network Connectivity With ping ”

- “Measuring Network Throughput With ttcp”

- “Collecting Network Statistics With netstat”

### Testing Network Connectivity With ping

Used with no options, the `ping` tool tells you if a machine is active and reachable over your network. You can also use `ping -s` to show datagrams of a given size and transit times (round trip times) and packet losses. An example of using `ping` to isolate network problems can be found in Managing NFS and NIS by Stern.

Unless used with the count `-c` option, `ping` continuously transmits datagrams until halted, and therefore should not be used in a script. When using `ping` to troubleshoot, start with the local host to ensure the local network interface is operational, then increase the radius of testing to remote hosts and gateways.

The following example uses `ping` with the`-c` option to limit the number of datagrams sent and received. The `ping` tool is testing and measuring traffic between the local station and the station testcase. See the `ping(1M)` reference page for more details about other `ping` options.

    /usr/etc/ping -c5 testcase
    PING testcase (192.55.43.4): 56 data bytes

    64 bytes from 192.55.43.4: icmp_seq=0 ttl=249 time=160.314 ms
    64 bytes from 192.55.43.4: icmp_seq=1 ttl=249 time=47.057 ms
    64 bytes from 192.55.43.4: icmp_seq=2 ttl=249 time=28.129 ms
    64 bytes from 192.55.43.4: icmp_seq=3 ttl=249 time=48.596 ms
    64 bytes from 192.55.43.4: icmp_seq=4 ttl=249 time=131.894 ms
    ----testcase PING Statistics----
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max = 28.129/83.198/160.314 ms

If `ping` shows no output, the pinged host is disconnected or out of service. Consistent packet loss over 0.1% should be investigated further. Damaged packets are sometimes an indication of faulty hardware, so tracing cabling, connectors, and terminators is a reasonable step. Packet loss may be sporadic, in which case a script to `ping` at specified intervals, saved to a file, would be useful. If `ping` responds but you still cannot`ftp` or`telnet`, you may be experiencing a TTL error You can extend datagram time-to-live with the`-T` option. See the `ping` reference page for details.

### Measuring Network Throughput With ttcp

The `ttcp` tool measures network throughput. It provides a realistic measurement of network performance between two stations because it allows measurements to be taken at both the local and remote ends of the transmission. 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.

You can use ttcp by issuing the following commands, the first from the receiver

    ttcp -r -s -l 32768

the second from the sender:

    ttcp -t -s -l 32768 -n XXX host

The receiver should be started before the sender. The`-l` option sets the length of the write/read size to 32K chunks. You can change this to 64K or 128K for slightly better performance, as long as it is a multiple of the page size. `ttcp` does memory-to-memory TCP data transfer between end systems, and measures end-to-end TCP throughput.

You should get over 800 KB per second on a 10baseT half duplex network and over 1000 Kbytes per second on a 10baseT full duplex switched network. On a 100baseT network you should get over 8500 KB per second for half duplex, and over 11500 KB per second for full duplex.

Most of the speed difference between half and full duplex is related to the Ethernet capture effect rather than anything else. There should be no`netstat -i` input nor output errors. Some of the network device drivers support a `ifconfig xxx debug` mode which causes more informative diagnostic error messages to be displayed on the console when errors occur. Use `ifconfig xxx -debug` to disable them again.

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(1)` reference page for details about the many `ttcp` options.

On sheridan, enter 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 192.102.108.4
    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, enter the 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 in units of KBps. The throughput on the station sheridan is 819.64 KBps and the throughput on the station longstreet is 820.02 KBps. Both throughput values indicate good network performance between the stations.

### Collecting Network Statistics With netstat

The `netstat` tool shows the status of the network by identifying active sockets, routing and traffic. You can see network addresses for the interfaces, and the maximum transmission unit (MTU) depending on the option selected. On a given system, if the output collision rate is consistently greater than 5% of that on other systems, it may indicate a suspicious physical fault—a bad tap, transceiver, loose terminator, and so forth. Network-wide collision rate is discussed later.

An analysis of using `netstat` in the measurement of collisions and network saturation can be found in Managing NFS and NIS by Stern. The example given here illustrates the statistics you might see on a station using `netstat`. See the `netstat(1)` reference page for details about the many `netstat` options:

    netstat -i

    Name  Mtu    Network  Address      Ipkts   Ierrs    Opkts  Oerrs   Coll
    enp0  1500   central  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.

If the network interface is assigned IP aliases, the output from `netstat -i` looks similar to this:

    netstat -i

    Name   Mtu   Network    Address   Ipkts    Ierrs    Opkts  Oerrs   Coll
    enp0  1500   central    thumper  498690      937  1066135      3   4858
    enp0  1500    bldg-2     hopper  584280      163   137245      0  40717
    lo0  32880  loopback  localhost 1678915        0  1678915      0      0

If the network-wide collision rate is consistently above 10%, it may be time to consider subdividing the network, although there are other possible culprits in the scenario—insufficient memory on diskless workstations, among several. See “Troubleshooting Network Daemons to Improve Network Performance”. Throughput is a reliable indicator of network performance (see“Measuring Network Throughput With ttcp”.).

## Network Tuning Information

In general, IRIX TCP/IP services are factory-tuned for optimum performance under routine network operating conditions and no tuning is required after a network setup. Kernel TCP/IP tuning parameters are controlled with the `systune` command or from the file `/var/sysgen/master.d/bsd`.

| Caution: It is not advisable to change the factory-shipped settings in this file unless you receive explicit instructions in product documentation or you are highly experienced in network administration.

The following subsections deal with specific tuning aspects of your network:

- “About Setting MTU Sizes”

- “About Setting Packet Forwarding”

- “About Setting Window Sizes”

- “HTTP Considerations”

### About Setting MTU Sizes

IRIX 6.2 and later versions implement MTU Discovery, a feature that allows a host to calculate maximum transmission unit (MTU) sizes using a table of commonly used MTU sizes. MTU Discovery is specified by the tcp_mtudisc variable in `/var/sysgen/master.d/bsd`. When tcp_mtudisc is on and a router requests packet fragmentation without providing MTU size information, the calculated segment size is used to fragment the packet instead of the default maximum segment size (specified by tcp_mssdflt). The MTU Discovery flag is on (set to 1) by default.

### About Setting Packet Forwarding

By default, IRIX hosts that contain more than one network interface are assumed to be routers, so IP packet forwarding is enabled at system startup. In addition, the factory-shipped configuration enables ICMP redirection, which causes the router to forward messages that are destined for a particular host to an alternative router instead. Two tunable kernel parameter, ipforwarding and icmp_dropredirects, turn packet forwarding and ICMP redirection on and off.

On firewall systems, ipforwarding and icmp_dropredirects must be turned off to prevent packets from breaching the security boundary. See the product documentation for your firewall application for specific instructions on setting IP forwarding characteristics. Also see the `systune(1M)` reference page for more information.

### About Setting Window Sizes

Send and receive window sizes are specified by the variables tcp_sendspace and tcp_recvspace in `/var/sysgen/master.d/bsd`. By default, both variables are set to 60 KB. For wide area network traffic, reducing window sizes to a value in the range of 4 to 8 KB can result in better response times in interactive sessions. Large amounts of bulk transfer traffic from systems using TCP windows larger than 4 to 8 KB can overflow the buffers of slow- or moderate-speed routers on wide area network. Overflowing WAN router buffers reduces the speed of the bulk transfers, and interactive traffic usually must wait behind such large bursts in a route queue.

| Note: Using small window sizes on high-speed WAN links (such as T3) severely reduces TCP speed.

On a local Ethernet network, reducing the window size often increases performance. However, it degrades performance on an FDDI network.

### HTTP Considerations

In some cases, variables in `/var/sysgen/master.d/bsd` need adjusting for HyperText Transport Protocol (HTTP) servers. These variables frequently include changes to the number of connections and connection time-outs. See the product documentation for your HTTP application for specific tuning instructions.

## Troubleshooting Poor Network Performance

Given the complexity of most networks it is often hard to troubleshoot poor network performance. Among the many factors to suspect are hardware problems, outgrown network configuration, heavy use of particular network applications, and excessive packet size. In general `/usr/adm/SYSLOG` is a good place to start looking for diagnostic messages. The following subsections consider particular aspects of network performance improvement:

- “Troubleshooting Hardware Problems to Improve Network Performance”

- “Troubleshooting Network Configuration to Improve Network Performance ”

- “Troubleshooting Network Daemons to Improve Network Performance”

- “Decreasing Packet Size to Improve Network Performance”

- “Kernel Configuration for Better Network Performance”

### Troubleshooting Hardware Problems to Improve Network Performance

A network can be slow or inoperable due to hardware malfunction, often manifesting in the form of packet loss or corruption. This can increase network traffic to the point of unmanageable congestion. Start by segmenting the network, and begin diagnosis section by section. The most obvious items to check at the physical level are these:

Controller board
| Even if the network media bandwidth is capable of handling the network traffic load, the individual station may not be able to handle the traffic. This is evidenced by a high degree of traffic on the network interface for no apparent reason. This traffic can be seen using the `gr_osview` tool (see the `gr_osview(1)` online reference page for options to see network traffic statistics). If traffic is unusually heavy on the interface, then there may be a problem with the controller, or the controller may be too slow to handle the volume of traffic. You may need a high-speed controller like the Efast card.
Transmitter and controller
| Ensure that the Signal Quality Error (SQE), also called heartbeat, is disabled on both the transmitter and controller. SQE can cause unnecessary network traffic between the local station and the transceiver. See the installation guides for your network controller and transceiver for instructions on disabling SQE. By default, all SGI network controller boards are shipped with SQE disabled.
Physical problems with the media
| Cables, taps, and other hardware will periodically break or malfunction. A time domain reflectometer (TDR) is essential for troubleshooting Ethernet cable problems. A good analyzer is also strongly recommended to assist in isolating network physical problems. SGI' NetVisualyzer product supplies a visual network analyzer ideal for locating physical problems with the media. Disk access difficulties can also contribute to slow network performance. An otherwise healthy network feels sluggish if NFS requests requiring disk access are not handled promptly.

### Troubleshooting Network Configuration to Improve Network Performance

The network configuration or topology may also be a factor in adverse network performance. Monitor network usage to benchmark when the network is performing well. It provides a standard against which any changes can be measured. In summary check:

- Physical path—the wiring (if appropriate) for EMI and crosstalk.

- Concentration points—hubs and concentrators for capacity and connectivity.

- Number and location of repeaters and bridges —their age and intelligence.

- Router and gateway configurations— for traffic load and throughput, particularly if connecting large subnets ensure that there are at least two ways in and out of a network.

- Work group affiliations and routine sharing of resources (NFS filesystems, NIS domain, electronic mail, financial databases).

- Client/server configurations and the traffic they generate.

- Individual workstation usage, specific disk activity, burden of directory name lookups.

The complexity of network configuration requires a familiarity with all of the resources listed in “Resources for Network Management”.

### Troubleshooting Network Daemons to Improve Network Performance

Some network daemons (`rwhod`, `rtnetd`, and so on) can have an undesirable effect 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 daemons should be evaluated individually.

Do not load `rtnetd` software on routers or other network intensive stations (mail servers, NIS and DNS servers, and so on).

### Decreasing Packet Size to Improve Network Performance

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. IRIX versions 6.2 and higher use MTU Discovery to perform fragmentation (see “About Setting MTU Sizes” for details).

### Kernel Configuration for Better Network Performance

You can change several parameters to customize network behavior for local configurations. The parameters listed below are in the `/var/sysgen/master.d/bsd` configuration file. For details on reconfiguring the kernel after changing this file, see IRIX Admin: System Configuration and Operation

#### Changing Kernel Tunable Options to Improve Network Performance

There are four kernel parameters that directly affect the network performance: tcp_sendspace, tcp_recvspace, udp_sendspace, and udp_recvgrams.

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` 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.

#### Changing TCP Parameters to Improve PC Connectivity

Many industry-standard personal computers with TCP/IP implementations experience difficulty connecting to SGI 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` command. For more information on reconfiguring these values, see IRIX Admin: System Configuration and Operation .

Prev | Table of Contents | Next
Chapter 3. Setting Up a Network |  | Chapter 5. SLIP and PPP