Ce document décrit comment configurer votre système afin d'activer le transport local (LAT) sur un tunnel GRE (Generic Routing Encapsulation) avec l'utilisation de la traduction de protocole.
Cisco vous recommande de respecter ces exigences avant de tenter cette configuration :
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
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.
Le LAT de Digital Equipment Corporation (DEC) est le protocole le plus souvent utilisé pour connecter des terminaux à des hôtes DEC. LAT est un protocole propriétaire de DEC et Cisco utilise la technologie LAT qui est sous licence de DEC. Le protocole LAT est similaire au protocole Telnet TCP/IP, car il permet à un utilisateur d’un site d’établir une connexion à un hôte d’un autre site, puis il transmet les frappes de touche d’un système à l’autre.
Pour établir une connexion LAT via le serveur de terminal à un hôte DEC, vous devez seulement entrer le nom d'hôte. Une différence principale entre les protocoles TCP/IP Telnet et LAT est que LAT ne peut pas être routé, comme Telnet peut l’être, via le protocole IP. Comme le protocole DEC LAT inclut son propre protocole de transport, qui s’exécute directement sur Ethernet plutôt qu’une couche de routage standard, il ne peut pas être transmis par un routeur. Un pont ou un pont et un routeur combinés, tels que les routeurs Cisco, doivent être utilisés pour transporter le trafic LAT sur un réseau étendu.
Le protocole LAT est asymétrique ; il a une fonctionnalité maître et esclave. Tout d'abord, le maître LAT démarre un circuit LAT lorsqu'il envoie un message de début de circuit, puis un esclave LAT répond avec son propre message de début de circuit. Jusqu'à 255 sessions LAT peuvent être multiplexées sur un circuit.
Dans une configuration classique, où le terminal de l'utilisateur est connecté à un routeur, le routeur agit en tant que maître et l'hôte cible en tant qu'esclave. Par exemple, cette commande génère le périphérique nommé router1 en tant que maître (ou serveur) et l'hôte cible nommé ORANGE en tant qu'esclave (ou hôte) :
router1> lat ORANGE
Un routeur peut également agir comme esclave lorsque l'utilisateur se connecte d'un serveur d'accès à un autre. Par exemple, cette commande génère router1 comme maître (serveur) et router2 comme esclave (hôte) :
router1> lat router2
Dans une connexion initiée par l'hôte LAT, le système de mémoire virtuelle (VMS) agit toujours comme esclave LAT. Par exemple, une tâche d'impression qui provient d'un système VMS initie ou déclenche le routeur auquel l'imprimante est connectée afin d'agir en tant que maître LAT. La relation maître-esclave s'applique également aux sessions initiées par l'hôte à partir d'un esclave LAT.
Les ressources telles que les modems, les ordinateurs et les logiciels d'application sont vues dans un réseau LAT comme des services que tout utilisateur du réseau peut utiliser. Un noeud LAT peut offrir un ou plusieurs de ces services LAT, et plusieurs noeuds LAT peuvent offrir le même service LAT.
Noeud LAT qui propose un ou plusieurs services, appelés collectivement services annoncés, diffuse ses services sous forme de messages de multidiffusion Ethernet, appelés annonces de service LAT. Un noeud LAT peut écouter les annonces de service LAT sur le réseau. Ces messages sont mis en cache dans une table dynamique de services LAT connus, collectivement appelés services appris.
Le logiciel Cisco IOS® prend en charge les services LAT appris et annoncés ; par conséquent, il prend également en charge les sessions LAT entrantes et sortantes. La notation des services de ses noeuds annoncés est déterminée dynamiquement, mais elle peut également être définie de manière statique.
Afin d'établir des connexions sortantes à un service LAT, le logiciel Cisco IOS recherche le service dans le cache des services appris. Si un ou plusieurs noeuds offrent le même service, le noeud ayant le niveau le plus élevé est choisi. Par exemple, une connexion LAT à un service offert par un cluster VAX (Virtual Address eXtension) se connecte au noeud de ce cluster avec la charge la plus faible, et donc le niveau de service le plus élevé. L'équilibrage de charge fonctionne via ces connexions, par rapport à un groupe de noeuds qui offrent le même service.
Afin d'établir une connexion entrante, une session LAT se connecte d'un autre noeud LAT au service annoncé par le noeud LAT local.
Tout utilisateur peut accéder à n'importe quel service sur un réseau LAT. Pour cette raison, un gestionnaire de serveur LAT utilise le concept de codes de groupe afin d'autoriser ou de restreindre l'accès aux services.
Lorsque le routeur et l’hôte LAT partagent un code de groupe commun, une connexion peut être établie entre les deux. Si les codes de groupe par défaut n'ont pas été modifiés de part et d'autre, un utilisateur de n'importe quel routeur peut se connecter à n'importe quel service appris sur le réseau.
Cependant, si vous définissez des groupes pour les serveurs d'accès, ou les routeurs et les hôtes LAT, vous pouvez partitionner ces services en sous-réseaux logiques. Vous pouvez organiser les groupes de sorte que les utilisateurs d'un périphérique voient un ensemble de services et que les utilisateurs d'un autre périphérique (ou d'une autre ligne du même périphérique) voient un ensemble différent. Vous pouvez également concevoir un plan qui établit une corrélation entre les numéros de groupe et les groupes organisationnels, tels que les départements.
Une session LAT est une connexion logique bidirectionnelle entre un service LAT et le routeur. La connexion est transparente pour l'utilisateur sur une console connectée à une session LAT ; il semble que la connexion a été établie directement sur le périphérique ou le programme d'application souhaité. Il n'existe aucune limite supérieure inhérente au nombre de sessions LAT que vous pouvez créer à partir d'un terminal asynchrone vers le routeur.
Une tâche d'impression hôte connectée à un routeur est appelée connexion initiée par l'hôte. Le logiciel Cisco IOS gère une file d’attente d’hôtes qui demandent une connexion et envoie des messages d’état périodiques à ces hôtes.
Vous pouvez établir des connexions initiées par l'hôte via un numéro de port spécifié ou un service défini. Ces mêmes services sont utilisés pour les connexions à partir d’autres serveurs d’accès ou routeurs.
Ce type d'exigence, pour exécuter LAT sur GRE, se présente dans des scénarios où le site distant (périphérique LAT A) est connecté au routeur A. La première traduction de protocole est effectuée sur le routeur A, de LAT à Telnet. Le routeur A est connecté au routeur B (derrière lequel les services LAT sont hébergés) via un tunnel GRE, x25 ou tout schéma IP. Sur Router-B, la traduction de protocole de Telnet à LAT est de nouveau effectuée.
LAT n'est pas pris en charge avec l'encapsulation de type GRE, la traduction de protocole est donc la seule option :
Error: LAT: Encapsulation failed
Utilisez cette section afin de configurer LAT sur GRE avec l'utilisation de la traduction de protocole.
Voici un exemple de configuration sur 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
!
Voici un exemple de configuration sur 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)
Voici un exemple de configuration sur 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
!
Utilisez cette section afin de vérifier votre configuration.
Entrez ces commandes afin de vérifier la configuration sur 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
Entrez ces commandes afin de vérifier la configuration sur 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
Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration. Cependant, ces débogages sont utiles pour les tentatives de recherche de messages d'erreur :
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
19-Dec-2013 |
Première publication |