Guida a BSC e BSTUN

Introduzione

Questo documento è stato progettato per aiutarti a configurare e utilizzare il protocollo BSC (Binary Synchronous Communication) e BSTUN (Block Serial Tunneling) sui router Cisco. Consente inoltre di risolvere eventuali problemi.

Prerequisiti

Requisiti

Questo documento è utile per conoscere i seguenti argomenti:

• Concetti BSC (Binary Synchronous Communications).

• Comprensione generale dei principi fondamentali del trattamento dei dati.

Componenti usati

Le informazioni di questo documento si basano su Cisco IOS? con il set di funzionalità IBM.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

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

Panoramica del sistema

Le figure 1 e 2 mostrano come un collegamento BSC esistente tra due dispositivi possa essere riconfigurato per l'uso di router Cisco. In questo modo viene fornito lo stesso collegamento logico, senza alcuna modifica alle periferiche BSC esistenti.

I router Cisco trasportano tutti i blocchi BSC tra i due dispositivi tramite l'incapsulamento Block Serial Tunneling (BSTUN). Per ogni blocco BSC ricevuto dalla linea, vengono aggiunti un indirizzo e dei byte di controllo per creare un frame BSTUN, quindi viene utilizzato BSTUN per recapitare il pacchetto al router di destinazione corretto.

Configurazione BSC/BSTUN

Su un router pulito, eseguire questi comandi nell'ordine in cui sono elencati.

Comandi globali

[no] bstun nome-peer indirizzo-ip

L'indirizzo ip-address definisce l'indirizzo con cui il peer BSTUN è noto agli altri peer BSTUN che utilizzano il trasporto TCP.

Nota:  Questo comando deve essere configurato nel software Cisco IOS versione precedente alla 11.3 o se gli indirizzi TCP/IP vengono utilizzati nelle istruzioni route.

[no] bstun protocol-group group-number {bsc | bsc-local-ack | adplex | adt-poll | adt-poll-select | scrutinio di città e vari | grassetto | asincrono-generico | mdi}

Questo è un comando globale per associare i numeri di gruppo ai nomi di protocollo. Il numero-gruppo è un numero intero decimale compreso tra 1 e 255. Il valore bsc | bsc-local-ack | adplex sono parole chiave predefinite del protocollo BSTUN. Per ulteriori informazioni, fare riferimento a Definizione del gruppo di protocolli nel documento sulla configurazione del tunnel seriale e del tunnel seriale a blocchi.

La selezione del tipo di gruppo è importante per determinare se utilizzare la conferma passthru o locale (local-ack).

Nota: questo comando deve essere sempre configurato.

Comandi di interfaccia

bstun di incapsulamento

Questo è un comando di interfaccia che configura la funzione BSTUN su una particolare interfaccia seriale. Il comando deve essere configurato su un'interfaccia prima di poter configurare altri comandi BSTUN o BSC per questa interfaccia.

[no] bstun group group-number

Questo è un comando di interfaccia che definisce il gruppo BSTUN a cui appartiene l'interfaccia. Ogni interfaccia abilitata BSTUN su un router deve essere posizionata in un gruppo BSTUN definito in precedenza. I pacchetti viaggiano solo tra interfacce abilitate per BSTUN che si trovano nello stesso gruppo. Il numero-gruppo è un numero intero decimale compreso tra 1 e 255.

Il numero di gruppo ha già determinato se l'interfaccia esegue local-ack o passthru.

[no] modalità bsc

Di seguito sono elencate alcune delle opzioni principali. Per un elenco completo, fare riferimento a Configurazione delle opzioni bisync su un'interfaccia seriale nel documento sulla configurazione del tunnel seriale e del tunnel seriale a blocchi

Non vengono ricevuti o inviati frame finché la modalità non viene configurata per una di queste impostazioni:

• contention - Imposta il collegamento BSC collegato all'interfaccia seriale per una stazione BSC point-to-point. Solo 3780, e solo in modalità passthru.

• contention virtual-address: primo comando disponibile nel software Cisco IOS versione 11.3. Utilizzato con dial-contention per consentire a più dispositivi remoti di usare la stessa interfaccia sul router host-end.

• timeout di dial-contention: disponibile per la prima volta nel software Cisco IOS versione 11.3. Utilizzato sul router host-end per il conflitto. Consente il multiplexing di più dispositivi remoti sulla stessa interfaccia fisica.

• primary: indica che il router agisce come estremità primaria del collegamento BSC e che i dispositivi collegati sono stazioni affluenti BSC.

