Document ID: 19150
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Background Information
Static versus Dynamic Mappings
ATM Addresses
Understand ATM ARP
Logical IP Subnet (LIS)
ATM ARP Packet Format
RFC 1577 in an SVC Environment
Configuration Steps for ATM ARP Server
Summary of Events as Seen by the ATM ARP Server
Configuration Steps for ATM ARP Client
Summary of Events as Seen by the ATM ARP Client
Configure
Network Diagram
Configurations
Configuration of Simple Redundant ARP Server
Verify
Troubleshoot
Related Information
Introduction
Request for Comments (RFC) 1577 
specifies "Classical IP and ARP over ATM". More specifically, it defines standard mechanisms for the transportation of IP datagrams as well as ATM Address Resolution Protocol (ATM ARP) requests and replies over an ATM network. Network devices that operate as ATM ARP servers or clients exchange ATM ARP requests and replies. This document provides background information on ATM ARP services, requests and replies over ATM Adaptation Layer 5 (AAL5) and provides a sample configuration of ATM ARP services using Cisco routers. This document complements these two documents:
This document requires an understanding of ATM addressing. For more information, refer to Understanding ATM Addresses with Cisco Devices.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
Commands for RFC 1577 were introduced in Cisco IOS® Software Release 11.1 and allow support on Cisco routers with ATM interfaces.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to Cisco Technical Tips Conventions.
Background Information
Static versus Dynamic Mappings
When you use routed RFC 1483, think of ATM as a Layer 2 protocol used to transmit IP and other Layer 3 packets over a physical wire. ATM is very similar to Ethernet technology. With both Layer 2 encapsulations, you must resolve the destination IP address to the destination MAC address. IP uses the address resolution protocol (ARP) to discover this mapping dynamically. You can also configure static ARP entries on a router or a host.
On ATM networks, there are two approaches:
-
Static map lists are a Cisco IOS software feature that offers an alternative to using the dynamic address-resolution mechanisms of ATM ARP and in the ATM ARP defined in RFC 1577. Using static maps, you can associate a protocol address with an ATM address on a Switched Virtual Circuit (SVC). Static mappings with ATM SVCs use these two configuration commands:
Router(config-if)# svc [name] nsap address Router(config-if-atm-vc)# protocol protocol protocol-address [[no] broadcast]
-
ATM ARP is defined in RFC 1577. The principle is to configure ATM ARP clients with the ATM address of the ARP server. The client initiates a connection to the server whenever an unknown packet is encountered. Rather than mapping each Layer 3 address to its appropriate destination, an administrator's job is simplified by entering the address of the ATM ARP server. The process of converting unknown addresses is dynamic and provided by the server.
Configuration of the client requires only configuration of the ATM ARP Server network service access point (NSAP):
Router(config-if)# atm arp-server nsap [nsap-address]
ATM Addresses
Every ATM interface involved with signaling must be configured with an NSAP address. The NSAP address is the ATM address of the interface and must be unique across the network.
Understand ATM ARP
ATM Address Resolution Protocol (ATM ARP) requests and replies over ATM Adaptation Layer 5 (AAL5). The ATM ARP architecture uses two components:
-
ATM ARP client - When configured for ATM ARP, the client announces itself to the ARP Server using the NSAP address via a point-to-point VC. Clients are configured by using the ATM address of the server.
Router_C(config-subif)#atm arp-server nsap 47.00918100000000902B03E001.111111111111.11 Router_C(config-subif)# 02:05:25: ATMARP: Starting ARP client on ATM1/0.2 02:05:25: ATMARP(ATM1/0.2): Opening ARP server VCC to 47.00918100000000902B03E001.111111111111.11 02:05:25: ATMARP(ATM1/0.2)I: INARP Request VCD#19 0/51 from 10.1.1.1 02:05:25: ATMARP(ATM1/0.2)O: INARP Response VCD#19 0/51 to 10.1.1.1
-
ATM ARP server - The ATM ARP server waits for a client to register. Servers compliant with RFC 1577 never initiate a connection for services. Functionality requires a client to initiate a connection for ATM ARP services. After it receives the client's registration request, the ATM ARP server adds the client's address to an ARP table, which lists Layer 3 to Layer 2 address mappings. The ATM ARP server obtains addresses via an Inverse ARP and adds the mapping to it's database. When the client makes a connection to the ATM ARP server, the server replies with an Inverse ARP request to learn the IP address and ATM address of the client on the network. The server uses this information to resolve future ATM ARP requests from other clients.
Router_A#show atm arp !--- Note that a "*" next to an IP address indicates an active call. IP Address TTL ATM Address ATM2/0.1: * 10.1.1.1 19:35 4700918100000000902b03e00111111111111111 * 10.1.1.2 19:48 4700918100000000902b03e00122222222222222 02:01:18: ARPSERVER (ATM2/0.1): tx InARP REQ on vc 31 02:01:18: ATMARP(ATM2/0.1)O: INARP_REQ to VCD#31 0/63 for link 7(IP) 02:01:18: ATMARP(ATM2/0.1)I: INARP Reply VCD#31 0/63 from 10.1.1.3 02:01:18: ATMARP(ATM2/0.1): ARP Update from VCD#31 10.1.1.3 MAP VCD#31 02:01:18: ARPSERVER (ATM2/0.1): rx InARP REPLY from 10.1.1.3 (vc 31) 02:01:18: ARPSERVER (ATM2/0.1): New IP address for vcd 31 -- was 0.0.0.0, now 10.1.1.3 02:01:37: ATMARP:(ATM2/0.1): ARP Request from 10.1.1.3 -> 47.00918100000000902B03E001.333333333333.33 02:01:37: ATMARP(ATM2/0.1): ARP Update from VCD#31 10.1.1.3 MAP VCD#31 02:01:37: ARPSERVER (ATM2/0.1): rx ARP REQ from 10.1.1.3 to 10.1.1.2 (vc 31) 02:01:37: ARPSERVER (ATM2/0.1): tx ARP REPLY from 10.1.1.2 to 10.1.1.3 (vc 31) Router_A#show atm map Map list ATM2/0.1_ATM_ARP : DYNAMIC arp maps to NSAP 47.00918100000000902B03E001.111111111111.11 , connection up, VC 15, VPI 0, VCI 46, ATM2/0.1 ip 10.1.1.1 maps to NSAP 47.00918100000000902B03E001.111111111111.11 , broadcast, connection up, VC 15, VPI 0, VCI 46, ATM2/0.1 ip 10.1.1.2 maps to NSAP 47.00918100000000902B03E001.222222222222.22 , broadcast, connection up, VC 34, VPI 0, VCI 66, ATM2/0.1 ip 10.1.1.3 maps to NSAP 47.00918100000000902B03E001.333333333333.33 , broadcast, connection up, VC 35, VPI 0, VCI 67, ATM2/0.1 Router_A#show atm arp !--- Note that a "*" next to an IP address indicates an active call. IP Address TTL ATM Address ATM2/0.1: * 10.1.1.1 14:33 4700918100000000902b03e00111111111111111 * 10.1.1.2 10:56 4700918100000000902b03e00122222222222222 * 10.1.1.3 15:10 4700918100000000902b03e00133333333333333
Logical IP Subnet (LIS)
A Logical IP Subnet (LIS) defines an IP subnet over ATM. The LIS is very similar in principle to sub-networks as viewed on an IP network. In order to traverse different logical subnets, intervention of a router is required to make forwarding decisions. Routers configured in an LIS contain Layer 3 IP addresses and Layer 2 ATM addresses. If the client needs to connect to another LIS, the connection needs to go through a router. This implies that a router needs to be aware of both LISs. For this reason, one ATM ARP Server is required per LIS.
LISs and IP subnets also share these qualities:
-
Matching Maximum Transmission Unit (MTU) sizes for all VC's in an LIS.
-
Default LLC/SNAP encapsulation of IP packets.
-
End-to-end routing architecture remains the same as seen on IP networks.
-
ATM ARP services remain within the LIS.
-
One IP subnet is used for many hosts and routers.
ATM ARP Packet Format
ATM ARP and InATM ARP packets are to be encoded in AAL5 PDUs using LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field for ATM ARP/InATM ARP PDUs is shown in this table:
|
LLC 0xAA-AA-03 |
|
OUI 0x00-00-00 |
|
Ethertype 0x08-06 |
|
ATM ARP/InATM ARP Packet |
-
The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a SNAP header.
-
The OUI value of 0x00-00-00 (3 octets) indicates that these two-bytes are an Ethertype.
-
The Ethertype value of 0x08-06 (2 octets) indicates ARP [4]. Leftover from the RFC.
-
The total size of the LLC/SNAP header is fixed at eight octets. This aligns the start of the ATM ARP packet on a 64-bit boundary relative to the start of the AAL5 CPCS-SDU.
RFC 1577 in an SVC Environment
The configuration of ATM ARP over SVC's has two components that are covered in this document:
-
ATM ARP Client
-
ATM ARP Server
Routers defined as ATM ARP clients announce themselves to the ARP Server. The function of the ATM ARP server is passive in the implementation of RFC 1577. A server never sends a request to a client. It waits for requests from clients. After the client announces itself to the server, the server adds the address to the ARP table which contains an index of Layer 3 addresses and Layer 2 ATM addresses. The implementation of RFC 1577 allows routers to dynamically discover addresses via the ARP server.
Configuration Steps for ATM ARP Server
This section provides a step-by-step process to configure the ATM ARP Server.
-
Configure Permanent Virtual Circuits (PVCs) required for SVC operation.
An SVC is dynamically established, maintained and released. It allows you to provide bandwidth on demand for a particular connection or set of user traffic. When configuring SVCs on Cisco router ATM interfaces, you need to configure these two permanent virtual circuits (PVCs):
-
pvc 0/5 qsaal - (Required) Configures the signaling PVC. SVC service requires a signaling protocol between the end-device and the ATM switch. Cisco IOS software conforms to the ATM Forum's UNI 3.0, UNI 3.1 or UNI 4.0 user-to-network signaling standard, depending on what version is selected by Interim Local Management Interface (ILMI) or configuration.
-
pvc 0/16 ilmi - (Optional) Configures an ILMI PVC. The ATM router interface exchanges ILMI packets to communicate ATM-layer addressing information and to register its complete ATM address with the directly attached switch, which then provides ATM-layer routing to the destination router. Refer to Understanding ILMI on ATM Interfaces. Both of these overhead PVCs are configured on the ATM main interface.
-
-
Configure end-system identifier (ESI) address and obtain NSAP.
ILMI is a protocol defined by the ATM Forum used to set and capture a physical layer, ATM layer, virtual path and virtual circuit parameters on ATM interfaces. Refer to Understanding ILMI on ATM Interfaces for additional information. Exec command show atm ilmi-status or show int atmx/x.y can be used to obtain the NSAP active prefix. (Sample output is outlined in the Configurations section for Router A).
-
Configure the IP address.
-
Configure the ATM ARP Server and optionally configure the number of minutes that an entry is valid.
Router_A(config-subif)#atm arp-server self ? timeout Minutes our ARP Server keeps an entry as valid
For the detailed configuration sample of the ATM ARP Server, see the Router A (Server) configuration.
Summary of Events as Seen by the ATM ARP Server
This section explains in detail the series of events that the ATM ARP Server goes through when it registers an ATM ARP client.
-
Accepts connections from clients.
-
Verifies that the VC supports LLC/SNAP encapsulation.
-
Transmits an Inverse ATM ARP request to the client and examines the response.
-
Adds / updates the IP/ATM addresses entries in the ATM ARP table if they do not exist.
If the entry exists, nothing happens as long as an open VC is associated with an entry. ATM ARP entries are considered valid until aged or associated with an inactive VC. Server ATM ARP table entries are valid for a minimum of twenty minutes by default. This timeout can be adjusted as seen in step 4. Before aging out an entry, the server requests an Inverse ARP on any VC that is associated with the entry. If a response is not received, the address is purged. In the event that a VC is not active for that entry the address is purged. However, the VC teardown process does not make an address eligible for time-out.
-
Upon receipt of an ATM ARP request, the server generates an ATM ARP reply if it has an entry in its table. If no entry is in the table, a negative ATM ARP reply is sent. ARP_NAK allows a client to determine the difference between a catastrophic server failure and an ATM ARP table lookup failure. The ARP_NAK packet is the same as the received ARP_REQUEST packet format with the operation code set to ARP_NAK.
Configuration Steps for ATM ARP Client
This section provides a step-by-step process to configure the ATM ARP client.
-
Configure PVCs required for SVC operation.
An SVC is dynamically established, maintained and released. It allows you to provide bandwidth on demand for a particular connection or set of user traffic. When configuring SVCs on Cisco router ATM interfaces, you need to configure these two PVCs:
-
pvc 0/5 qsaal - (Required) Configures the signaling PVC. SVC service requires a signaling protocol between the end-device and the ATM switch. Cisco IOS software conforms to the ATM Forum's UNI 3.0, UNI 3.1 or UNI 4.0 user-to-network signaling standard, depending on what version is selected by Interim Local Management Interface (ILMI) or configuration.
-
pvc 0/16 ilmi - (Optional) Configures an ILMI PVC. The ATM router interface exchanges ILMI packets to communicate ATM-layer addressing information and to register its complete ATM address with the directly attached switch, which then provides ATM-layer routing to the destination router. Refer to Understanding ILMI on ATM Interfaces. Both of these overhead PVCs are configured on the ATM main interface.
-
-
Configure ESI address.
-
Configure IP address.
-
Configure the ATM ARP Client by pointing to the Server NSAP address of the server.
Router_A(config-subif)#atm arp-server nsap ? 20-octet NSAP address
ILMI is a protocol defined by the ATM Forum used to set and capture physical layer, ATM layer, virtual path and virtual circuit parameters on ATM interfaces. Refer to Understanding ILMI on ATM Interfaces for additional information.Exec command show atm ilmi-status or show int atmx/x.y can be used to obtain the NSAP active prefix. (Sample output is outlined in the configurations section for Router A).
For the detailed configuration sample of the ATM ARP Client, see the Router B (Client) configuration.
Summary of Events as Seen by the ATM ARP Client
This section explains in detail the series of events that the ATM ARP client goes through when it registers to an ATM network.
-
Contacts the ARP Server to register its IP/ATM address through a point-to-point VC.
-
Obtains / refreshes its own ARP entry information about other members.
-
Responds to ATM ARP requests received on any VC.
-
Generates and transmits ATM ARP requests to the server and responds to ATM ARP replies and ARP NAK received from the server. ARP replies are used to build and/or refresh their own ATM ARP entries.
-
Ages ARP entries in its own ATM ARP table every twenty minutes by opening a VC to the server and exchanging ATM ARP information with the server.
Configure
This section contains the basic configuration of Routers A, B and C that are shown in the network diagram. In our example, Router A is the ATM ARP Server and Routers B and C are the ATM ARP clients. The configurations here use SVC's, but PVC can also be implemented.
For the ARP client routers, you need to know the complete NSAP ATM address of the ATM ARP Server. To find out this address, the show interface atm x/y command can be used. For this configuration, this command is enabled in Router A as shown here:
Note: The comments in blue explain the related commands.
Router_A#show interface atm2/0.1
ATM2/0.1 is up, line protocol is up
Hardware is RS8234 ATMOC
3 Internet address is 10.1.1.1/24
MTU 4470 bytes, BW 155000 Kbit, DLY 80 usec,
reliability 255/255, txload 1/255, rxload 1/255
NSAP address: 47.00918100000000902B03E001.111111111111.11
<omitted>
!--- NSAP is used for the server address. Prefix obtained through ILMI.
Note: To find additional information on the commands used in this document, use the Command Lookup Tool (registered customers only) .
Network Diagram
This diagram shows Routers A, B, and C. Router A is the ATM ARP Server and routers B and C are the ATM ARM clients. Routers B and C need to register to the server so that whenever router B wants to talk to Router C, it goes to Router A to find the path to router C.
Configurations
This document uses these configurations:
|
Router A (Server) |
|---|
interface ATM2/0 no ip address atm ilmi-keepalive pvc 0/5 qsaal pvc 0/16 ilmi interface ATM2/0.1 multipoint ip address 10.1.1.1 255.255.255.0 atm esi-address 111111111111.11 atm arp-server self !--- Configures router as the ARP Server. |
|
Router B (Client) |
|---|
interface ATM0 no ip address no ip route-cache no ip mroute-cache pvc 0/5 qsaal pvc 0/16 ilmi atm ilmi-keepalive interface ATM0.1 multipoint ip address 10.1.1.2 255.255.255.0 no ip route-cache atm esi-address 222222222222.22 atm arp-server nsap 47.00918100000000902B03E001.111111111111.11 !--- NSAP of router A. |
|
Router B (Client) |
|---|
interface ATM1/0 no ip address atm ilmi-keepalive pvc 0/5 qsaal pvc 0/16 ilmi interface ATM1/0.2 multipoint ip address 10.1.1.3 255.255.255.0 atm esi-address 333333333333.33 atm arp-server nsap 47.00918100000000902B03E001.111111111111.11 !--- NSAP of router A. |
Configuration of Simple Redundant ARP Server
Cisco's implementation of RFC 1577 includes an optional Simple Redundant ARP server function. This feature allows you to configure more than one ARP server. If an ATM ARP server is unavailable, the client can still obtain ARP services from the secondary. By configuring additional ATMARP servers, you can point clients to two locations.
This feature is specified in RFC 2225 which provides an enhancement to RFC 1577 by redundancy for ATM ARP servers.
These commands are used to configure server redundancy.
Router_B(config-subif)#atm arp-server self ? timeout Minutes our ARP Server keeps an entry as valid <cr> Router_C(config-subif)#atm classic-ip-extensions ? BFI Simple Redundant ARP Servers none Standard RFC 1577 behavior (no redundant ARP Servers)
Verify
Before you troubleshoot RFC 1577 ARP issues, you need to ensure that SVC and ILMI are active. The output of the show atm vc and show atm ilmi-status commands displays the status of QSAAL and ILMI VC's.
Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.
Router_A#show atm vc
VCD / Peak Avg/Min Burst
Interface Name VPI VCI Type Encaps SC Kbps Kbps Cells Sts
2/0 2 0 5 PVC SAAL UBR 149760 UP
2/0 1 0 16 PVC ILMI UBR 149760 UP
Router_A#show atm ilmi-status
Interface : ATM2/0 Interface Type : Private UNI (User-side)
ILMI VCC : (0, 16) ILMI Keepalive : Disabled
ILMI State: UpAndNormal
Peer IP Addr: 10.1.1.3 Peer IF Name: ATM1/0
Peer MaxVPIbits: 8 Peer MaxVCIbits: 14
Active Prefix(s) :
47.0091.8100.0000.0090.2B03.E001
To understand how the ATM ARP process is taking place and verifying that the exchange of messages is correct, enable the debug atm arp command. This output shows a sample of this command when there is a successful ping. Notice that Router B sends an ARP when it is pinging Router A. When router A gets the ARP, it responds with an INARP Request. An INARP Response is then sent to Router A.
Router_B#ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: *Dec 28 01:27:29.187 UTC: ATMARP(ATM0.1): Sending ARP to 10.1.1.1 *Dec 28 01:27:29.211 UTC: ATMARP(ATM0.1)I: INARP Request VCD#24 0/55 from 10.1.1.1 *Dec 28 01:27:29.211 UTC: ATMARP(ATM0.1): ARP Update from VCD#24 10.1.1.1 MAP VCD#24 *Dec 28 01:27:29.211 UTC: ATMARP(ATM0.1)O: INARP Response VCD#24 0/55 to 10.1.1.1.!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/3/8 ms Router_B#
Sample debug atm arp from Server as requests arrive:
This output is from the ATM ARP Server (router A) as the request arrives. Notice that as the ATM ARP Server receives a request from Router C and answers with an ARP Reply using VC #34, it also receives an ARP request from Router B. The ATM ARP Server answers with an ARP Reply.
01:23:12: ATMARP:(ATM2/0.1): ARP Request from 10.1.1.3 -> 47.00918100000000902B03E001.333333333333.33 01:23:12: ATMARP(ATM2/0.1): ARP Update from VCD#34 10.1.1.3 MAP VCD#34 01:23:12: ARPSERVER (ATM2/0.1): rx ARP REQ from 10.1.1.3 to 10.1.1.1 (vc 34) 01:23:12: ARPSERVER (ATM2/0.1): tx ARP REPLY from 10.1.1.1 to 10.1.1.3 (vc 34) 01:23:19: ATMARP:(ATM2/0.1): ARP Request from 10.1.1.2 -> 47.00918100000000902B03E001.222222222222.22 01:23:19: ATMARP(ATM2/0.1): ARP Update from VCD#31 10.1.1.2 MAP VCD#31 01:23:19: ARPSERVER (ATM2/0.1): rx ARP REQ from 10.1.1.2 to 10.1.1.1 (vc 31) 01:23:19: ARPSERVER (ATM2/0.1): tx ARP REPLY from 10.1.1.1 to 10.1.1.2 (vc 31)
Troubleshoot
This section provides information you can use to troubleshoot your configuration. To troubleshoot a problem using Classical IP over ATM configuration, first do a ping while debug atm arp is enabled. This output shows that the ARP Request and Reply occurred between the ATM ARP Server (Router A) and the ATM ARP Client (Router C).
Certain show commands are supported by the Output Interpreter Tool (registered customers only) , which allows you to view an analysis of show command output.
Note: Before issuing debug commands, refer to Important Information on Debug Commands.
-
ATM ARP request from the ATM ARP client at Router C:
Router_A#debug atm arp ATM ARP events debugging is on Router_A# 00:42:08: ATMARP:(ATM2/0.1): ARP Request from 10.1.1.3 -> 47.00918100000000902B03E001.333333333333.33 00:42:08: ATMARP(ATM2/0.1): ARP Update from VCD#15 10.1.1.3 MAP VCD#15 00:42:08: ARPSERVER (ATM2/0.1): rx ARP REQ from 10.1.1.3 to 10.1.1.1 (vc 15) 00:42:08: ARPSERVER (ATM2/0.1): tx ARP REPLY from 10.1.1.1 to 10.1.1.3 (vc 15) !--- ARP request and reply from Router C.
-
ATM ARP reply from the ATMARP server at Router A:
Router_A#debug atm arp ATM ARP events debugging is on Router_A# 00:02:22: ATMARP:(ATM2/0.1): ARP Request from 10.1.1.3 -> 47.00918100000000902B03E001.333333333333.33 00:02:22: ATMARP(ATM2/0.1): ARP Update from VCD#5 10.1.1.3 MAP VCD#5 00:02:22: ARPSERVER (ATM2/0.1): rx ARP REQ from 10.1.1.3 to 10.1.1.2 (vc 5) 00:02:22: ARPSERVER (ATM2/0.1): tx ARP REPLY from 10.1.1.2 to 10.1.1.3 (vc 5) 00:02:24: ATMARP:(ATM2/0.1): ARP Request from 10.1.1.2 -> 47.00918100000000902B03E001.222222222222.22 00:02:24: ATMARP(ATM2/0.1): ARP Update from VCD#6 10.1.1.2 MAP VCD#6 00:02:24: ARPSERVER (ATM2/0.1): rx ARP REQ from 10.1.1.2 to 10.1.1.3 (vc 6) 00:02:24: ARPSERVER (ATM2/0.1): tx ARP REPLY from 10.1.1.3 to 10.1.1.2 (vc 6)
Next, check that the ATM map is correct. This output displays the mapping between NSAP, IP addresses and SVCs. This can be done by enabling the show atm map command. The output of this command in shown here.
Router_A#show atm map Map list ATM2/0.1_ATM_ARP : DYNAMIC arp maps to NSAP 47.00918100000000902B03E001.111111111111.11 , connection up, VC 68, VPI 0, VCI 46, ATM2/0.1 ip 10.1.1.1 maps to NSAP 47.00918100000000902B03E001.111111111111.11 , broadcast, connection up, VC 67, VPI 0, VCI 47, ATM2/0.1 ip 10.1.1.2 maps to NSAP 47.00918100000000902B03E001.222222222222.22 , broadcast, connection up, VC 70, VPI 0, VCI 49, ATM2/0.1 ip 10.1.1.3 maps to NSAP 47.00918100000000902B03E001.333333333333.33 , broadcast, connection up, VC 62, VPI 0, VCI 41, ATM2/0.1
Another way to verify that the ATM to IP translation is occurring is to enable the show atm arp command. An asterisk (*) next to an IP address indicates an active call. The default time-out for ARP is twenty minutes. The output of this command in shown here.
Router_A#show atm arp
Note that a '*' next to an IP address indicates an active call
IP Address TTL ATM Address
ATM2/0.1:
* 10.1.1.1 19:55 4700918100000000902b03e00111111111111111
10.1.1.2 16:23 4700918100000000902b03e00122222222222222
* 10.1.1.3 19:55 4700918100000000902b03e00133333333333333
!--- The default timeout for ARP entries is 20 minutes.
In our present configuration, we have configured one ATM ARP server. Assume that the output of the server is unreachable.
An example of failed ARP requests from Client to Server:
Router_B#ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: *Dec 28 01:26:11.047 UTC: ATMARP(ATM0.1): Sending ARP to 10.1.1.1. *Dec 28 01:26:13.043 UTC: ATMARP(ATM0.1): Sending ARP to 10.1.1.1. *Dec 28 01:26:15.043 UTC: ATMARP(ATM0.1): Sending ARP to 10.1.1.1. *Dec 28 01:26:17.043 UTC: ATMARP(ATM0.1): Sending ARP to 10.1.1.1. *Dec 28 01:26:19.043 UTC: ATMARP(ATM0.1): Sending ARP to 10.1.1.1. Success rate is 0 percent (0/5) Router_B#
Related Information
- Understanding ILMI on ATM Interfaces
- Configuring RFC 1483 ATM SVCs Without ILMI for Address Registration
- Configuring ATM SVCs With Static Map Statements
- RFC 1577
- ATM Technology Support Pages
- Technical Support - Cisco Systems
| Updated: Nov 15, 2007 | Document ID: 19150 |