Advanced LANE Issues and Features

Advanced LANE Issues and Features

This section explores several advanced issues that might be relevant in large LANE networks, including the following:

  • Where to run LANE services
  • Using hard-coded addresses
  • SSRP
  • Dual-PHY
  • Using the well-known NSAP for LECS discovery
  • PVCs and traffic shaping

Where to Run LANE Services

One of the first questions facing most implementers of LANE is “Where should I locate my three server components (LECS, LES, and BUS)?”

Because the LECS function is a very low-CPU function, you have a fair amount of latitude in terms of where you place the LECS. The main criterion is to pick a device with high availability. Some network designers argue that the best location is an ATM switch because it provides a centrally-located database. However, other designers argue that during a partial network outage, the ATM switch has its hands full just trying to build new SVCs. To further burden it with handling LECS duties hampers network resiliency. I generally try to locate the LECS in a Catalyst LANE module. However, a platform such as a 7500 router can also be a good choice.

The LES function requires more CPU effort than the LECS function, but it is generally not a burdensome amount. On the other hand, the BUS does require a tremendous amount of effort—it must be able to handle all broadcasts and all multicasts on the network while also supporting unicast traffic until the Flush process can occur. Because Cisco requires the LES to be co-located with the BUS, the BUS becomes the component that must be carefully positioned. In practice, the Catalyst 5000 currently provides the best BUS performance of the Cisco product line (as well as having top performance within the industry). Table 9-5 shows the BUS performance for various Cisco ATM devices expressed in kilopackets (thousands of packets) per second. When released, the Catalyst 6000 OC-12 ATM module is expected to have performance comparable to that of the Catalyst 5000 OC-12 module.

Table 9-5. BUS Performance by Hardware Platform (in Kilopackets per Second)

Platform KPPS
Catalyst 5000 OC-12 LANE Module 500+
Catalyst 5000 OC-3 LANE Module 125
ATM PA (in 7500 and 7200) 70
Catalyst 3000 50
4700 NMP-1A 41
LS1010 30
7000 AIP 27

Although Catalyst LANE modules provide the highest throughput in Cisco’s products line, routers with very powerful CPUs (such as the 7500 RSP4) can provide faster recovery during network failover (the additional CPU capacity allows them to build VCs more quickly). In general, this is less important than the throughput numbers presented in Table 9-5.

Using Hard-Coded Addresses

Although the automatic NSAP scheme based on MAC addresses and subinterface numbers does allow for very easy configuration of LANE across Cisco devices, it can lead to maintenance problems. Because the MAC addresses used for the NSAP scheme are tied to the chassis or Supervisor module, swapping cards can create a need for minor reconfigurations. Chassis that support redundant Supervisors such as the 55XX family derive their MAC address from chips located on the backplane.

Each slot is assigned a block of addresses, causing problems if either the chassis is changed or the LANE module is moved to a different slot. Chassis that only support a single Supervisor engine (such as the Catalyst 5000) pull their MAC addresses from the Supervisor module itself. Again, each slot is assigned a block of addresses. However, in this case, problems do not result from a change in the chassis (after all, the backplane in these platforms is passive) but from a change in Supervisor modules or if the LANE module is moved to another slot.

Note that reconfiguration is only required if the device acting as the LECS or the LES is changed. If the LECS changes, you need to modify the NSAP address configured on every ATM switch (but, assuming ILMI or well-known LECS NSAPs are in use, this does not require a change on the LECs). If the LES changes, you need to modify the LES’ NSAP listed in the LECS database.


The LANE 1.0 spec released in January 1995 did not provide for a server-to-server protocol (known as the LNNI [LANE Network-Network Interface] protocol). Because this limitation prohibited multiple servers from communicating and synchronizing information with each other, the ATM Forum had a simple solution: allow only a single instance of each type of server. The entire network was then dependent on a single LECS, and each ELAN was dependent on a single LES and BUS. Because this obviously creates multiple single points of failure, most ATM vendors have created their own redundancy protocols. Cisco’s protocol is known as the Simple Server Redundancy Protocol (SSRP).

SSRP allows for an unlimited number of standby LECS and LES/BUS servers, although one standby of each type is most common. It allows the standby servers to take over if the primary fails, but it does not allow multiple active servers. One of the primary benefits of SSRP is that it is interoperable with most third-party LECs.

