We will first briefly introduce LANE as it was conceived: a LAN technology aimed at emulating a legacy Ethernet network over ATM. We will then cover troubleshooting of the most common problems using this technology:

Troubleshooting LANE Clients not coming up
Troubleshooting LANE connectivity (after LANE Clients are up)

Introduction

LANE is a standard defined by the ATM Forum that provides ATM-attached stations the same capabilities that they normally obtain from legacy Ethernet LANs. As the name suggests, the function of the LANE protocol is to emulate a LAN on top of an ATM network. By making an ATM interface look like one or more separate Ethernet interfaces, LANE enables LAN users to take advantage of ATM's benefits without requiring modifications to end-station hardware or software.

ATM is a connection-oriented service that establishes connections between source and destination devices. LAN-based protocols, on the other hand, are connectionless and use broadcasts so that source devices can find one or more destination devices. The primary purpose of LANE, then, is to provide the same services that a broadcast medium such as Ethernet does.

The LANE protocol resolves MAC addresses to ATM addresses so that LANE end systems can set up direct connections between themselves and then can forward data. The LANE protocol can be deployed in two types of ATM-attached equipment:

Hosts or routers with ATM network interface cards (NICs). ATM NICs implement the LANE protocol and interface to the ATM network while presenting the current Ethernet service interface to the higher-level protocol drivers. The network layer protocols continue to communicate as if they were on an Ethernet by using known procedures. However, they are capable of taking advantage of most of the advanced services of the ATM network.

The second class of network device that implements LANE consists of ATM-attached LAN switches and routers. These devices, together with directly attached ATM hosts equipped with ATM NICs, are used to provide a virtual LAN service in which ports are assigned to particular virtual LANs, independent of physical location.

The LANE specification defines several components that enable the protocol to provide the broadcast and address resolution services required to emulate traditional LANs:

LAN Emulation Client (LEC)—An entity such as a workstation, LAN switch, or router that performs data forwarding and receiving, address resolution, and other control functions for a single endpoint in a single emulated LAN. The LEC provides a standard LAN service to any higher layers that interface to it. A router or switch can have multiple resident LECs, each connecting with different emulated LANs. The LANE client registers its MAC and ATM address with the LES.

LAN Emulation Server (LES)—A server that provides a registration facility for clients to join the emulated LAN. Among other things, the LES handles LAN Emulation Address Resolution Protocol (LE_ARP) requests and maintains a list or lookup table of LAN destination MAC addresses. Each emulated LAN must have a LES.

Broadcast-and-Unknown Server (BUS)—A server that floods unknown destination traffic and that forwards multicast and broadcast traffic to clients within an emulated LAN. Each emulated LAN (ELAN) must have a BUS.

Note In Cisco's LANE implementation, the LES and the BUS are combined.

LAN Emulation Configuration Server (LECS)—A server that assigns individual clients to particular emulated LANs by directing them to the LES that corresponds to the emulated LAN. The LECS can enforce security by restricting ELAN membership to certain LECs based on their MAC addresses. The LECS component, however, is optional in LANE—a client can contact directly the LES to join an emulated LAN.

Troubleshooting a LAN Emulation Network

Though not very complex in theory, the different configurations necessary to implement a LANE network include a lot of long ATM addresses. It becomes easy to insert a typo that will cause the whole setup to fail. Very often, then, troubleshooting a LANE network simply means to have it work! For this reason, this part is split in two sections:

The "Troubleshooting LECs Not Coming Up" section deals with initial configuration issues when it is a matter of bringing up a LEC.
When the initial connection of the LECs is established, the second part, Table 21-2, goes deeper into the troubleshooting of the live network.

Troubleshooting LECs Not Coming Up

The flowchart shown in Figure 21-1 explains which section to use in this section. Issue a show lane client exec command on the device hosting the LEC. Use the field Last Fail Reason, and jump to the corresponding section in next table (the show lane client command is fully described in the section "Understanding the show lane client Output," later in this chapter). If you could not solve your issue by simply following the flowchart, refer to the entry "If None of This Works," in Table 21-1.

