Introduction

La transmission tunnel série (STUN) est la transmission tunnel des trames SDLC sur un WAN. Dans le monde traditionnel de l'architecture de réseau de systèmes (SNA), les contrôleurs distants sont connectés au processeur frontal (FEP) par le biais d'un ensemble de modems connectés via POTS (Plain Old Telephone Service) 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

STUN SDLC est généralement utilisé dans deux environnements : FEP vers contrôleur distant et AS/400 vers contrôleur distant.

Components Used

Dépannage STUN à l'aide des commandes du logiciel Cisco IOS® ainsi que des problèmes spécifiques au contrôleur distant AS/400.

Informations générales

À mesure que les réseaux évoluent vers l'intégration et que les bureaux distants ont besoin de différents types de services (tels que NetBIOS, IP, IPX), il est logique, du point de vue de la maintenance et des coûts, d'intégrer tous ces services dans un seul périphérique. Par exemple, dans le schéma suivant, nous voyons l'intégration de 3270 terminaux à l'hôte avec le trafic NetBIOS des stations Windows.

STUN vous permet d'utiliser IP comme transport pour les trames SDLC (Synchronous Data Link Control) sur un WAN ou un autre réseau multimédia. Cela évite d'avoir besoin d'une ligne louée supplémentaire ou d'un POTS. La traduction multimédia est l’une des fonctions SDLC des routeurs Cisco. Dans la traduction de support, le routeur traduit la session de SDLC en Logical Link Control, type 2 (LLC2). Cette question est traitée en détail dans Présentation et dépannage de la traduction de supports réseau SDLC vers LLC.

Il existe deux types de configuration STUN : STUN Basic et STUN SDLC. La première est utilisée pour les trames de type dérivé HDLC (High-Level Data Link Control) et la seconde pour les trames SDLC uniquement. STUN Basic peut également être utilisé pour SDLC, mais des fonctionnalités telles que local-ack ne peuvent pas être utilisées. Il est courant d’utiliser STUN Basic pour SDLC à des fins de dépannage, car les paramètres spécifiques à SDLC n’ont pas besoin d’être configurés sur le routeur.

Configuration STUN

La première commande pour toute configuration STUN (Basic ou SDLC) est stun peer-name. Sans stun peer-name, le routeur ne vous permet pas de poursuivre les étapes de configuration.

stun peer-name ip-address

