Sommario

Introduzione

Operazioni preliminari

Convenzioni

Prerequisiti

Componenti usati

Premesse

Configurazione STUN

Esempio di configurazione di base STUN

Configurazione di esempio STUN SDLC

Configurazione di esempio STUN Multipoint (con Local-Pack)

Comandi show

Risoluzione dei problemi

Risoluzione dei problemi SDLC Basic

Risoluzione dei problemi di STUN SDLC con e senza riconoscimento locale

Risoluzione dei problemi dell'interfaccia multipoint SDLC Full Duplex

Informazioni correlate

Introduzione

Il tunneling seriale (STUN) è il tunneling dei frame SDLC su una WAN. Nel mondo delle tradizionali architetture di rete (SNA), i telecomandi sono collegati al processore front-end (FEP) tramite un set di modem collegati tramite POTS (Plain Old Telephone Service) o linee contrattate.

Operazioni preliminari

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Prerequisiti

STUN SDLC viene comunemente utilizzato in due ambienti: FEP al telecomando e AS/400 al telecomando.

Componenti usati

Risoluzione dei problemi STUN con i comandi software Cisco IOS® e AS/400 per problemi specifici del controller remoto.

Premesse

Poiché le reti evolvono verso l'integrazione e gli uffici remoti richiedono diversi tipi di servizi (come NetBIOS, IP, IPX), dal punto di vista della manutenzione e dei costi è opportuno integrare tutti questi elementi in un unico dispositivo. Ad esempio, nel seguente diagramma è illustrata l'integrazione dei terminali 3270 con l'host e il traffico NetBIOS delle stazioni Windows.

Lo STUN consente di utilizzare l'IP come trasporto per i frame SDLC (Synchronous Data Link Control) su una rete WAN o su un'altra rete multimediale. In questo modo non è più necessario disporre di una linea in leasing o POTS aggiuntiva. Una funzionalità SDLC dei router Cisco è la traduzione dei contenuti multimediali. Nella conversione dei contenuti multimediali, il router converte la sessione da SDLC a LLC2 (Logical Link Control). Questo argomento viene descritto in dettaglio in Descrizione e risoluzione dei problemi relativi a SDLC to LLC Network Media Translation.

Esistono due tipi di configurazioni STUN: STUN Basic e STUN SDLC. Il primo viene utilizzato per i frame di tipo derivato HDLC (High-Level Data Link Control), mentre il secondo viene utilizzato per i frame SDLC. STUN Basic può essere utilizzato anche per SDLC, ma non è possibile utilizzare funzioni quali local-ack. Lo standard STUN Basic viene comunemente usato per la risoluzione dei problemi del protocollo SDLC, in quanto non è necessario configurare sul router i parametri specifici del protocollo SDLC.

Configurazione STUN

Il primo comando di una configurazione STUN (Basic o SDLC) è stun peer-name. Senza lo stun peer-name, il router non consente di continuare la configurazione.

Attività

Comando

Abilitare STUN per un particolare indirizzo IP.

stun peer-name ip-address

Selezionare un indirizzo IP valido dal router. Questo indirizzo IP deve essere l'interfaccia più affidabile presente nella confezione. Per ottenere risultati ottimali, configurare il router con un'interfaccia di loopback. Per informazioni sulla configurazione delle interfacce di loopback.

Il passaggio successivo consiste nel determinare la modalità STUN da utilizzare. Una modalità è STUN Basic, in cui cerca l'inizio e il delimitatore del frame [7e] e trasporta il frame sull'altro lato. In questa modalità operativa, a STUN non importa lo stato specifico della sessione o informazioni SDLC dettagliate, come l'indirizzo di polling. L'altra modalità è STUN SDLC. Questa modalità richiede decisioni più dettagliate nel router, in particolare se si esegue la conferma locale o qualsiasi tipo di multipunto. I comandi utilizzati per specificare una modalità STUN sono descritti nella tabella seguente:

Attività

Comando

