Troubleshooting While Starting a SunATM Interface

There are many steps involved in making an interface active on an ATM network. Problems in your configuration may cause a failure at any number of points along the way. The following sections contain steps you can take to determine where in the process your system failed, and what to do to remedy the situation. If you continue to experience problems, information gathered from these steps will help your service provider diagnose the problem.

Generic Configuration

To Diagnose Problems

1. Make sure that there is an entry for the interface in /etc/opt/SUNWconn/atm/atmconfig.

   Configuration of an interface begins during system boot. Configuration will be attempted for all interfaces listed in /etc/opt/SUNWconn/atm/atmconfig. For information about the format of this file, see "Basic ATM Interface Plumbing", and the atmconfig(4) man page.

2. Check to see if any error messages were printed during the boot process.

   If there were error messages, see "Error Messages".

3. Verify linkstate in qccstat(1M).

   This command indicates the signalling status of your interface. If the linkstate is not DL_ACTIVE, your interface is not communicating properly with your switch.

   • Make sure that your switch and interface are configured to run the same version of UNI signalling.

     The SunATM software supports UNI versions 3.0, 3.1, and 4.0; set the version for each interface in the /etc/opt/SUNWconn/atm/atmconfig file.

   • Verify that your interface is physically connected to the switch and that the switch sees the physical connection (most switches have a physical link LED for each port).

     If your interface is a multimode fiber interface, one possible cause for a bad physical connection is that transmit and receive are swapped. "transmit" on your interface should be connected to "receive" on the switch, and "receive" on your interface to "transmit" on the switch. There is generally writing on one of the cables in a transmit-receive pair so that the two cables are distinct.

4. Verify that an address has been registered with the switch.

   The qccstat(1M) command also lists all addresses registered to the interface with the switch. See "ATM Addresses and Address Registration", for more information about address registration. If there are no addresses registered, the ilmid daemon on your system is not communicating properly with the switch.

   • Verify that there are incoming packets on VC 16 using atmstat(1M).

     If there are no incoming packets, the switch is not responding to ILMI requests. Check its ILMI configuration.

   • Verify that there are outgoing packets on VC 16 using atmstat(1M).

     If you do not see any outgoing packets on VC 16, your interface is not transmitting ILMI packets. Verify that ilmid is running on your system, and if necessary, start it in the background. Starting ilmid with the -v flag causes it to print a notice for every message received or transmitted, along with other diagnostic information.

5. Interfaces that are not running Classical IP or LAN Emulation will not appear in the output of the ifconfig command.

   ifconfig(1M) displays interfaces that have been configured for IP. In order to support IP, ATM interfaces must run either Classical IP or LAN Emulation. Therefore, an ATM interface that is not configured to support IP by running one of these two protocols will not be displayed by ifconfig.

6. Verify the packets that are moving over the network with the /etc/opt/SUNWconn/bin/atmsnoop command.

Classical IP Configuration

1. Check all of the generic configuration points.

   These are issues that apply to all SunATM interfaces, so they all must be working in order for Classical IP to work.

2. Verify the output of ifconfig(1M).

   Executing the command ifconfig -a displays the SunATM interface, baN, where N is the instance number.

   • If your interface does not appear, an error probably occurred during the boot process.

     Check for error messages during the boot process. The meanings and possible solutions for error messages can be found in "Error Messages".

   • If your interface appears, but has incorrect information, verify your configuration files.

     The information given to ifconfig comes from the /etc/opt/SUNWconn/atm/atmconfig and /etc/opt/SUNWconn/atm/aarconfig files. Check the entries in those files that apply to this interface and verify their contents. For descriptions of the file formats, see "Basic ATM Interface Plumbing", and "Editing the /etc/opt/SUNWconn/atm/aarconfig File", or the atmconfig(4) and aarconfig(4)man pages.

3. Check the setup_state with aarstat(1M).

   This command will provide information about the Classical IP status on your interface. The setup_state refers to the completion of the aarsetup program.

   • If the setup_state is setup-started, it indicates that the aarsetup program has not completed; it may be delayed by slow switch responses, or failed attempts to register ATM addresses in /etc/opt/SUNWconn/atm/aarconfig. Make sure that the local address given for your interface in /etc/opt/SUNWconn/atm/aarconfig is unique to this switch. Using $myaddress and the reserved server addresses is a good way to guarantee that all addresses are unique. After making any changes to /etc/opt/SUNWconn/atm/aarconfig, run aarsetup again.

   • If the state is not setup-started or setup-finished, verify that the addresses and interfaces in /etc/opt/SUNWconn/atm/aarconfig are valid, and run aarsetup again. If you see any error messages, check their meaning in "Error Messages".