Vous devez sélectionner une adresse IP valide dans le routeur. Cette adresse IP doit être l’interface la plus fiable du boîtier. Pour obtenir les meilleurs résultats, configurez le routeur avec une interface de bouclage. (Pour en savoir plus sur la configuration des interfaces de bouclage.

L'étape suivante consiste à déterminer le mode STUN à utiliser. Un mode est STUN Basic, dans lequel il recherche le démarrage et le délimiteur de la trame [7e], et transporte la trame vers l'autre côté. Dans ce mode de fonctionnement, STUN ne se soucie pas de l'état spécifique de la session ou des informations détaillées du SDLC, comme l'adresse d'interrogation. L’autre mode est STUN SDLC. Ce mode nécessite des décisions plus détaillées dans le routeur, en particulier si vous exécutez un accusé de réception local ou tout type de multipoint. Les commandes utilisées pour spécifier un mode STUN sont décrites dans le tableau ci-dessous :

stun protocol-group group-number basic 

stun protocol-group group-number sdlc

L'étape suivante consiste à configurer l'interface série pour STUN. Le groupe que vous sélectionnez dans l'interface doit correspondre à celui défini dans le groupe de protocoles. Avec les multipoints virtuels, vous devez également créer un groupe de protocoles stun avec des numéros différents pour chacun des multipoints virtuels. Assurez-vous toujours que vous n'avez configuré qu'une seule interface secondaire par groupe stun, sauf si vous configurez sdlc-tg. Voir stun protocol-group.

encapsulation stun

stun group group-number

Remarque : Ne configurez pas ce paramètre sur un Cisco 7000, un Cisco 7500 ou tout autre routeur doté d'un CxBUS, CyBUS pendant la durée du réseau de production. Cette configuration fait que le routeur modifie la MTU de l'interface en 2032 octets, ce qui entraîne une taille de tampon CBUS et fait rebondir (réinitialiser) toutes les interfaces du routeur. Dans un environnement Token Ring, cela peut signifier que les Token Ring descendent pendant 16 secondes. En outre, le Cisco 7000 est souvent au centre des préoccupations de nombreux utilisateurs.

L'étape suivante de la configuration de STUN consiste à ajouter l'instruction stun route. Vous pouvez définir ceci comme route stun all ou route stun [adresse]. Les options de configuration sont expliquées ci-dessous.

stun route all tcp ip-address

stun route address address-number tcp ip-address [priority] [tcp-queue-max]

Les commandes ci-dessus sont destinées aux homologues d’encapsulation TCP. Vous pouvez également configurer STUN pour l'encapsulation directe, mais cette configuration est rarement utilisée. La configuration la plus courante est la configuration de l'accusé de réception local STUN.

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

• L'option priority de l'instruction stun route est utilisée pour créer plusieurs canaux TCP entre deux homologues STUN afin que les structures de priorité puissent être créées à l'aide de la mise en file d'attente personnalisée ou de la mise en file d'attente prioritaire.

• L'option tcp_queue_max augmente ou diminue les files d'attente TCP entre les deux homologues STUN. Ceci est utile si la session TCP entre les homologues n'est pas très fiable et que vous devez déterminer ce qui ne va pas entre les homologues. Cette option n'est pas couramment utilisée dans les environnements STUN, sauf lors de STUN FEP-to-FEP où beaucoup plus de trafic est impliqué.

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

stun sdlc-role primary

stun sdlc-role secondary

Ces commandes définissent le « rôle » de la configuration STUN. Dans le cas de l’hôte dans le schéma ci-dessus, le routeur est défini sur principal, ce qui signifie que l’hôte est celui qui initie la session. Le 3174 est donc secondaire. Lorsque vous utilisez STUN Basic, vous n'avez pas besoin de définir le rôle, car vous n'avez pas besoin de savoir qui va lancer la session. Mais l’accusé de réception local nécessite des détails sur la ligne elle-même et la définition du rôle permet au routeur de connaître le flux du démarrage de la session, que le routeur doit vérifier avant de passer à l’accusé de réception local.

Remarque : Dans les environnements STUN AS/400 faisant un accusé de réception local, il est très important de définir le rôle (sur la description de ligne) sur *pri à partir de *neg. La raison en est que dans un environnement pur (connexion directe par modem), l'AS/400 peut négocier le rôle. En codant le rôle que nous allons jouer dans la ligne, vous pouvez vous assurer que le rôle du routeur est opposé à celui de l'AS/400. En règle générale, vous voulez que l'AS/400 lance la session (avec « varier sur » la ligne ). Accédez à la configuration de ligne et configurez-la pour *pri. La description de la ligne d'affichage AS/400 est présentée ci-dessous. Cela ne peut être fait que lors de la création/copie de la description de ligne.

La commande permettant de configurer STUN avec un accusé de réception local est expliquée ci-dessous.

stun route address address-number tcp ip-address [local-ack] [priority] [tcp-queue-max]

Le paramètre important ici est la route stun [adresse] avec local-ack. Rappelez-vous que STUN local-ack peut être effectué avec l'encapsulation TCP et l'encapsulation Frame Relay (à l'aide de la RFC 1490).

Comme dans RSRB et DLSw, conserve le flux STUN entre les homologues TCP pour s'assurer que la connexion homologue est active. Vous pouvez régler les messages de test d'activité si vos homologues sont en panne ou en hausse en raison de la perte de test d'activité. Les commandes STUN utilisées pour configurer les keepalives sont décrites ci-dessous :

stun remote-peer-keepalive seconds

Exemple de configuration STUN

STUN Basic est la configuration la plus simple de STUN. Dans ce mode, tous les paquets que le routeur reçoit d’un côté sont transportés au suivant. Une configuration STUN Basic est présentée dans le schéma ci-dessous :

Les routeurs du schéma ci-dessus sont configurés comme suit :

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

Exemple de configuration STUN SDLC

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

Exemple de configuration STUN multipoint (avec local-ack)

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 des marques de caractères inactifs. Reportez-vous à la section Alerte de champ pour plus de détails.

Commandes show

La première commande show utilisée avec STUN est show stun. La sortie de cette commande dépend de l'utilisation de STUN Basic ou STUN SDLC avec local-ack. Dans la partie STUN Basic illustrée ci-dessous, seuls les paquets transmis et reçus sont visibles.

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 locale-ack ci-dessous, vous obtenez plus d'informations car 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 show interface fournit également des informations différentes selon que vous exécutez STUN Basic ou STUN SDLC. L'interface show pour STUN Basic est identique à celle d'une ligne série classique.

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

La show interface pour STUN SDLC avec accusé de réception local fournit plus d'informations. Un exemple de sortie pour une interface série avec local-ack est présenté 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

Certaines parties de ce résultat sont expliquées ci-dessous :

• MTU est la taille physique de la mémoire tampon utilisée par l'interface.

• PRIMARY (ETCD) signifie qu’il s’agit du bureau de vote sur le câble et que nous fournissons l’horloge. Si nous regardions le côté qui est attaché au vrai primaire, ce résultat aurait été SECONDAIRE.

• N1 est la valeur de la taille utilisable de la trame SDLC qui peut être prise en charge par l’interface série du routeur.

• T1 est le délai pendant lequel nous attendons une réponse à un sondage avant que la ligne ne soit dépassée.

• poll-pause-timer est la durée delta en ms entre les interrogations.

• k est la taille de la fenêtre ou le nombre de cadres que nous pouvons avoir en suspens entre les finales du scrutin.

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

  • DISCONNECT

  • CONNECTÉ

  • THEMBUSY (normalement défini par suite de la réception d’une RNR par ce routeur)

  • USBUSY (généralement en raison de l'absence de réponse du côté réseau).

• RNR est le nombre de RNR envoyées/reçues.

• DTR/RTS sont les lignes utilisées dans la plupart des environnements de multidiffusion bidirectionnel non simultané. Lorsque vous déboguez un environnement STUN et que vous regardez l'emplacement du contrôleur, prêtez une attention particulière à RTS. Si cela tombe en panne de façon intermittente alors que DTR et CTS sont élevés, il est probable que le résultat de l’ETTD soit bidirectionnel non simultané.

La dernière commande importante show pour STUN est la commande show tcp, qui fournit des informations sur la session TCP entre homologues. Un exemple de sortie est présenté 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 à toute convention peer-to-peer. Si vous rencontrez des problèmes dans le transport, vous devez les diagnostiquer avant de commencer le dépannage de la partie SDLC/STUN. En général, la première étape consiste à envoyer une requête ping d’un homologue à l’autre pour s’assurer que le protocole IP est correctement configuré. En outre, envoyez une requête ping avec des types de paquets étendus pour vous assurer que le transport est fiable.

Dépannage de base de SDLC

Cette section traite du dépannage d'une configuration STUN Basic. Dans cet exemple, supposez que le WAN fonctionne correctement.

Ce scénario dispose d'une configuration STUN Basic pour connecter le 5494 à l'AS/400. La première chose à vérifier avec toute configuration STUN est que les homologues sont configurés dans le routeur. Pour le déterminer, utilisez la commande show stun peer. Il fournit des informations sur l'état de l'homologue et les paquets qui ont été transmis/reçus. Un exemple de sortie est présenté 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 l'homologue est ouvert, comme ci-dessus, utilisez la commande show interfacecomet pour déterminer ce qui arrive aux paquets. Un exemple de résultat pour cette commande est présenté 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

Tout d’abord, vérifiez si tous les signaux série du routeur sont activés. Au bas de la sortie ci-dessus, nous pouvons voir que tous les signaux sont « up » pour le « Serial2 » sur le 2522. DTR et RTS indiquent que le contrôleur a déjà activé la ligne elle-même et attend que l'AS/400 envoie la conversation initiale.

Ensuite, vérifiez l'interface show du côté AS/400 du routeur. Dans le résultat ci-dessous, nous voyons que l'interface série qui se connecte à l'AS/400 est désactivée/désactivée. Cela signifie que l'AS/400 est probablement « varié ». Si la ligne est « variable » et que vous ne parvenez pas à démarrer la ligne ou que vous exécutez le mode bidirectionnel non simultané, 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#

À ce stade, vérifiez l'état « Work with Configuration Status » pour ce contrôleur spécifique, qui est un écran AS/400 qui ressemble à :

Ensuite, varie selon la définition de la ligne. Vous devez alors voir que le routeur s’active/s’active. Si la ligne s'active/s'active mais que le contrôleur ne s'active toujours pas, vérifiez l'interface pour vérifier si des paquets ont atteint l'interface en entrée à partir de l'AS/400. Si le nombre est égal à zéro, vérifiez le mécanisme de codage de la ligne SDLC sur l'AS/400. Elle se trouve sur la description de la ligne d'affichage, comme indiqué ci-dessous.

Remarque : Sur cet écran, nous pouvons voir que le codage de ligne est défini pour le codage NRZI. Vous devez activer cette option avec l'option de configuration nrzi-codage sur le routeur.

Cette configuration ne nécessite pas de codage NRZ/NRZI de bout en bout, comme dans les conventions point à point SDLC conventionnelles, mais peut être NRZI d'un côté et NRZ de l'autre. Mais rappelez-vous que le codage doit être identique entre les périphériques qui partagent la ligne SDLC.

Le NRZI mérite une attention particulière. Dans les nouveaux routeurs tels que les routeurs Cisco 2500 et 4500, NRZI est configuré via un logiciel. Mais avec les plates-formes plus anciennes, notamment la carte NP-2T pour le Cisco 4000, vous devez changer de cavalier sur les cartes elles-mêmes. Dans de tels cas, il est probablement plus facile de remplacer l'AS/400 par NRZ/NRZI. Toutefois, si vous devez modifier les cavaliers, reportez-vous à la documentation matérielle Cisco de votre plate-forme spécifique.

Si le problème persiste, exécutez un paquet debug stun 1. Cette commande 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 XID s'écoulant de l'AS/400, mais il n'y a pas eu de réponse à ces derniers (CO est l'adresse d'interrogation et bf est l'XID). Nous savons que le paquet provient de l'AS/400, car il provient de SDI. Il existe deux types de paquets entrants dans cette sortie de commande :

• SDI : Série entrante, qui sont des paquets reçus de l’interface SDLC.

• NDI : Réseau entrant, qui sont des paquets désencapsulés du WAN.

Examinez ensuite la partie XID de la trame elle-même. Dans cet exemple, l'AS/400 envoie un XID avec ses IDBLOCK et IDNUM, 05645253.

Il s'agit d'un problème de délai d'attente, car le contrôleur ne répond pas. Dans l'AS/400, consultez la file d'attente des messages sysopr pour voir s'il existe des messages indiquant un problème. Un écran « SYSOPR » avec une défaillance est affiché ci-dessous.

Maintenant sur le 2522, activez debug stun packet 1 pour voir si les paquets sont envoyés au contrôleur. L'exemple de résultat de la commande est présenté ci-dessous :

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

Ceci nous montre que le XID qui provient du côté AS/400 passe par le contrôleur, mais que le contrôleur ne répond pas, ce qui signifie qu'il s'agit d'un problème de contrôleur. Une interface show nous montre si toutes les pistes de contrôle sont actives ou non :

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

Les pistes de contrôle sont activées et l'interface s'active/active. Nous pouvons également constater que le routeur sort des paquets, mais aucun paquet n'est entrant. Cette opération indique l'adresse d'interrogation incorrecte configurée sur l'AS/400. L'étape suivante consiste donc à vérifier l'adresse d'interrogation du contrôleur.

Chaque type de contrôleur dispose d'une méthode unique de configuration de l'adresse d'interrogation. Vous devez donc le vérifier avec les manuels de contrôleur de votre contrôleur.

Dans cet exemple, nous avons découvert que le contrôleur utilisait l'adresse d'interrogation « DD ». Après avoir modifié ceci sur l'AS/400, la sortie du paquet debug stun 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 permet de déterminer les informations suivantes :

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

Cette ligne contient le XID de l'AS/400 vers le contrôleur. Cela provient de NDI (en provenance du cloud), dd (adresse d'interrogation), bf (XID) et IDBLOCK et IDNUM (05645253).

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

Il s'agit de la réponse du contrôleur. Ceci est indiqué par SDI (venant de la ligne SDLC) et le même que ci-dessus, à l'exception de la réponse XID (073000dd), car il s'agit d'un 5494.

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

Il s'agit du SNRM (93) de l'AS/400 au contrôleur, qui est le principal 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), ce qui signifie que la session est en cours d'exécution. Ensuite, nous devons voir la déconnexion provenant de l'AS/400, car la ligne a été modifiée.

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

