Cet exemple de configuration décrit le processus de transmission tunnel de données asynchrones.
Aucune condition préalable spécifique n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.
Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.
Par exemple, supposons que les périphériques RS-232 asynchrones doivent être connectés par des modems de ligne louée. Au lieu de cela, les modems de ligne louée sont remplacés par des serveurs de communication Cisco. Branchez les périphériques RS-232 sur des lignes asynchrones sur les serveurs de communication Cisco et connectez les serveurs de communication via un réseau IP de topologie arbitraire.
Dans cet exemple de configuration, un côté est l'appelant et l'autre côté est l'appelé. Il est présumé que le côté appelant est plus persistant dans la tentative d'envoi de données.
Hypothèses :
L'adresse IP de l'appelant est 10.1.2.3 et utilise la ligne 2.
Le côté appelé a l'adresse IP 10.3.2.1 et utilise la ligne 3.
Remarque : Pour en savoir plus sur les commandes utilisées dans le présent document, utilisez l’outil de recherche de commandes (clients inscrits seulement).
Ce document utilise la configuration réseau indiquée dans le diagramme suivant :
Ce document utilise les configurations présentées ci-dessous.
Côté appelant
Appelé latéral
Côté appelant |
---|
!--- On caller box - 10.1.2.3 define an IP hostname to use on the TELNET so we can use BUSY-MESSAGE to shut up TELNET. ip host CALLED-LINE 4003 10.3.2.1 ! port 40xx is raw TCP !--- Busy-message cannot have a null string - single space works. busy-message CALLED-LINE \ \ [1] service tcp-keepalives-out [3] ! line 2 !--- Shut up everything. no motd-banner !--- Not available in all versions. no exec-banner no vacant-message autocommand telnet CALLED-LINE /stream autohangup !--- The following command means incoming serial data is saved until the TCP connection is made. ! no flush-at-activation !--- Not available in all feature sets. no activation-character !--- Any character will create the EXEC. escape-character NONE !--- This can also be escape-character BREAK. exec !--- Need an EXEC to do the TELNET. special-character-bits 8 exec-timeout 0 0 session-timeout 0 0 !--- RS232 configuration: no modem inout !--- Disable modem control [2]. no autobaud speed 9600 !--- Set the desired speed. stopbits 1 !--- Alternatively, this can be 2, as desired. flowcontrol NONE !--- Alternatively, this can be HARDWARE, or SOFTWARE. transport input NONE !--- Do not allow reverse connections. |
Appelé latéral |
---|
!--- On called box - 10.3.2.1. no banner incoming service tcp-keepalives-in [3] line 3 no exec no exec-banner no vacant-message !--- RS232 configuration: modem DTR-active !--- DTR indicates the status of the TCP connection. no autobaud speed 2400 !--- As desired. This does not need to match the speed on the called side. stopbits 1 !--- Alternatively, this can be 2, as desired. flowcontrol NONE !--- Alternatively, this can be HARDWARE, or SOFTWARE. transport input telnet !--- Allow the incoming TCP connection. |
[1] Malheureusement, il n'est pas possible de spécifier une commande Null de message d'occupation. Il semble que le message d'occupation minimal est un espace unique. Cela signifie que, si le côté appelant ne parvient pas à établir la connexion TCP au côté appelé, le périphérique appelant envoie une séquence <CR><LF><space> à partir de la ligne RS-232 appelante (une fois pour chaque tentative de connexion sortante). Si la commande flush-at-activation est en vigueur, il y aura une séquence <CR><LF><space> pour chaque caractère envoyé par le périphérique RS-232 appelant. Si la commande no flush-at-activation est en vigueur, le périphérique effectue une boucle, envoyant des séquences <CR><LF><space> jusqu'à ce que la connexion TCP puisse être établie. Avec la commande no flush-at-activation, le périphérique persiste à transmettre les données non sollicitées.
[2] Utilisez la commande no modem inout du côté appelant. Avec la signalisation par modem, si le périphérique voit une augmentation du DSR (Data Set Ready), il lancera la commande automatique. Cependant, si le périphérique est mis hors tension et si le DSR est élevé lorsque le périphérique est allumé, la commande automatique ne sera pas lancée tant qu'une commande clear line n'aura pas été lancée.
[3] S'assurer que les keepalives TCP sont activés des deux côtés pour la connexion d'intérêt ; sinon, si le côté appelant (ou le chemin réseau) tombe en panne, le côté appelé ne sait pas (sauf s'il a des données d'application à envoyer) que la connexion de l'appelant a été abandonnée, ce qui entraîne l'échec de la nouvelle tentative de connexion côté appelant.
Aucune procédure de vérification n'est disponible pour cette configuration.
Cette section fournit des informations que vous pouvez utiliser pour dépanner votre configuration.
Les débogages suivants vérifient que les lignes s'activent et s'arrêtent, et que la session TCP démarre et s'arrête :
configure terminal service timestamp debug date msec end debug modem debug ip tcp packet N !--- Where N is the line of interest.
S'il semble que la transmission tunnel asynchrone échoue de manière transparente à transmettre des données, alors connectez une étendue de données RS-232 aux lignes asynchrones et un analyseur IP au chemin IP au milieu.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
19-Nov-2007 |
Première publication |