IP : Tunnel série (STUN)

Configuration et dépannage de la tunnelisation série (STUN)

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Serial Tunneling (STUN) est le Tunnellisation des trames SDLC à travers un WAN. Dans le monde traditionnel du Systems Network Architecture (SNA), des contrôleurs distants sont reliés au processeur frontal (FEP) par un ensemble de modems relié au-dessus des POTS (réseau téléphonique public commuté) ou des lignes louées.

Avant de commencer

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de Cisco.

Conditions préalables

Le SDLC STUN est le plus utilisé généralement dans deux environnements : FEP au contrôleur distant, et AS/400 au contrôleur distant.

Composants utilisés

Le dépannage STUN utilisant le logiciel de ½ du ¿  de Cisco IOSï commande aussi bien qu'AS/400 aux problématiques spécifiques de contrôleur distant.

Informations générales

Pendant que les réseaux se déplacent vers l'intégration et des bureaux de distant exigent le type de services différent (tels que Netbios, IP, IPX), il a semblé raisonnable d'un point de vue de maintenance et de coût d'intégrer toute la ces derniers dans un à un dispositif. Par exemple, dans le diagramme suivant nous voyons l'intégration de 3270 terminaux à l'hôte avec le trafic de Netbios des stations de Windows.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-3.gif

Le STUN te permet pour utiliser l'IP comme transport des trames de Protocole SDLC (Synchronous Data Link Control) à travers un WAN ou tout autre réseau de medias. Ceci élimine la nécessité d'avoir une ligne louée supplémentaire ou des POTS. Une caractéristique SDLC des Routeurs de Cisco est traduction des médias. Dans la traduction des médias, le routeur traduit la session du SDLC au Logical Link Control, le type-2 (LLC2). Ceci est discuté en détail en comprenant et en dépannant le SDLC à la traduction de supports réseau LLC.

Il y a deux types de configurations STUN : STUN de base et SDLC STUN. L'ancien est utilisé de toutes les trames dérivées de type de High-Level Data Link Control (HDLC) et ce dernier est utilisé des trames SDLC seulement. Le STUN de base peut également être utilisé pour le SDLC, mais des caractéristiques telles que le gens du pays-ACK ne peuvent pas être utilisées. Il est commun pour utiliser le STUN de base pour le SDLC pour dépannage des buts puisque des paramètres de SDLC-particularité n'ont pas besoin d'être configurés sur le routeur.

Configuration STUN

La première commande pour n'importe quelle configuration STUN (de base ou SDLC) est stun peer-name. Sans stun peer-name, le routeur ne vous permettra pas de continuer les étapes de configuration.

Tâche Commande
Enable STUN pour une adresse IP particulière.
stun peer-name ip-address

Vous devez sélectionner une adresse IP valide du routeur. Cette adresse IP devrait être l'interface la plus fiable dans la case. Pour les meilleurs résultats, configurez le routeur avec une interface de bouclage. (Pour se renseigner sur configurer des interfaces de bouclage, référez-vous à la Documentation Cisco).

L'étape suivante est de déterminer le mode STUN que vous voulez utiliser. Un mode est le STUN de base, dans lequel il recherche commencer et délimiteur de la trame [7e], et transporte la trame à l'autre côté. Dans ce mode de fonctionnement, le STUN ne s'inquiète pas de l'état spécifique de la session ou des informations détaillées SDLC, comme l'adresse de sondage. L'autre mode est SDLC STUN. Ce mode exige des décisions plus détaillées dans le routeur, particulièrement si vous exécutez l'accusé de réception local ou n'importe quel type de multipoint. Les commandes utilisées pour spécifier un mode STUN sont décrites dans la table ci-dessous :

Tâche Commande
Spécifiez un groupe de protocole de base et assignez un nombre de groupe.
stun protocol-group group-number basic 
Spécifiez un groupe de protocole SDLC et assignez un nombre de groupe.
stun protocol-group group-number sdlc

L'étape suivante est de configurer l'interface série pour le STUN. Le groupe que vous sélectionnez dans l'interface doit apparier celui défini dans le Protocol-groupe. Avec les multipoints virtuels, vous devriez également créer un stun protocol-group avec des numéros différents pour chacun des multipoints virtuels. Assurez-vous toujours que vous avez configuré seulement une interface secondaire par stun group, à moins que vous configuriez le SDLC-tg. Voir le stun protocol-group.

Tâche Commande
Fonction de l'enable STUN sur une interface série.
encapsulation stun
Placez l'interface à un stun group précédemment défini.
stun group group-number

Remarque: Ne configurez ceci sur un Cisco 7000, le Cisco 7500, ou aucun autre routeur qui a un CxBUS, CyBUS pendant le temps de réseau de production. Cette configuration fait changer le routeur le MTU de l'interface à 2032 octets, que les résultats dans une mémoire tampon CBUS découpent et font toutes les interfaces du routeur rebondir (remise). Dans un environnement Token Ring, il peut signifier que les Anneaux à jeton descendront pendant jusqu'à 16 secondes. En outre, puisque le Cisco 7000 est souvent le centre du noyau où ce type de problème affecte beaucoup d'utilisateurs.

L'étape suivante en configurant le STUN est d'ajouter l'instruction de route de stupéfaction. Vous pouvez définir ceci comme stupéfiez artère toute ou stupéfiez l'artère [adresse]. Les options de configuration sont expliquées ci-dessous.

Tâche Commande
Expédiez tout le trafic TCP pour cette adresse IP.
stun route all tcp ip-address

