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.