• secondario: per definire che il router agisce come estremità secondaria del collegamento BSC e che il dispositivo remoto collegato è una stazione di controllo BSC (ad esempio un processore front-end [FEP] o un altro dispositivo host).

Se il comando non è configurato, il protocollo di linea sull'interfaccia non sarà attivo e l'interfaccia non funzionerà.

Configurazione route TCP

In questa configurazione, il sistema di trasporto è TCP/IP. Può essere eseguito su qualsiasi supporto fisico su cui è possibile eseguire il protocollo TCP/IP.

[no] avvia il routing di tutti gli indirizzi ip tcp

[no] bstun route address-number tcp ip-address

L'indirizzo ip corrisponde all'indirizzo IP specificato nel nome peer del router partner.

Configurazione route seriale

In questa configurazione, il tunnel utilizza il trasporto proprietario Cisco. È molto più veloce del protocollo TCP/IP, ma può essere eseguito solo su un'interfaccia seriale.

[no] bstun route all interface serial interface-number

[no] bstun route address-number interface serial interface-number

Configurazione passthru Direct Frame Relay

In questa configurazione, il tunnel utilizza una forma proprietaria di incapsulamento seriale su Frame Relay, che funziona veloce come i percorsi seriali.

[no] bstun route address-number interface serial interface-number dlci dlci-number

Utilizzare questo comando sull'interfaccia Frame Relay:

[no] frame-relay map dlci-number bstun

Configurazione Direct Frame Relay Local-Ack

Questa configurazione utilizza Logical Link Control, tipo 2 (LLC2) sull'incapsulamento Frame Relay, per fornire conferma locale e controllo completo delle sessioni. è necessario includere la parola chiave lsap; in caso contrario, l'incapsulamento verrà considerato come passthru.

[no] bstun route address-number interface serial interface-number dlci dlci-number lsap

Utilizzare questo comando sull'interfaccia Frame Relay:

[no] frame-relay map dlci-number llc2

Nota: per ulteriori informazioni, consultare il documento sulla specifica della modalità di inoltro dei frame in Configurazione del tunnel seriale e del tunnel seriale a blocchi.

Configurazione passthru

Perché Passthru?

PassThru è la modalità di tunneling di base. Ogni frame trasmesso tra i dispositivi viene trasmesso, invariato, attraverso il tunnel BSTUN. Vengono aggiunti un numero di sequenza e un indirizzo di dispositivo per garantire che le latenze nella rete non influiscano sul funzionamento del protocollo. L'arrivo di sondaggi tardivi o di segnali di fine trasmissione (EOT, End of Transmission) potrebbe interrompere in modo significativo una sessione esistente.

Scenari d'uso di PassThru

PassThru deve essere utilizzato nelle seguenti circostanze:

• Per i dati da trasferire non è stato inviato un frame di riconoscimento esplicito per verificare l'integrità dei dati.

• Il protocollo non è puro 3270.

• L'utente desidera una connettività di dispositivo end-to-end e latenze di rete ridotte.

Configurazione Local-Ack

Perché Local-Ack?

Local-ack rimuove il sovraccarico causato dall'invio di tutti i frame di controllo attraverso il tunnel. Quando l'host invia il primo polling a un'unità di controllo, viene inviato un frame di controllo speciale attraverso il tunnel per avviare il polling remoto dell'indirizzo di quel dispositivo. Quando il dispositivo remoto indica che è attivo, viene inviato un frame di controllo al router host per comunicare di rispondere ai sondaggi. Quando il dispositivo remoto si blocca, viene inviata un'indicazione attraverso il tunnel per indicare al router host di non rispondere più ai polling.

Quando utilizzare Local-Ack

Local-ack può essere utilizzato nelle seguenti circostanze:

• 3270 bisync è in uso.

• La latenza di rete causa timeout di sessioni bisync.

• L'eccesso di traffico sulla WAN è un problema.

Opzioni Local-Ack

[no] tempo pausa bsc

Questo comando specifica l'intervallo di tempo tra l'inizio di un ciclo di polling e quello successivo. Il valore predefinito è 30, ovvero 30 decimi o 3 secondi.

È consigliabile configurare questo comando quando sull'interfaccia bisync sono presenti solo uno o due controller. Rallenta in modo efficace il polling e assegna più cicli della CPU al dispositivo collegato.

[no] tempo bsc poll-timeout

Questo comando imposta il timeout per una sequenza di polling o selezione, in unità di un decimo di secondo; il valore predefinito è 30, ovvero 30 decimi o 3 secondi.

