| Platform Notes: The SunATM Driver Software |     |
| Platform Notes: The SunATM Driver Software | |
| A P P E N D I X B |
|
Troubleshooting and Error Messages |
This appendix defines steps to help you diagnose problems you may encounter with SunATM and describes error messages you may see.
This appendix contains the following sections:
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.
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.
If you are not sure of your saved configuration, stop all daemons and unplumb everything with
Then, replumb and reinitialize your ATM network with
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/laneconfig 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:
If the ping is not successful:
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.
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.
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.
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).
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.
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:
If the ping is not successful:
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.
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.
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).
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.
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.
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:
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:
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:
After you have modified and saved /etc/path_to_inst, reboot the system for the changes to take effect.
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.
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.
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.
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.
The SunATM adapters do not currently support diskless, dataless, or autoclient systems. The root filesystem must be local for the SunATM adapter to operate.
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.
This section includes a list of some of the most common error messages you might see while configuring and bringing up your SunATM interface. For each message, there is a brief explanation of the problem and a possible solution.
Cannot find ATM utilities in /etc/opt/SUNWconn/atm/bin;exiting S00sunatm.
The SunATM utility directory /etc/opt/SUNWconn/atm/bin does not exist. Make sure that the SUNWatm package installation completed successfully (see Checking the Package Installation Using pkginfo, for more information). You might need to reinstall the package.
Cannot find atmconfig file in /etc; exiting S00sunatm.
The /etc/opt/SUNWconn/atm/atmconfig file provides configuration information to the S00sunatm script so that it can bring up the SunATM interfaces during system boot. If the /etc/opt/SUNWconn/atm/atmconfig file is not present, S00sunatm prints this warning message and exits. The
/etc/opt/SUNWconn/atm/atmconfig file is installed with the SUNWatm package as /etc/opt/SUNWconn/atm/atmconfig.template; if you choose autoconfiguration or if no previous /etc/opt/SUNWconn/atm/atmconfig file exists, pkgadd copies this template file to /etc/opt/SUNWconn/atm/atmconfig. If a previous /etc/opt/SUNWconn/atm/atmconfig file exists, it is not overwritten. See Basic ATM Interface Plumbing.
warning: can't plumb <device>; no UNI version provided
The first entry in /etc/opt/SUNWconn/atm/atmconfig for a physical interface must include a UNI value in the second field.
warning: can't plumb <uni version> on <device>; <uni version> already plumbed
The system encountered an entry which attempted to plumb a signalling version on an interface that has already been plumbed with a different signalling version. The script ignores the new UNI version and continues processing the entry and the remaining entries in the file.
warning: can't plumb <lane instance>: too many lane instances on <device>
A physical interface will support up to n lane instances, where n is the number of MAC addresses on the board (or 1 if the board has no MAC address).You can check the number of MAC addresses on a board using the count option of the atmgetmac(1m) command. If an entry is encountered that attempts to plumb more LANE instances than allowed, this message occurs; processing will continue with the next entry in the file.
warning: can't plumb signalling on <device>warning: can't plumb classical IP interface <device>warning: can't plumb <lane instance> on <device>
An error occurred when the script attempted to run atmplumb(1m) (either to plumb signalling, classical IP, or LAN Emulation on an interface) with information specified in /etc/opt/SUNWconn/atm/atmconfig. The atmplumb program will generally display an error message indicating why it failed; use that information to check your values in the /etc/opt/SUNWconn/atm/atmconfig entry for device. The script proceeds to read and process the remaining entries in
/etc/opt/SUNWconn/atm/atmconfig, although further entries for the failed interface are not processed correctly.
warning: invalid interface <lane instance>
The minor number provided in a logical interface name was not in the range 0 - 255. The script proceeds without attempting to configure the invalid lane device.
warning: only one classical ip hostname is allowed on <device>
An additional entry was found containing a Classical IP hostname after an initial Classical IP hostname was already plumbed for the given device. Multiple Classical IP instances are not supported on a single physical interface. The script ignores additional Classical IP information for a physical interface.
warning: <laneN> entry must appear before <laneN:X> entry
When you use logical interface names, the first entry in /etc/opt/SUNWconn/atm/atmconfig must always be either laneN or laneN:0, which are equivalent. All entries that appear before the laneN or laneN:0 entry are ignored.
Please install <SUNWatm>
A required software package is not installed on the system. Install the package and reboot the system.
warning: extra fields for <device> will be ignored
There were additional fields in the /etc/opt/SUNWconn/atm/atmconfig entry for the given device name. The script proceeds, ignoring the additional fields.
warning: duplicate entry <lane device>
There were multiple entries in /etc/opt/SUNWconn/atm/atmconfig using the same LAN Emulation instance number. This is not a fatal error; the script continues to run. However, only the first entry for each LAN Emulation instance number is configured for LAN Emulation.
warning: not enough fields to configure <device>
The /etc/opt/SUNWconn/atm/atmconfig entry for the given device did not have all the required fields. You must edit the /etc/opt/SUNWconn/atm/atmconfig file (see Basic ATM Interface Plumbing), filling in all the appropriate information, and reboot the system. Empty fields should be indicated with a hyphen (-).
warning: ifconfig failed for classical IP interface <device>warning: ifconfig failed for <lane instance>
The script attempted to run ifconfig for the specified interface. Error messages indicate why ifconfig failed; use that information to check your values in
/etc/opt/SUNWconn/atm/atmconfig. In particular, verify that the hostname you provide in /etc/opt/SUNWconn/atm/atmconfig appears in the /etc/hosts file on your system.
warning: invalid lane instance (<lane instance>) for <device>
The lane instance number provided in /etc/opt/SUNWconn/atm/atmconfig was not in the range 0 to 999. The script proceeds without attempting to configure the invalid lane instance.
warning: aarsetup failed; could not configure classical IP interfaceswarning: lanesetup failed; could not configure LAN Emulation interfaces
Either the LAN Emulation or the Classical IP startup script failed and exited with an error value. Check the error messages that were printed by aarsetup or lanesetup, and verify the values you have entered in /etc/opt/SUNWconn/atm/aarconfig and/or /etc/opt/SUNWconn/atm/laneconfig.
aarsetup: could not become control process lanesetup: could not become control process
An instance of the setup program was running when another instance was started up. The second instance exits with this error message. Make sure that there is not a previous instance of the program still running. The setup program might take a while to complete if the switch is slow to respond.
aarsetup: could not open stream to Q93B lanesetup: could not open stream to Q93B
The program was unable to communicate with the Q93B driver. Make sure that you run aarsetup or lanesetup as root, and that the SUNWatm package has been properly installed.
aarsetup: could not scan input file lanesetup: could not scan input file
The program was unable to open the /etc/opt/SUNWconn/atm/aarconfig or /etc/opt/SUNWconn/atm/laneconfig file (or the file specified on the command line). Verify that the appropriate file exists, and has the proper permissions. Also make sure you run aarsetup or lanesetup as root.
aarsetup: exiting because of errors lanesetup: exiting because of errors
Errors were encountered while parsing the /etc/opt/SUNWconn/atm/aarconfig or /etc/opt/SUNWconn/atm/laneconfig file, so the setup program cannot successfully complete. Correct the error condition and then execute either aarsetup or lanesetup.
aarsetup: <interface> running as a server, but PVC-only `t' entries exist
The aarsetup program has found an L entry in /etc/opt/SUNWconn/atm/aarconfig, meaning that this interface will be running as a server; however, there are table entries (t entries) containing only PVCs, which cannot be entered into the server's ATM ARP table. Verify your interface's status (server, client, or stand-alone), make sure all t entries include ATM addresses, and execute aarsetup. See Editing the /etc/opt/SUNWconn/atm/laneconfig File, for more information.
aarsetup: waiting for ilmid to provide prefixlanesetup: waiting for ilmid to provide prefix
In some cases, the address registration process may take several minutes. If so, aarsetup or lanesetup prints out this message saying that it cannot complete until address registration completes. If the messages continue for more than a minute or two, verify your connection to the switch, and that the switch and interface are both supporting ILMI.
undefined variable
You used a variable in a configuration file without using a set statement to assign the value. Add a set statement, or correct the variable name, and run aarsetup or lanesetup again. See Using Variables in the /etc/opt/SUNWconn/atm/laneconfig File, and Using Variables in the /etc/opt/SUNWconn/atm/laneconfig File, for more information.
variable already defined
You tried to set a variable that had been previously set in the same configuration file. Remove the second assignment and run aarsetup or lanesetup again.
variable name ill-formed
You created a variable in /etc/opt/SUNWconn/atm/aarconfig or /etc/opt/SUNWconn/atm/laneconfig that was syntactically invalid. Variable names are a combination of letters, digits, and underscores (_). Choose a conforming variable name and run aarsetup or lanesetup again.
variable name too long
You created a variable in /etc/opt/SUNWconn/atm/aarconfig or /etc/opt/SUNWconn/atm/laneconfig with a name that is greater than the maximum length (32 characters). Choose a variable name shorter than 32 characters and run aarsetup or lanesetup again.
variable value too long
You assigned a value longer than the maximum value length of 128 characters to a variable in a configuration file. If you want a longer value, use a combination of variable names, with each value less than 128 characters. After correcting the variable value lengths, run aarsetup or lanesetup again.
ifname:cannot join ELAN (frame size too large; please usea different ELAN and rerun lanesetup)
The largest MTU size supported by the SunATM software is 9 kilobytes. If the LAN Emulation Services try to set a size larger than 9 Kbytes, the SunATM client cannot join the emulated LAN. Reset your LAN Emulation services to use an MTU size less than or equal to 9 Kbytes, and rerun lanesetup to join the emulated LAN.
ifname: frame-size change (please rerun lanesetup)
The MTU size was changed by the LAN Emulation Services; rerun lanesetup to notify IP of the change. There is a slight chance that TCP connections will remain open during this change, and if that is the case, performance on those connections is affected by the change. Either restart the affected applications or reboot the system if this becomes a problem.
<ifname> could not download the MAC address
This message indicates that an error occurred while lanesetup was attempting to retrieve a MAC address for the indicated interface. Most likely the kernel is out of memory or you have not run atmplumb for the specified interface.
Could not find driver for <ifname>
Each LAN Emulation interface is associated with an ATM driver when LAN Emulation is set up by atmplumb. This message indicates that this interface/driver association has not been made, most likely because you have not run atmplumb for the specified interface.
Not enough MAC addresses on <ATM interface>
The number of Emulated LANs that can be joined over a single physical interface is limited by the number of MAC addresses on the ATM interface board. This message indicates that you tried to join more Emulated LANs than allowed by the number of MAC addresses on the specified interface. You can find the number of MAC addresses on an interface by using the count option on the atmgetmac(1M) command; the number of Emulated LANs and lane instances indicated in /etc/opt/SUNWconn/atm/atmconfig and /etc/opt/SUNWconn/atm/laneconfig should not exceed this number. See Supporting Multiple Emulated LANs on a Single Interface.
q93b: warning: link coming back up on <interface>, but ilmid is not running
The link has gone down and come back up on an interface, but ilmid is not running at this time. Register addresses with the switch again, because both the interface and switch must clear out their address tables when the link goes down. Start ilmid; if the interface does not seem to be running properly after doing this, you may need to reboot the system. It is likely that the interface was in an unusual or unknown state when the link came back up, and may need to be taken down completely by rebooting.
| Platform Notes: The SunATM Driver Software | 816-1915-10 | |
Copyright © 2002, Sun Microsystems, Inc. All rights reserved.
