Configurazione e risoluzione dei problemi di Serial Tunneling (STUN)
Sommario
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.
Feedback