Il valore temporale più piccolo è determinato dalla velocità del dispositivo collegato ed è di maggiore interesse per l'estremità host. Se l'host che gestisce il router riduce il timeout al valore più basso possibile, si verificherà un miglioramento delle prestazioni in caso di guasto di alcuni dispositivi.

[no] numero tentativi bsc

Questo comando imposta il numero di tentativi da effettuare prima che un dispositivo venga considerato inattivo. L'intervallo è compreso tra 1 e 100; il valore predefinito è 5 tentativi.

[no] valore servlim bsc

Questo comando specifica il valore del servlim (rapporto di polling della stazione terminale attiva rispetto a quella inattiva). L'intervallo è compreso tra 1 e 50; il valore predefinito è 3.

[no] sondaggio spec bsc

Questo comando indica all'host di gestire polling specifici come polling generali. Utilizzare questo comando quando si utilizzano host tandem.

Per ulteriori informazioni, fare riferimento a Configurazione delle opzioni bisync su un'interfaccia seriale nel documento sulla configurazione del tunnel seriale e del tunnel seriale a blocchi.

Configurazione dei conflitti

Perché la contesa?

Contention è la variante 3780 del bisync. Nessun indirizzo di unità di controllo. I dispositivi sono collegati point-to-point. In genere, un dispositivo remoto effettua una chiamata a una posizione centrale e presume che non esistano altri dispositivi.

Quando utilizzare il conflitto

Utilizzare il conflitto solo quando si utilizzano i protocolli RJE (Remote Job Entry), 3780 e 2780. Dopo aver identificato il conflitto, verificare che entrambe le estremità siano configurate per l'utilizzo del conflitto.

In caso di dubbi, eseguire la procedura seguente:

1. Configurare il database primario bsc.

2. Attivare il pacchetto BSC di debug.

3. Avviare il polling del dispositivo collegato.

I messaggi con 1 byte 2D indicano conflitto. I byte precedenti al 2D non sono 3780.

Priorità

Rispetto a tutto il traffico che attraversa la backbone WAN, il traffico bisync è molto piccolo e facilmente sommerso da altro traffico. Una perdita di fotogrammi in bisync richiede un lungo intervallo di recupero, che è facilmente visibile ai dispositivi terminali. Per ridurre al minimo questo problema, si consiglia di assegnare la priorità al traffico bisync. È possibile assegnare priorità al traffico con priorità BSTUN o con l'accodamento personalizzato.

• L'accodamento di priorità è una funzione di routing in cui ai frame di una coda di output dell'interfaccia viene assegnata una priorità in base a varie caratteristiche, quali dimensioni del pacchetto o tipo di interfaccia.

  L'accodamento di output con priorità consente a un amministratore di rete di definire quattro priorità di traffico (alta, normale, media e bassa) su una determinata interfaccia. Quando il traffico entra nel router, viene assegnato a una delle quattro code di output. I pacchetti nella coda con priorità più alta vengono trasmessi per primi. Quando la coda si svuota, viene trasmesso il traffico sulla coda con priorità più alta successiva e così via. Questo meccanismo garantisce che, durante la congestione, i dati con priorità più alta non vengano ritardati dal traffico con priorità più bassa. Tuttavia, se il traffico inviato a una determinata interfaccia supera la larghezza di banda di tale interfaccia, il traffico con priorità inferiore può sperimentare ritardi significativi.

  Ad esempio, se si assegna a IP una priorità più alta rispetto a IPX sui collegamenti seriali WAN, il traffico BSC in TCP/IP sfrutterà il fatto che IP viene trasferito con una priorità più alta.

• L'accodamento personalizzato consente a un cliente di riservare una percentuale della larghezza di banda per i protocolli specificati. I clienti possono definire fino a dieci code di output per i dati normali e una coda aggiuntiva per i messaggi di sistema, come i messaggi keepalive LAN (i pacchetti di routing non sono assegnati alla coda di sistema). I router Cisco gestiscono ciascuna coda in modo sequenziale: trasmettono una percentuale configurabile del traffico su ciascuna coda prima di passare alla successiva. Quando si utilizza l'accodamento personalizzato, è possibile garantire che ai dati mission-critical venga sempre assegnata una determinata percentuale della larghezza di banda, assicurando al tempo stesso una velocità effettiva prevedibile per il traffico di altro tipo.

  Per fornire questa funzione, i router Cisco determinano il numero di byte da trasmettere da ciascuna coda, in base alla velocità dell'interfaccia e alla percentuale configurata. Quando il conteggio byte calcolato da una determinata coda è stato trasmesso, il router completa la trasmissione del pacchetto corrente e passa alla coda successiva. Alla fine, ogni coda viene servita, in modo round robin.

