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.