Specificare un gruppo di protocolli di base e assegnare un numero di gruppo.

stun protocol-group group-number basic

Specificare un gruppo di protocolli SDLC e assegnare un numero di gruppo.

stun protocol-group group-number sdlc

Il passaggio successivo è quello di configurare l'interfaccia seriale per STUN. Il gruppo selezionato nell'interfaccia deve corrispondere a quello definito nel gruppo di protocolli. Con i multipoint virtuali è inoltre necessario creare un gruppo di protocolli di stordimento con numeri diversi per ogni multipoint virtuale. Accertarsi sempre di aver configurato una sola interfaccia secondaria per stun-group, a meno che non si stia configurando sdlc-tg. Vedere stun protocol-group.

Attività

Comando

Abilitare la funzione STUN su un'interfaccia seriale.

encapsulation stun

Posizionate l'interfaccia in un gruppo STUN definito in precedenza.

stun group group-number

Nota: non configurarlo su Cisco 7000, Cisco 7500 o su qualsiasi altro router dotato di CxBUS o CyBUS durante il tempo di rete della produzione. In base a questa configurazione, il router cambia la MTU dell'interfaccia a 2032 byte, creando un'unità buffer CBUS e reimpostando tutte le interfacce del router. In un ambiente Token Ring, può significare che i Token Ring non saranno attivi per fino a 16 secondi. Inoltre, poiché Cisco 7000 è spesso il centro del core in cui questo tipo di problema interessa molti utenti.

Il passaggio successivo per la configurazione dello STUN è aggiungere l'istruzione stun route. Per stun route si intende stun route all o stun route [indirizzo]. Le opzioni di configurazione sono spiegate di seguito.

Attività

Comando

Inoltra tutto il traffico TCP per questo indirizzo IP.

stun route all tcp ip-address

Specificare l'incapsulamento TCP.

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

I comandi precedenti sono per i peer di incapsulamento TCP. È possibile anche configurare STUN per l'incapsulamento diretto, ma questa configurazione viene utilizzata raramente. La configurazione più comune di tutte è la certificazione locale STUN.

Di seguito sono descritti i parametri del comando:

- L'opzione priority nell'istruzione stun route viene utilizzata per creare più pipe TCP tra due peer STUN in modo che le strutture di priorità possano essere create utilizzando una coda personalizzata o una coda di priorità.

- L'opzione tcp_queue_max aumenta o diminuisce le code TCP tra i due peer STUN. Questa opzione è utile se la sessione TCP tra peer non è molto affidabile ed è necessario determinare gli errori tra peer. Questa opzione non viene comunemente utilizzata in ambienti STUN, tranne quando si esegue STUN FEP-to-FEP in cui è coinvolto molto più traffico.

Di seguito sono descritti i comandi utilizzati per configurare STUN con riconoscimento locale.

Attività

Comando

Assegnare al router abilitato per STUN un ruolo primario SDLC.

stun sdlc-role primary

Assegnare al router abilitato per STUN un ruolo secondario SDLC.

stun sdlc-role secondary

Questi comandi definiscono il "ruolo" dell'impostazione STUN. Nel caso dell'host indicato nel diagramma precedente, il router è impostato su primario, ossia l'host avvia la sessione. Questo rende il 3174 secondario. Quando si utilizza STUN Basic, non è necessario definire il ruolo, in quanto non è necessario sapere chi inizierà la sessione. Tuttavia, la conferma locale richiede i dettagli della linea stessa e la definizione del ruolo consente al router di conoscere il flusso dell'avvio della sessione, che il router deve verificare prima di passare alla conferma locale.

Nota: negli ambienti AS/400 STUN che effettuano la conferma locale, è molto importante impostare il ruolo (nella descrizione della linea) su *pri da *neg. Il motivo è che in un ambiente puro (connessione diretta via modem), AS/400 può negoziare il ruolo. Codificando il ruolo che verrà assegnato alla riga, è possibile garantire che il ruolo del router sia opposto a quello di AS/400. In genere si desidera che AS/400 avvii la sessione (con "vary on" della riga ). Andare alla configurazione della linea e impostarla per *pri. Di seguito è riportata la descrizione della linea di visualizzazione AS/400. Questa operazione può essere eseguita solo durante la creazione/copia della descrizione della linea.