Spécifiez l'encapsulation de TCP.
stun route address address-number tcp ip-address [priority] [tcp-queue-max]

Les commandes ci-dessus sont pour des homologues d'encapsulation de TCP. Vous pouvez également configurer le STUN pour l'encapsulation directe, mais cette configuration est rarement utilisée. Le plus commun de toutes les configurations est l'installation d'accusé de réception local STUN.

Ces paramètres de commande sont décrits ci-dessous :

  • L'option prioritaire dans l'instruction de route de stupéfaction est utilisée pour créer de plusieurs canaux de TCP entre deux pairs STUN de sorte que des structures prioritaires puissent être créées utilisant la queue faite sur commande ou la queue prioritaire.

  • L'option de tcp_queue_max augmente ou diminue les files d'attente de TCP entre les deux pairs STUN. C'est utile si la session TCP entre les pairs dans pas très fiable et vous doit déterminer ce qui est erroné entre les pairs. Cette option n'est pas utilisée généralement dans des environnements STUN, excepté en faire STUN FEP-À-FEP où beaucoup plus de trafic est impliqué.

Les commandes utilisées pour configurer le STUN avec l'accusé de réception local sont décrites ci-dessous.

Tâche Commande
Assignez au routeur STUN-activé un SDLC rôle primaire.
stun sdlc-role primary
Assignez au routeur STUN-activé un SDLC rôle secondaire.
stun sdlc-role secondary

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-2.gif

Ces commandes définissent le « rôle » de l'installation STUN. Dans le cas de l'hôte dans le diagramme ci-dessus, le routeur est placé à primaire, ainsi il signifie que l'hôte est celui qui initie la session. Ceci rend les 3174 secondaires. En utilisant le STUN de base, vous ne devez pas définir le rôle, parce que vous n'avez pas besoin de savoir qui va initier la session. Mais l'accusé de réception local a besoin des détails de la ligne lui-même et définissant le rôle fait le routeur connaître l'écoulement du démarrage de session, que le routeur doit vérifier avant le déplacement à l'accusé de réception local.

Remarque: Dans des environnements d'AS/400 STUN faisant l'accusé de réception local, il est très important de placer le rôle (sur la ligne description) au *pri de *negative. La raison pour ceci est celle dans un environnement pur (connexion modem directe), AS/400 peut négocier le rôle. En codant le rôle qui nous allons être alignés en, vous pouvez s'assurer que le rôle du routeur est opposé d'AS/400. Vous voulez habituellement qu'AS/400 initie la session (avec « variez sur » de la ligne). Allez à la ligne configuration et établissez ceci pour le *pri. La ligne d'affichage d'AS/400 description est affichée ci-dessous. Ceci peut seulement être fait pendant créent/copies de la ligne description.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-as400-3.gif

La commande de configurer le STUN avec l'accusé de réception local est expliquée ci-dessous.

Tâche Commande
Établissez l'accusé de réception local SDLC utilisant l'encapsulation de TCP.
stun route address address-number tcp ip-address [local-ack] [priority] [tcp-queue-max]

L'important paramètre ici est l'artère de stupéfaction [adresse] avec le gens du pays-ACK. Souvenez-vous que STUN gens du pays-ACK peut être fait avec l'encapsulation et l'Encapsulation de relais de trames de TCP (utilisant le RFC 1490).

Comme dans RSRB et DLSw, le Keepalives dans le STUN circule entre les pairs de TCP pour s'assurer que la connexion homologue est en hausse. Vous pouvez accorder le Keepalives si vos pairs vont down/up en raison de la perte keepalive. Les commandes STUN utilisées pour configurer le Keepalives sont décrites ci-dessous :

Tâche Commande
Détection d'enable d'un pair perdu distant.
stun remote-peer-keepalive seconds

Nombre de fois de tenter une connexion homologue avant de déclarer le pair « vers le bas. » quantité de stun keepalive-count

Configuration d'échantillon de base STUN

Le STUN de base est la configuration la plus simple du STUN. En ce mode, tous les paquets que le routeur reçoit d'un côté sont transportés au prochain. Une configuration de base STUN est affichée dans le diagramme ci-dessous :

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-1.gif

Les Routeurs dans le diagramme ci-dessus sont configurés comme suit :

4700 2522
Current configuration:
!
version 10.3
service udp-small-servers
service tcp-small-servers
!
hostname s5e
!
stun peer-name 10.17.5.1
stun protocol-group 1 basic
!
interface Loopback1
 no ip address
!
interface Serial0
 ip address 10.17.5.1 255.255.255.0
 clockrate 2000000
!
interface Serial1
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun route all tcp 10.17.5.2
!

Current configuration:
!
version 11.0
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname rick
!
stun peer-name 10.17.5.2
stun protocol-group 1 basic
!
interface Serial0
 ip address 10.17.5.2 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial1
 ip address 10.17.92.4 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun route all tcp 10.17.5.1

Configuration d'échantillon SDLC STUN

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-1.gif

4700 2522
Current configuration:
!
version 10.3
service udp-small-servers
service tcp-small-servers
!
hostname s5e
!
stun peer-name 10.17.5.1
stun protocol-group 1 sdlc
!
interface Loopback1
 no ip address
!
interface Serial0
 ip address 10.17.5.1 255.255.255.0
 clockrate 2000000
!
interface Serial1
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role secondary
 sdlc address DD
 stun route address DD tcp 10.17.5.2