Ces lignes indiquent le DISQUE (53) et la réponse UA. La ligne est maintenant en panne. Vous trouverez ci-dessous un tableau contenant les valeurs nécessaires au débogage de ces problèmes.

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

rrrz cc01
rrrz 0001
rrrz 0101
rrrz 1001

 

xx-xx
x1-x1
x5-x5
x9-x9

 

Supervisory Format
Receiver Ready
Receiver Not Ready
Reject

rrr1 sssz

 

xx-xx

 

Information format

Clé :

z = Le bit final du sondage peut être 0 ou 1

rrr = Nombre de blocs devant être reçus

sss = Nombre de blocs envoyés

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

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

Contrairement à STUN Basic, STUN SDLC exige que vous spécifiez l’adresse d’interrogation correcte, sinon le routeur ne verra même pas les paquets entrer. C'est pourquoi STUN Basic est parfois utilisé pour trouver l'adresse d'interrogation lorsque vous n'avez pas les informations, ou que vous ne pouvez pas accéder à l'hôte ou à l'AS/400. Le diagramme ci-dessus montre un scénario multipoint avec local-ack.

Dans un environnement point à point traditionnel, le sondage se termine de bout en bout. Lorsque l'accusé de réception local est introduit, l'interrogation est terminée à chaque extrémité du nuage, de sorte que chaque routeur doit gérer une machine à état fini. Cette machine suit toutes les sessions et doit connaître l'état de la ligne pour chaque station interrogée. Pour cette raison, vous devez vous assurer que les stations suivent le protocole SDLC.