Possible Problem	Solution
Cannot connect to the LEC S (config vc being released): Couldn't get our prefix Or Fail to set up config VC: Couldn't create a SETUP message to be sent to the LECS	1. Enter the show lane default command. Check that full ATM addresses are showing up in the output. When the prefix is acquired correctly, you will typically see something like this: ok#sh lane default interface ATM2/0: LANE Client: 47.00918100000001604799FD01.0050A219F038. LANE Server: 47.00918100000001604799FD01.0050A219F039. LANE Bus: 47.00918100000001604799FD01.0050A219F03A. LANE Config Server: 47.00918100000001604799FD01.0050A219F03B.00 note: is the subinterface number byte in hex If not, ". . ." is appearing at the beginning of each address. The output will then look like this: notok#sh lane default interface ATM1/0: LANE Client: ...00000C409820. LANE Server: ...00000C409821. LANE Bus: ...00000C409822. LANE Config Server: ...00000C409823.00 note: is the subinterface number byte in hex 2. Check that the ILMI PVC is configured on your ATM interface. You should have atm pvc <x> 0 16 ilmi in your configuration (where x represents the PVC number—be careful that the VPI may be different from 0). Check also that the PVC used for signaling is also configured: atm pvc <x> 0 5 qsaal. 3. Use the command show atm ilmi-status to check that the ILMI state is up and normal.
Cannot connect to the LECS (config vc being released): Incorrect LECS address	1. Check the LECS ATM address given on the output of show lane client. If it is 47.007900000000000000000000.00A03E000001.00 but you didn't want to use this well-known address, it is probably because the device couldn't get the LECS address via ILMI. If the remote ATM switch is not a Cisco device, be careful—some vendors don't support LECS address advertising via ILMI. In that case, you can use the well-known address on the LECS, for instance. Check on the ATM switch where the client is connected if the LECS address is specified with the command atm lecs-address-default.
Cannot connect to the LECS (config vc being released): Incorrect LECS address (continued)	2. If you hard-coded the LECS ATM address in your configuration, or if you have a valid LECS ATM address that differs from the well-known address in show lane client, go to the device hosting the LECS. Use the show lane config command to compare the LECS address with the one that you see at the client, and check that the server is up and running.
The LECS refuses the connection (receiving negative config response)	1. Check your configuration for the type (Ethernet/Token Ring) and the name of the ELAN that you are trying to join. Connect to the device hosting the LECS, and check whether the name and type of the ELAN match. 2. Check whether the LES could connect to the LECS. On the device hosting the LES, use the command show lane server, and check that the LECS is connected. To connect to the LECS, the LES needs the same information that a simple client would. Refer to the previous entry "Cannot Connect to the LECS."
Couldn't connect to the LES (Control Direct VC being released)	1. If you hard-coded the LES address into the configuration, check on the machine hosting the LES server that its address exactly matches the one that you configured. 2. On the device that hosts the LECS, check that the LECS database entry for this ELAN is set with the right LES address. To know this, go to the device hosting the LES and type show lane default.
The LES refuses the connection (receiving negative join response)	1. If the ELAN to which you are trying to connect is restricted, and if you connect to the LES directly bypassing the LECS, this could be a security issue. Check the LANE database configuration on the LECS to be sure that it includes the ATM address of the client attempting to connect. 2. If you configured on the same subinterface a LEC and a LES, and you also specified the ATM address for the LES with the command lane server-atm-address, the LEC might be trying to contact a backup LES (which refuses the connection). The reason is that the LEC is also using the lane server-atm-address command to decide which LES to contact. It then unconditionally contacts the local LES that may currently be the backup. The easy way of fixing this is to configure the LES on a different subinterface.
If none of this works	A simple configuration problem can, in fact, hide a much deeper issue with the network itself. Enable debug lane client all on your machine, and go to the section " LANE Client Connection Example, with debug lane client all Enabled " to compare to the output of a successful connection." Exercise caution when using debug lane client all. Because debugging output is assigned high priority in the CPU process, it can render the system unusable. It is best to use debug commands during periods of lower network traffic and fewer users. You should avoid sending verbose debugging output to the console (use the logging console info command). Instead, send the debug output to the logging buffer using the command logging buffer <buffer-size> debug.

Possible Problem	Solution
The LE_ARP cannot be completed.	1. Locate an IP address to which you do not have connectivity (that is, an address that you cannot ping). 2. Write down its real MAC address. This information can be obtained from the station itself. 3. Check that indeed there is no mapping between this MAC address and an ATM destination address. You can check this with show lane le-arp. Refer to the section "Understanding the LE_ARP Process," later in this chapter. 4. Likely, there is no connectivity with the destination LEC. Check that the destination LEC is indeed "UP, operational." Refer to the next possible problem, regarding an ELAN split in two parts.
Using SSRP redundancy, the ELAN is split in two parts.	This happens when two clients seem to be up in the same ELAN. In reality, however, they connect to different LES. There is a big connectivity problem in the network. A part of the LECs went down and contacted the backup LECS/LES/BUS. As a result, both LECs are up but cannot communicate. 1. Locate two LANE clients between which you do not have connectivity. Those lane clients are "UP, Operational." 2. Issue a show lane client name <elanname> command on both clients. 3. Check the ATM address in the line with type direct. If the ATM address is different in the two displays, then you do have two separated ELANs. This means that one LES was not reachable on one ELAN and that the backup LES was contacted.
Using SSRP redundancy, the ELAN is split in two parts. (continued)	4. In the LECS database, locate the LES with the highest priority (which is the one listed first in the database). Then find the client that contacted a backup address and could not establish contact with the primary LES. There must be a serious physical issue between this LEC and the primary LES.
Using HSRP, a problem has occurred with the default gateway.	Connectivity seems to work fine, but several users report problems to ping the default gateway several times a day. Each outage is several minutes long. The default gateway is an HSRP virtual IP address. When this happens, third-party devices are often used to connect those users to the ATM network. 1. The first recommendation is to upgrade all devices to the latest release. 2. Another strongly recommended action is to force the usage of the real MAC address on the default gateway. This can be done in configuration interface on the router: RouterName(config-if)#standby use-bia Here, use-bia means to use the burned-in address, not the virtual MAC address. The burned-in address can be seen on the router via the show interface command on the router.
A problem with shaped VP tunnels has occurred.	Sometimes two remote ATM campus networks are linked with a shaped VP tunnel. The network designer must make sure that enough bandwidth is reserved on the link. If the traffic between the two campus site goes above the VP limit, some cells will be discarded, resulting in frames being lost. Generally speaking, when it comes to such a design, routing between the sites is strongly recommended. Troubleshooting this is often tricky. Refer to Chapter 22, "Troubleshooting ATM PVCs in a WAN Environment," for more information. The troubleshooting procedures are the same.
An ATM signaling issue has occurred.	This can be considered as advanced. Connectivity is broken between two LANE clients. They are both "UP, Operational." Even though the le-arp entry is there, the data direct VCC is not established. 1. Locate two LANE Clients between which connectivity is broken. 2. Check that the le-arp entries are both complete and point to the right ATM address. 3. Check that indeed no data direct is established between the LANE Clients. You can check this via show lane client. There is no VC with the type of data.
An ATM signaling issue has occurred. (continued)	4. Enable debug atm sig-error and debug atm errors. Check that when you try to ping, you see an ATM signaling error appearing. Look for "cause code" messages. 5. Those problems are usually seen in a multivendor environment. If Steps 1 through 4 didn't help, upgrade all devices to the latest release.