Di seguito viene spiegato il comando per configurare STUN con riconoscimento locale.

Attività

Comando

Stabilire la conferma locale SDLC con l'incapsulamento TCP.

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

Il parametro importante è il percorso di storno [address] con local-ack. Tenere presente che lo STUN local-ack può essere eseguito con l'incapsulamento TCP e con il Frame Relay (usando la RFC 1490).

Come in RSRB e DLSw, i pacchetti keepalive nello STUN vengono trasmessi tra i peer TCP per garantire che la connessione peer sia attiva. È possibile regolare i pacchetti keepalive se i peer stanno andando giù/su a causa della perdita di keepalive. I comandi STUN utilizzati per configurare i pacchetti keepalive sono descritti di seguito:

Attività

Comando

Abilita il rilevamento di un peer remoto perso.

stun remote-peer-keepalive seconds

Numero di tentativi di connessione peer prima di dichiarare il peer "inattivo".

quantità stun keepalive-count

Esempio di configurazione di base STUN

STUN Basic è la configurazione più semplice di STUN. In questa modalità, tutti i pacchetti ricevuti dal router da un lato vengono trasportati all'altro. La configurazione di base di STUN è illustrata nel diagramma seguente:

I router nello schema sopra riportato sono configurati come segue:

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

Configurazione di esempio STUN SDLC

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

Configurazione di esempio STUN Multipoint (con Local-Pack)

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

Nota: sul router AS400 sono stati utilizzati i simboli sdlc k1 e idle-character. Fare riferimento alla sezione Avviso sui prodotti per ulteriori dettagli.

Comandi show

Il primo comando show usato con STUN è show stun. L'output di questo comando dipende dal tipo di SDLC STUN Basic o STUN con local-ack. Nella sezione Base dello STUN mostrata di seguito, si vedono solo i pacchetti trasmessi e ricevuti.

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

Nello STUN SDLC con la parte local-ack mostrata di seguito, si ottengono maggiori informazioni perché ora lo stato della sessione è noto.

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

Il comando show interface fornisce anche informazioni diverse a seconda che si stia eseguendo STUN Basic o STUN SDLC. L'interfaccia show per STUN Basic è la stessa di una normale linea seriale.

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

Per ulteriori informazioni, consultare l'interfaccia show per STUN SDLC con riconoscimento locale. Di seguito è riportato un esempio di output per un'interfaccia seriale con local-ack.

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

Di seguito sono descritte alcune parti di questo output:

- L'MTU è la dimensione fisica del buffer usato dall'interfaccia.

- PRIMARY (DCE) significa che questo è il seggio in rete e che stiamo fornendo l'orologio. Se guardassimo il lato collegato al primario reale, questo output sarebbe stato SECONDARIO.

- N1 è il valore delle dimensioni utilizzabili del frame SDLC che può essere alloggiato dall'interfaccia seriale del router.

- T1 è la quantità di tempo prevista per la risposta a un sondaggio prima del timeout della riga.

- poll-pause-timer è il delta di tempo in millisecondi tra un polling e l'altro.

- k è la dimensione della finestra o il numero di fotogrammi che possono essere superati tra le finali dei sondaggi.

- stato è lo stato corrente della sessione, che può essere uno degli stati seguenti:

- DISCONNETTI

- CONNESSO

- THEMBUSY (generalmente impostato come risultato della ricezione di un RNR da parte del router)

- USBUSY (generalmente il risultato della mancata risposta sul lato rete).

- RNR è il numero di RNR inviati/ricevuti.