4. Verify the interface_state in aarstat(1M).

   The interface_state is either up or down, and reflects the linkstate given in the output of qccstat. If the linkstate is DL_ACTIVE, the interface_state is up; otherwise, the interface_ state is down. If aarstat indicates that the interface_state is down, try the suggestions for a linkstate that is not DL_ACTIVE, given in "Generic Configuration".

5. Make sure Classical IP is configured correctly.

   The aarstat(1M) output lists several parameters for Classical IP. The field arpcsmode lists whether Classical IP is running as a client, a server, or stand-alone (a client with no server configured). Verify that this is correct; if it is not, check your /etc/opt/SUNWconn/atm/aarconfig file entries.

6. If the system is a Classical IP client, verify the server connection.

   On systems running in client mode, aarstat also provides information about the server. Verify the server address, and that the server_state is connected.

7. If the server_state is no-connection or connecting.

   The system is likely having a problem establishing a connection to the server. Verify that the server address is correct, and that there is a system on the network which has registered that address. The server and applicable switch ports must also be configured to support UNI signalling, also called Q.2931 or Q.93b.

8. Verify that addresses are resolved and connections are made with the ping(1M) command.

   Once you have two systems configured and running to this point, they should be able to ping each other. To ping client2 from client1:

   % ping client2 client2 is alive

   If the ping is not successful:

   1. Check that ARP requests are being sent to the server.

      Find the server_vci in the output of aarstat. Then run atmstat, and verify that there are outgoing packets on that VC. If not, make sure that your interface is up and configured properly.

   2. Make sure that you are receiving ARP responses from the server.

      In the atmstat output, check the output packets for the server VC (found in the aarstat information). If none are being received, your server is not responding to ARP requests from the client. If it is a SunATM server, verify its Classical IP status with the suggestions given here. If not, verify that it is up and running as a server.

   3. Make sure the address is resolved correctly.

      Run the atmarp command for the system you are trying to ping, and verify that its IP address has been resolved to the correct ATM address. If not, make sure that the remote system is registering the correct address with the ATM ARP server. If the address has not been resolved at all, make sure that the remote system has a connection to the server.

   4. Verify that a connection has been established between the two systems.

      The output of qccstat lists the source and destination addresses of all open connections. You should have at least one connection to the server, and you should also see a connection to the remote host you are trying to ping. If not, make sure both interfaces are up and registered with the switch, and that both interfaces and the switch are running UNI signalling (Q.2931 or Q.93b).

   5. Check for IP problems.

      If the address has been resolved correctly, and a connection has been established between the two systems, but they still cannot ping, the problem is likely outside the scope of ATM.

LAN Emulation Configuration

1. Check all of the generic configuration points.

   These are issues that apply to all SunATM interfaces, so they must all be working in order for LAN Emulation to work.

2. Verify the output of ifconfig(1M).

   Executing the command ifconfig -a should display the ATM LAN Emulation interface, laneN, where N is the instance number.

   • If your interface does not appear, an error probably occurred during the boot process.

     Check for error messages during the boot process. The meanings and possible solutions for error messages can be found in "Error Messages".

   • If your interface appears, but has incorrect information, verify your configuration files.

     The information given to ifconfig comes from the /etc/opt/SUNWconn/atm/atmconfig and /etc/opt/SUNWconn/atm/laneconfig files. Check the entries in those files that apply to this interface and verify their contents. For descriptions of the file formats, see "Basic ATM Interface Plumbing" and "Editing the /etc/opt/SUNWconn/atm/laneconfig File", or the atmconfig(4) and laneconfig(4) man pages.