!

Current configuration:
!
version 11.0
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname rick
!
stun peer-name 10.17.5.2
stun protocol-group 1 sdlc
!
interface Serial0
 ip address 10.17.5.2 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial1
 ip address 10.17.92.4 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role primary
 sdlc address DD
 stun route address DD tcp 10.17.5.1

Configuration d'échantillon multipoint STUN (avec le gens du pays-ACK)

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-4.gif

4700 2522
hostname s5e
!
!
!
stun peer-name 10.17.5.1
stun protocol-group 1 sdlc
stun remote-peer-keepalive 5
!
interface Serial0
 ip address 10.17.5.1 255.255.255.0
 clockrate 2000000
!
interface Serial1
 no ip address
 encapsulation stun
 idle-character marks
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role secondary
 sdlc K 1
 sdlc address 01
 sdlc address DD
 stun route address 1 tcp 10.17.5.2 local-ack
 stun route address DD tcp 10.17.5.2 local-ack
!

hostname rick
!
!

!
stun peer-name 10.17.5.2
stun protocol-group 1 sdlc
stun remote-peer-keepalive 5
!
interface Serial0
 ip address 10.17.5.2 255.255.255.0
 no fair-queue
 no cdp enable
!
interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role primary
 sdlc address DD
 stun route address DD tcp 10.17.5.1 local-ack
!
interface Serial3
 no ip address
 encapsulation stun
 clockrate 19200
 stun group 1
 stun sdlc-role primary
 sdlc address 01
 stun route address 1 tcp 10.17.5.1 local-ack

Remarque: Sur le routeur AS400, nous avons utilisé SDLC k1 et marques d'inactif-caractère. Référez-vous à la section d'alerte sur site pour plus de détails.

Commandes show

La première commande show utilisée avec le STUN est show stun. La sortie de cette commande dépend de si vous utilisez le STUN de base ou le SDLC STUN avec le gens du pays-ACK. Dans la partie de base STUN affichée ci-dessous, vous voyez seulement des paquets transmis et reçus.

rick#sh stun
This peer: 10.17.5.2
 
 *Serial2  (group 1 [basic])
                              state       rx_pkts   tx_pkts     drops
all     TCP 10.17.5.1        closed           5729      5718         0

Dans le SDLC STUN avec la partie gens du pays-ACK affichée ci-dessous, vous obtenez plus d'informations parce que maintenant l'état de la session est connu.

rick#sh stun
This peer: 10.17.5.2
 
 *Serial2  (group 1 [sdlc])
                              state       rx_pkts   tx_pkts     drops    poll
DD     TCP 10.17.5.1        open       *      182        94         0
 
 
  Serial3  (group 1 [sdlc])
                              state       rx_pkts   tx_pkts     drops    poll
1     TCP 10.17.5.1        open       *      209        89         0
 
SDLC Local Acknowledgement:
 
 *Serial2  (group 1 [sdlc])
                                 slack_state conn disc iframe_s iframe_r
DD     TCP 10.17.5.1                  Active    1    0        0        0
 
  Serial3  (group 1 [sdlc])
                                 slack_state conn disc iframe_s iframe_r
1     TCP 10.17.5.1                  Active    1    0        3        3

La commande d'interface d'exposition fournit également des informations différentes selon si vous exécutez le STUN de base ou le SDLC STUN. L'interface d'exposition pour le STUN de base est identique que pour une ligne série régulière. La Documentation Cisco fournit des explications spécifiques pour chaque entrée de la sortie d'interface d'exposition, un échantillon dont est affiché ci-dessous.

Serial2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input 1:10:40, output 0:18:12, output hang never
  Last clearing of "show interface" counters 0:21:49
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     4 packets output, 312 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

L'interface d'exposition pour le SDLC STUN avec l'accusé de réception local fournit plus d'informations. La sortie témoin pour une interface série avec le gens du pays-ACK est affichée ci-dessous.

Serial3 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
    Router link station role: PRIMARY (DCE)
    Router link station metrics:
      slow-poll 10 seconds
      T1 (reply time out) 3000 milliseconds
      N1 (max frame size) 12016 bits
      N2 (retry count) 20
      poll-pause-timer 10 milliseconds
      poll-limit-value 1
      k (windowsize) 7
      modulo 8
  sdlc addr 01 state is CONNECT
      VS 1, VR 0, Remote VR 1, Current retransmit count 0
      Hold queue: 0/200 IFRAMEs 16/12
      TESTs 0/0 XIDs 0/0, DMs 0/0 FRMRs 0/0
      RNRs 316/0 SNRMs 2/0 DISC/RDs 1/0 REJs 0/0
      Poll: clear, Poll count: 0, ready for poll, chain: 01/01
  Last input 0:00:00, output 0:00:00, output hang never
  Last clearing of "show interface" counters 1d06
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 1 packets/sec
  5 minute output rate 0 bits/sec, 1 packets/sec
     332226 packets input, 664647 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     332227 packets output, 665220 bytes, 0 underruns
     0 output errors, 0 collisions, 3444 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     5 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