Fare riferimento alla sezione Configurazione del tunnel seriale e del tunnel seriale a blocchi e alla sezione Scelta dei criteri di coda da utilizzare nella panoramica della gestione della congestione.

[no] priority-list list-number protocol bstun queue [gt] | lt packetsize] [indirizzo bstun-group bsc-addr]

Eseguire il comando priority-list protocol bstun global configuration per stabilire le priorità della coda BSTUN in base all'intestazione BSTUN. Eseguire il comando no per ripristinare le priorità normali.

[no] custom-queue-list [list]

L'elenco è un numero intero (1 - 16) che rappresenta il numero dell'elenco delle code personalizzate.

Configurazione keepalive

[no] intervallo bstun remote-peer-keepalive

Questo comando abilita i pacchetti keepalive peer BSTUN. In questo modo viene inviata una richiesta al peer ogni volta che il peer rimane inattivo per un periodo di tempo superiore a quello specificato per l'intervallo. Qualsiasi frame reimposta l'orologio, non solo keepalive. L'impostazione predefinita è 30 secondi.

[no] numero bstun keepalive

Quando questo numero di keepalive viene perso consecutivamente, la connessione BSTUN viene interrotta. Il valore predefinito è 3.

Scenari d'uso

I pacchetti keepalive sono utili per proteggere il sistema da interruzioni del tunnel quando si eseguono local-ack e TCP/IP. Il tunnel disattiva un'interfaccia solo quando si riceve un segnale dal telecomando. Se il tunnel non è attivo, non verrà ricevuto alcun segnale.

In passthru, questo non è necessario, perché è richiesta una connettività end-to-end.

Comandi debug

[no] debug bstun event group

Questo comando consente di eseguire il debug delle connessioni e dello stato BSTUN. Se questa opzione è attivata, verranno visualizzati messaggi che mostrano la connessione stabilita e lo stato generale.

[no] debug bstun packet group group buffer-size displayed-bytes-size

Questo comando consente di eseguire il debug dei pacchetti che viaggiano attraverso i collegamenti BSTUN.

[no] debug bsc packet group group buffer-size display-byte-size

Questo comando consente di eseguire il debug dei frame che viaggiano attraverso la funzione BSC.

[no] debug pacchetto bsc

Questo comando consente di eseguire il debug dei frame che viaggiano attraverso la funzione BSC. Traccia tutte le interfacce configurate con un numero di gruppo BSTUN.

[no] debug del gruppo di eventi bsc

Questo comando consente di eseguire il debug degli eventi che si verificano nella funzionalità BSC. Se il numero di gruppo viene omesso, verrà eseguita la traccia di tutte le interfacce configurate con un numero di gruppo BSTUN.

Comandi show

mostra bstun

Questo comando visualizza lo stato corrente di BSTUN.

This peer: 10.10.20.108
 *Serial5 -- interface for ATM: R1710V421 (group 3 [bsc])
route  transport  address      state       rx_pkts   tx_pkts     drops
C2    TCP         10.10.10.107 open        655630    651332      0
 Serial6 -- interface for SEC: MST012  (group 2 [bsc])
route  transport  address      state       rx_pkts   tx_pkts   drops
C2     TCP        10.10.10.107 open        649385    644001      0

Verificare i seguenti problemi:

• Stato chiuso.

• Gocce.

• Numero di pacchetti basso.

  Nota: il numero basso di pacchetti non sempre indica problemi. Quando si esegue local-ack, il conteggio è costituito solo da frame di dati, che è significativamente più piccolo del numero effettivo di frame che vengono inviati dall'host.

mostra bsc

Questo comando visualizza lo stato corrente di BSC.

In PassThru

BSC pass-through on Serial5:
Output queue depth: 0.
HDX enforcement state: IDLE.
Frame sequencing state: SEC.
Tx-Active: Idle. Rx-Active: False.
Tx Counts: 670239 frames(total). 670239 frames(data). 9288816 bytes.
Rx Counts: 651332 frames(total). 651332 frames(data). 651332 bytes.

Verificare i seguenti problemi:

• Se lo stato di imposizione HDX rimane bloccato in uno stato diverso da IDLE, potrebbe essersi verificato un problema con il dispositivo collegato o con il router. Ciò indica in genere che il dispositivo non risponde. Attiva debug eventi bsc. Se i messaggi remoti non restituiscono molte risposte, verificare innanzitutto che il dispositivo sia attivato, quindi controllare la modalità duplex. Se non sono presenti messaggi ed è in corso un eventuale ripristino, l'evento di completamento della trasmissione è stato perso ed è stato rilevato un bug potenzialmente grave.