Tout d'abord, vérifiez que vous êtes dans le rôle STUN correct. Les AS/400 ont du mal à négocier le rôle avec le contrôleur dans les environnements point à point traditionnels. La description de la ligne est présentée ci-dessous.

Ceci nous montre que l'interface du routeur doit être configurée pour un rôle secondaire. Vérifiez toujours la ligne et vérifiez qu'elle est *PRI , car l'AS/400 a par défaut la valeur *NEG lors de sa création. NRZI est défini sur *OUI, vous devez donc coder nrzi-codage. En outre, codez des marques de caractères inactifs et définissez la fenêtre sur une (1) à l'aide de sdlc k 1. (Reportez-vous à l'alerte de champ FNA-IOS-0696-02 pour obtenir une description détaillée des raisons pour lesquelles des marques de caractères inactifs sont requises sur l'interface.) Ce codage est indiqué 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 fournie par le routeur est indépendante du paramètre de vitesse de ligne configuré sur la ligne AS/400. (Ce paramètre est utilisé pour les calculs de performances ; il peut être laissé à la valeur par défaut de 9600.) L'identificateur Exchange configuré sur la ligne est celui de l'AS/400, tel que le XID que l'AS/400 enverra. Le nombre maximal de contrôleurs est le nombre de PU (contrôleurs) qui peuvent être créés et reliés à cette ligne.

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