Des parties de cette sortie sont expliquées ci-dessous :

  • Le MTU est la taille physique de la mémoire tampon que l'interface utilise.

  • PRIMAIRE (DCI) signifie que c'est le bureau de vote sur le fil et que nous fournissons l'horloge. Si nous regardant le côté qui est relié au vrai primaire, cette sortie aurait été SECONDAIRE.

  • N1 est la valeur de la taille utilisable de la trame SDLC qui peut être facilitée par l'interface série du routeur.

  • Le t1 est la durée que nous nous attendons à une réponse à un balayage avant que la ligne soit synchronisée-.

  • le balayage-pause-temporisateur est le temps delta dans la milliseconde entre les balayages.

  • k est la taille de la fenêtre ou le nombre de trames que nous pouvons avoir l'examen intermédiaire exceptionnel de balayage.

  • l'état est l'état actuel de la session, qui peut être l'un des états ci-dessous :

    • DÉBRANCHEMENT

    • CONNECTÉ

    • THEMBUSY (normalement réglé en raison de ce routeur recevant un RNR.)

    • USBUSY (normalement un résultat de ne pas obtenir une réponse de retour du côté de réseau.)

  • RNRs est le nombre de RNRs a envoyé/reçu.

  • DTR/RTS sont les lignes utilisées dans la plupart des environnements multidrops bidirectionnels-alternés. Quand vous mettez au point n'importe quel environnement STUN et regardez l'emplacement de contrôleur, prêtez la grande attention au RTS. Si ceci descend par intermittence tandis que le DTR et les CTS sont élevés, il est le plus susceptible le résultat du DTE étant bidirectionnel-alterné.

L'importante commande show finale pour le STUN est la commande de show tcp, qui fournit des informations concernant la session TCP entre les pairs. La sortie témoin est affichée ci-dessous :

Stand-alone TCP connection from host 10.17.5.1
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.17.5.2, Local port: 1994
Foreign host: 10.17.5.1, Foreign port: 11035
 
Enqueued packets for retransmit: 0, input: 0, saved: 0
 
Event Timers (current time is 0x1B2E50):
Timer          Starts    Wakeups            Next
Retrans           229          0             0x0
TimeWait            0          0             0x0
AckHold           229          0             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
 
iss: 2847665974  snduna: 2847667954  sndnxt: 2847667954     sndwnd:   9728
irs: 3999497423  rcvnxt: 3999499452  rcvwnd:       9672  delrcvwnd:    568
 
SRTT: 300 ms, RTTO: 607 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 300 ms, ACK hold: 300 ms
Flags: passive open, higher precedence
 
Datagrams (max data segment is 1460 bytes):
Rcvd: 459 (out of order: 0), with data: 229, total data bytes: 2028
Sent: 457 (retransmit: 0), with data: 228, total data bytes: 1979

Dépannage

Le dépannage d'une configuration STUN est identique qu'avec n'importe quelle convention peer-to-peer. Si vous rencontrez des problèmes dans le transport, ceci doit être diagnostiqué avant que vous puissiez commencer dépanner la partie SDLC/STUN. Habituellement, la première étape est de cingler du pair pour scruter pour s'assurer que l'IP est installé correctement. En outre, ping avec les types de paquet étendus pour s'assurer que le transport est fiable.

Dépannage du SDLC de base

Cette section couvre dépanner une installation de base STUN. Dans cet exemple, supposez que le WAN fonctionne correctement.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-1.gif

Ce scénario a une installation de base STUN pour connecter les 5494 à AS/400. La première chose à vérifier avec n'importe quelle installation STUN est que les pairs sont installés dans le routeur. Pour déterminer ceci, utilisez l'ordre de pair de show stun. Lui fournit des informations au sujet de l'état du pair et les paquets qui ont été transmis/reçus. La sortie témoin est affichée ci-dessous :

rick#sh stun peer
This peer: 10.17.5.2

 *Serial2  (group 1 [basic])
                              state       rx_pkts   tx_pkts     drops
all     TCP 10.17.5.1        open             5729      5718         0

Si le pair est ouvert, comme ci-dessus, employez l'interfacecommand d'exposition pour déterminer ce qui arrive aux paquets. La sortie témoin pour cette commande est affichée ci-dessous :

Serial2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input 1:10:40, output 0:18:12, output hang never
  Last clearing of "show interface" counters 0:21:49
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     4 packets output, 312 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

D'abord, vérifiez si le routeur a les tous les signaux séquentiels. Au bas de la sortie ci-dessus, nous pouvons voir que tous les signaux sont « vers le haut de » pour le "Serial2" sur les 2522. Le DTR et le RTS indiquent que le contrôleur a déjà lancé la ligne elle-même et attend AS/400 pour envoyer la conversation initiale.

Ensuite, vérifiez l'interface d'exposition pour le côté d'AS/400 du routeur. Dans le résultat présenté ci-dessous, nous voyons que l'interface série qui se relie à AS/400 est en baisse/vers le bas. Ceci signifie qu'AS/400 « est varié probablement hors fonction. » Si la ligne « est variée sur » et vous ne pouvez pas obtenir la ligne ou êtes s'exécuter bidirectionnel-alterné, alors vous devez vérifier la connexion RS-232/V.35.

Serial1 is down, line protocol is down
  Hardware is HD64570
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input never, output 1:51:24, output hang never
  Last clearing of "show interface" counters 0:00:01
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=down  RTS=down  CTS=up
s5e#

En ce moment, vérifiez le « travail avec l'état de configuration » pour ce contrôleur spécifique, qui est un écran d'AS/400 qui ressemble à :

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-as400-1.gif

Ensuite, variez sur la ligne définition. Vous devriez alors voir que le routeur va la ligne /up. Si la ligne est soulevée /up mais le contrôleur ne monte toujours pas, vérifiez l'interface pour vérifier si des paquets ont frappé l'interface d'arrivée d'AS/400. Si le compte est zéro, vérifiez le mécanisme de codage pour la ligne SDLC sur AS/400. Ceci se trouve sur la ligne d'affichage description, comme affiché ci-dessous.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-as400-4.gif