Figure 21-1: Flowchart Explaining How to Troubleshoot a LEC Not Coming Up

Table 21-1: Troubleshooting LECs Not Coming Up

Possible Problem Solution

Cannot connect to the LEC S (config vc being released):

Couldn't get our prefix

Or

Fail to set up config VC:

Couldn't create a SETUP message to be sent to the LECS

1. Enter the show lane default command. Check that full ATM addresses are showing up in the output. When the prefix is acquired correctly, you will typically see something like this:

ok#sh lane default interface ATM2/0: LANE Client: 47.00918100000001604799FD01.0050A219F038.** LANE Server: 47.00918100000001604799FD01.0050A219F039.** LANE Bus: 47.00918100000001604799FD01.0050A219F03A.** LANE Config Server: 47.00918100000001604799FD01.0050A219F03B.00 note: ** is the subinterface number byte in hex
If not, ". . ." is appearing at the beginning of each address. The output will then look like this:

notok#sh lane default interface ATM1/0: LANE Client: ...00000C409820.** LANE Server: ...00000C409821.** LANE Bus: ...00000C409822.** LANE Config Server: ...00000C409823.00 note: ** is the subinterface number byte in hex

2. Check that the ILMI PVC is configured on your ATM interface. You should have atm pvc <x> 0 16 ilmi in your configuration (where x represents the PVC number—be careful that the VPI may be different from 0). Check also that the PVC used for signaling is also configured: atm pvc <x> 0 5 qsaal.

3. Use the command show atm ilmi-status to check that the ILMI state is up and normal.

Cannot connect to the LECS (config vc being released):

Incorrect LECS address

1. Check the LECS ATM address given on the output of show lane client. If it is 47.007900000000000000000000.00A03E000001.00 but you didn't want to use this well-known address, it is probably because the device couldn't get the LECS address via ILMI.

If the remote ATM switch is not a Cisco device, be careful—some vendors don't support LECS address advertising via ILMI. In that case, you can use the well-known address on the LECS, for instance.

Check on the ATM switch where the client is connected if the LECS address is specified with the command atm lecs-address-default.

Cannot connect to the LECS (config vc being released):

Incorrect LECS address (continued)

2. If you hard-coded the LECS ATM address in your configuration, or if you have a valid LECS ATM address that differs from the well-known address in show lane client, go to the device hosting the LECS. Use the show lane config command to compare the LECS address with the one that you see at the client, and check that the server is up and running.

The LECS refuses the connection (receiving negative config response)

1. Check your configuration for the type (Ethernet/Token Ring) and the name of the ELAN that you are trying to join. Connect to the device hosting the LECS, and check whether the name and type of the ELAN match.

2. Check whether the LES could connect to the LECS. On the device hosting the LES, use the command show lane server, and check that the LECS is connected. To connect to the LECS, the LES needs the same information that a simple client would. Refer to the previous entry "Cannot Connect to the LECS."

Couldn't connect to the LES (Control Direct VC being released)

1. If you hard-coded the LES address into the configuration, check on the machine hosting the LES server that its address exactly matches the one that you configured.

2. On the device that hosts the LECS, check that the LECS database entry for this ELAN is set with the right LES address. To know this, go to the device hosting the LES and type show lane default.

The LES refuses the connection (receiving negative join response)

1. If the ELAN to which you are trying to connect is restricted, and if you connect to the LES directly bypassing the LECS, this could be a security issue. Check the LANE database configuration on the LECS to be sure that it includes the ATM address of the client attempting to connect.

2. If you configured on the same subinterface a LEC and a LES, and you also specified the ATM address for the LES with the command lane server-atm-address, the LEC might be trying to contact a backup LES (which refuses the connection). The reason is that the LEC is also using the lane server-atm-address command to decide which LES to contact. It then unconditionally contacts the local LES that may currently be the backup. The easy way of fixing this is to configure the LES on a different subinterface.

If none of this works

A simple configuration problem can, in fact, hide a much deeper issue with the network itself. Enable debug lane client all on your machine, and go to the section " LANE Client Connection Example, with debug lane client all Enabled " to compare to the output of a successful connection." Exercise caution when using debug lane client all. Because debugging output is assigned high priority in the CPU process, it can render the system unusable. It is best to use debug commands during periods of lower network traffic and fewer users. You should avoid sending verbose debugging output to the console (use the logging console info command). Instead, send the debug output to the logging buffer using the command logging buffer <buffer-size> debug.

Table 21-2: Troubleshooting LANE Connectivity When LECs Are Up

Possible Problem Solution

The LE_ARP cannot be completed.

1. Locate an IP address to which you do not have connectivity (that is, an address that you cannot ping).

