Testing the LANE Configuration | Cisco Catalyst LAN Switching

At this point, you should have a working LANE configuration. Use the show lane client command to troubleshoot your configuration it is a deceptively powerful and useful command. Notice that, for two reasons, I recommend using show lane client before you even try a ping. First, the LANE module does not have a ping command (requiring that you use the exit command to return to the Supervisor). Second, show lane client provides much more useful information.

Example 9-13 demonstrates the show lane client display from a working configuration.

Example 9-13 show lane client Command Output

 ATM#show lane client LE Client ATM0.1  ELAN name: ELAN1  Admin: up  State: operational Client ID: 3                 LEC up for 8 seconds Join Attempt: 1 HW Address: 0010.2962.e430   Type: ethernet             Max Frame Size: 1516         VLANID: 1 ATM Address: 47.00918100000000102962E801.00102962E430.01  VCD  rxFrames  txFrames  Type       ATM Address    0         0         0  configure  47.00918100000000102962E801.00102962E433.00   22         1         3  direct     47.00918100000000102962E801.00102962E431.01   23         7         0  distribute 47.00918100000000102962E801.00102962E431.01   25         0         1  send       47.00918100000000102962E801.00102962E432.01   26         6         0  forward    47.00918100000000102962E801.00102962E432.01

The breakdown for the output in Example 9-13 is as follows:

The first line (after the show lane client command, of course) shows the subinterface, the ELAN name, whether the LEC is administratively up, and whether the LEC is in an operational state.
The second line shows the LEC-ID assigned by the LES to this LEC and how long the LEC has been active.
The third line displays how many attempts it took the LEC to join (in some cases, this information might appear at the end of the second line).
The fourth line shows the MAC address being used by the Client (it should tie to the first line in show lane default), whether the LEC is an Ethernet or Token Ring Client, and the MTU being used.
The VLAN mapped to the ELAN specified in the first line generally wraps on the display to be shown on the fifth line.
The sixth line shows the NSAP address being used by the LEC (if you have used the auto-NSAP addresses, it should include the MAC address on line four as the ESI).
The remaining output shows the five overhead connections created during the joining process. Notice that they are shown in the order they are created. Remember to use this great reference tool when you forget the joining order! Each line shows the VCD currently in use for that connection, the number of frames transmitted and received on that connection, the name of the connection (abbreviated), and the NSAP of the device at the other end of the connection. Notice that the Configuration Direct VC to the Configuration Server has a VCD of 0. This reflects the fact that Cisco closes this control connection as soon as the LECS has provided the NSAP of the LES. As Data Direct VCs are built, they appear as additional lines after the five overhead VCs.

Tip

Use the show lane client command to remember the order of the LANE joining process.

There are several items in Example 9-13 showing that the LEC has successfully joined the ELAN:

The State is operational.
The LEC has been up for eight seconds.
All five overhead VCs have valid NSAPs listed.

Example 9-14 shows a common failure condition.

Example 9-14 LEC Failure

 ATM#show lane client LE Client ATM0.1  ELAN name: ELAN1  Admin: up  State: initialState Client ID: unassigned        Next join attempt in 9 seconds  Join Attempt: 7 Last Fail Reason: Config VC being released HW Address: 0010.2962.e430   Type: ethernet             Max Frame Size: 1516         VLANID: 1 ATM Address: 47.00918100000000102962E801.00102962E430.01  VCD  rxFrames  txFrames  Type       ATM Address    0         0         0  configure  47.007900000000000000000000.00A03E000001.00    0         0         0  direct     00.000000000000000000000000.000000000000.00    0         0         0  distribute 00.000000000000000000000000.000000000000.00    0         0         0  send       00.000000000000000000000000.000000000000.00    0         0         0  forward    00.000000000000000000000000.000000000000.00

Several sections of the output in Example 9-14 point to the failure, including:

The State is initialState.
The LEC attempts to join again in nine seconds.
A Last Fail Reason is provided.
Only the first VC (the Configuration Direct) lists a non-zero NSAP.