Remarque: Sur cet écran, nous pouvons voir que le codage de ligne est placé pour le codage NRZI. Ceci doit être activé avec le nrzi-encoding d'option de configuration sur le routeur.

Cette installation n'exige pas NRZ/NRZI encodant de bout en bout, comme dans les conventions point par point conventionnelles SDLC, mais peut être NRZI sur un côté et NRZ sur l'autre. Mais souvenez-vous que le codage doit être identique entre les périphériques qui partagent la ligne SDLC.

NRZI exige la prise en considération soigneuse. Dans les nouveaux Routeurs comme le Cisco 2500 et les 4500, NRZI est placé par l'intermédiaire du logiciel. Mais avec des Plateformes plus anciennes, y compris le NP-2T pour Cisco 4000, vous devez changer les cavaliers sur les panneaux eux-mêmes. En pareil cas, il est probablement plus facile de changer AS/400 à NRZ/NRZI. Mais, si vous devez changer les cavaliers, référez-vous à la documentation technique de Cisco pour votre plate-forme spécifique.

Si le problème persiste, faites un debug stun packet 1. Cette commande nous fournit les informations suivantes :

STUN basic: 0:00:35 Serial1         SDI:   Data: c0bf324c056452530000
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
%LINK-3-UPDOWN: Interface Serial1, changed state to down
STUN basic: 0:00:38 Serial1         SDI:   Data: c0bf324c056452530000
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
%LINK-3-UPDOWN: Interface Serial1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
STUN basic: 0:00:35 Serial1         SDI:   Data: c0bf324c056452530000
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down
%LINK-3-UPDOWN: Interface Serial1, changed state to down

