This document describes how to configure your system in order to enable Local Area Transport (LAT) over a Generic Routing Encapsulation (GRE) tunnel with the use of protocol translation.
Cisco recommends that you meet these requirements before you attempt this configuration:
- The tunnel between Router 1 (R1) and Router 2 (R2) must be established.
- R2 and Router 3 (R3) must have proper IP connectivity.
- You must be able to ping from R1 to R3.
- The LAT services must be configured and must run properly.
- You must have access to the LAT services from R2 to R3.
This document is not restricted to specific software and hardware versions.
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.
The Digital Equipment Corporation (DEC) LAT is the protocol that is most often used in order to connect terminals to DEC hosts. LAT is a DEC-proprietary protocol, and Cisco uses LAT technology that is licensed from DEC. The LAT protocol is similar to the TCP/IP Telnet protocol, because it allows a user at one site to establish a connection to a host at another site, and then it passes the keystrokes from one system to the other.
In order to establish a LAT connection through the terminal server to a DEC host, you only have to enter the host name. One main difference between the TCP/IP Telnet and LAT protocols is that LAT cannot be routed, as Telnet can be, over the IP protocol. Because the DEC LAT protocol includes its own transport protocol, which runs directly over Ethernet rather than a standard routing layer, it cannot be passed by a router. A bridge or combined bridge and router, such as the Cisco routers, must be used in order to carry LAT traffic across a wide area network.
The LAT protocol is asymmetrical; it has master and slave functionality. First, the LAT master starts a LAT circuit when it sends a circuit start message, and then a LAT slave responds with its own circuit start message. Up to 255 LAT sessions can be multiplexed on a circuit.
In a typical setup, where the terminal of the user is connected to a router, the router acts as the master, and the target host acts as the slave. For example, this command results in the device named router1 as the master (or server), and the target host named ORANGE as the slave (or host):
router1> lat ORANGE
A router can also act as a slave when the user connects from one access server to another. For example, this command results in router1 as the master (server), and router2 as the slave (host):
router1> lat router2
In a LAT host-initiated connection, the Virtual Memory System (VMS) always acts as the LAT slave. For example, a print job that originates from a VMS system initiates or triggers the router to which the printer is connected in order to act as the LAT master. The master-slave relationship also applies to host-initiated sessions from a LAT slave.
Resources such as modems, computers, and application software are viewed in a LAT network as services that any user in the network can use. A LAT node can offer one or more such LAT services, and more than one LAT node can offer the same LAT service.
A LAT node that offers one or more services, collectively called advertised services, broadcasts its services in the form of Ethernet multicast messages, called LAT service announcements. A LAT node can listen for LAT service announcements on the network. These messages are cached in a dynamic table of known LAT services, collectively called learned services.
The Cisco IOS® software supports both learned and advertised LAT services; therefore, it also supports incoming and outgoing LAT sessions. The services rating of its advertised nodes is determined dynamically, but it can also be set statically.
In order to establish outgoing connections to a LAT service, the Cisco IOS software searches for the service in the learned services cache. If one or more nodes offers the same service, the node with the highest rating is chosen. For example, a LAT connection to a service offered by a VAX (Virtual Address eXtension) cluster connects to the node in that cluster with the smallest load, and thus the highest service rating. Load balancing operates through these connections, in relation to a group of nodes that offer the same service.
In order to establish an incoming connection, a LAT session connects from another LAT node to the service that is advertised by the local LAT node.
Any user can access any of the services on a LAT network. For this reason, a LAT server manager uses the concept of group codes in order to allow or restrict access to the services.
When both the router and the LAT host share a common group code, a connection can be established between the two. If the default group codes have not been changed on either side, a user on any router can connect to any learned service on the network.
However, if you define groups for access servers, or routers and LAT hosts, you can partition these services into logical subnetworks. You can organize the groups so that users on one device view one set of services, and users on another device (or another line on the same device) view a different set. You might also design a plan that correlates group numbers with organizational groups, such as departments.
LAT Sessions and Connection Support
A LAT session is a two-way logical connection between a LAT service and the router. The connection is transparent to the user at a console that is connected to a LAT session; it appears that the connection has been made directly to the desired device or application program. There is no inherent upper limit to the number of LAT sessions that you can create from an asynchronous terminal to the router.
A host print job that is connected to a router is called a host-initiated connection. The Cisco IOS software maintains a queue of hosts that request connection, and it sends periodic status messages to those hosts.
You can establish host-initiated connections via a specified port number or a defined service. These same services are used for connections from other access servers or routers.
LAT Over GRE
This type of requirement, to run LAT over GRE, comes in scenarios where the remote site (LAT device A) is connected to Router-A. The first protocol translation is performed on Router-A, from LAT to Telnet. Router-A is connected to Router-B (behind which LAT services are hosted) either over a GRE tunnel, x25, or any IP scheme. On Router-B, protocol translation from Telnet to LAT is performed again.
LAT is not supported with GRE-type encapsulation, so protocol translation is the only option:
Error: LAT: Encapsulation failed
Use this section in order to configure LAT over GRE with the use of protocol translation.
Configuration on R1
Here is an example of the configuration on R1:
translate lat TEST tcp 192.168.2.3
!! translating lat TEST to telnet to ip 192.168.2.3 that is in same
tunnel subnet but not used by any interface
ip address 192.168.1.1 255.255.255.0 !! Going towards R2
lat enabled !! lat must be enabled on interface
ip address 192.168.2.1 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 192.168.1.2
Configuration on R2
Here is an example of the configuration on R2:
ip vrf forwarding TEST
ip address 192.168.1.2 255.255.255.0 !! Going towards R1
ip address 192.168.3.1 255.255.255.0 !! Going towards R3
ip address 192.168.2.2 255.255.255.0
ip mtu 1400
tunnel source FastEthernet0/0
tunnel destination 192.168.1.1
tunnel vrf TEST
translate tcp 192.168.2.3 lat TEST
!! Translating tcp connection from R1 to lat TEST
(LAT service TEST hosted on R3)
Configuration on R3
Here is an example of the the configuration on R3:
ip address 192.168.3.2 255.255.255.0 !! Going towards R2
lat service TEST enabled
!!LAT service TEST hosted
line vty 0 4
Use this section in order to verify your configuration.
Verification on R1
Enter these commands in order to verify the configuration on R1:
R1#show lat service
Service Name Rating Interface Node (Address)
TEST 5 Local
Password: !!enter password configured under line vty of R3
R3> !!Access to R3
Verification on R3
Enter these commands in order to verify the configuration on R3:
R3#show lat session
tty98, virtual tty from host R2
!! LAT coming in from R2
Name TEST, Remote Id 1, Local Id 1
Remote credits 2, Local credits 0, Advertised Credits 4
Max Data Slot 255, Max Attn Slot 255, Stop Reason 0
No known LAT nodes.
R3#show lat traffic
Local host statistics:
1/95 circuits, 1/0 sessions, 1/0 services
255 sessions/circuit, circuit timer 80, keep-alive timer 20
Recv: 219 messages (0 duplicates), 141 slots, 714 bytes
0 bad circuit messages, 111 service messages (8 used)
Xmit: 228 messages (0 retransmit), 140 slots, 787 bytes
0 circuit timeouts, 111 service messages
Total: 16 circuits created, 16 sessions
There is currently no specific troubleshooting information available for this configuration. However, these debugs are helpful with attempts to check for error messages:
- Debug lat events
- Debug lat packets
- Debug lat filtering