2. Write down its real MAC address. This information can be obtained from the station itself.

3. Check that indeed there is no mapping between this MAC address and an ATM destination address. You can check this with show lane le-arp. Refer to the section "Understanding the LE_ARP Process," later in this chapter.

4. Likely, there is no connectivity with the destination LEC. Check that the destination LEC is indeed "UP, operational." Refer to the next possible problem, regarding an ELAN split in two parts.

Using SSRP redundancy, the ELAN is split in two parts.

This happens when two clients seem to be up in the same ELAN. In reality, however, they connect to different LES. There is a big connectivity problem in the network. A part of the LECs went down and contacted the backup LECS/LES/BUS. As a result, both LECs are up but cannot communicate.

1. Locate two LANE clients between which you do not have connectivity. Those lane clients are "UP, Operational."

2. Issue a show lane client name <elanname> command on both clients.

3. Check the ATM address in the line with type direct. If the ATM address is different in the two displays, then you do have two separated ELANs. This means that one LES was not reachable on one ELAN and that the backup LES was contacted.

Using SSRP redundancy, the ELAN is split in two parts. (continued)

4. In the LECS database, locate the LES with the highest priority (which is the one listed first in the database). Then find the client that contacted a backup address and could not establish contact with the primary LES. There must be a serious physical issue between this LEC and the primary LES.

Using HSRP, a problem has occurred with the default gateway.

Connectivity seems to work fine, but several users report problems to ping the default gateway several times a day. Each outage is several minutes long. The default gateway is an HSRP virtual IP address. When this happens, third-party devices are often used to connect those users to the ATM network.

1. The first recommendation is to upgrade all devices to the latest release.

2. Another strongly recommended action is to force the usage of the real MAC address on the default gateway. This can be done in configuration interface on the router:

RouterName(config-if)#standby use-bia

Here, use-bia means to use the burned-in address, not the virtual MAC address. The burned-in address can be seen on the router via the show interface command on the router.

A problem with shaped VP tunnels has occurred.

Sometimes two remote ATM campus networks are linked with a shaped VP tunnel. The network designer must make sure that enough bandwidth is reserved on the link. If the traffic between the two campus site goes above the VP limit, some cells will be discarded, resulting in frames being lost.

Generally speaking, when it comes to such a design, routing between the sites is strongly recommended.

Troubleshooting this is often tricky. Refer to Chapter 22, "Troubleshooting ATM PVCs in a WAN Environment," for more information. The troubleshooting procedures are the same.

An ATM signaling issue has occurred.

This can be considered as advanced. Connectivity is broken between two LANE clients. They are both "UP, Operational." Even though the le-arp entry is there, the data direct VCC is not established.

1. Locate two LANE Clients between which connectivity is broken.

2. Check that the le-arp entries are both complete and point to the right ATM address.

3. Check that indeed no data direct is established between the LANE Clients. You can check this via show lane client. There is no VC with the type of data.

An ATM signaling issue has occurred. (continued)

4. Enable debug atm sig-error and debug atm errors. Check that when you try to ping, you see an ATM signaling error appearing. Look for "cause code" messages.

5. Those problems are usually seen in a multivendor environment. If Steps 1 through 4 didn't help, upgrade all devices to the latest release.

Annex: Commands and Examples

In this section, we'll give examples of the most common ebug and show commands used when troubleshooting LANE.

LANE Client Connectio n Example, with debug lane client all Enabled

Figure 21-2 shows VCs required for LANE to work.

Figure 21-2: Example of VCs Required for LANE to Work

This is the sequence of events that needs to happen for LEC to come up from LEC's perspective, which is shown in debug lane client all:

1. Configure direct (3-11)

2. Control direct (1-7)

3. Control distribute (2-8)

4. Multicast send (4-9)

5. Multicast forward (5-10)

6. Data direct (6-6), LEC to LEC, is not shown in this debug output

ATM Addresses Used in This debug Output

The ATM addresses of the LECS/LES/BUS/LEC used in this example are shown below.

LECS    47.00918100000000603E899601.00E01E2EE8B3.00
LES     47.00918100000000603E899601.00E01E2EE8B1.01
BUS     47.00918100000000603E899601.00E01E2EE8B2.01
LEC     47.00918100000000603E899601.00E01E2EE8B0.01
ELAN Name      Elan1

Address Registration via ILMI

The LEC first registers its ATM address with the ATM network.

LEC ATM0.1: action A_REGISTER_ADDR
LEC ATM0.1: predicate PRED_LEC_NSAP TRUE
LEC ATM0.1: state IDLE event LEC_LOCAL_ACTIVATE => REGISTER_ADDR
LEC ATM0.1: action A_POST_LISTEN
LEC ATM0.1: sending LISTEN
LEC ATM0.1: listen on 47.00918100000000603E899601.00E01E2EE8B0.01
LEC ATM0.1: state REGISTER_ADDR event LEC_CTL_ILMI_SET_RSP_POS => POSTING_LISTEN
LEC ATM0.1: received LISTEN
LEC ATM0.1: action A_ACTIVATE_LEC
LEC ATM0.1: predicate PRED_CTL_DIRECT_NSAP FALSE
LEC ATM0.1: predicate PRED_LECS_NSAP FALSE
LEC ATM0.1: state POSTING_LISTEN event LEC_SIG_LISTEN_POS => GET_LECS_ADDR
LEC ATM0.1: action A_ALLOC_LECS_ADDR
LEC ATM0.1: state GET_LECS_ADDR event LEC_CTL_ILMI_SET_RSP_POS => GET_LECS_ADDR