3. Check the setup_state with lanestat(1M).

   This command provides information about the LAN Emulation status on your interface. The setup_state refers to the completion of the lanesetup program.

   • If the setup_state is setup-started:

     This indicates that the lanesetup program has not completed; it may be delayed by slow switch responses, or failed attempts to register ATM addresses in /etc/opt/SUNWconn/atm/laneconfig. Make sure that the local address given for your interface in /etc/opt/SUNWconn/atm/laneconfig is unique to this switch. Using the variable $myaddress for all systems is a good way to guarantee that all addresses are unique. After making any changes to /etc/opt/SUNWconn/atm/laneconfig, run lanesetup again.

   • If the state is not setup-started or setup-finished:

     Verify that the addresses and interfaces in /etc/opt/SUNWconn/atm/laneconfig are valid, and re-run lanesetup. If you see any error messages, check their meanings in "Error Messages".

4. Verify that a connection has been made to the LAN Emulation server (LES).

   A LAN Emulation client must establish and maintain a connection to the LES. In most cases, the LES also establishes and maintains a second connection to the client. Find the LES address in the output of lanestat, and then look for connections with that address as the destination or source in the output of qccstat.

   If you do not see any connections with that address, take the appropriate action from the list below:

   • If you have a LAN Emulation configuration server (LECS):

     Make sure that the correct address is configured for the LECS. By default, the SunATM software uses the ATM Forum well-known address. If your LECS uses a different address, enter the alternate address in the /etc/opt/SUNWconn/atm/laneconfig file. See "Editing the /etc/opt/SUNWconn/atm/laneconfig File", for information on editing /etc/opt/SUNWconn/atm/laneconfig. You can check the address currently being used in the output of lanestat.

   • If you do not have an LECS:

     One of the LECS functions is to provide the LES address, so if you do not have an LECS, you must provide the address. Create an entry in /etc/opt/SUNWconn/atm/laneconfig. See "Editing the /etc/opt/SUNWconn/atm/laneconfig File". You can check the LES address currently being used in the output of lanestat.

   • Verify that the LECS, if present, and LES are configured properly.

5. Verify that a connection has been made to the BUS.

   In addition to the LES connection(s), a LAN Emulation client must also establish and maintain a connection to the BUS, and the BUS typically establishes and maintains a second connection to the client. You can find the BUS ATM address in the output of lanestat, and then verify that there is a connection with that address as the destination, and probably a second connection with that address as source, in the output of qccstat. If there are not any connections, verify that the BUS is configured properly.

6. Verify that the host has joined the Emulated LAN.

   The lanestate field in the output of lanestat indicates that the client is in the active state.

   If your system cannot join the emulated LAN, there may be a problem with the way in which your LAN Emulation Services are configured. If the Emulated LAN uses an MTU size larger than 9 Kbytes, the SunATM host will not join (9 Kbytes is the largest MTU size supported by the SunATM product). If the host is not able to join, an error message will be printed with an explanation.

7. Verify that addresses are resolved and connections are made with the ping command.

   Once you have two systems configured and running to this point, they should be able to ping each other. To ping client2 from client1:

   % ping client2 client2 is alive

   If the ping is not successful:

   1. Check that the IP hostname or address is resolved to a MAC address.

      LAN Emulation requires two address resolution steps to make a call. The first is to resolve an IP address to a MAC address. From the perspective of IP and ARP, this works exactly as it does on an Ethernet interface; using the arp command, you can verify that this resolution has been made correctly. If it has not, verify the connections to the BUS, and make sure data is being transmitted and received on the connection(s) to the BUS by finding the VC in the output of qccstat, and looking at the statistics for that VC in atmstat.

   2. Check that the MAC address has been resolved to an ATM address.

      This is the second address resolution step, and is accomplished by the LAN Emulation software and communication with the LES. You can use the lanearp command to verify that MAC addresses have been properly resolved to ATM addresses. If they have not, verify the connections to the LES, and make sure data is being transmitted and received on the connection(s) to the LES by finding the VC in the output of qccstat and looking at the statistics for that VC in atmstat.

   3. Verify that a connection has been established between the two systems.

      The output of qccstat lists the source and destination addresses of all open connections. There you should see a connection to the remote host you are trying to ping. If not, make sure both interfaces are up and registered with the switch, and that both interfaces and the switch are running UNI signalling (Q.2931 or Q.93b).

   4. Check for IP problems.

      If the address has been resolved correctly, and a connection has been established between the two systems, but they still cannot ping, the problem is likely outside the scope of ATM.

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.