• Lo stato della sequenza di fotogrammi indica quale macchina a stati finiti (FSM) controllare.

• Se Rx-Active è bloccato su True, significa che si è verificato un problema hardware. Eseguire i comandi shutdown e no shutdown per ripristinare l'interfaccia. Se l'operazione non riesce, ricaricare il router.

In Local-Ack

BSC local-ack on Serial0:
Secondary state is CU_Idle.
Control units on this interface:

      Poll address: 40. Select address: 60 *CURRENT-CU*
      Current active device address is: 40.
      State is Active.
      Tx Counts: 87228 frames(total). 11 frames(data). 87353 bytes.
      Rx Counts: 87271 frames(total). 5 frames(data). 436312 bytes.

Total Tx Counts: 87228 frames(total). 11 frames(data). 87353 bytes.
Total Rx Counts: 174516 frames(total). 5 frames(data). 523557 bytes.

Se lo stato rimane bloccato in TCU_Down, significa che l'interfaccia è stata bloccata. Verificare la modalità di clock e BSC e accertarsi che non vi siano interruzioni amministrative. A volte, un comando shut seguito da un comando no shut avvia di nuovo l'interfaccia.

In generale

• Una profondità della coda di output maggiore di 1 indica un backlog sull'interfaccia. Verificare che la modalità half-duplex sia configurata correttamente.

• Uscita dalla modalità di risposta SYN significa che l'interfaccia è inattiva o che il ricevitore è stato disabilitato. Ciò che si applica a Rx-Active vale anche in questo caso.

show interface serial number

Questo comando è utile per visualizzare i contatori associati all'interfaccia seriale.

Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

Nota: eventuali errori indicano problemi.

Verificare i seguenti problemi:

• interruzioni indicano una trasmissione errata.

• i frame ignorati sono frame che violano il protocollo bisync.

• i giganti indicano che l'MTU è troppo piccola o che una sequenza bisync è errata.

• il sovraccarico indica la carenza di risorse CPU.

• CRC indica un danneggiamento sulla linea (rumoroso o di altro tipo).

Se si utilizza un cavo DTE e la linea sembra diminuire frequentemente o se la trasmissione non riesce ma riceve il lavoro, potrebbe essere necessario eseguire il comando ignore-dcd. È possibile verificare questa condizione con un analizzatore di protocolli. Quando DCE trasmette, viene generato il DCD (Data Carried Detect). Al termine, il DCD viene abbassato in modo che il router non possa rispondere.

• L'hardware è CD2430 e indica il chipset Cirrus.

• Hardware è HD64570 indica il chipset Hitachi.

Hitachi utilizza interrupt di caratteri e framing basato su software. Non è in grado di gestire bene il DCD. Cirrus utilizza gli interrupt dei fotogrammi. I frame sono incorporati in ucode. Consente di riprodurre con DCD. Quando si esegue il debug, è importante conoscere il tipo di interfaccia, poiché esistono alcune differenze.

Il protocollo di linea deve essere attivo. Se il protocollo di linea non è attivo, verificare che sia configurata la modalità BSC.

Serial5 is up, line protocol is up
  Hardware is CD2430 in sync mode
 MTU 265 bytes, BW 4 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation BSTUN, loopback not set
    Half-duplex enabled.
      cts-delay 0 millisec
      dcd-txstart-delay 100 millisec
      dcd-drop-delay 100 millisec
      transmit-delay 0 millisec
      Errors - 0 half duplex violation
   Last input 10:27:12, output 1:07:12, output hang never
   Last clearing of "show interface" counters 4d11
   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
      3223346 packets input, 3223356 bytes, 0 no buffer
      Received 0 broadcasts, 0 runts, 0 giants
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
      3242346 packets output, 45259079 bytes, 0 underruns
      0 output errors, 0 collisions, 8 interface resets, 0 restarts
      0 output buffer failures, 0 output buffers swapped out
      4 carrier transitions
      DCD=up DSR=up DTR=up RTS=down CTS=down

Come risolvere i problemi relativi a IBM Bisync

Come utilizzare gli FSM PassThru

Assicurarsi di eseguire passthru. È necessario trovare la macchina a stati finiti (FSM) corretta da seguire.