Nous pouvons voir que le premier contrôleur va être un PU 2.1 parce que la catégorie du contrôleur est "*APPC. » Il s'agit de l'abréviation de Advance Program-to-Program Communications, qui ne peut être effectuée que via une connexion T2.1. L'identificateur de réseau distant est à nouveau associé à APPN/APPC et appelé « NETID ». "*NETATR » est un paramètre qui spécifie l'utilisation du NETID défini dans la zone de données appelée « Attributs réseau. » Vous pouvez afficher cette zone de données à l'aide de la commande DSPNETA et substituer les valeurs en conséquence. Le « Remote Control Point » ou « CP_name » est le nom du point de contrôle que vous avez configuré dans le PU2.1. Dans ce cas, il s'agit du CP5494. Le rôle liaison de données peut être laissé sous *NEG. L'« adresse de la station » doit correspondre à l'« adresse sdlc DD" qui a été configurée sur l'interface secondaire ainsi que sur l'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 plupart des informations qui résident dans la description du contrôleur sont pertinentes pour l'unité physique elle-même, et ne peuvent pas être configurées dans le routeur.

Sur cet écran, le second contrôleur (PU) est en fait un 3174, qui est un PU de type 2. Le XID configuré dans ce 3174 est 05600001. L'adresse de la station, ou adresse sdlc, utilisée est 01. Vous avez besoin d'une « adresse sdlc 01" configurée sur l'interface secondaire et l'une des interfaces principales distantes. Comme vous pouvez le voir ci-dessous, la configuration d'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 d'affichage des réseaux (DSPNETA) de l'AS/400 sont indiqués ci-dessous :

