External Links RFC 1483 RFC 1577 Classical IP Over ATM

Packet™ Magazine Archives, Fourth Quarter 1998 Deploying and Troubleshooting Multiprotocol over ATM By Himanshu Desai, Network Consulting Engineer, Cisco Systems' Network Supported Accounts Group You've done your homework and finally decided. Asynchronous Transfer Mode (ATM) is the networking technology your company needs to move forward into the next century. Now, the real work begins -- designing your new network. One of the ATM design considerations you'll have to make involves choosing a method of transmitting legacy protocols such as IP, SNA, IPX, and others over your ATM network. It's an important consideration, because the method you choose will impact how smoothly you can make the transition to ATM, how scalable your new network will be, and how easy it will be to manage. Ultimately, it could even impact your company's bottom line. Three different methods of deploying legacy protocols over ATM exist today -- RFC 1483, RFC 1577, and LAN Emulation (LANE). Before you decide which of them will work best in your new network, ask yourself these questions: How many nodes does your network require? Do you plan to add more nodes in the future? What legacy protocols do you need to support? Are you building a campus backbone, a WAN backbone, or both? Do you have the staff to support a network that may at first be significantly more difficult to configure and manage than your existing network? If not, do you have the time to train your staff or the budget to hire additional staff? Keep your answers to these questions firmly in mind as your read this article. By the time you've finished reading, you should have a basic understanding of these three methods of deploying legacy protocols over ATM and an idea of which is best suited for your own network. RFC 1483 RFC 1483 defines a method of encapsulating multiple protocols and then transmitting them over an ATM cloud using either switched virtual circuits (SVCs) or permanent virtual circuits (PVCs). The method works somewhat differently with PVCs than it does with SVCs. With PVCs, you must configure point-to-point connections between every node in your network and then manually map the addresses of these connections on all of your switches and routers. This task is relatively simple in small networks, but can be cumbersome to set up and difficult to troubleshoot in larger ones. The process is easier with SVCs, because configuration is semidynamic. You still must manually map the addresses of the routers, but the switches connecting the routers do not require manual mapping. RFC 1483 was designed for small campus or wide-area networks with these characteristics: Five to ten nodes Support for IP, IPX, Banyan VINES, AppleTalk, and other protocols Requirement for an easy transition to ATM However, RFC 1483 has its limitations, because it doesn't scale well and requires a great deal of configuration. RFC 1577 Like RFC 1483, RFC 1577 is a good fit for small networks in either the campus or the wide area, but that's where most of the similarity between the two methods ends. RFC 1577 supports IP only, while RFC 1483 supports multiple protocols. And RFC 1577 is configured dynamically, so it's easier than RFC 1483 to set up initially and change later. To perform dynamic configuration, RFC 1577 uses an Address Resolution Protocol (ARP) mechanism similar to the mechanism used in Ethernet networks. The routers and switches in an RFC 1577 network (the ARP clients) automatically register their IP and ATM addresses with a node that has been assigned the task of acting as an ARP server. When one client wants to communicate with another, it simply contacts the ARP server to request the ATM address of that client. No manual mapping is required. You should consider using RFC 1577 if your network has 10 to 20 nodes and only runs IP traffic. RFC 1577 also has some limitations: It has a single point of failure because of the centralized ARP server. It does not scale well. It still requires manual configuration to establish neighbor relationships among routers. LAN Emulation LANE is a method of emulating a LAN over an ATM infrastructure. It makes the ATM network look and behave like an Ethernet or Token Ring LAN, which makes it easier to support multiple protocols over ATM. LANE works by mapping Media Access Control (MAC) addresses to ATM addresses so the devices on the network can set up direct connections with one another and forward data. To do this, it uses four components: the LAN Emulation Server (LES); the Broadcast and Unknown Server (BUS); the LAN Emulation Configuration Server (LECS); and LAN Emulation Clients (LECs). These components can be used to set up single or multiple emulated LANs on the same ATM infrastructure. LANE is best-suited to campus backbone networks, because it's protocol-independent and scales easily -- from five nodes to hundreds of nodes. A LANE network, however, can be difficult to troubleshoot if it is not designed properly and well-documented. Looking Out for Trouble If there's trouble on your network, you need to know how to pinpoint and fix the problem quickly. The process you'll go through to do this will differ depending on whether you've implemented RFC 1483, RFC 1577, or LANE. This section leads you through an explanation of how to troubleshoot generic problems in each of these three types of networks. The examples assume that you have been unable to set up a connection between source and destination devices in the network because of a problem that exists somewhere in the logical connections among the Layer 2 or Layer 3 devices. Troubleshooting RFC 1483 with PVCs and SVCs In this example, Router 1 is unable to set up a connection with Router 2. Refer to the diagram for a step-by-step explanation of how to troubleshoot this problem using either PVCs or SVCs. Using PVCs Check the IP-to-ATM mapping on Router 1 to make sure that its IP address is correctly mapped to the PVC identifier (VPI/VCI = 0/35) of Switch 1. After you've checked the configuration on Router 1 and determined that it's correct, check the PVC identifier (VPI/VCI = 0/35), exiting the router to make sure it matches the PVC identifier on the incoming port of the nearest switch -- in this case, ATM Switch 1. Next, check to make sure that the PVC identifier exiting Switch 1 matches with the PVC identifier on the Switch 2, and so on, until you reach Router 2, the destination router. By this final check, assuming that none of the devices has a hardware problem, you should be able to identify a mismatch in one of the logical connections and fix the problem. Using SVCs Make sure the IP-to-ATM mapping between Router 1 and Router 2 is correct by checking the ATM address of the destination router, Router 2. If your manual mapping is correct, use the show atm map command to tell you whether the virtual connection between the two end routers is up. If it's not, you know there's something wrong with your call setup process. To check the call setup, use the debug atm sig-events command to make sure the source router (Router 1) is making the call correctly and is being rejected. If it is, enter the debug atm sig-events command on Router 2, the destination router, to see if it's getting the call and rejecting it. If the call setup message is not reaching Router 2 at all, check the intermediate ATM switches, Switches 1 and 2. Next, check the corresponding call routing tables in the switches to be sure they are correct, or use the debug atm sig-events command to see if one of the switches is rejecting the call because of a resource problem.