Esaminare i messaggi di debug dell'evento. Ci sono due FSM da attraversare. L'HDX-FSM è una modalità di applicazione half-duplex. La guida avviene indipendentemente dal fatto che la linea sia configurata come full duplex o half duplex. e verifica che la coda di trasmissione di un router non venga registrata con i dati obsoleti. Il modulo FS-FSM garantisce che i frame in ritardo attraverso la rete non distruggano le sessioni stabilite.

Per determinare dove cercare, andare direttamente a contention FSM, se il conflitto è configurato. In caso contrario, osservate lo stato in cui si trova dopo lo stato IDLE. Se viene visualizzato SEC, osservare la sequenza di frame secondaria FSM. Se vedete PRI, guardate la sequenza di fotogrammi primaria FSM.

BSC: Serial6: HDX-FSM event: RXV old_state: PND_RCV. new_state: IDLE.
BSC: Serial6: FS-FSM event: SDI EOT old_state: SEC. new_state: IDLE.
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: FS-FSM event: NDI BID old_state: IDLE. new_state: SEC.
BSC: Serial6: New Address(C2) New NS(01)
BSC: Serial6: HDX-FSM event: TX old_state: IDLE. new_state: PND_COMP.
BSC: Serial6: HDX-FSM event: CmpOTH old_state: PND_COMP. new_state: PND_RCV.
BSC: Serial6: SDI: Data (1 bytes): 37
BSC: Serial6: HDX-FSM event: RXV old_state: PND_RCV. new_state: IDLE.

Se osservate la tabella, vedete gli input sul lato sinistro e gli stati in alto. Ogni voce di una colonna è nel formato {next state,action} L'azione viene eseguita per prima, quindi viene eseguita la transizione.

Come utilizzare Local-Ack FSM

Accertarsi di eseguire local-ack. Un comando show bsc indica se l'interfaccia è più poller o più polle. Da ciò, utilizzare l'appropriato FSM BLACK.

Problemi comuni

Passaggio dei dati 3780 alla configurazione 3270 o viceversa

Attenzione:  Non farlo. Questo non funziona in modo affidabile.

Configura route a peer non valido

Hai configurato tutto e non succede niente. Il pacchetto debug bsc viene attivato sul router remoto e non viene visualizzato nulla. A questo punto, è possibile attivare il pacchetto debug bstun senza visualizzare nulla. In questa fase, attivare l'evento debug bstun; probabilmente non vedi ancora niente. Tornare al router terminale dell'host e attivare l'evento debug bstun. Verranno visualizzati diversi messaggi che indicano una connessione non valida.

Numeri di gruppo errati nella configurazione

Ciò si verifica quando una delle estremità del tunnel è configurata con un numero di gruppo diverso. I dati possono fuoriuscire dall'interfaccia sbagliata o essere eliminati a livello BSTUN.

I numeri di gruppo locale-ack e passthru non vengono combinati. Verificare che le definizioni dei gruppi di protocolli siano coerenti nell'intera rete. Anche i dispositivi che eseguono il contention (3780) devono avere numeri di gruppo diversi da quelli di un 3270.

Host tandem

21:55:18: BSC: Serial4: SDI-rx: Data (5 bytes): C7C740402D
21:55:19: BSC: Serial5: SDI-tx: Data (1 bytes): 37
21:55:19: BSC: Serial5: SDI-tx: Data (5 bytes): C2C240402D
21:55:21: BSC: Serial4: SDI-rx: Data (1 bytes): 37
21:55:21: BSC: Serial4: SDI-rx: Data (5 bytes): C7C740402D
21:55:22: BSC: Serial5: SDI-tx: Data (1 bytes): 37
21:55:22: BSC: Serial5: SDI-tx: Data (5 bytes): 404040402D
21:55:24: BSC: Serial4: SDI-rx: Data (1 bytes): 37

I tandem non obbediscono alle severe convenzioni 3270. Svolgono tutte le loro votazioni con sondaggi specifici, il che causa un problema per la mancanza di FSM. Per il corretto funzionamento dei tandem, configurare bsc spec-poll sull'interfaccia secondaria BSC.

Differenza tra full e half duplex

È facile confondere la modalità full duplex e half duplex.

• La modalità full duplex può trasmettere dati contemporaneamente tra una stazione di invio e una stazione ricevente.

• La modalità half-duplex può trasmettere i dati in una sola direzione alla volta, tra una stazione di invio e una stazione ricevente.

Per ulteriori informazioni, vedere la sezione sul comando show bsc.

Se è disponibile un analizzatore di protocolli o una breakout box, collegare l'analizzatore al sistema senza router.

• Se il segnale RTS o CTS viene modificato, si ha la modalità half-duplex; in caso contrario, è full duplex.

