Guest

X.25 Protocols

Enable LAT Over a GRE Tunnel with Protocol Translation Configuration Example

Enable LAT Over a GRE Tunnel with Protocol Translation Configuration Example

Document ID: 116997

Updated: Dec 19, 2013

Contributed by Utsav Dutt, Cisco TAC Engineer.

   Print

Introduction

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.

Prerequisites

Requirements

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.

Components Used

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.

Background

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.

Note: This document specifically describes how to configure LAT in the environments where remote sites are connected over GRE tunnels.

LAT Functionality

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 (VMSalways 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.

LAT Services

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.

LAT Groups

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.

Restrictions

LAT is not supported with GRE-type encapsulation, so protocol translation is the only option:

Error: LAT: Encapsulation failed

Configure

Use this section in order to configure LAT over GRE with the use of protocol translation.

Note: Use the Command Lookup Tool (registered customers only) in order to obtain more information on the commands used in this section.

Network Diagram

  

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
!
interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0 !! Going towards R2
 duplex auto
 speed auto
 lat enabled              !! lat must be enabled on interface
end
!
interface Tunnel1
 ip address 192.168.2.1 255.255.255.0
 load-interval 30
 tunnel source FastEthernet0/0
 tunnel destination 192.168.1.2
end
!

Configuration on R2

Here is an example of the configuration on R2:

!
interface FastEthernet0/0
 ip vrf forwarding TEST
 ip address 192.168.1.2 255.255.255.0 !! Going towards R1
 duplex auto
 speed auto
 lat enabled
end
!
interface FastEthernet0/1
 ip address 192.168.3.1 255.255.255.0 !! Going towards R3
 duplex auto
 speed auto
 lat enabled
end
!
interface Tunnel1
 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
end
!
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:

!
interface FastEthernet0/0
 ip address 192.168.3.2 255.255.255.0 !! Going towards R2
 duplex auto
 speed auto
 lat enabled
end
!
lat service TEST enabled
!!LAT service TEST hosted
!
line vty 0 4
 password cisco
 login
!

Verify

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
R1#lat TEST
Trying TEST...Open
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

Session:
  Name TEST, Remote Id 1, Local Id 1
  Remote credits 2, Local credits 0, Advertised Credits 4
  Flags: none
  Max Data Slot 255, Max Attn Slot 255, Stop Reason 0

Remote Node:
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

Troubleshoot

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

Related Information

Updated: Dec 19, 2013
Document ID: 116997