- DTR/RTS sono le linee utilizzate nella maggior parte degli ambienti half-duplex multidrop. Quando si esegue il debug di un ambiente STUN e si controlla la posizione del controller, prestare particolare attenzione a RTS. Se il DTR e il CTS sono elevati a intermittenza, è molto probabile che il risultato del DTE sia half-duplex.

L'ultimo importante comando show per STUN è il comando show tcp, che fornisce informazioni sulla sessione TCP tra i peer. Di seguito è riportato un esempio di output:

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

Risoluzione dei problemi

La risoluzione dei problemi di una configurazione STUN è la stessa di qualsiasi convenzione peer-to-peer. Se si verificano problemi nel trasporto, è necessario eseguire una diagnosi prima di iniziare la risoluzione della parte SDLC/STUN. In genere, il primo passaggio è eseguire il ping tra peer per verificare che l'IP sia configurato correttamente. Inoltre, eseguire il ping con i tipi di pacchetto estesi per verificare che il trasporto sia affidabile.

Risoluzione dei problemi SDLC Basic

In questa sezione viene descritto come risolvere i problemi relativi all'installazione di STUN Basic. Nell'esempio, si supponga che la WAN funzioni correttamente.

In questo scenario è disponibile una configurazione STUN Basic per collegare lo switch 5494 allo switch AS/400. La prima cosa da verificare con qualsiasi configurazione STUN è che i peer siano configurati nel router. Per verificare questa condizione, utilizzare il comando show stun peer. Fornisce informazioni sullo stato del peer e sui pacchetti trasmessi/ricevuti. Di seguito è riportato un esempio di output:

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

Se il peer è aperto, come indicato in precedenza, utilizzare il comando show interface per determinare la causa dei pacchetti. Di seguito è riportato un esempio di output per questo comando:

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

Verificare innanzitutto che il router disponga di tutti i segnali seriali attivi. Nella parte inferiore dell'output precedente, è possibile vedere che tutti i segnali sono "verso l'alto" per "Serial2" sul modello 2522. DTR e RTS indicano che il controller ha già attivato la linea e sta aspettando che AS/400 invii la conversazione iniziale.

Quindi, controllare l'interfaccia show per il lato AS/400 del router. Nell'output mostrato di seguito, si nota che l'interfaccia seriale che si collega all'AS/400 è inattiva/inattiva. Ciò significa che l'AS/400 è probabilmente "disattivato". Se la linea è "attivata" e non è possibile attivarla o la modalità half-duplex è necessario controllare la connessione 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#

A questo punto, selezionare "Work with Configuration Status" (Usa stato configurazione) per il controller specifico, che è una schermata AS/400 simile a:

Successivamente, variare in base alla definizione della linea. A questo punto, il router si allinea/si allinea. Se la linea si accende/si accende ma il controller ancora non si accende, controllare l'interfaccia per verificare se sono presenti pacchetti sull'interfaccia in entrata da AS/400. Se il conteggio è zero, controllare il meccanismo di codifica per la linea SDLC su AS/400. Questo si trova nella descrizione della linea visualizzata, come mostrato di seguito.

Nota: in questa schermata, è possibile vedere che la codifica della linea è impostata per la codifica NRZI. Questa funzionalità deve essere attivata con l'opzione di configurazione encoding nzi sul router.

Questa configurazione non richiede la codifica end-to-end NRZ/NRZI, come nelle convenzioni convenzionali SDLC point-to-point, ma può essere NRZI da un lato e NRZ dall'altro. Tuttavia, occorre ricordare che la codifica deve essere la stessa tra i dispositivi che condividono la linea SDLC.

NRZI richiede un'attenta considerazione. Nei nuovi router, come i modelli Cisco 2500 e 4500, il protocollo NRZI è impostato tramite software. Con le piattaforme più datate, tra cui l'NP-2T per Cisco 4000, è necessario sostituire i ponticelli sulle schede stesse. In questi casi, è probabilmente più semplice modificare AS/400 in NRZ/NRZI. Tuttavia, se è necessario modificare i jumper, consultare la documentazione dell'hardware Cisco per la piattaforma in uso.