Connecting to LECS (Configure Direct)

The LEC sets up a connection to LECS (bidirectional point-to-point VC) to find the ATM address of the LES for its ELAN. When this is done, this VC to the LECS is released.

The LEC finds the LECS ATM address by using three methods, in this order:

1. Using hard-coded ATM address

2. Getting the LECS via ILMI VPI=0, VCI=16 (not supported by some vendors)

3. Fixing the address defined by the ATM Forum: (47.007900000000000000000000.00A03E000001.00)

Using the same VCC, the LECS returns the ATM address of the LES for the LEC ELAN.

In this debug output, the LEC is getting LECS address via ILMI:

LEC ATM0.1: action A_SEND_LECS_SETUP
LEC ATM0.1: sending SETUP
LEC ATM0.1:   callid            0x40518C04
LEC ATM0.1:   called party      47.00918100000000603E899601.00E01E2EE8B3.00  LECS address 
LEC ATM0.1:   calling_party     47.00918100000000603E899601.00E01E2EE8B0.01  LEC address
LEC ATM0.1: state GET_LECS_ADDR event LEC_CTL_ILMI_SET_RSP_NEG => LECS_CONNECT
 
LEC ATM0.1: received CONNECT
LEC ATM0.1:   callid            0x40518C04
LEC ATM0.1:   vcd               884
LEC ATM0.1: action A_SEND_CFG_REQ
LEC ATM0.1: sending LANE_CONFIG_REQ on VCD 884
LEC ATM0.1:   SRC MAC address   00e0.1e2e.e8b0      LEC's MAC address
LEC ATM0.1:   SRC ATM address   47.00918100000000603E899601.00E01E2EE8B0.01
LEC ATM0.1:   LAN Type  1
LEC ATM0.1:   Frame size        1
LEC ATM0.1:   LAN Name  elan1      elan LEC is trying to join
LEC ATM0.1:   LAN Name size     5
LEC ATM0.1: state LECS_CONNECT event LEC_SIG_CONNECT => GET_LES_ADDR
LEC ATM0.1: received LANE_CONFIG_RSP on VCD 884
LEC ATM0.1:   SRC MAC address   00e0.1e2e.e8b0
LEC ATM0.1:   SRC ATM address   47.00918100000000603E899601.00E01E2EE8B0.01
LEC ATM0.1:   LAN Type  1
LEC ATM0.1:   Frame size        1
LEC ATM0.1:   LAN Name  elan1                           
LEC ATM0.1:   LAN Name size     5
 
LEC ATM0.1: action A_PROCESS_CFG_RSP
LEC ATM0.1: sending RELEASE
LEC ATM0.1:   callid            0x40518C04
LEC ATM0.1:   cause code        31
 
LEC ATM0.1: state GET_LES_ADDR event LEC_CTL_CONFIG_RSP_POS => LECS_RELEASE
LEC ATM0.1: received RELEASE_COMPLETE
LEC ATM0.1:   callid            0x40518C04
LEC ATM0.1:   cause code        16

Connecting to LES (Control Direct) and Back from LES (Control Distribute)

In the next step, the LEC establishes a VC to the LES (called the control direct). It then waits for the LES to add itself to the multipoint VC between the LES and all LECs (called the control distribute).

The LEC sets up a connection to the LES for its ELAN (bidirectional point-to-point VC).
The LES maintains a VC (server configure) to the LECS (not shown in debug because it is not a LEC action) to verify whether the LEC is allowed to join the ELAN. Notice that the join request contains the LEC MAC address, its ATM address, and the name of the ELAN.
If allowed, the LES adds the LEC to the unidirectional point-to-multipoint control distribute VC and confirms the join over the control direct VC.

LEC ATM0.1: action A_SEND_LES_SETUP
LEC ATM0.1: sending SETUP        Control Direct (LEC to LES)
LEC ATM0.1:   callid            0x40518E74
LEC ATM0.1:   called party      47.00918100000000603E899601.00E01E2EE8B1.01  LES address
LEC ATM0.1:   calling_party     47.00918100000000603E899601.00E01E2EE8B0.01  LEC address
 
LEC ATM0.1: state LECS_RELEASE event LEC_SIG_RELEASE_COMP => CTL_DIRECT_CONN
 
LEC ATM0.1: received CONNECT
LEC ATM0.1:   callid            0x40518E74
LEC ATM0.1:   vcd               889
 
LEC ATM0.1: action A_SEND_JOIN_REQ
LEC ATM0.1: sending LANE_JOIN_REQ on VCD 889
LEC ATM0.1:   Status            0
LEC ATM0.1:   LECID             0
LEC ATM0.1:   SRC MAC address   00e0.1e2e.e8b0
LEC ATM0.1:   SRC ATM address   47.00918100000000603E899601.00E01E2EE8B0.01
LEC ATM0.1:   LAN Type  1
LEC ATM0.1:   Frame size        1
LEC ATM0.1:   LAN Name  elan1                           
LEC ATM0.1:   LAN Name size     5
 
LEC ATM0.1: state CTL_DIRECT_CONN event LEC_SIG_CONNECT => JOIN_CTL_DIST_CONN
 