Troubleshooting LANE Follow this procedure if one of the end clients on your ATM network has trouble connecting to an end server. The procedure remains the same whether the LECs involved are in the same or different emulated LANs. Check to make sure that the LECs running on Switch 1 and Switch 2 can transfer and accept data by using the show lane client command. If one of the LECs is not operational, there may have been a failure during the initialization and registration process that took place when it first joined the emulated LAN. If there has been such a failure, correct the problem by using the shut and noshut commands to reset the LEC and perform the joining process all over again. Assuming the underlying ATM virtual channel connection (VCC) setup is working correctly, the LEC should now become operational. If the end client behind Switch 1 still has a problem connecting, use the show cam mac-address command to check the content-addressable memory (CAM) table in Switch 2 to make sure the MAC address of the end server behind it exists. You also need to determine the corresponding ATM address of the resident LEC 2 client for Switch 2 by using the show lane client command. Next, go to Switch 1 and use the show lane-le-arp command to see if the correct destination MAC-to-ATM address pair exists in the LE ARP cache. If there is a mismatch in the LE ARP table, use the clear-lane le-arp command to clear out the incorrect cache entry. The switch will rebuild the table dynamically. Now try to initiate a session between the end client and the end server to see if the new LE ARP entry appears in the table with the correct MAC-ATM address pair.

Himanshu Desai presented the popular "ATM Troubleshooting" sessions to capacity audiences at Networkers and Cisco Certified Internetwork Expert (CCIE) conferences in 1998. He is a network consulting engineer in Cisco's Network Supported Accounts group, which provides proactive support and consulting services to some of Cisco's largest enterprise customers. To contact him, e-mail hdesai@cisco.com.

Top of Page Table of Contents Posted: Thu Feb 4 17:13:00 PST 1999 Copyright © 1998 Cisco Systems, Inc.