Se il problema persiste, eseguire un debug stun packet 1. Questo comando fornisce le seguenti informazioni:

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

È possibile osservare il flusso di diversi XID dall'AS/400, ma non è stata ricevuta alcuna risposta (CO è l'indirizzo di polling e bf è l'XID). Sappiamo che il pacchetto proviene dall'AS/400 in quanto proviene da SDI. I pacchetti in arrivo in questo output del comando sono di due tipi:

- SDI Seriale in entrata, ossia pacchetti ricevuti dall'interfaccia SDLC.

- NDI: I pacchetti in entrata sono decapsulati dalla WAN.

Osservare quindi la parte XID della cornice stessa. In questo esempio, AS/400 invia un XID insieme ai relativi IDBLOCK e IDNUM, 05645253.

Si tratta di un problema di timeout perché il controller non risponde. In AS/400, controllare la "sysopr message queue" per verificare se vi sono messaggi che indicano un problema. Di seguito è riportata una schermata "SYSOPR" con un errore.

Ora, sullo switch 2522, attivare il debug stun packet 1 per verificare se i pacchetti vengono inviati al controller. Di seguito è riportato un esempio di output del comando:

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

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

Ciò dimostra che l'XID che ha origine sul lato AS/400 sta passando al controller, ma il controller non risponde, il che significa che si tratta di un problema del controller. L'interfaccia show mostra se tutti i cavi di controllo sono attivi o meno:

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

I cavi di controllo sono attivi e l'interfaccia è attiva/attiva. Vediamo anche che il router sta inviando i pacchetti, ma non ci sono pacchetti in arrivo. Poiché si tratta di un indirizzo di polling non corretto configurato su AS/400, il passaggio successivo consiste nel verificare l'indirizzo di polling del controller.

Ogni tipo di controller dispone di un modo univoco di configurare l'indirizzo di polling, pertanto è necessario verificarlo con i manuali del controller per il controller.

In questo esempio, abbiamo scoperto che il controller stava usando l'indirizzo di polling "DD". Dopo aver modificato questo valore su AS/400, l'output del pacchetto di debug stun diventa:

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

Questo output di debug aiuta a determinare le informazioni seguenti:

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

Questa riga contiene l'XID dall'AS/400 al controller. Questo proviene da NDI (proveniente dal cloud), dd (indirizzo di polling), bf (XID) e IDBLOCK e IDNUM (05645253).

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

Risposta del controller. Questo è indicato da SDI (proveniente dalla linea SDLC) e lo stesso come sopra, con l'eccezione della risposta XID (073000dd), perché questo è un 5494.

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

Si tratta del protocollo SNRM (93) tra AS/400 e il controller, che è il principale in questa configurazione.

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

Qui vediamo il controller che risponde (SDI) con un UA (73), il che significa che la sessione è attiva e in esecuzione. In seguito, si dovrebbe vedere la disconnessione proveniente dall'AS/400 come la linea è stata svariata.

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

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

Queste linee mostrano il DISC (53) e la risposta dell'UA. La linea è in discesa. Di seguito è riportata una tabella con i valori necessari per eseguire il debug di questi problemi.

Campo di controllo - Senza numero (1 byte)

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

Campo di controllo - Supervisione (2 byte)

rrrz cc01

rrrz 0001

rrrz 0101

rrrz 1001

xx-xx

x1-x1

x5-x5

x9-x9

Supervisory Format

Receiver Ready

Receiver Not Ready

Reject

Campo di controllo - Frame di informazioni (2 byte)

rrr1 sssz

xx-xx

Information format

Chiave:

z = Il bit finale del polling può essere 0 o 1

rr = Numero previsto di blocchi da ricevere

sss = Numero di blocchi da inviare

Risoluzione dei problemi di STUN SDLC con e senza riconoscimento locale

In questa sezione viene descritto lo stesso scenario con la conferma locale configurata.