LEC ATM0.1: received SETUP      Control Distribute (LES to LEC)
LEC ATM0.1:   callid            0x404DC0A8
LEC ATM0.1:   called party      47.00918100000000603E899601.00E01E2EE8B0.01
LEC ATM0.1:   calling_party     47.00918100000000603E899601.00E01E2EE8B1.01
 
LEC ATM0.1: action A_PROCESS_CTL_DIST_SETUP
LEC ATM0.1: sending CONNECT
LEC ATM0.1:   callid            0x404DC0A8
LEC ATM0.1:   vcd               890
 
LEC ATM0.1: state JOIN_CTL_DIST_CONN event LEC_SIG_SETUP => JOIN
 
LEC ATM0.1: received CONNECT_ACK
 
LEC ATM0.1: state JOIN event LEC_SIG_CONNECT_ACK => JOIN
 
LEC ATM0.1: received LANE_JOIN_RSP on VCD 889
LEC ATM0.1:   Status            0
LEC ATM0.1:   LECID             1
LEC ATM0.1:   SRC MAC address   00e0.1e2e.e8b0
LEC ATM0.1:   SRC ATM address   47.00918100000000603E899601.00E01E2EE8B0.01
LEC ATM0.1:   LAN Type  1
LEC ATM0.1:   Frame size        1
LEC ATM0.1:   LAN Name  elan1                           
LEC ATM0.1:   LAN Name size     5

Obtaining BUS Address

In the next step, the LEC establishes a VC to the BUS (called the multicast send). It then waits for the BUS to add itself to the multipoint VC between the BUS and all LECs (called the multicast forward).

The LEC sends an LE_ARP request for the broadcast address (all ones) to the LES.
The LES returns an LE_ARP response with the ATM address of the BUS.
The LEC then sets up the multicast send VC to the BUS.
The BUS adds the LEC to the multicast forward VC.

LEC ATM0.1: action A_PROCESS_JOIN_RSP_SEND_REQ
LEC ATM0.1: sending LANE_ARP_REQ on VCD 889
LEC ATM0.1:   SRC MAC address     00e0.1e2e.e8b0
LEC ATM0.1:   SRC ATM address     47.00918100000000603E899601.00E01E2EE8B0.01 LES address
LEC ATM0.1:   TARGET MAC address  ffff.ffff.ffff                              Broadcast address
LEC ATM0.1:   TARGET ATM address  00.000000000000000000000000.000000000000.00 NSAP address is empty
 
LEC ATM0.1: state JOIN event LEC_CTL_JOIN_RSP_POS => GET_BUS_ADDR
 
LEC ATM0.1: received LANE_ARP_RSP on VCD 890
LEC ATM0.1:   SRC MAC address     00e0.1e2e.e8b0
LEC ATM0.1:   SRC ATM address     47.00918100000000603E899601.00E01E2EE8B0.01
LEC ATM0.1:   TARGET MAC address  ffff.ffff.ffff
LEC ATM0.1:   TARGET ATM address  47.00918100000000603E899601.00E01E2EE8B2.01 BUS address is filled in
 
LEC ATM0.1: action A_SEND_BUS_SETUP
LEC ATM0.1: predicate PRED_MCAST_SEND_NSAP FALSE
 
LEC ATM0.1: sending SETUP       Mulitcast Send (LEC to BUS)
LEC ATM0.1:   callid            0x40506F14
LEC ATM0.1:   called party      47.00918100000000603E899601.00E01E2EE8B2.01
LEC ATM0.1:   calling_party     47.00918100000000603E899601.00E01E2EE8B0.01
 
LEC ATM0.1: state GET_BUS_ADDR event LEC_CTL_ARP_RSP => MCAST_SEND_FORWARD_CONN
 
LEC ATM0.1: received CONNECT
LEC ATM0.1:   callid            0x40506F14
LEC ATM0.1:   vcd               893
 
LEC ATM0.1: action A_PROCESS_BUS_CONNECT
 
LEC ATM0.1: state MCAST_SEND_FORWARD_CONN event LEC_SIG_CONNECT => MCAST_FORWARD_CONN
 
LEC ATM0.1: received SETUP      Mulitcast Forward (BUS to LEC) 
LEC ATM0.1:   callid            0x4051B580
LEC ATM0.1:   called party      47.00918100000000603E899601.00E01E2EE8B0.01
LEC ATM0.1:   calling_party     47.00918100000000603E899601.00E01E2EE8B2.01
 
LEC ATM0.1: action A_SEND_BUS_CONNECT
 
LEC ATM0.1: sending CONNECT
LEC ATM0.1:   callid            0x4051B580
LEC ATM0.1:   vcd               894
 
LEC ATM0.1: state MCAST_FORWARD_CONN event LEC_SIG_SETUP => ACTIVE
LEC ATM0.1: received CONNECT_ACK
LEC ATM0.1: action A_PROCESS_CONNECT_ACK
LEC ATM0.1: state ACTIVE event LEC_SIG_CONNECT_ACK => ACTIVE

LANE Client Is Operational

After all these steps have been completed, the LEC is UP and Operational. We can see this using the following command:

Cat5000_LANE>#show lane client
LE Client ATM0.1  ELAN name: elan1  Admin: up  State: operational
Client ID: 1                 LEC up for 10 minutes 0 second 
Join Attempt: 759            
HW Address: 00e0.1e2e.e8b0   Type: ethernet             Max Frame Size: 1516
          VLANID: 100                  