An additional benefit of SSRP is that it is easy and intuitive to configure. To provide for multiple LECSs, you simply need to configure multiple atm lecs-address-default commands on every ATM switch. To provide for multiple LES/BUSs for every ELAN, just add multiple name ELAN_NAME server-atm-address NSAP commands to the LECS database. For example, the commands in Example 9-16 configure two LECSs on a LS1010 ATM switch.

Example 9-16 Configuring Two LECSs on a LS1010 ATM Switch

If the first LECS is available, the LS1010 always provides this address to LECs via ILMI. However, if the first LECS becomes unavailable, the ATM switch just returns the second LECS’ NSAP to the LEC. Other than an address change, the LEC doesn’t even know the first LECS failed.

You must be certain to enter redundant LECS addresses in the same order on all ATM switches.

The commands in Example 9-17 configure redundant LES/BUS servers for ELAN1 and ELAN2.

Example 9-17 Configuring Redundant LES/BUS Servers for Multiple ELANs

If the first LES listed is available, the LECS returns this address to the LEC in the LE_CONFIGURE_REPLY. If the first LES fails, the LECS returns the second LES’ NSAP when the LEC tries to rejoin. Again, the LEC isn’t aware of the change (other than it was given a different address).


Make certain that all of the LECS database are identical.

The LECS redundancy mechanism is implemented by control connections between the LECSs. The LECS uses ILMI to acquire the complete list of LECSs servers from the ATM switch (just as an LEC does). Each LECS then builds an SVC to every LECS listed below itself on the list. The one LECS with no inbound connections is the primary LECS. However, if the primary fails, its connection to the second LECS closes, causing the second LECS to no longer have any inbound connections. For example, imagine three LECS devices A, B, and C. A is listed first on the LS1010 and C is listed last. After all three switches acquire the complete list of LECSs via ILMI, the A device opens a connection to B and C, and B opens a connection to C. Because B has one inbound connection and C has two inbound connections, both of these devices are backup LECSs. Because it has no inbound connections, A becomes the primary LECS. However, if A fails, the connection to B fails causing B to become the primary. If B fails, its connection to C drops and C becomes the primary.

The LES/BUS redundancy mechanism also utilizes ILMI. Upon startup, all LES/BUSs use ILMI to locate the primary LECS. Every LES/BUS then builds a connection to this single LECS. The Configuration Server then evaluates all of the inbound connections to determine which connection is from the LES/BUS listed first in the LECS database. That LES/BUS’ NSAP is then provided in LE_CONFIGURE_REPLY messages to LANE Clients.


Cisco offers Dual-PHY on all of the high-end Catalyst LANE Modules (such as the Catalyst 5000 and 6000). Although these cards still have only a single set of ATM and AAL logic, it provides dual physical layer paths for redundant connections. This allows the LANE card to connect to two different ATM switches (in case one link or switch fails), but only one link can be active at a time. You can configure which link is preferred with the atm preferred phy command.

Although this feature is of great value in large networks, it does introduce a subtle configuration change. Notice the configuration in Figure 9-27.

Figure 9-27. Dual-PHY Connection to Two ATM Switches

If A is the preferred port, the resulting NSAP is the following:


However, if the left-hand switch fails, the NSAP changes when the B port becomes active:


Although this change does not affect LANE Clients, it has a significant influence on LECS and LES/BUS configurations that use SSRP. In practice, this means that the LS1010 must list four LECS addresses to provide a single redundant LECS device. In addition, the LECS database must list four LES addresses to provide a single redundant LES/BUS.

  • Tip
    Using SSRP with Dual-PHY connections generally requires careful planning of the order of SSRP entries.

For example, Figure 9-28 illustrates two LES/BUSs linked to two LS1010s through dual-PHY connections.

Figure 9-28. Redundant LES/BUSs Connected via Dual-PHY to Two ATM Switches

The LECS database should contain four name ELAN_NAME server-atm-address NSAP commands for each ELAN. Look at Example 9-18.

Example 9-18 Inefficient LECS Configuration for SSRP