A differenza di STUN Basic, per STUN SDLC è necessario specificare l'indirizzo di polling corretto, altrimenti il router non vedrà nemmeno i pacchetti arrivare. Ecco perché a volte STUN Basic viene usato per trovare l'indirizzo di polling quando non si hanno le informazioni, o quando non si riesce a raggiungere l'host o AS/400. Il diagramma precedente mostra uno scenario multipunto con local-ack.

In un ambiente point-to-point tradizionale, le operazioni di voto si svolgono dall'estremità alla punta. Quando viene introdotto il riconoscimento locale, il polling viene terminato a ciascuna estremità del cloud, quindi ogni router deve mantenere una macchina a stati finiti. Questo computer tiene traccia di tutte le sessioni e deve conoscere lo stato della linea per ogni stazione sottoposta a polling. Per questo motivo, è necessario verificare che le stazioni rispettino il protocollo SDLC.

Verificare innanzitutto che il ruolo assegnato sia corretto. Gli AS/400 hanno problemi a negoziare il ruolo con il controller negli ambienti point-to-point tradizionali. La descrizione della riga è riportata di seguito.

Ciò dimostra che l'interfaccia del router deve essere configurata per un ruolo secondario. Controllare sempre la linea e verificare che sia *PRI , in quanto l'impostazione predefinita di AS/400 è *NEG al momento della creazione. NRZI è impostato su *YES, quindi è necessario codificare nrzi-encoding. Inoltre, codificare i segni di caratteri inattivi e impostare la finestra su uno (1) utilizzando sdlc k 1. (Fare riferimento a FNA-IOS-0696-02 Field Alert per una descrizione dettagliata del motivo per cui i segni di caratteri inattivi sono richiesti sull'interfaccia.) Questa codifica è mostrata di seguito:

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

Nota: la temporizzazione fornita dal router è indipendente dal parametro della velocità della linea configurato sulla linea AS/400. (Questo parametro è utilizzato per i calcoli delle prestazioni; è possibile impostare il valore predefinito 9600.) L'identificativo di Exchange configurato sulla riga è quello di AS/400, ad esempio l'XID che verrà inviato da AS/400. Il numero massimo di controller è il numero di unità di elaborazione (controller) che è possibile creare e collegare a questa linea.

Nella schermata seguente viene mostrato il primo dei due controller collegati a questa linea, un IBM 5494.

Possiamo vedere che il primo controller sarà un PU 2.1 perché la categoria del controller è "*APPC". Questa è l'abbreviazione di Advanced Program-to-Program Communications, che può essere effettuata solo tramite una connessione T2.1. L'identificativo di rete remoto è di nuovo correlato ad APPN/APPC e viene definito "NETID". "*NETATR" è un parametro che specifica l'utilizzo del NETID definito nell'area dati denominata "Network Attributes". È possibile visualizzare questa area dati utilizzando il comando DSPNETA e sostituire i valori di conseguenza. "Punto di controllo remoto" o "CP_name" è il nome del punto di controllo configurato nella PU2.1. In questo caso, è CP5494. Il ruolo di collegamento dati può essere lasciato come *NEG. L'indirizzo della stazione deve corrispondere all'indirizzo sdlc DD configurato sia sull'interfaccia secondaria che su una delle interfacce primarie.

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

È possibile notare che la maggior parte delle informazioni contenute nella descrizione del controller sono relative all'unità fisica stessa e non sono configurabili nel router.

In questa schermata, il secondo controller (PU) è in realtà un 3174, che è un PU di tipo 2. L'XID configurato in questo 3174 è 05600001. L'indirizzo della stazione utilizzato è 01. È necessario un indirizzo sdlc 01 configurato sull'interfaccia secondaria e su una delle interfacce primarie remote. Come si può vedere di seguito, la configurazione di una PU2 è meno complessa di una 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

Di seguito sono riportati gli attributi di rete visualizzati (DSPNETA) in AS/400:

In questa schermata viene mostrato che l'AS/400 è attualmente configurato per l'ID di rete "NETA", ossia che lo switch 5494 deve essere configurato per la stessa rete. Questa, così come il resto della configurazione specifica di APPN, è disponibile nella seconda schermata di configurazione dello switch 5494. Il nome del punto di controllo locale dell'AS/400 è "RTP400A". Il nome LU dell'AS/400 è "LU9404;", che deve corrispondere a quanto configurato nel campo di definizione LU partner del modello 5494. La descrizione della modalità utilizzata da 5494 deve corrispondere a quella della periferica. Ad esempio, se il dispositivo dice "*NETATR", deve corrispondere all'impostazione predefinita di "BLANK".

Di seguito è riportata la descrizione del dispositivo APPC creato per lo switch 5494.

In questa schermata viene mostrato che la descrizione del dispositivo per lo switch 5494 è associata al nome di PC remoto "CP5494;" deve corrispondere a quello configurato sullo switch 5494. Il valore predefinito di NETID e Locale è "*NETATR", che nell'esempio precedente è stato codificato in LU9404 e NETA. Anche in questo caso, è necessario che corrispondano ai campi Nome LU partner e NETID nel modello 5494.

Di seguito è illustrato il pezzo finale della configurazione del dispositivo relativo alla connessione.

In questa schermata viene mostrato che la modalità utilizzata nella descrizione della periferica è "QRMTWSC". Questo non è il valore predefinito trovato in *NETATR, quindi significa che è stato ignorato nella descrizione del dispositivo. Si tratta di una delle modalità predefinite fornite da IBM nell'ambito del supporto APPN di base per AS/400. Se vengono visualizzate informazioni diverse, contattare IBM, in quanto vengono eseguite con una descrizione della modalità creata. In questo esempio viene stabilita una connessione di base. per visualizzare le informazioni sulle modalità disponibili, usare il comando WRKMODD o Descrizioni modalità di lavoro.

Di seguito è riportata la descrizione della modalità.

Questa schermata identifica chiaramente le definizioni dei modi fornite da IBM.

Risoluzione dei problemi dell'interfaccia multipoint SDLC Full Duplex

Quando si esegue il riconoscimento locale in un ambiente multipoint con AS/400, tenere presente che l'"interfaccia multipoint SDLC Full Duplex" è stata implementata sui mini-mainframe AS/400, SYS/38 e SYS/36. L'avviso sul campo FNA-IOS-0696-02 (incluso di seguito) spiega i tipi di problemi che possono verificarsi in questa situazione.

Descrizione breve

La modifica del cavo del router che collega il "rilevamento portante" alla messa a terra non impedisce il ripristino periodico della linea SDLC da un AS/400 se su AS/400 è stato applicato IBM PTF# MF10030. Questo avviso si applica solo alle connessioni multi-drop STUN full duplex a un AS/400 in cui il cavo SDLC del router è stato modificato in modo da disabilitare il rilevamento vettore.

Conseguenze

Gli utenti possono subire reimpostazioni periodiche della connessione STUN e di tutti i dispositivi secondari SDLC, con il risultato di una connessione inaffidabile.

Descrizione completa/Sfondo

In un ambiente con più drop, un AS/400 si comporta in modo diverso dagli altri dispositivi IBM. Mentre un FEP accetta caratteri 0x7E (flag) o 0xFF (indicatori) come spazio "inattivo" tra i frame, un AS/400 tratta i flag e i contrassegni in modo diverso. Solo un segno viene interpretato come carattere inattivo. Un contrassegno viene interpretato come "riga ancora attiva - in attesa di ulteriori dati". È possibile configurare un router Cisco per inviare flag o contrassegni, ma non entrambi. Non si alternerà tra i due per riflettere lo stato della linea. Per impostazione predefinita, il router invia i flag.

Questa differenza pone un problema negli ambienti multi-drop full duplex. Normalmente l'AS/400 passa da dispositivo a dispositivo, con un polling di ciascun dato. Se un dispositivo non risponde e AS/400 ritiene che la linea sia ancora attiva, viene ripristinata l'intera linea. Poiché per impostazione predefinita il router invia i flag, l'AS/400 visualizza sempre una linea attiva e viene reimpostato invece di eseguire semplicemente il polling del dispositivo successivo.

Per evitare questo problema, Cisco ha sempre consigliato una modifica del cavo che disabiliti il segnale di rilevamento della portante (CD). Questa modifica sfrutta la logica AS/400 che interpreta l'assenza di portante come "stato di inattività della linea". Pertanto, con la modifica, un AS/400 rileva sempre lo stato di inattività della linea indipendentemente dai caratteri interframe inviati dal router. Quindi, se un dispositivo secondario non risponde, AS/400 controlla il CD, visualizza una linea inattiva e passa alla stazione successiva.

Di recente, IBM ha rilasciato AS/400 problem fix PTF# MF10030 che modifica la logica di rilevamento della portante sulle linee a rilascio multiplo. Con questa correzione installata, un AS/400 ignora completamente lo stato del CD sulle linee multi-drop full duplex. Di conseguenza, la modifica del cavo Cisco non impedisce più il ripristino periodico della linea.

Soluzione alternativa

Sono disponibili due soluzioni, a seconda del modello di router e della versione di Cisco IOS in esecuzione. Entrambe le opzioni richiedono modifiche alla configurazione del router collegato all'AS/400.

Opzione 1

Modificare il carattere di inattività SDLC da quello predefinito a un carattere di contrassegno. Il carattere di inattività può essere modificato con il comando di configurazione dell'interfaccia del router:

idle-character marks

Aggiungere questo comando all'interfaccia seriale SDLC connessa a AS/400. In questo modo, il router trasmetterà sempre i caratteri contrassegno per una pausa tra i frame. Quindi, se un dispositivo secondario perde un polling, AS/400 vedrà una linea inattiva e passerà al polling del dispositivo successivo. Purtroppo, ciò significa anche che AS/400 sarà inattivo anche se si stanno trasferendo più frame di dati dal dispositivo. AS/400 riconosce solo il primo fotogramma, anche se il bit di polling/finale è 0. Ignora quindi tutti i fotogrammi successivi ed esegue il polling del dispositivo successivo causando ritrasmissioni di fotogrammi non necessarie. Per evitare ritrasmissioni, impostare anche le dimensioni della finestra SDLC su 1 con il comando:

sdlc k 1

Nota: il comando idle-character è supportato in Cisco IOS versione 10.0(5.2) e successive e funziona su router 2500, 4x00 con NP-4T e 70x0/75xx.

Opzione 2

Abilitare il rilevamento dei dispositivi secondari inattivi con il comando interface:

stun quick-response

Con questo comando il router risponderà con un frame "disconnect mode" (DM) per qualsiasi dispositivo secondario inattivo su cui verrà eseguito il polling da AS/400. AS/400 procederà quindi con il polling della periferica successiva senza reimpostare la linea.

Nota: questo comando è supportato in Cisco IOS versione 11.1, 11.0(3.1) e successive o versione 10.3(7.2) e successive.

Suggerimento: se si verificano problemi durante l'attivazione della linea multipunto con la risposta rapida configurata, utilizzare l'opzione 1. Il codice di risposta rapida stun nel router fa parte della macchina a stati finiti per local-ack, che può sfuggire di mano con alcune unità di elaborazione. Abbiamo testato il codice in laboratorio e verificato la sua interoperabilità con i modelli 5494, 5394 e Perl494E. È possibile che si verifichino problemi se la CPU che si sta tentando di collegare ha timer impostati in modo diverso da quello previsto da quick_response.

Informazioni correlate

- Pagina di supporto STUN/BSTUN

- Pagina sulle tecnologie IBM

- Documentazione e supporto tecnico – Cisco Systems