Cet écran indique que l'AS/400 est actuellement configuré pour l'ID réseau « NETA », ce qui signifie que le 5494 doit être configuré pour le même réseau. Ceci, ainsi que le reste de la configuration spécifique à APPN, se trouve sur le deuxième écran de configuration du 5494. Le nom du point de contrôle local de l'AS/400 est « RTP400A. » Le nom de l'unité logique de l'AS/400 est « LU9404 » ; il doit correspondre à ce qui est configuré dans le champ de définition de l'unité logique partenaire du 5494. La description du mode utilisée par le 5494 doit correspondre à celle de la description du périphérique. Par exemple, si le périphérique dit "*NETATR », il doit correspondre à la valeur par défaut de « BLANK ».

La description du périphérique APPC créée pour le 5494 est présentée ci-dessous.

Cet écran montre que la description du périphérique du 5494 a un nom de point de contrôle distant CP de « CP5494 » ; cela doit correspondre à ce qui est configuré sur le 5494. Les paramètres NETID et Local Location ont été définis par défaut sur "*NETATR », qui ont été codés sur LU9404 et NETA dans l'exemple précédent. Là encore, ils doivent correspondre au nom de la LU du partenaire et aux champs NETID du 5494.

La dernière partie de la configuration du périphérique qui est pertinente pour établir une connexion est présentée ci-dessous.

Cet écran indique que le mode utilisé sur la description du périphérique est « QRMTWSC ». Il ne s'agit pas de la valeur par défaut trouvée dans le *NETATR, ce qui signifie qu'elle a été remplacée dans la description du périphérique. Il s'agit de l'un des modes par défaut fournis par IBM dans le cadre de la prise en charge APPN de base sur l'AS/400. Si vous voyez quelque chose de différent, contactez IBM, car ils exécutent 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 Descriptions du mode de travail.

La description du mode est présentée ci-dessous.

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

Dépannage de l’interface multipoint duplex intégral SDLC

Lorsque vous effectuez un accusé de réception local dans un environnement multipoint avec AS/400, sachez que l'interface multipoint duplex intégral SDLC a été implémentée sur les mini-mainframes AS/400, SYS/38 et SYS/36. L'alerte de champ FNA-IOS-0696-02 (incluse ci-dessous) explique le type de problèmes qui peuvent survenir dans cette situation.

Brève description

La modification du câble du routeur reliant la détection de porteuse à la mise à la terre n'empêchera pas les réinitialisations périodiques de ligne SDLC à partir d'un AS/400 si IBM PTF# MF10030 a été appliqué à l'AS/400. Cette alerte s'applique uniquement aux connexions STUN full duplex multi-drop à un AS/400 où le câble SDLC du routeur a été modifié pour désactiver la détection de porteuse.

Incidence

Les utilisateurs peuvent subir une réinitialisation périodique de la connexion STUN et de tous les périphériques secondaires SDLC, ce qui entraîne une connexion non fiable.

Description complète/Contexte

Dans un environnement multipoint, un AS/400 se comporte différemment des autres périphériques IBM. Alors qu'un FEP accepte les caractères 0x7E (indicateurs) ou 0xFF (marques) comme espace « inactif » entre les trames, un AS/400 traite les indicateurs et les marques différemment. Seule une marque est interprétée comme un caractère inactif. Un indicateur est interprété comme signifiant « la ligne est toujours active - plus de données sont en attente. » Un routeur Cisco peut être configuré pour envoyer des indicateurs ou des marques, mais pas les deux. Il n'alterne pas entre les deux pour refléter l'état de la ligne. Par défaut, le routeur envoie des indicateurs.

