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:
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.
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:
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.
During system initialization, the shell script /etc/init.d/network is called. These are the actions performed by the script at startup:
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.
Determines names and addresses or primary and router interfaces for typical configurations.
Obtains any site-dependent information for interfaces from the netif.options file.
If system is not diskless, the shell script flushes all old routes.
Configures all interfaces, including loopback, using the ifconfig command.
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.
Initializes gateway interface.
Initializes additional interfaces specified in the netif.options file.
If specified, initializes the Hypernet interface according to the ifconfig-hy.options file.
Initializes the loopback interface.
Using the chkconfig command, determines daemon configuration and reads relevant daemon configuration files (*.options).
Sets default route for all IP multicast packets to the primary interface.
If NIS software is configured, defines and sets NIS domain name.
If NIS software is configured, starts appropriate NIS daemons.
If NFS software is configured, starts appropriate NFS daemons and mounts any NFS filesystems listed in the /etc/fstab.
If NFS software is configured, starts other NFS daemons if autofs, cachefs, or lockd is configured on with chkconfig.
If configured on with chkconfig, it starts standard daemons (inetd, timed, timeslave, rarpd, rwhod, snmpd, and so on).
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:
Kills all network services that may be associated with a shell (rlogind, rexecd, rshd, ftpd, telnetd, and so on).
Kills some network daemons immediately (inetd, bootp, tftpd, snmpd, and so on).
If NFS is running, unmounts remote filesystems.
Kills all remote daemons.
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.
Kills daemons that must be kept alive until the last minute (portmap, slip, ipfilterd).
Gracefully takes the system off the FDDI ring, if it is on the ring.
Stops the ypbind process of NIS.
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. | |
| 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.
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:
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.
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.
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”.).
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:
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.
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.
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.
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.
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:
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:
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”.
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).
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).
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
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.
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 .