Vous pouvez voir plusieurs XIDs circulant d'AS/400, mais il n'y avait aucune réponse à eux (la Co est l'adresse de sondage et le FB est le XID). Nous savons que le paquet provient AS/400 parce que le paquet a provenu du SDI. Il y a deux types de paquets entrant dans cette sortie de commande :

  • SDI : Entrant séquentiel, qui est des paquets a reçu de l'interface SDLC.

  • NDI : Le réseau entrant, qui sont des paquets De-s'est encapsulé du WAN.

Ensuite, regardez la partie XID de la trame elle-même. Dans cet exemple, AS/400 envoie un XID avec son IDBLOCK et IDNUM, 05645253.

C'est une question de délai d'attente, parce que le contrôleur ne répond pas. Dans AS/400, regardez la « file d'attente de messages de sysopr » pour voir s'il y a des messages indiquant un problème. Un écran « SYSOPR » avec une panne est affiché ci-dessous.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-as400-2.gif

Maintenant sur les 2522, activez le debug stun packet 1 pour voir si les paquets obtiennent envoyaient au contrôleur. L'exemple de sortie de commande est affiché ci-dessous :

STUN basic: 0:00:34 Serial2         NDI:   Data: c0bf324c056452530000
STUN basic: 0:00:42 Serial2         NDI:   Data: c0bf324c056452530000

Ceci nous prouve que le XID qui a lancés du côté d'AS/400 obtient au contrôleur, mais le contrôleur ne répond pas, ainsi il signifie que c'est un problème de contrôleur. Une interface d'exposition nous affiche si toute la piste de contrôle est ou pas :

Serial2 is up, line protocol is up
  Hardware is CD2430 in sync mode
  MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation STUN, loopback not set
  Last input 0:50:56, output 0:00:23, output hang never
  Last clearing of "show interface" counters 0:02:06
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     1 packets output, 78 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

La piste de contrôle est les expositions up/up hautes et d'interface. Nous pouvons également voir que le routeur sort des paquets, mais aucun paquet n'est entrant. Ceci indique l'adresse de sondage incorrecte configurée sur AS/400, ainsi l'étape suivante est de vérifier l'adresse de sondage du contrôleur.

Chaque type de contrôleur a une façon unique de configurer l'adresse de sondage, ainsi vous devez vérifier ceci avec les manuels de contrôleur pour votre contrôleur.

Dans cet exemple, nous fondons que le contrôleur utilisait l'adresse de sondage de la « densité double. » Après avoir changé ceci sur AS/400, la sortie du debug stun packet devient :

STUN basic: 0:24:03 Serial2         NDI:   Data: ddbf324c056452530000
STUN basic: 0:00:00 Serial2         SDI:   Data: ddbf3244073000dd0000
STUN basic: 0:00:00 Serial2         NDI:   Data: dd93
STUN basic: 0:00:00 Serial2         SDI:   Data: dd73
STUN basic: 0:00:00 Serial2         NDI:   Data: dd11
STUN basic: 0:00:00 Serial2         SDI:   Data: dd11
STUN basic: 0:00:00 Serial2         NDI:   Data: dd11
STUN basic: 0:00:00 Serial2         SDI:   Data: dd102f00000200016b80
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         SDI:   Data: dd11
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         SDI:   Data: dd11
.
.
.
.
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         SDI:   Data: dd71
STUN basic: 0:00:00 Serial2         NDI:   Data: dd362f00020080004b80
STUN basic: 0:00:00 Serial2         NDI:   Data: dd31
STUN basic: 0:00:00 Serial2         NDI:   Data: dd53
STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Cette sortie de débogage aide à déterminer les informations suivantes :

STUN basic: 0:24:03 Serial2         NDI:   Data: ddbf324c056452530000

Cette ligne contient le XID d'AS/400 au contrôleur. Ceci provient le NDI (provenant le nuage), la densité double (adresse de sondage), le FB (le XID), et l'IDBLOCK et l'IDNUM (05645253).

STUN basic: 0:00:00 Serial2         SDI:   Data: ddbf3244073000dd0000

C'est la réponse du contrôleur. Ceci est indiqué par le SDI (provenant la ligne SDLC) et les mêmes qu'en haut, excepté la réponse XID (073000dd), parce que c'est des 5494.

STUN basic: 0:00:00 Serial2         NDI:   Data: dd93

C'est le SNRM (93)from AS/400 au contrôleur, qui est le primaire dans cette configuration.

STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Ici nous voyons le contrôleur répondre (SDI) avec un uA (73), ainsi il signifie que la session est en service. Ensuite, nous devrions voir le débranchement provenir AS/400 pendant que la ligne était variée hors fonction.

STUN basic: 0:00:00 Serial2         NDI:   Data: dd53
STUN basic: 0:00:00 Serial2         SDI:   Data: dd73

Ces lignes affichent le DISQUE (53) et la réponse uA. La ligne est maintenant vers le bas. Être suit une table avec des valeurs requises pour mettre au point ces questions.

Champ de contrôle - Non-numéroté (1 octet)
000z 0011  
0001 0111  
0001 0111  
0001 1111  
0011 0011  
0101 0011  
0101 0011  
0101 0011  
0111 0011  
1001 0011  
1001 0111  
101z 1111  
110z 0111  
111z 0011  
 
03-13    UI  
07-17    SIM  
07-17    RIM  
0F-1F    DM  
23-33    UP  
43-53    DISC  
43-53    RD  
43-53    RD  
63-73    UA  
83-93    SNRM  
87-97    FRMR  
AF-BF    XID  
C7-D7    CFGR  
E3-F3    TEST  
 
Unnumbered Information   
Set Initialization mode  
Request Intialization Mode   
Secondary in Disconnect Mode  
Unumber Poll  
Disconnect  
Request Disconnect  
Secondary Requests Disconnect  
Unnumbered Acknowledgement  
Set Normal Response Mode  
Frame Reject  
Exchange Identification  
Configure  
I-Field contains test pattern 
   

Champ de contrôle - De surveillance (2 octets)
rrrz cc01  
rrrz 0001  
rrrz 0101  
rrrz 1001  

 
xx-xx  
x1-x1  
x5-x5  
x9-x9  
 
 
Supervisory Format  
Receiver Ready  
Receiver Not Ready  
Reject  
  
   

Champ de contrôle - Trames d'informations (2 octets)
rrr1 sssz 

 
xx-xx
 
 
Information format
  
   

Clé :

z = le bit final de balayage peut être 0 ou 1

rrr = nombre de bloc prévu pour être reçu

sss = nombre de bloc étant envoyé

Dépannage du SDLC STUN avec et sans l'accusé de réception local

Cette section couvre le même scénario d'accusé de réception local configuré.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-4.gif

Contrairement au STUN de base, le SDLC STUN exige que vous spécifiez l'adresse de sondage correcte ou le routeur ne verra pas même les paquets entrés. C'est pourquoi parfois le STUN de base est utilisé pour trouver l'adresse de sondage quand vous n'avez pas les informations, ou ne peut pas obtenir à l'hôte ou à l'AS/400. Le diagramme ci-dessus affiche un scénario multipoint avec le gens du pays-ACK.

Dans un environnement point par point traditionnel, l'interrogation va de bout en bout. Quand l'accusé de réception local est présenté, l'interrogation est terminée à chaque extrémité du nuage, ainsi chaque routeur doit mettre à jour une machine à état défini. Cet ordinateur maintient toutes les sessions et doit connaître l'état de la ligne pour chaque station votée. Pour cette raison, vous devez s'assurer que les stations suivent le protocole SDLC.

D'abord, vérifiez que vous êtes dans le rôle correct STUN. AS/400s ont le problème étant en pourparlers le rôle avec le contrôleur dans les environnements point par point traditionnels. La ligne description est affichée ci-dessous.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-5.gif

Ceci nous prouve que l'interface de routeur a besoin configuré pour un rôle secondaire. Toujours vérifiez la ligne et la vérifiez que c'est *PRI, parce qu'AS/400 se transfère sur *NEGATIVE quand vous le créez. NRZI est placé à *YES, ainsi vous devez coder le nrzi-encoding. En outre, les marques d'inactif-caractère de code et placent la fenêtre à un (1) utilisant le sdlc k 1. (référez-vous à l'alerte sur site FNA-IOS-0696-02 pour une description en profondeur de pourquoi des marques d'inactif-caractère est exigées sur l'interface.) Ce codage est affiché ci-dessous :

interface Serial1
no ip address
encapsulation stun
idle-character marks
nrzi-encoding 
clockrate 56000 (real clockrate on the line; see note about as400 line speed)
stun group 1
stun sdlc-role secondary (this must be secondary because the line is primary)
sdlc K 1
sdlc address 01
sdlc address DD
stun route address 1 tcp 10.17.5.2 local-ack
stun route address DD tcp 10.17.5.2 local-ack

Remarque: La synchronisation que le routeur fournit est indépendant du paramètre de vitesse linéaire qui est configuré sur la ligne d'AS/400. (Ce paramètre est utilisé pour des calculs de représentation ; il peut être laissé au par défaut de 9600.) L'identifiant d'échange qui est configuré sur la ligne est celui d'AS/400, tel que le XID qu'AS/400 enverra. Les contrôleurs maximum est le nombre de nombre de pus (contrôleurs) qui peut être créé et relié à cette ligne.

Le premier des deux contrôleurs reliés à cette ligne, IBM 5494, est affiché dans l'écran ci-dessous.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-6.gif

Nous pouvons voir que le premier contrôleur va être une unité centrale 2.1 parce que la catégorie du contrôleur est « *APPC. » C'est l'abréviation pour les transmissions anticipées de Programme-à-programme, qui peuvent seulement faire par l'intermédiaire d'une connexion T2.1. L'identifiant de réseau distant est de nouveau lié à APPN/APPC et désigné sous le nom du « NETID. » « *NETATR » est un paramètre qui spécifie utilisant le NETID défini dans la zone de données appelée les « attributs de réseau. » Vous pouvez afficher cette zone de données utilisant la commande DSPNETA, et substituez les valeurs en conséquence. « Le point à télécommande » ou « CP_name » est le nom de point de contrôle que vous avez configuré dans le PU2.1. Dans ce cas, c'est CP5494. Le rôle de liaison de données peut être laissé comme *NEGATIVE. La « adresse de station » doit apparier « la densité double d'adresse SDLC » qui a été configurée sur l'interface secondaire aussi bien qu'une des interfaces principales.

interface Serial2
 no ip address
 encapsulation stun
 nrzi-encoding
 clockrate 56000
 stun group 1
 stun sdlc-role primary
 sdlc address DD
 stun route address DD tcp 10.17.5.1 local-ack

Vous pouvez voir que la majeure partie des informations qui résident dans la description de contrôleur est ayant trait à l'unité physique elle-même, et non configurable dans le routeur.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-7.gif

Sur cet écran, le deuxième contrôleur (unité centrale) est réellement des 3174, qui est un type-2 unité centrale. Le XID configuré dans ces 3174 est 05600001. La « adresse de station », ou l'adresse SDLC, étant utilisé est 01. Vous avez besoin d'une « adresse 01" configuré sur l'interface secondaire et une SDLC des interfaces principales distantes. Comme vous pouvez voir ci-dessous, la configuration pour un PU2 est moins impliquée qu'un PU2.1.

interface Serial3
 no ip address
 encapsulation stun
 clockrate 19200
 stun group 1
 stun sdlc-role primary
 sdlc address 01
 stun route address 1 tcp 10.17.5.1 local-ack

Les attributs de réseaux d'affichage (DSPNETA) dans AS/400 est affichés ci-dessous :

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-8.gif

Cet écran prouve qu'AS/400 est actuellement configuré pour l'ID « NETA de réseau, » ce qui signifie que les 5494 besoins d'être configuré pour le même réseau. Ceci, aussi bien que le reste de la configuration d'APPN-particularité, peuvent être trouvés sur le deuxième écran de configuration dans les 5494. Le nom local de point de contrôle d'AS/400 est "RTP400A." que le nom LU d'AS/400 est "LU9404;" ceci doit apparier avec ce qui est configuré dans le menu de définition LU du partenaire 5494's. La description de mode qui est utilisée par les 5494 besoins d'apparier ce qui est dans la description du périphérique. Par exemple, si le périphérique indique « *NETATR, » alors il doit apparier le par défaut du « BLANC ».

La description du périphérique APPC créée pour les 5494 est affichée ci-dessous.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-9.gif

Cet écran prouve que la description du périphérique pour les 5494 a un nom du distant CP de "CP5494;" que ceci doit apparier ce qui est configuré sur les 5494. Les NETID et l'emplacement local se sont transférés sur « *NETATR, » qui ont été codés à LU9404 et à NETA dans l'exemple précédent. De nouveau, ceux-ci doivent apparier le nom LU de partenaire et des champs NETID dans les 5494.

L'élément final de la configuration de périphérique qui est ayant trait à obtenir une connexion établie est affiché ci-dessous.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-10.gif

Cet écran prouve que le mode étant utilisé sur la description du périphérique est « QRMTWSC. » Ce n'est pas le par défaut trouvé dans le *NETATR, de sorte que signifie qu'il a été ignoré dans la description du périphérique. C'est l'un des modes par défaut fournis par IBM en tant qu'élément du support de la base APPN sur AS/400. Si vous voyez n'importe quoi différent, contactez IBM, parce qu'ils s'exécutent avec une description de mode qu'ils ont créée. Cet exemple établit une connexion de base ; si vous voulez afficher les informations sur les modes disponibles vous pouvez utiliser la commande WRKMODD ou fonctionner des descriptions de mode.

La description de mode est affichée ci-dessous.

http://www.cisco.com/c/dam/en/us/support/docs/ip/serial-tunnel-stun/16398-stun-11.gif

Cet écran identifie clairement les définitions de mode fournies par IBM.

Dépannage de l'interface multipoint de bidirectionnel simultané SDLC

En faire l'accusé de réception local dans un environnement multipoint avec AS/400s, rendez-vous compte de la façon dont la « interface multipoint bidirectionnelle simultanée SDLC » a été mise en application sur AS/400, les mini-mainframes SYS/38, et SYS/36. L'alerte sur site FNA-IOS-0696-02 (incluse ci-dessous) explique le type de problèmes qui peuvent se poser dans cette situation.

Brève description

Détection Onde Porteuse » se connectante de modification du câble de routeur la « à rectifier n'empêchera pas la ligne périodique remises SDLC d'AS/400 si AS/400 a eu IBM PTF# MF10030 appliqué. Cette alerte s'applique seulement aux connexions bidirectionnelles simultanées de multi-baisse STUN à AS/400 où le câble SDLC de routeur a été modifié pour désactiver la Détection Onde Porteuse.

Incidence

Les utilisateurs peuvent éprouver la remise périodique de la connexion STUN et de tous les périphériques secondaires SDLC, ayant pour résultat une connexion peu fiable.

Description complète/fond

Dans un environnement de multi-baisse, AS/400 se comporte différemment d'autres périphériques IBM. Considérant qu'un FEP reçoit des caractères les caractères 0x7E (indicateurs) ou le 0xFF (marques) en tant qu'espace « de veille » entre les indicateurs de trames, de festins d'AS/400 et les marques différemment. Seulement une marque est interprétée comme caractère de veille. Un indicateur est interprété pour signifier que la « ligne est encore en activité - plus de données sont en suspens. » Un routeur de Cisco peut être configuré pour envoyer des indicateurs ou des marques mais pas chacun des deux. Il n'alternera pas entre les deux pour refléter l'état de la ligne. Le par défaut est pour que le routeur envoie des indicateurs.

Cette différence pose un problème dans les environnements bidirectionnels simultanés de multi-baisse. Normalement AS/400 va du périphérique au périphérique, votant chacun pour des données. Si un périphérique ne répond pas et AS/400 pense que la ligne est encore en activité, elle remettra à l'état initial la ligne entière. Puisque le par défaut est pour que le routeur envoie des indicateurs, AS/400 toujours verra une ligne active et rayera la remise au lieu de voter simplement le périphérique suivant.

Pour éviter ce problème, Cisco a historiquement recommandé une modification du câble qui désactive le signal de Détection Onde Porteuse (CD). Cette modification tire profit de la logique d'AS/400 qui interprète l'absence du transporteur pour signifier « l'état de la ligne de veille. » Par conséquent, avec la modification, AS/400 détecte toujours l'état de la ligne de veille indépendamment des caractères d'inter-trame étant envoyés par le routeur. Ainsi, si un périphérique secondaire ne répond pas, AS/400 vérifiera le CD, verra une ligne de veille et passera pour voter la prochaine station.

Récemment, IBM a libéré la difficulté PTF# MF10030 de problème d'AS/400 qui change la logique de Détection Onde Porteuse sur des lignes pour plusieurs destinataires. Cette difficulté étant installé, AS/400 ignore complètement l'état de CD sur les lignes pour plusieurs destinataires bidirectionnelles simultanées. En conséquence, la modification de câble Cisco n'est plus efficace à empêcher la ligne périodique remises.

Contournement

Deux contournements sont disponibles, selon le modèle de routeur et la version de s'exécuter de Cisco IOS. Les deux options exigent des modifications de configuration au routeur connecté à AS/400.

Option 1

Changez le caractère de veille SDLC du caractère par défaut d'indicateur à un caractère de marque. Le caractère de veille peut être changé utilisant la commande de configuration d'interface de routeur :

idle-character marks 

Ajoutez cette commande à l'interface série SDLC connectée à AS/400. Cette commande fera transmettre toujours le routeur des caractères de marque pour une pause entre les trames. Ainsi, si un périphérique secondaire manque un balayage, AS/400 verra une ligne de veille et passera pour voter le périphérique suivant. Malheureusement, ceci signifie également qu'AS/400 verra l'inactif même si plus de trames de données sont sur le chemin du périphérique. AS/400 reconnaîtra seulement la première trame, même si le balayage/bit final est 0. Il alors ignorera toutes les trames ultérieures et votera le périphérique suivant entraînant les retransmissions inutiles de trame. Pour éviter les retransmissions, vous devez également fixer la taille de la fenêtre SDLC à 1 avec la commande :

sdlc k 1 

Remarque: La commande d'inactif-caractère est prise en charge dans la version 10.0(5.2) et ultérieures de Cisco IOS, et travaille aux Routeurs 2500s, 4x00 avec NP-4T, et 70x0/75xx.

Option 2

Activez la détection des périphériques secondaires inactifs avec la commande d'interface :

stun quick-response

Cette commande fera répondre le routeur avec une trame « de mode de débranchement » (DM) pour n'importe quel périphérique secondaire inactif voté par AS/400. AS/400 poursuivra alors pour voter le périphérique suivant sans remettre à l'état initial la ligne.

Remarque: Cette commande est prise en charge dans le Cisco IOS 11.1, 11.0(3.1) et plus tard ou 10.3(7.2) et plus tard.

Conseil : Si vous rencontrez n'importe quels problèmes évoquant la ligne multipoint avec la rapide-réponse configurée, utilisez l'option 1. Le code de stun quick-response dans le routeur fait partie de la machine à état défini pour le gens du pays-ACK, qui peut sortir de l'étape avec du pus. Nous avons testé le code dans le laboratoire et avons vérifié son Interopérabilité avec les 5494, les 5394, et le Perl494E. Il est possible de rencontrer des problèmes si l'unité centrale que vous essayez de se relier a des temporisateurs réglés différemment de ce que le quick_response compte.


Informations connexes


Document ID: 16398