Cette différence pose un problème dans les environnements multipoints en mode bidirectionnel simultané. Normalement, l'AS/400 va d'un périphérique à l'autre, en recherchant les données de chacun d'entre eux. Si un périphérique ne répond pas et que l'AS/400 pense que la ligne est toujours active, il réinitialise la ligne entière. Puisque la valeur par défaut est que le routeur envoie des indicateurs, le système autonome AS/400 verra toujours une ligne active et réinitialisera la ligne au lieu de simplement interroger le périphérique suivant.

Pour éviter ce problème, Cisco a toujours recommandé une modification du câble qui désactive le signal de détection de porteuse (CD). Cette modification tire parti de la logique AS/400 qui interprète l'absence de porteuse comme étant l'état de la ligne inactive. Par conséquent, avec la modification, un AS/400 détecte toujours l'état de la ligne inactive indépendamment des caractères d'intertrame envoyés par le routeur. Ainsi, si un périphérique secondaire ne répond pas, le système autonome AS/400 vérifie le CD, voit une ligne inactive et passe à l'étape suivante.

Récemment, IBM a publié le correctif du problème AS/400 PTF# MF10030 qui modifie la logique de détection de porteuse sur les lignes à plusieurs lignes. Une fois ce correctif installé, un AS/400 ignore complètement l'état du CD sur les lignes multipoints en mode bidirectionnel simultané. Par conséquent, la modification du câble Cisco n'est plus efficace pour empêcher les réinitialisations périodiques de la ligne.

Solution de contournement

Deux solutions de contournement sont disponibles, selon le modèle de routeur et la version de Cisco IOS en cours d’exécution. Les deux options nécessitent des modifications de configuration du routeur connecté à l'AS/400.

Option 1

Remplacer le caractère inactif SDLC du caractère d'indicateur par défaut par un caractère de marque. Le caractère inactif peut être modifié à l’aide de la commande de configuration d’interface du routeur :

idle-character marks 

Ajoutez cette commande à l'interface série SDLC connectée à l'AS/400. Cette commande permet au routeur de toujours transmettre des caractères de marque pour une pause entre les trames. Ainsi, si un périphérique secondaire manque un sondage, l'AS/400 verra une ligne inactive et passera à l'interrogation du périphérique suivant. Malheureusement, cela signifie également que l'AS/400 sera inactif même si davantage de trames de données sont en route depuis le périphérique. L'AS/400 ne reconnaît que la première trame, même si le bit d'interrogation/final est 0. Il ignore ensuite toutes les trames suivantes et interroge le périphérique suivant, ce qui entraîne des retransmissions de trames inutiles. Pour éviter les retransmissions, vous devez également définir la taille de la fenêtre SDLC sur 1 avec la commande :

sdlc k 1

Remarque : La commande idle-character est prise en charge dans Cisco IOS version 10.0(5.2) et ultérieure, et fonctionne sur les routeurs 2500, 4x00 avec NP-4T et 70x0/75xx.

Option 2

Activez la détection des périphériques secondaires inactifs à l’aide de la commande d’interface :

stun quick-response

Cette commande amènera le routeur à répondre par une trame de « mode de déconnexion » (DM) pour tout périphérique secondaire inactif interrogé par l'AS/400. L'AS/400 va ensuite interroger le périphérique suivant sans réinitialiser la ligne.

Remarque : cette commande est prise en charge dans Cisco IOS 11.1, 11.0(3.1) et versions ultérieures ou 10.3(7.2) et ultérieures.

Conseil : Si vous rencontrez des problèmes lors de l'élévation de la ligne multipoint avec la réponse rapide configurée, utilisez l'option 1. Le code stun de réponse rapide du routeur fait partie de la machine à état fini pour local-ack, qui peut sortir de l'étape avec certains PU. Nous avons testé le code dans ces travaux pratiques et vérifié son interopérabilité avec les modèles 5494, 5394 et Perl494E. Il est possible de rencontrer des problèmes si les temporisateurs de l'unité de données que vous essayez d'attacher sont différents de ceux attendus par la réponse rapide.

Informations connexes

• Page d'assistance STUN/BSTUN
• Page IBM Technology
• Support et documentation techniques - Cisco Systems