Because the first line represents the Configuration Direct to the LECS, the information in this display is strong evidence of a problem very early in the joining process. Also look carefully at the NSAP for the Configuration Direct it is the well-known NSAP. Because Cisco uses the well-known NSAP as a last gasp effort to contact the LECS if all other measures have failed, it is often a sign that the join process failed. In fact, this display is almost always the result of three specific errors:

The ATM switch provided the wrong NSAP (or no NSAP) for the LECS When the LEC contacted the device specified by this NSAP and tried to begin the joining process, it was rudely told the equivalent of "Join an ELAN?? I don't know what you are talking about!" Look at the atm lecs-address-default command on the LS1010 to verify and fix this problem.
The LEC was given the correct NSAP address LECS, but the LECS is down In this case, the Client contacted the correct devices, but it was still rebuffed because the LECS couldn't yet handle LE_CONFIGURE_REQUESTS (the message sent between Clients and LECSs). Look at the configuration of the LECS to verify and fix this problem. The show lane config command is often useful for this purpose.
The LEC requested an ELAN that doesn't exist To verify this condition, issue a terminal monitorcommand on the LANE module to display error messages. If you see "CFG_REQ failed, no configuration (LECS returned 20)" messages, use the show lane client command to check the ELAN name. Make certain that this ELAN name is identical to one of the ELANs displayed in show lane database on the LECS. Carefully check for incorrect case ELAN names are case sensitive.

The output in Example 9-15 shows the results of an LEC that made it past contacting the LECS but has run into problems contacting the LES.

Example 9-15 LEC Can't Contact LES

 ATM#show lane client LE Client ATM0.1  ELAN name: ELAN1  Admin: up  State: initialState Client ID: unassigned        Next join attempt in 10 seconds Join Attempt: 8 Last Fail Reason: Control Direct VC being released HW Address: 0010.2962.e430   Type: ethernet             Max Frame Size: 1516       VLANID: 1 ATM Address: 47.00918100000000102962E801.00102962E430.01  VCD  rxFrames  txFrames  Type       ATM Address    0         0         0  configure  47.00918100000000102962E801.00102962E433.00    0         0         0  direct     47.00918100000000102962E801.00102962E431.01    0         0         0  distribute 00.000000000000000000000000.000000000000.00    0         0         0  send       00.000000000000000000000000.000000000000.00    0         0         0  forward    00.000000000000000000000000.000000000000.00

The output in Example 9-15 shows most of the same symptoms as the output in Example 9-14; however, the first two overhead connections have NSAPs listed. For two reasons, this pair of overhead connections proves that the LEC successfully reached the LECS. First, the Configuration Direct (first overhead circuit) lists the correct NSAP for the LECS. Second, the LEC could not have attempted a call to the LES (second overhead circuit) without having received an NSAP from the LECS. In this case, the LEC called the LES (Control Direct, second VC), but the LES didn't call the LEC back (Control Distribute, third VC). This diagnosis is further supported by the Last Fail Reason indicating "Control Direct VC being released." In almost all cases, one of two problems is the cause:

The LEC received the incorrect NSAP address for the LES from the LECS The LEC again "jumped off in the weeds" and called the wrong device only to receive an "I don't know what you're talking about!" response. Use the show lane database command on the LECS to verify LES' NSAP addresses for the appropriate ELAN. If necessary, correct the LECS database.
The LEC was given the right NSAP address for the LES, but the LES is down The LEC called the correct device, but the device was not a functioning LES. Verify the problem with the show lane server command on the LES (make certain that the LES is operational). If necessary, adjust the LES configuration parameters.

It is very uncommon to have a problem with only the Multicast Send and Multicast Forward VCs on Cisco equipment. Such behavior suggests a problem with the BUS: either the LES provided the wrong NSAP for the BUS or the BUS was not active. Because Cisco requires that the LES and BUS be co-located, the BUS should always be reachable if the LES is reachable. However, if you are using a third-party device for the LES and BUS, it is possible to run into this problem.

If you are still not able to successfully join the ELAN, consult the more detailed information given in Chapter 16, "Troubleshooting." Chapter 16 explores additional troubleshooting techniques.