ATM Address: 47.00918100000000603E899601.00E01E2EE8B0.01
 
 VCD  rxFrames  txFrames  Type       ATM Address
   0         0         0  configure 47.00918100000000603E899601.00E01E2EE8B3.00
 889         1         2  direct    47.00918100000000603E899601.00E01E2EE8B1.01
 890         4         0  distribute47.00918100000000603E899601.00E01E2EE8B1.01
 893         0       317  send      47.00918100000000603E899601.00E01E2EE8B2.01
 894         9         0  forward   47.00918100000000603E899601.00E01E2EE8B2.01

Understanding the show lane client Output

This command is by far the most important when it comes to LANE troubleshooting. On the TAC page, the Output Interpreter will decode the output for you. We will describe the most important fields here.

Let's focus on the following output:

Gambrinus#sh lane client
LE Client ATM2/0/0  ELAN name: default  Admin: up  State: operational
Client ID: 2                 LEC up for 15 minutes 39 seconds 
ELAN ID: 1
Join Attempt: 691            
Last Fail Reason: Control Direct VC being released
HW Address: 0060.4750.8402   Type: ethernet             Max Frame Size: 1516  
ATM Address: 47.009181000000006047508401.006047508402.00
 
 VCD  rxFrames  txFrames  Type       ATM Address
   0         0         0  configure  47.009181000000006047508401.006047508405.00
 256         1        10  direct     47.009181000000006047508401.000000000002.01
 257       476         0  distribute 47.009181000000006047508401.000000000002.01
 258         0        56  send       47.009181000000006047508401.000000000003.01
 259         2         0  forward    47.009181000000006047508401.000000000003.01
 263         1        18  data       47.009181000000006047508401.006047508402.00

1. LE Client ATM2/0/0 ELAN name: default Admin: up State: operational

: We can see that the client is administratively up and is operational. As we've seen earlier in this chapter, this is the right state; it is up and running.

2. Client ID: 2 LEC up for 15 minutes, 39 seconds

: The only thing to keep in mind here is that the LEC is up for only 15 minutes. Is this normal? Did a maintenance action happen 15 minutes ago?

3. Join Attempt: 691

: Although scary, this does not necessarily indicate that the LEC went down 691 times. The LECS/LES was perhaps unreachable for a long amount of time.

4. Last Fail Reason: Control Direct VC being released

: This precious field indicates that the last reason for which the LEC could not reach the "UP/Operational" state was because it could not reach the LES

5. ATM Address: 47.009181000000006047508401.006047508402.0

: This is interesting only when we check other LECs' sh lane client to find that the remote side of a data direct is this station.

6. 0 0 0 configure 47.009181000000006047508401.006047508405.00

: This line gives detail on the connection to the LECS; this VCC is called the configure direct, as the Type field suggests. The VCD number is 0 because the connection is torn down, per the spec.

7. 256 1 10 direct 47.009181000000006047508401.000000000002.01

: This line gives details on the connection to the LES; this VCC is called the control direct, as suggested by the Type field.

8. 257 476 0 distribute 47.009181000000006047508401.000000000002.01

: This line gives details on the connection from the LES to all LECs. It is called the control distribute. We can see that the LES address is the same for the control direct and control distribute, as it should be.

9. 258 0 56 send 47.009181000000006047508401.000000000003.01

: This line gives details on the connection to the BUS. It is called multicast send, as the Type field suggests.

10. 259 2 0 forward 47.009181000000006047508401.000000000003.01

: This line gives details on the connection from the BUS to all LECs. It is called multicast forward. We can see that the BUS address is the same for the multicast send and multicast forward.

11. 263 1 18 data 47.009181000000006047508401.006047508402.00

: The remaining lines give details on each data direct VCC. Refer to the section "Understanding the LE_ARP Process" for more details.

Understanding the LE_ARP Process

The LAN Emulation Address Resolution Protocol is one of the most important in LANE. When a LEC must forward a unicast frame (that is, a frame with the destination MAC address set to the real MAC address), it should not forward it to the BUS.

Practically, it will try to create a mapping between this destination MAC address and the ATM address of the LEC to be contacted to reach this station. The LEC can be a LANE module, a router, or a directly attached station. This process is called LE_ARP. Waiting for this process to complete, the source LEC will forward the traffic to the BUS as unknown traffic.

Let's examine this in details. Say that we have the following topology:

IP station-----(ethernet connection)-----catalyst----(ATM lane module)------ls1010

10.200.10.61

As you can see, the LANE Client is up and operational:

Gambrinus#sh lane client
LE Client ATM2/0/0  ELAN name: default  Admin: up  State: operational
Client ID: 2                 LEC up for 12 minutes 26 seconds 
ELAN ID: 1
Join Attempt: 10             
Last Fail Reason: Control Direct VC being released
HW Address: 0060.4750.8402   Type: ethernet             Max Frame Size: 1516  
ATM Address: 47.009181000000006047508401.006047508402.00
 
 VCD  rxFrames  txFrames  Type       ATM Address
   0         0         0  configure  47.009181000000006047508401.006047508405.00
  94        15       109  direct     47.009181000000006047508401.000000000002.01
  95      1015         0  distribute 47.009181000000006047508401.000000000002.01
  96         0       202  send       47.009181000000006047508401.000000000003.01
  97       105         0  forward    47.009181000000006047508401.000000000003.01

Say that we want to contact the station 10.200.10.62:

Gambrinus#ping 10.200.10.62

From the user point of view, it works, and nothing special can be seen:

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.200.10.62, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

