Common Problems

This section describes some common problems that you may experience during or after the SunATM adapter installation. Please review this section before calling Sun Service for assistance.

Are you replacing an old SunATM SBus adapter?

1. If you are replacing an old SunATM/S 155 adapter with a new adapter, you must edit the /etc/path_to_inst file to remove the old device instance.

   The SunATM/S 155 adapter originally shipped with an FCode name of "ba" (part numbers 501-2794-07, 501-2795-05, and prior versions). Since then, Sun Microsystems, Inc. has changed the naming convention to include SUNW at the beginning of every device name. When a third-party adapter was found, which also used the name property "ba", the SunATM/S 155 adapter was updated to use the "SUNW,ba" name property instead (the change was made to part numbers 501-2794-08, 501-2795-06, and compatible versions).

As a result, when an older SunATM/S 155 adapter (with the "ba" name property) is replaced by a newer SunATM/S 155 adapter (with the "SUNW,ba" name property), the system does not recognize the new adapter as a replacement. Instead, the system sees it as a new interface and assigns a new instance number to the adapter. The /etc/path_to_inst file is created by the Solaris operating environment to identify installed devices and their instance numbers. When a SunATM/S 155 adapter (with the "ba" name) is installed in a system, /etc/path_to_inst has an entry, similar to the following, to identify it as ba0:

"/sbus@1f,0/ba@0,0" 0 "ba"

When a replacement adapter (with the "SUNW,ba" name) is installed into the same location and the system is rebooted, it treated as a new device and a new entry in /etc/path_to_inst is created for ba1:

"/sbus@1f,0/SUNW,ba@0,0" 1 "ba"

To correct this, delete the original entry that contains the "ba" name. Then, modify the second field of the new entry, which contains the name "SUNW,ba", to reflect the proper instance number. In this example, the new entry is designated as instance 0:

"/sbus@1f,0/SUNW,ba@0,0" 0 "ba"

After you have modified and saved /etc/path_to_inst, reboot the system for the changes to take effect.

The physical name listed in /etc/path_to_inst varies from one architecture to another and might not match the previous examples exactly. However, modify only the instance number field. Be sure to leave all other fields as they are.

Are you trying to use the /usr/sbin/arp command?

Since the Classical Internet Protocol (IP) network model resolves IP-to-ATM address pairs rather than IP to MAC address pairs, the /usr/sbin/arp command does not support Classical IP interfaces at this time. A version of the arp command, /etc/opt/SUNWconn/atm/bin/atmarp, provides similar functionality for Classical IP interfaces. Refer to the atmarp (1M) man page for more information.

Are you using a Router with Classical IP and LAN Emulation (LANE)?

Performance problems occur if a router uses ATM Classical IP (default 9180 byte MTU) and LAN Emulation (default 1500 byte MTU) links simultaneously when a TCP connection is set up using one interface in one direction and the other interface in the opposite direction, TCP is confused about the maximum packet size.

For example, suppose a TCP connection is set up between Host A and Host B, where packets from Host A travel to Host B over the LANE interface and packets from Host B travel to Host A travel over the Classical IP interface. Host A attempts to send a 9180 byte packet that cannot traverse the LANE network to Host B. TCP recovers from this error and retransmits the packet, but a significant performance loss will be noted.

Possible workarounds to improve performance are:

• Adjust the MTU size, if possible, of the Classical IP link to 1500 bytes.

• Depending upon the network topology, adjust the routing table on Host B to ensure that the route back to Host A points to the LANE interface.

This problem is not unique to ATM networks. It may affect any network configuration that has multiple routes with differing MTUs (such as FDDI and Ethernet or Token Ring). The problem is more pronounced with ATM subnets because of the different default MTUs of Classical IP and LANE.

Are you trying to use the /usr/sbin/snoop command?

The /usr/bin/snoop command, which can be used to detect network problems, does not support SunATM interfaces at this time. A version of the snoop command, /etc/opt/SUNWconn/atm/bin/atmsnoop, provides this support. Refer to the atmsnoop(1M) man page for more information.

Do you want to increase system performance by adjusting TCP/IP parameters?

TCP/IP performance over an ATM network can be poor unless you carefully configure your network. Poor performance usually occurs because the TCP/IP packets are segmented into cells for transmission by the ATM software. Therefore, a loss of a single cell can cause the loss of an entire TCP/IP packet which can lead to retransmissions that congest the network. When it detects congestion, the destination system reduces the transmission rate, which significantly reduces the network performance.

You can achieve better network performance from the SunATM adapter and software by adjusting your application's socket buffer size to 48 Kbytes. Refer to the application's documentation for instructions on how to set the socket buffer size.

Are you trying to mount a diskless, dataless, or autoclient system?

The SunATM adapters do not currently support diskless, dataless, or autoclient systems. The root filesystem must be local for the SunATM adapter to operate.

Did the atmtest diagnostic fail?

If the bandwidth or outstanding packets value is set too high on your system, the SunVTS atmtest diagnostic can fail, giving a error similar to the following:

SUNWvts.atmtest.4000 09/17/98 17:33:10 atmtest ba0 

WARNING: "VC30 dropped pkt, seq: exp=41, obs=43; len: exp=1747, obs=6022"

To correct this error, reduce the bandwidth or the number of outstanding packets in the SunVTS atmtest.