• Se il DCD sembra cambiare molto e la linea continua a salire o a scendere, è possibile che sia stato modificato.

Nota: il router primario può essere full duplex mentre il router remoto è half duplex e viceversa. Si tratta di linee fisiche separate e i segnali di controllo provenienti dalle interfacce non vengono trasportati attraverso il tunnel.

Esempi di BSC e BSTUN

Esempio di assenza di risposta del dispositivo

Questo è un esempio di due interfacce su un router secondario: uno locale-ack e l'altro passthru. Nessuno dei due sta ricevendo una risposta dal telecomando. Non appena si verificano polling nel router secondario, è necessario determinare cosa sta accadendo all'estremità remota.

21:55:18: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D
21:55:19: BSC: Serial5: SDI-tx: Data (1 bytes): 37
21:55:19: BSC: Serial5: SDI-tx: Data (5 bytes): C2C27F7F2D
21:55:21: BSC: Serial4: SDI-rx: Data (1 bytes): 37
21:55:21: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D
21:55:22: BSC: Serial5: SDI-tx: Data (1 bytes): 37
21:55:22: BSC: Serial5: SDI-tx: Data (5 bytes): 40407F7F2D
21:55:24: BSC: Serial4: SDI-rx: Data (1 bytes): 37
21:55:24: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D
21:55:25: BSC: Serial5: SDI-tx: Data (1 bytes): 37
21:55:25: BSC: Serial5: SDI-tx: Data (5 bytes): C2C27F7F2D
21:55:27: BSC: Serial4: SDI-rx: Data (1 bytes): 37
21:55:27: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D
21:55:28: BSC: Serial5: SDI-tx: Data (1 bytes): 37
21:55:28: BSC: Serial5: SDI-tx: Data (5 bytes): C2C27F7F2D
21:55:30: BSC: Serial4: SDI-rx: Data (1 bytes): 37
21:55:30: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D

Se si controlla l'estremità remota nella custodia passthru, è possibile vedere i frame passare attraverso il tunnel, ma il dispositivo collegato è ancora silenzioso.

BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: NDI: Data (4 bytes): C2C00037
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: NDI: Data (4 bytes): C2C00037
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: NDI: Data (4 bytes): C2C00037
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: NDI: Data (4 bytes): C2C00037
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: NDI: Data (4 bytes): C2C00037

Quindi, determinare se il dispositivo collegato è inattivo o se il router ha un trasmettitore non valido: attivare il debug degli eventi.

BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: FS-FSM event: NDI BID old_state: IDLE. new_state: SEC.
BSC: Serial6: New Address(C2) New NS(01)
BSC: Serial6: HDX-FSM event: TX old_state: IDLE. new_state: PND_COMP.
BSC: Serial6: HDX-FSM event: CmpOTH old_state: PND_COMP. new_state: PND_RCV.
BSC: Serial6: Response not received from remote
BSC: Serial6: HDX-FSM event: T/O old_state: PND_RCV. new_state: IDLE.
BSC: Serial6: NDI: Data (4 bytes): C2C00037
BSC: Serial6: FS-FSM event: NDI EOT old_state: SEC. new_state: IDLE.
BSC: Serial6: HDX-FSM event: TX old_state: IDLE. new_state: PND_COMP.
BSC: Serial6: HDX-FSM event: CmpEOT old_state: PND_COMP. new_state: IDLE.
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D
BSC: Serial6: FS-FSM event: NDI BID old_state: IDLE. new_state: SEC.
BSC: Serial6: New Address(C2) New NS(01)

Dal trace, seguire l'HDX-FSM. Se il trasmettitore è bloccato nello stato PND_COMP, si verifica un errore nel trasmettitore. Probabilmente non viene fornito alcun orologio. Come si può vedere nell'output dell'esempio precedente, lo stato PND_RCV viene raggiunto e viene visualizzata la risposta non ricevuta dal telecomando, che indica una ricezione errata o una periferica inattiva.

Esempio di latenze di rete

Questo è un esempio di latenze di rete in un ambiente multidrop virtuale:

BSC: Serial0: NDI: Data (5 bytes): C703001061
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (5 bytes): 404040402D
BSC: Serial0: NDI: Data (4 bytes): 40C00037
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37

!--- Output suppressed.

BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (5 bytes): C4C4C4C42D

Si è verificato un problema in questo caso, poiché C4 non ha risposto in tempo:

BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (5 bytes): C5C5C5C52D
BSC: Serial0: NDI: Data (4 bytes): C5C00037
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (5 bytes): C7C7C7C72D