If we enabled debug lane client packet, we would have seen the details of the process. That is, the LEC sends an LE_ARP request to the LES and waits for the response with the ATM address to be used.

<snip>
*Mar 22 02:32:46.499: LEC ATM2/0/0: sending LANE_ARP_REQ on VCD 94
*Mar 22 02:32:46.499: LEC ATM2/0/0:   LECID             2
*Mar 22 02:32:46.499: LEC ATM2/0/0:   SRC MAC address     0060.4750.8402
*Mar 22 02:32:46.499: LEC ATM2/0/0:   SRC ATM address     47.0091810000000060470
*Mar 22 02:32:46.499: LEC ATM2/0/0:   TARGET MAC address  00e0.b012.17ff
*Mar 22 02:32:46.499: LEC ATM2/0/0:   TARGET ATM address  00.0000000000000000000
*Mar 22 02:32:46.499: LEC ATM2/0/0:   Flags             0x0
*Mar 22 02:32:46.499: LEC ATM2/0/0:   num of TLVs         0
<snip>
*Mar 22 02:32:46.515: LEC ATM2/0/0: received LANE_ARP_RSP on VCD 95
*Mar 22 02:32:46.515: LEC ATM2/0/0:   LECID             2
*Mar 22 02:32:46.515: LEC ATM2/0/0:   SRC MAC address     00e0.b012.17ff
*Mar 22 02:32:46.515: LEC ATM2/0/0:   SRC ATM address     47.0091810000000060471
*Mar 22 02:32:46.515: LEC ATM2/0/0:   TARGET MAC address  0060.4750.8402
*Mar 22 02:32:46.515: LEC ATM2/0/0:   TARGET ATM address  47.0091810000000060470
*Mar 22 02:32:46.515: LEC ATM2/0/0:   Flags             0x0
*Mar 22 02:32:46.515: LEC ATM2/0/0:   num of TLVs         0
<snip>

When the LEC receives the reply, it sets up a virtual channel connection (VCC) directly to this ATM address. This VCC is called data direct VCC. Any frame that needs to be sent to this destination MAC address will be forwarded on this VCC.

To ensure that no frame is left on the delivery path through the BUS when the data direct VCC becomes active, a mechanism called FLUSH is used. Still with debug lane client packet, we can see more details of the FLUSH process.

*Mar 22 02:32:46.627: LEC ATM2/0/0: sending LANE_FLUSH_REQ on VCD 96
<snip>
*Mar 22 02:32:46.633: LEC ATM2/0/0: received LANE_FLUSH_RSP on VCD 95

The result of the LE_ARP process is saved and can be checked:

Gambrinus#sh lane le-arp 
Active le-arp entries: 1
 
Hardware Addr   ATM Address                                  VCD  Interface
00e0.b012.17ff  47.009181000000006047508401.000000000001.01  100  ATM2/0/0

If we check the ARP table on the source IP station, we can see that the right MAC address was taken in account.

<snip>
Gambrinus#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.200.10.62           20   00e0.b012.17ff  ARPA   ATM2/0/0
<snip>

And, most interesting, the output of show lane client has changed. You can see that there is a new VCC and that traffic is flowing on it. It remains up as long as there is traffic over it. The default timeout is 300 seconds without activity.

Gambrinus#sh lane client
LE Client ATM2/0/0  ELAN name: default  Admin: up  State: operational
Client ID: 2                 LEC up for 13 minutes 15 seconds 
ELAN ID: 1
Join Attempt: 10             
Last Fail Reason: Control Direct VC being released
HW Address: 0060.4750.8402   Type: ethernet             Max Frame Size: 1516  
ATM Address: 47.009181000000006047508401.006047508402.00
 
 VCD  rxFrames  txFrames  Type       ATM Address
   0         0         0  configure  47.009181000000006047508401.006047508405.00
  94        15       115  direct     47.009181000000006047508401.000000000002.01
  95      1384         0  distribute 47.009181000000006047508401.000000000002.01
  96         0       232  send       47.009181000000006047508401.000000000003.01
  97       112         0  forward    47.009181000000006047508401.000000000003.01
  99         1         2  data       47.009181000000006047508401.000000000001.01

Additional Commands

The following show commands are the most useful for troubleshooting LANE.

show lane
show lane client
show lane server
show lane config
show lane default
show atm ilmi-status

Before Calling Cisco Systems' TAC Team

Before calling the Cisco Systems Technical Assistance Center (TAC), make sure that you have read through this chapter and completed the actions suggested for your system's problem.

Additionally, do the following and document the results so that we can better assist you:

If the problem is that a LANE Client cannot reach the "UP, operational" state (that is, the LANE Client is down or cannot join the ELAN), locate which service (LES, LECS, BUS) is preventing the LEC to go up.
Create a map of your network clearly indicating the location of the LECS/LES/BUS.
Take the output of show lane on every key device. That is where the active LECS/LES/BUS elements are and where the LANE Clients giving problems are.
If you are using a VP tunnel to a remote site, provide the contract details for this VP.

Additional Sources of Information

Cisco LAN Switching (CCIE Professional Development), Cisco Press
www.cisco.com/tac (check the ATM section in the Technology Home Page)
www.atmforum.com/ (includes a lot of standards that can be downloaded for free)
www.techfest.com/networking

www.protocols.com/

cell-relay.indiana.edu/

news:comp.dcom/cell-relay (archived in http:// cell-relay.indiana.edu/)

Table of Contents