Although this provides LES/BUS redundancy, it introduces another complication. Assume that both Catalysts are using PHY-A as the preferred link and LS-1010-A fails. The LECs instantly try to rejoin ELAN1 and be directed by the LECS to the second LES listed in the database, Port B on the SW-1. However, because this port has not completed its ILMI address registration process (when LS-1010-A failed, PHY-A went down with it and it typically takes about 10–15 seconds to bring up ILMI on another port), the call fails and the LECs try the third LES listed, Port A on SW-2.

The call succeeds and all the LECs rejoin the ELAN. However, a few seconds later Port B on SW-1 completes the ILMI addresses registration process and becomes active. Now that the second LES in the database is active, Port A on SW-2 reverts to backup mode, causing all of the LECs to again be thrown out of the ELAN. When the LECs try again to rejoin, the LECS sends them to Port B on SW-1.

This unnecessary backtracking can be avoided by carefully coding the order of the LECS database as in Example 9-19.

Example 9-19 Coding the LECS Database Order

The configuration in Example 9-19 offers faster failover because the second device listed completes address registration before Port A on SW-1 fails. This allows the second LES to be immediately available without backtracking.

Using the Well-Known NSAP for LECS Discovery

Earlier in the chapter, the text mentioned that Cisco recommends using ILMI to pass the NSAP address of the LECS to the LECs. However, Cisco also supports using hard-coded NSAP addresses and using the well-known NSAP address. Because the well-known NSAP address is used in many networks (for example, it is the default method used on Fore Systems equipment), this section briefly looks at the configuration syntax and issues involved in using the well-known NSAP.

To configure use of the well-known NSAP, merely modify the command used to enable the LECS—use the lane config fixed-config-atm-address command as opposed to the lane config auto-config-atm-address command. The causes the LECS to register the 47.007900000000000000000000.00A03E000001.00 so that it can be made reachable via PNNI.

Example 9-20 illustrates a complete configuration that uses the well-known LECS NSAP and places all four LANE components for two ELANs on a single device.

Example 9-20 Using the Well-Known LECS NSAP

One of the advantages of using the well-known NSAP is that it does not require any configuration at all on the LS1010 ATM switch. Because the LECs automatically try the well-known NSAP if the hard-coded NSAP and ILMI options fail, the LEC reaches the LECS with minimal configuration.

Although the well-known NSAP is potentially easier to configure in small networks, Cisco recommends the ILMI approach because it provides better support for SSRP server redundancy. There is a problem if multiple LECS servers try to use the well-known NSAP for LECS discovery: both servers try to register the same 47.0079… address! With ILMI and SSRP, every device registers a unique NSAP address, avoiding any PNNI routing confusion.

If you run into a situation where you need to run SSRP and also support the well-known NSAP (this can be the case if you are using third-party LECs that do not support the ILMI LECS discovery method), there is a solution. First, configure all of the LECS devices with the lane config fixed-config-atm-address command. Next, be sure to also configure every LECS for ILMI support with the lane config auto-config-atm-address command. This allows SSRP to function properly and elects only a single primary LECS. Because the backup LECS servers do not register the well-known NSAP, only the primary originates the 47.0079… route into PNNI. You now have the resiliency of SSRP combined with the simplicity and widespread support of the well-known NSAP!

PVCs and Traffic Shaping

The Catalyst LANE module allows connections to one or more Catalysts using PVCs. When implementing this, the LECS, LES, and BUS server functions are not utilized. You simply build a PVC and then bind a VLAN to that circuit as in Example 9-21.

Example 9-21 Catalyst ATM PVC Configuration

This creates a PVC using VPI 0 and VCI 50 and then binds it to VLAN 1. PVCs can be useful in small networks, especially when connecting two Catalyst LANE blades back-to-back without using an ATM switch. Another advanced feature offered by the Catalyst is PVC-based traffic shaping. This allows you to set a peak bandwidth level on a particular circuit. It can be very useful for controlling bandwidth across expensive wide-area links. This feature requires you to load a special image into flash on the LANE module and does not work with SVCs. For example, Example 9-22 adds traffic shaping to the configuration in Example 9-21.

Example 9-22 Traffic Shaping and ATM PVCs

The final parameter on the atm pvc command limits the traffic to a peak rate of 11 Mbps.

About the author


Leave a Comment