Di nuovo, questo è perso. Guardate oltre, e vedete che il problema diventa un po' peggiore:

BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (5 bytes): 404040402D
BSC: Serial0: NDI: Data (4 bytes): 40C00037
BSC: Serial0: SDI: Data (1 bytes): 37
BSC: Serial0: Discard SDI: Data (1 bytes): 37
BSC: Serial0: SDI: Data (5 bytes): C1C1C1C12D

L'EOT per C7 è apparso di nuovo all'improvviso. Ignorare l'EOT da ripristinare; il frame successivo è l'EOT per C1.

Nell'esempio, i frame della rete stanno arrivando in ritardo e fuori sequenza. Ciò provoca un gran numero di sondaggi senza risposta presso l'host. La soluzione, in questo caso, è configurare l'ack locale.

Configurazioni di esempio BSC e BSTUN

Esempio di rete

Il diagramma mostra una configurazione di esempio di un sito in cui sono in esecuzione entrambi i terminali bisync 3270 e 3780.

Configurazioni

Il diagramma utilizza le configurazioni seguenti:

• Centrale

• Remoto 1

• Remoto 2

hostname central
!
bstun peer-name 10.10.10.107
bstun protocol-group 1 bsc
bstun protocol-group 2 bsc
bstun protocol-group 44 bsc-local-ack
!
interface Serial0
 description EFTPOS host
 no ip address
 encapsulation bstun
 no keepalive
 full-duplex
 clockrate 19200
 bstun group 1
 bsc contention 1
 bstun route all tcp 10.10.10.108
!
interface Serial2
 description WAN-ppp backbone
 ip address 10.10.10.107 255.255.255.0
 encapsulation ppp
 clockrate 2000000
!
interface Serial3
 description WAN-hdlc
 ip address 10.10.20.107 255.255.255.0
 bandwidth 2000
 no keepalive
 clockrate 2000000
!
interface Serial4
 description ATM Host
 no ip address
 encapsulation bstun
 no keepalive
 full-duplex
 bstun group 44
 bsc secondary
 bstun route all tcp 10.10.20.108
!
interface Serial5
 description ATM host
 no ip address
 encapsulation bstun
 no keepalive
 bstun group 2
 bsc secondary
 bstun route address C2 tcp 10.10.20.108
!
end

hostname remote1
!
bstun peer-name 10.10.10.108
bstun protocol-group 1 bsc
bstun protocol-group 44 bsc-local-ack
!
interface Serial0
 description EFTPOS 1
 no ip address
 encapsulation bstun
 no keepalive
 full-duplex
 clockrate 19200
 bstun group 1
 bsc char-set ebcdic
 bsc contention
 bstun route all tcp 10.10.10.107
!
interface Serial1
 description ATM 3
 no ip address
 encapsulation bstun
 no keepalive
 bstun group 44
 bsc char-set ebcdic
 bsc primary
 bstun route address 40 tcp 10.10.10.107
!
interface Serial3
 description WAN -ppp
 ip address 10.10.10.108 255.255.255.0
 encapsulation ppp
!
end

hostname remote2
!
!
bstun peer-name 10.10.20.108
bstun protocol-group 2 bsc
bstun protocol-group 44 bsc-local-ack
bstun protocol-group 10 bsc-local-ack
!
interface Serial0
 description WAN-hdlc
 ip address 10.10.20.108 255.255.255.0
 bandwidth 2000
 no keepalive
!
interface Serial5
 description ATM 1
 mtu 265
 encapsulation bstun
 clockrate 19200
 bstun group 44
 bsc char-set ebcdic
 bsc primary
 bstun route address C2 tcp 10.10.10.107
!
interface Serial6
 description interface for ATM 2
 mtu 265
 encapsulation bstun
 clockrate 19200
 bstun group 2
 bsc char-set ebcdic
 bsc primary
 bstun route address C2 tcp 10.10.10.107
!
ip route 10.10.10.0 255.255.255.0 10.10.20.107
!
end

Riferimenti

Informazioni generali - Binary Synchronous Communication, IBM Systems Reference Library, GA27-3004-2.

IBM 3274: Capitolo 4: Operazioni remote BSC.

IBM 3275: Capitolo 9.

Comandi BSTUN sul CD-ROM della documentazione Cisco (disponibile online in Comandi Serial Tunnel e Block Serial Tunnel).

Informazioni correlate

• Configurazione e risoluzione dei problemi di Serial Tunneling (STUN)
• Supporto tecnico – Cisco Systems