Data Link Switching Plus

Introduzione

DLSw (Data-link switching) è uno standard implementato da IBM che supporta il trasporto di LLC (Logical Link Control) su WAN. DLSw è una forma più elaborata di RSRB (Remote Source-Route Bridging) ed è più specifica per quanto riguarda le operazioni che può o non può eseguire. DLSw richiede che il router trasporti una sessione LLC2 valida o una sessione NetBIOS.

I router Cisco implementano la RFC 1795 (standard DSLw) e la RFC 2166 (DLSw versione 2). Inoltre, DLSw implementa più funzioni per il controllo del broadcast e trasporta meno informazioni sulla WAN rispetto ad altri metodi.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Convenzioni

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

Comandi generali

In questa sezione vengono descritti importanti comandi DLSw, i comandi per la configurazione di DLSw e i comandi per la risoluzione dei problemi di DLSw.

source-bridge ring-group

Il primo passaggio nella configurazione di DLSw è aggiungere il comando source-bridge ring-group. Questo comando connette le interfacce Token Ring che eseguono il bridging origine-route (SRB).

Nota: quando si eseguono le DLSw su un router dotato solo di interfacce Ethernet, non è necessario configurare un ring group.

Definizione dell'identificazione peer locale

L'opzione successiva consente di definire l'identificazione peer locale. Questo è un indirizzo IP nella stessa casella. In questo modo viene avviato DLSw nel router.

L'opzione più semplice per configurare DLSw è quella di stabilire l'indirizzo ip del peer-id locale. Di seguito vengono descritti i parametri del comando:

• group and border: questi comandi vengono eseguiti insieme per creare peer di confine nella rete.

• cost: questo comando viene emesso quando sono presenti più percorsi alla stessa posizione. Questo comando indica al router come raggiungere questi siti remoti usando prima il percorso più economico.

• lf: questo comando determina la dimensione massima del frame che il peer può gestire. Le dimensioni dei frame possono essere:

  • Dimensione massima del frame di 516-516 byte

  • Dimensione massima del frame di 1470-1470 byte

  • Dimensione massima del frame di 1500-1500 byte

  • Dimensione massima del frame di 2052-2052 byte

  • Dimensione massima del frame di 4472-4472 byte

  • Dimensione massima del frame di 8144-8144 byte

  • Dimensione massima del frame di 1.407-1.407 byte

  • Dimensione massima del frame di 1.454-1.454 byte

  • Dimensione massima del frame di 17800-17800 byte

• keepalive: questo comando definisce l'intervallo tra i pacchetti keepalive. L'intervallo può variare da 0 a 1200 secondi. In genere è impostato su 0 quando si configura DLSw per il routing DDR (Dial-on-Demand Routing).

• passive: questo comando configura il router in modo che non avvii un avvio peer dal router.

• promiscuo: questo comando indica che il router accetta le connessioni da qualsiasi peer remoto che richiede un avvio peer. Questo comando è utile nei siti di grandi dimensioni con molti peer, in quanto non è necessario definire tutti i peer remoti nel router principale.

• biu-segment: questo comando è un'opzione delle DLSw che consente alle DLSw di controllare le dimensioni del segmento più alte nei livelli SNA (System Network Architecture). Questo comando consente alle stazioni terminali di ritenere di poter inviare quantità maggiori di dati.

Definisci peer remoto

Dopo aver definito il peer locale, è possibile definire il peer remoto. È possibile definire tre tipi di peer: TCP, Fast-Sequenced Transport (FST), Direct High-Level Link Control (HDLC) e Frame Relay. Di seguito sono riportate le spiegazioni dei comandi eseguiti per definire il peer remoto:

Di seguito vengono descritte le opzioni del comando:

• backup peer: questa opzione di comando definisce il peer che esegue il backup del peer in caso di errore del primo peer.

• cost: questa opzione di comando definisce il costo del peer. Questo comando viene utilizzato quando vi sono più percorsi a una destinazione e quando è necessario uno scenario con capacità preferita.

• dest-mac, dynamic, no-llc e inactivity: queste opzioni di comando sono discusse nella sezione Backup/Cost Peer di questo documento.

• dmac-output-list: questa opzione di comando viene emessa per definire un elenco degli accessi che indichi al router quali indirizzi MAC di destinazione remota autorizzare, o negare, il traffico dell'esploratore.

• host-netbios-out: questa opzione di comando viene emessa per applicare i nomi dei filtri host NetBIOS.

• keepalive: questa opzione di comando consente di determinare l'intervallo in secondi tra i pacchetti keepalive. Viene utilizzato principalmente per le impostazioni DDR.

• lf: questa opzione di comando specifica la dimensione massima consentita per il peer.

• residuo: questa opzione di comando specifica il tempo che il router lascia aperto il peer di backup e che diventa attivo (a causa di un errore primario) dopo che il collegamento primario torna attivo.

• priority: questa opzione di comando crea più peer per assegnare la priorità al traffico DLSw.

• tcp-queue-max: questa opzione di comando modifica il valore predefinito di 200 per le code TCP.

• timeout: questa opzione del comando indica il numero di secondi che il protocollo TCP attende per un riconoscimento prima di interrompere la connessione.

• V2-single-tcpM: questa opzione di comando è progettata per l'utilizzo in ambienti NAT (Network Address Translation). Ogni peer ritiene di disporre dell'indirizzo IP più alto per impedire a ogni peer di interrompere una delle connessioni TCP.

Timer utilizzati nelle DLSw

Ecco le spiegazioni dei timer usati in DLSw:

Questi parametri sono molto utili. Ad esempio, è possibile modificare l'intervallo in secondi tra l'invio di un elenco di cartelle da parte del router. In questo modo è possibile ridurre la quantità di esploratori nella rete aumentando il tempo che li separa. Inoltre, è possibile modificare i valori di timeout delle voci della cache da parte del router.

Comandi DLSw aggiuntivi

Questi sono altri importanti comandi DLSw:

• dlsw allroute-sna/netbios: questo comando viene emesso per modificare il comportamento di DLSw in modo che vengano utilizzati tutti gli esploratori di percorso anziché gli esploratori di percorso singoli.

• dlsw bridge-group: questo comando viene emesso per collegare i domini con bridging trasparente a DLSw. È ampiamente utilizzato per la configurazione di NetBIOS con Ethernet.

• dlsw explorerq-depth: questo comando imposta il valore della coda di DLSw explorer. Questo comando viene emesso dopo il normale comando source-bridge explorer-queue, ma si riferisce a tutti i frame CANUREACH (CUR) che devono essere elaborati. Questo comando è importante perché copre i pacchetti provenienti da Ethernet, anche se non è specificato nel comando source-bridge explorerq-depth. Per ulteriori informazioni sul comando Source-Route Bridging, consultare il documento sulla descrizione e la risoluzione dei problemi di Source-Route Bridging.

Comandi show

I comandi show e gli output descritti in questa sezione sono utili per risolvere i problemi relativi alle DLSw.

show dlsw peer

Questo comando fornisce informazioni sui peer. In questa sezione vengono visualizzati tutti i peer remoti configurati, inclusa la quantità di pacchetti trasmessi e ricevuti.

Peers:                state     pkts_rx   pkts_tx  type  drops ckts TCP   uptime
 TCP 5.5.5.1         CONNECT          2         2  conf      0    0   0 00:00:06

Questi sono gli stati possibili:

• CONNECT: questo stato indica che il peer DLSw è attivo e in esecuzione.

• DISCONNECT: questo stato indica che il peer è inattivo o non connesso.

• CAP_EXG: questo stato indica che DLSw è in grado di scambiare funzionalità con il peer remoto.

• WAIT_RD: questo stato è l'ultimo passaggio nell'avvio del peer. Questo peer è in attesa che il peer remoto apra la porta di lettura. Fare riferimento alla sezione debug di questo documento per ulteriori informazioni su quando il peer si avvia e usa il comando debug dlsw peer.

• WAN_BUSY: questo stato significa che la coda TCP in uscita è piena e il pacchetto non può essere trasmesso.

Il comando show dlsw peer mostra anche il numero di cali, la quantità di circuiti sul peer specifico, la coda TCP e il tempo di attività. L'altezza del contatore aumenta per i seguenti motivi:

• L'interfaccia WAN non è attiva per un peer diretto.

• DLSw tenta di inviare un pacchetto prima che il peer sia completamente connesso (in attesa dell'evento TCP o dell'evento di funzionalità). Coda TCP in uscita piena.

• Mancata corrispondenza del numero di sequenza FST.

• Impossibile ottenere il buffer per il pacchetto FST dell'opzione lenta.

• Guasto del controller CiscoBus nella fascia alta; Impossibile spostare il pacchetto dal buffer di ricezione al buffer di trasmissione o viceversa.

• L'indirizzo IP di destinazione del pacchetto FST non corrisponde all'ID peer locale.

• Interfaccia WAN non attiva per un peer FST.

• Nessun comando di cache route SRB configurato.

• Il buffer madge ring è pieno sui sistemi di fascia bassa: La LAN di alimentazione WAN è troppo veloce.

mostra funzionalità dlsw

DLSw: Capabilities for peer 5.5.5.1(2065)
  vendor id (OUI)         : '00C' (cisco)
  version number          : 1
  release number          : 0
  init pacing window      : 20
  unsupported saps        : none
  num of tcp sessions     : 1
  loop prevent support    : no
  icanreach mac-exclusive : no
  icanreach netbios-excl. : no
  reachable mac addresses : none
  reachable netbios names : none
  cisco version number    : 1
  peer group number       : 0
  border peer capable     : no
  peer cost               : 3
  biu-segment configured  : no
  local-ack configured    : yes
  priority configured     : no
  version string          :
Cisco Internetwork Operating System Software
IOS (tm) 4500 Software (C4500-J-M), Version 10.3(13), RELEASE SOFTWARE (fc2)
Copyright (c) 1986-1996 by cisco Systems, Inc.

mostra raggiungibilità dlsw

DLSw MAC address reachability cache list
Mac Addr        status     Loc.    peer/port            rif
0800.5a0a.c51d  FOUND      LOCAL   TokenRing3/0     06B0.0021.00F0
0800.5a49.1e38  FOUND      LOCAL   TokenRing3/0     06B0.0021.00F0
0800.5a95.3a13  FOUND      REMOTE  5.5.5.1(2065)
 
DLSw NetBIOS Name reachability cache list
NetBIOS Name    status     Loc.    peer/port            rif
PIN-PIN         FOUND      LOCAL   TokenRing3/0     06B0.0021.00F0
QUENEPA         FOUND      LOCAL   TokenRing3/0     06B0.0021.00F0
WIN95           FOUND      REMOTE  5.5.5.1(2065)

Il campo status è la parte più importante del comando show dlsw reach. Gli stati possibili sono:

• FOUND: il router ha individuato il dispositivo.

• RICERCA: il router sta cercando la risorsa.

• NOT_FOUND: la cache negativa è attiva e la stazione non ha risposto alle query.

• NON CONFERMATO: la stazione è configurata, ma DLSw non l'ha verificata.

• VERIFY: verifica delle informazioni della cache perché la cache sta diventando obsoleta o la configurazione utente è in corso di verifica.

mostra circuito dlsw

Index           local addr(lsap)    remote addr(dsap)  state
1622193728      4001.68ff.0001(04)  4000.0000.0001(04) CONNECTED
        PCEP: 60A545B4   UCEP: 60B0B640
        Port:To3/0          peer 5.5.5.1(2065)
        Flow-Control-Tx CW:20, Permitted:32; Rx CW:20, Granted:32
        RIF = 06B0.0021.00F0

Quando si esegue il comando show dlsw circuit, prestare attenzione al controllo del flusso. Il controllo del flusso esiste per circuito. Si tratta di una comunicazione che ha luogo mentre i due peer DLSw assegnano al circuito una finestra di possibile trasferimento. Questo valore aumenta e diminuisce a seconda della quantità di traffico che il circuito sta tentando di attraversare. Il valore può variare a seconda della congestione del cloud.

Il comando show dlsw circuit è più esteso a partire dalla versione IOS 11.1. Il comando permette ora di esaminare il circuito DLSw su un valore SAP (Service Access Point) o MAC, semplificando l'individuazione dei circuiti durante la risoluzione dei problemi. Di seguito viene riportato un esempio di output:

ibu-7206#sh dlsw cir
Index           local addr(lsap)    remote addr(dsap)  state
1622193728      4001.68ff.0001(04)  4000.0000.0001(04) CONNECTED
ibu-7206#sh dls cir det ?
  <0-4294967295>  Circuit ID for a specific remote circuit
  mac-address     Display all remote circuits using a specific MAC
  sap-value       Display all remote circuits using a specific SAP
  <cr>
 
ibu-7206#show dlsw circuit detail mac 4000.0000.0001
Index           local addr(lsap)    remote addr(dsap)  state
1622193728      4001.68ff.0001(04)  4000.0000.0001(04) CONNECTED
        PCEP: 60A545B4   UCEP: 60B0B640
        Port:To3/0          peer 5.5.5.1(2065)
        Flow-Control-Tx CW:20, Permitted:29; Rx CW:20, Granted:29
        RIF = 06B0.0021.00F0
241-00  4000.0000.0001(04)  4001.68ff.0000(04) CONNECTED
        Port:To0          peer 5.5.7.1(2065)
        Flow-Control-Tx CW:20, Permitted:27; Rx CW:20, Granted:27
        RIF = 0630.00F1.0010
s5e#sh cls
DLU user: DLSWDLU
      SSap:0x63       type:  llc0   class:0
        DTE:0800.5a95.3a13 0800.5a0a.c51d F0 F0
        T1 timer:0      T2 timer:0      Inact timer:0
        max out:0       max in:0        retry count:0
        XID retry:0     XID timer:0     I-Frame:0
 
        DTE:4000.0000.0001 4001.68ff.0000 04 04
        T1 timer:0      T2 timer:0      Inact timer:0
        max out:0       max in:0        retry count:0
        XID retry:0     XID timer:0     I-Frame:0
TokenRing0 DTE: 4000.0000.0001 4001.68ff.0000 04 04 state NORMAL
   V(S)=23, V(R)=23, Last N(R)=22, Local window=7, Remote Window=127
   akmax=3, n2=8, Next timer in 1240
   xid-retry timer      0/0       ack timer    1240/1000
   p timer              0/1000    idle timer  10224/10000
   rej timer            0/3200    busy timer      0/9600
   akdelay timer        0/100     txQ count       0/200

Risoluzione dei problemi

Per impostazione predefinita, DLSw termina le sessioni LLC sui router (local-ack). Inoltre, poiché termina il campo RIF (Routing Information Field), è necessario considerare altri problemi di progettazione. In questa sezione vengono descritti i problemi DLSw più comuni.

Loop

Una delle cose più importanti da ricordare riguardo a DLSw è la terminazione RIF. Si tratta di un problema perché è possibile creare facilmente i loop principali nella rete. Il diagramma mostra un loop:

In questo caso, poiché DLSw termina il RIF, il pacchetto continua a circolare all'infinito. Questo perché ogni volta che un frame CUR viene inviato da un peer all'altro, il peer ricevente crea un nuovo explorer (NO RIF) e lo invia. Di seguito sono descritti i passaggi dell'elenco delle cartelle:

1. Il 3174 nel ring 11 invia un esploratore per raggiungere l'host.

2. Sia SF1 che il ponte copiano la cornice.

3. SF1 crea un frame CUR a LA1 (il suo peer) per comunicare a LA1 che il 3174 vuole raggiungere l'HOST.

4. SF2 riceve il pacchetto e fa la stessa cosa.

5. Ora LA1 e LA2 creano l'esploratore e lo inviano al ring.

6. LA1 e LA2 ricevono un elenco di cartelle creato l'uno dall'altro.

7. Ora c'è un dilemma, perché entrambe le parti credono che il 3174 sia collegato localmente.

8. Ogni router dispone dello switch 3174, sia in locale che in remoto.

9. Ora inviano un frame Icanreach a SF1 e SF2, rispettivamente, che crea una risposta dall'host verso il 3174.

10. Sia SF1 che SF2 inseriscono la risposta dell'esploratore sul Token Ring e ognuno di essi apprende che l'indirizzo MAC dell'host è raggiungibile localmente e in remoto.

11. La raggiungibilità DLSw costituisce un firewall efficace contro il loop indefinito di explorer. Tuttavia, con i frame di informazioni senza numero (UI), questo può eseguire un loop, quindi guidare l'utilizzo della CPU e della linea fino al 100%.

In questo caso, verificare che l'anello virtuale nei router sia esattamente lo stesso su ogni lato del cloud, come mostrato nel diagramma:

I router su ciascun lato del cloud hanno lo stesso numero di anello virtuale. In questo modo, uno dei router invia un elenco di cartelle che ha già attraversato il ring, quindi il router lo scarta. Quando LA1 genera un explorer per un frame CUR ricevuto da SF1, LA2 lo rifiuta in quanto il explorer ha già attraversato il ring 1. In questo scenario, è importante che il router abbia un bridge diverso configurato se il pacchetto è diretto allo stesso ring, come nel caso del lato LA della rete.

In una versione Ethernet dello stesso scenario è necessario disabilitare un peer. Il seguente diagramma mostra un esempio:

Poiché un pacchetto su Ethernet non ha un RIF, il router non può determinare se la trasmissione, creata dall'altro router sulla LAN, proviene dall'altro router o da una stazione di origine. Con la SNA, il pacchetto ha origine locale o è remoto. Poiché gli elenchi di esplorazione di un ambiente Token Ring dispongono in effetti di indirizzi MAC di origine e di destinazione, non sono una trasmissione su Ethernet, ma un frame diretto a una stazione da un'altra.

Di seguito vengono illustrati gli eventi del diagramma precedente:

1. Lo switch 3174 invia un esploratore all'host.

2. Questo explorer è accettato sia da SF1 che da SF2.

3. SF1 e SF2 generano ciascuna un CUR sull'altro lato LA1 e LA2.

4. Questi generano un oggetto explorer a cui l'host risponde; poiché si tratta di un elenco di cartelle a route singola, viene fornita una risposta con un elenco di cartelle a route completa.

5. Sia LA1 che LA2 creano un frame CUR per SF1 e SF2, che creano il pacchetto per 3174.

6. SF1 sente l'indirizzo MAC dell'HOST proveniente da Ethernet e ora ritiene che l'HOST si trovi sulla LAN locale. Ma nella cache di SF1, l'ID HOST risponde da un peer remoto.

7. In questo modo, l'host del router è sia locale che remoto e il DLSw è interrotto.

Peer di backup/costo

I peer di backup aggiungono tolleranza di errore alle DLSw nel caso in cui un peer venga perso. Questa funzionalità viene in genere configurata negli ambienti core in modo che, in caso di guasto di un router principale, un altro router possa accettare il router in errore. Le configurazioni e il diagramma in questa sezione illustrano una configurazione peer di backup.

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3b
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.14.1
   cost 2 promiscuous
!
interface Loopback0
 ip address 1.1.14.1 255.255.255.0
!
interface Serial0
 ip address 1.1.6.2 255.255.255.0
 bandwidth 125000
 clockrate 125000
!
interface TokenRing0
 ip address 1.1.5.1 255.255.255.0
 ring-speed 16
 source-bridge 3 1 2
 source-bridge spanning
!

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3c
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.12.1
   cost 4 promiscuous
!
interface Loopback0
 ip address 1.1.12.1 255.255.255.0
!
interface Serial0
 ip address 1.1.4.1 255.255.255.0
 bandwidth 500000
 clockrate 500000
!
interface TokenRing0
 ip address 1.1.5.2 255.255.255.0
 ring-speed 16
 source-bridge 3 2 2
 source-bridge spanning
!

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3a
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.13.1
dlsw remote-peer 0 tcp 1.1.14.1
dlsw remote-peer 0 tcp 1.1.12.1
dlsw timer explorer-wait-time 2
!
interface Loopback0
 ip address 1.1.13.1 255.255.255.0
!
interface Serial0
 ip address 1.1.6.1 255.255.255.0
 bandwidth 500000
!
interface Serial1
 ip address 1.1.4.2 255.255.255.0
 bandwidth 125000
!
interface TokenRing0
 ip address 1.1.1.1 255.255.255.0
 ring-speed 16
 source-bridge 3 1 2
 source-bridge spanning
!

La prima cosa da ricordare sui peer DLSw cost è che entrambi sono attivi. Il router mantiene solo un peer di backup. Se il linger è configurato, può avere due. Questo è quello che si è verificato nel diagramma precedente:

1. D3a riceve un elenco di cartelle e avvia il processo inviando un frame CUR a ogni peer remoto.

2. D3B e D3C ricevono i frame CUR. Ognuno genera un oggetto Explorer per l'host, che risponde sia a D3B che a D3C.

3. Sia D3B che D3C rispondono a D3A con Icanreach.

4. D3A invia la risposta del navigatore alla stazione terminale.

5. La stazione remota avvia il circuito dlsw, con l'identificazione di scambio (XID) per SNA e l'impostazione della modalità asincrona bilanciata estesa (SABME) per NetBIOS.

6. D3A seleziona i costi inferiori entro i limiti di raggiungibilità.

C'è un timer in D3A che può essere definito per dire al router quanto tempo deve attendere che tutti gli explorer tornino a D3A. In questo modo si evitano i problemi relativi ai costi che possono verificarsi quando il router utilizza il primo explorer che ritorna al router. Eseguire il comando dlsw timer explorer-wait-time <seconds> per impostare il timer.

Inoltre, quando si eseguono peer di confine, DLSw invia solo un frame CUR al peer più economico. Si comporta in modo diverso quando esegue costi senza peer di confine.

I peer di backup funzionano in modo leggermente diverso. Specificare il peer di backup nel peer di cui verrà eseguito il backup per il peer specificato. Ciò significa che il peer con l'istruzione di backup è il peer di backup stesso.

Specificare l'opzione linger in modo che, quando il peer primario torna operativo, i circuiti non possano essere eliminati immediatamente. Ciò è utile se il peer primario varia verso l'alto e verso il basso, poiché non si desidera utilizzare il peer difettoso.

In questo modo viene illustrata la configurazione dei peer di backup:

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3b
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.14.1
   promiscuous
!
interface Loopback0
 ip address 1.1.14.1 255.255.255.0
!
interface Serial0
 ip address 1.1.6.2 255.255.255.0
 bandwidth 125000
 clockrate 125000
!
interface TokenRing0
 ip address 1.1.5.1 255.255.255.0
 ring-speed 16
 source-bridge 3 1 2
 source-bridge spanning
!

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3c
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.12.1
   promiscuous
!
interface Loopback0
 ip address 1.1.12.1 255.255.255.0
!
interface Serial0
 ip address 1.1.4.1 255.255.255.0
 bandwidth 500000
 clockrate 500000
!
interface TokenRing0
 ip address 1.1.5.2 255.255.255.0
 ring-speed 16
 source-bridge 3 2 2
 source-bridge spanning
!

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3a
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.13.1
dlsw remote-peer 0 tcp 1.1.14.1
dlsw remote-peer 0 tcp 1.1.12.1 backup-peer 1.1.14.1 linger 5
dlsw timer explorer-wait-time 2
!
interface Loopback0
 ip address 1.1.13.1 255.255.255.0
!
interface Serial0
 ip address 1.1.6.1 255.255.255.0
 bandwidth 500000
!
interface Serial1
 ip address 1.1.4.2 255.255.255.0
 bandwidth 125000
!
interface TokenRing0
 ip address 1.1.1.1 255.255.255.0
 ring-speed 16
 source-bridge 3 1 2
 source-bridge spanning
!

Il peer viene disconnesso usando il comando show dlsw peer:

d3a#sh dls peer
Peers:                state     pkts_rx   pkts_tx  type  drops ckts TCP   uptime
 TCP 1.1.14.1        CONNECT        464      1286  conf      0    0   0 03:17:02
 TCP 1.1.12.1        DISCONN          0         0  conf      0    0   -        -

Bordi peer

I peer di confine sono un'importante funzione DLSw perché risolvono il problema del controllo della trasmissione in una rete. In questo esempio viene illustrato come vengono configurati i peer del bordo e cosa accade quando viene visualizzata una sessione:

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3e
!
!
dlsw local-peer peer-id 1.1.11.1 group 1
   border promiscuous
dlsw remote-peer 0 tcp 1.1.12.1
!
interface Loopback0
 ip address 1.1.11.1 255.255.255.0
!
interface Serial0
 ip address 1.1.3.1 255.255.255.0
!
interface Serial1
 ip address 1.1.2.2 255.255.255.0
 clockrate 500000
!
interface TokenRing0
 ip address 10.17.1.189 255.255.255.0
 ring-speed 16
!
router ospf 100
 network 1.0.0.0 0.255.255.255 area 0
!

Current configuration:
!
version 11.1

service udp-small-servers
service tcp-small-servers
!
hostname d3c
!
!
dlsw local-peer peer-id 1.1.12.1 group 2
   border promiscuous
dlsw remote-peer 0 tcp 1.1.11.1
!
interface Loopback0
 ip address 1.1.12.1 255.255.255.0
!
interface Serial0
 ip address 1.1.4.1 255.255.255.0
 no fair-queue
 clockrate 500000
!
interface Serial1
 ip address 1.1.3.2 255.255.255.0
 clockrate 500000
!
interface TokenRing0
 no ip address
 shutdown
 ring-speed 16
!
router ospf 100
 network 1.0.0.0 0.255.255.255 area 0
!

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3f
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.10.1 group 1
   promiscuous
dlsw remote-peer 0 tcp 1.1.11.1
dlsw peer-on-demand-defaults inactivity 1
!
interface Loopback0
 ip address 1.1.10.1 255.255.255.0
!
interface Serial0
 ip address 1.1.2.1 255.255.255.0
 no fair-queue
!!
interface TokenRing0
 ip address 1.1.1.1 255.255.255.0
 ring-speed 16
 source-bridge 1 1 2
 source-bridge spanning
!
router ospf 100
 network 1.0.0.0 0.255.255.255 area 0

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3a
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.13.1 group 2
   promiscuous
dlsw remote-peer 0 tcp 1.1.12.1
dlsw peer-on-demand-defaults inactivity 1
!
interface Loopback0
 ip address 1.1.13.1 255.255.255.0
!
interface Serial0
 ip address 1.1.4.2 255.255.255.0
!
interface TokenRing0
 ip address 1.1.5.1 255.255.255.0
 ring-speed 16
 source-bridge 3 1 2
 source-bridge spanning
!
router ospf 100
 network 1.0.0.0 0.255.255.255 area 0
!

La prima parte della configurazione dei peer di confine consiste nel creare peer promiscui. I peer promiscui accettano le connessioni da qualsiasi router DLSw che tenta di aprire un peer con questo router. Ad esempio, nel diagramma precedente si desidera che D3A apra un peer con D3F. Se non sono presenti peer con bordo, è necessario configurare peer statici nella rete. Questa procedura funziona correttamente, ma quando si hanno centinaia di siti e si utilizzano peer statici quando un router deve trovare una stazione in remoto, deve inviare un frame CUR a ciascun peer. Questo può causare un grande sovraccarico.

D'altra parte, quando si utilizzano peer di bordo, quel router remoto deve inviare solo una richiesta al peer di bordo. Questa richiesta viene quindi propagata attraverso i gruppi e il router remoto apre un peer con l'altro router remoto per avviare un circuito e stabilire una connessione. Questo processo viene spiegato nel diagramma seguente:

1. Quando D3A riceve l'elenco di cartelle, invia una trasmissione a D3C. D3C è il peer del bordo a cui D3A è collegato.

2. Quando D3C riceve il frame CUR, lo invia a tutti i peer del gruppo. D3C invia inoltre un frame di prova a tutte le interfacce locali configurate a tale scopo e invia un frame CUR ai peer di bordo dell'altro gruppo.

3. D3E riceve il CUR da D3C in un altro gruppo. Quindi D3E fa lo stesso inviando il CUR a tutti i peer del gruppo e a tutte le interfacce locali.

4. D3F riceve il frame CUR e invia un polling di test all'interfaccia locale. Se D3F ha un peer che punta a un altro router, non può eseguire l'echo del frame CUR a un altro router.

5. Quando D3F riceve una risposta per la stazione terminale, restituisce il frame Icanreach a D3E.

6. D3E lo invia a D3C, che lo inoltra a D3A. D3A invia una risposta di test al dispositivo.

7. Quando la stazione terminale avvia un circuito dlsw, con XID per SNA e SABME per NetBIOS, D3A avvia una connessione peer con D3F e avvia la sessione.

Questo è il debug eseguito sia da D3C che da D3A durante il processo:

d3a#
DLSW Received-ctlQ : CLSI Msg : TEST_STN.Ind   dlen: 40
CSM: Received CLSI Msg : TEST_STN.Ind   dlen: 40 from TokenRing0
CSM:   smac c001.68ff.0000, dmac 4000.0000.0001, ssap 4 , dsap 0
DLSw: sending bcast to BP peer 1.1.12.1(2065)

Viene visualizzato il frame di test che entra nel router. Quindi, il router genera un frame CUR in D3C. L'attività D3C visualizza questo output:

DLSw: Pak from peer 1.1.13.1(2065) with op DLX_MEMBER_TO_BP
DLSw: recv_member_to_border() from peer 1.1.13.1(2065)
DLSw: passing pak to core originally from 1.1.13.1 in group 2
%DLSWC-3-RECVSSP: SSP OP = 3( CUR  ) -explorer from peer 1.1.13.1(2065)
DLSw: Pak from peer 1.1.11.1(2065) with op DLX_RELAY_RSP
DLSW: relaying pak to member 1.1.13.1 in group 2

Quando D3C riceve il pacchetto da D3A, lo inoltra al core. In seguito verrà visualizzata la risposta del peer remoto che viene ritrasmesso a D3A. D3A avvia quindi la connessione (peer on demand) con il peer remoto D3F in questo debug:

DLSw: Pak from peer 1.1.12.1(2065) with op DLX_RELAY_RSP
DLSW: creating a peer-on-demand for 1.1.10.1
DLSw: passing pak to core originally from 1.1.10.1 in group 1
%DLSWC-3-RECVSSP: SSP OP = 4( ICR  ) -explorer from peer 1.1.10.1(2065)
DISP Sent : CLSI Msg : TEST_STN.Rsp   dlen: 44
DLSW Received-ctlQ : CLSI Msg : ID_STN.Ind   dlen: 54
CSM: Received CLSI Msg : ID_STN.Ind   dlen: 54 from TokenRing0
CSM:   smac c001.68ff.0000, dmac 4000.0000.0001, ssap 4 , dsap 4
DLSw: new_ckt_from_clsi(): TokenRing0 4001.68ff.0000:4->4000.0000.0001:4
DLSw: action_a() attempting to connect peer 1.1.10.1(2065)
DLSw: action_a(): Write pipe opened for peer 1.1.10.1(2065)
DLSw: peer 1.1.10.1(2065), old state DISCONN, new state WAIT_RD
DLSw: passive open 1.1.10.1(11003) -> 2065
DLSw: action_c(): for peer 1.1.10.1(2065)
DLSw: peer 1.1.10.1(2065), old state WAIT_RD, new state CAP_EXG
DLSw: CapExId Msg sent to peer 1.1.10.1(2065)
DLSw: Recv CapExId Msg from peer 1.1.10.1(2065)
DLSw: Pos CapExResp sent to peer 1.1.10.1(2065)
DLSw: action_e(): for peer 1.1.10.1(2065)
DLSw: Recv CapExPosRsp Msg from peer 1.1.10.1(2065)
DLSw: action_e(): for peer 1.1.10.1(2065)
DLSw: peer 1.1.10.1(2065), old state CAP_EXG, new state CONNECT
DLSw: peer_act_on_capabilities() for peer 1.1.10.1(2065)
DLSw: action_f(): for peer 1.1.10.1(2065)
DLSw: closing read pipe tcp connection for peer 1.1.10.1(2065)
DLSw: new_ckt_from_clsi(): TokenRing0 4001.68ff.0000:4->4000.0000.0001:4
DLSw: START-FSM (1474380): event:DLC-Id state:DISCONNECTED
DLSw: core: dlsw_action_a()
DISP Sent : CLSI Msg : REQ_OPNSTN.Req   dlen: 106
DLSw: END-FSM (1474380): state:DISCONNECTED->LOCAL_RESOLVE

Dopo aver ricevuto il pacchetto inoltrato dal peer di confine, il router apre un peer su richiesta con il peer remoto D3F (1.1.10.1) e avvia il circuito.

debug

Il primo passo in una rete DLSw è far crescere i peer. Senza i "pari", non c'è scambio di dati. La maggior parte dei dettagli relativi a ciò che accade tra peer DLSw è spiegata nella RFC 1795.

Nota: se si parla con apparecchiature non Cisco tramite DLSw, utilizzare DLSw. Tuttavia, tra i router Cisco, utilizzare DLSw+.

Questo output viene generato dal rilascio di peer dlsw di debug e dalla visualizzazione dei peer tra due router Cisco:

DLSw: passive open 5.5.5.1(11010) -> 2065
DLSw: action_b(): opening write pipe for peer 5.5.5.1(2065)
DLSw: peer 5.5.5.1(2065), old state DISCONN, new state CAP_EXG
DLSw: CapExId Msg sent to peer 5.5.5.1(2065)
DLSw: Recv CapExId Msg from peer 5.5.5.1(2065)
DLSw: Pos CapExResp sent to peer 5.5.5.1(2065)
DLSw: action_e(): for peer 5.5.5.1(2065)
DLSw: Recv CapExPosRsp Msg from peer 5.5.5.1(2065)
DLSw: action_e(): for peer 5.5.5.1(2065)
shSw: peer 5.5.5.1(2065), old state CAP_EXG, new state CONNECT
DLSw: peer_act_on_capabilities() for peer 5.5.5.1(2065)
DLSw: action_f(): for peer 5.5.5.1(2065)
DLSw: closing read pipe tcp connection for peer 5.5.5.1(2065)

In questo output il router avvia il peer e apre una sessione TCP con l'altro router. Poi inizia a scambiare capacità. Dopo uno scambio positivo di funzionalità, il peer è connesso. A differenza di RSRB, DLSw non sposta il peer in uno stato chiuso quando non è presente alcuna attività, ad esempio il traffico. Rimangono sempre connessi. Se i peer sono disconnessi, eseguire il debug dlsw peer per determinare il motivo per cui non sono in grado di aprirli.

Quando viene avviata la risoluzione dei problemi di una sessione, eseguire il comando debug dlsw core per osservare l'errore della sessione e verificare se il circuito è attivo.

Questo è il flusso per un controller di comunicazione 3174 all'host tramite DLSw+:

L'output del comando debug dlsw visualizza il flusso della sessione visualizzata correttamente:

ibu-7206#debug dlsw
DLSw reachability debugging is on at event level for all protocol traffic
DLSw peer debugging is on
DLSw local circuit debugging is on
DLSw core message debugging is on
DLSw core state debugging is on
DLSw core flow control debugging is on
DLSw core xid debugging is on
ibu-7206#
DLSW Received-ctlQ : CLSI Msg : UDATA_STN.Ind   dlen: 208
CSM: Received CLSI Msg : UDATA_STN.Ind   dlen: 208 from TokenRing3/0
CSM:   smac 8800.5a49.1e38, dmac c000.0000.0080, ssap F0, dsap F0
CSM: Received frame type NETBIOS DATAGRAM from 0800.5a49.1e38, To3/0
DLSw: peer_put_bcast() to non-grouped peer 5.5.5.1(2065)
DLSw: Keepalive Request sent to peer 5.5.5.1(2065))
DLSw: Keepalive Response from peer 5.5.5.1(2065)
DLSW Received-ctlQ : CLSI Msg : TEST_STN.Ind   dlen: 41
CSM: Received CLSI Msg : TEST_STN.Ind   dlen: 41 from TokenRing3/0
CSM:   smac c001.68ff.0001, dmac 4000.0000.0001, ssap 4 , dsap 0

Si noti il frame di prova proveniente dalla LAN (localmente) dalla stazione c001.68ff.0001 all'indirizzo MAC 4000.0000.0001. Ciascun frame .Ind indica che un pacchetto proviene dalla LAN. Quando il router invia un pacchetto alla LAN, viene visualizzato un .RSP.

DLSw: peer_put_bcast() to non-grouped peer 5.5.5.1(2065)
%DLSWC-3-RECVSSP: SSP OP = 4( ICR  ) -explorer from peer 5.5.5.1(2065)
DISP Sent : CLSI Msg : TEST_STN.Rsp   dlen: 44

Ora è possibile visualizzare la trasmissione inviata al peer remoto e la risposta ICR (Frequenza cellulare iniziale). Ciò significa che il router remoto ha identificato la stazione come raggiungibile. TEST_STN.Rsp è il router che invia una risposta di test alla stazione.

DLSW Received-ctlQ : CLSI Msg : ID_STN.Ind   dlen: 54
CSM: Received CLSI Msg : ID_STN.Ind   dlen: 54 from TokenRing3/0
CSM:   smac c001.68ff.0001, dmac 4000.0000.0001, ssap 4 , dsap 4

Dopo aver ricevuto la risposta al test, la stazione invia il primo XID. Potete notare questa condizione con IS_STN.Ind. A questo punto, il router deve mantenere temporaneamente il frame finché non cancella un paio di dettagli tra i due router DLSw.

DLSw: new_ckt_from_clsi(): TokenRing3/0 4001.68ff.0001:4->4000.0000.0001:4
DLSw: START-FSM (1622182940): event:DLC-Id state:DISCONNECTED
DLSw: core: dlsw_action_a()
DISP Sent : CLSI Msg : REQ_OPNSTN.Req   dlen: 108
DLSw: END-FSM (1622182940): state:DISCONNECTED->LOCAL_RESOLVE
 
DLSW Received-ctlQ : CLSI Msg : REQ_OPNSTN.Cfm CLS_OK dlen: 108
DLSw: START-FSM (1622182940): event:DLC-ReqOpnStn.Cnf state:LOCAL_RESOLVE
DLSw: core: dlsw_action_b()
CORE: Setting lf size to 30
%DLSWC-3-SENDSSP: SSP OP = 3(CUR)  to peer 5.5.5.1(2065) success
DLSw: END-FSM (1622182940): state:LOCAL_RESOLVE->CKT_START
 
%DLSWC-3-RECVSSP: SSP OP = 4(ICR)  from peer 5.5.5.1(2065)
DLSw: 1622182940 recv FCI 0 - s:0 so:0 r:0 ro:0
DLSw: recv RWO
DLSw: START-FSM (1622182940): event:WAN-ICR state:CKT_START
DLSw: core: dlsw_action_e()
DLSw: sent RWO
DLSw: 1622182940 sent FCI 80 on  ACK   - s:20 so:1 r:20 ro:1
%DLSWC-3-SENDSSP: SSP OP = 5(ACK)  to peer 5.5.5.1(2065) success
DLSw: END-FSM (1622182940): state:CKT_START->CKT_ESTABLISHED

In questa schermata è possibile notare il flusso interno di DLSw tra i due peer. Questi pacchetti sono normali all'avvio di ciascuna sessione. La prima fase consiste nel passare da uno stato disconnesso a uno stato CKT_DEFINED. Entrambi i router trasmettono un frame CUR per il circuito stesso. Questa operazione è denominata configurazione del circuito di portata (CURCS). Quando il peer che avvia il frame CURCS riceve un frame ICRCS, invia un messaggio di conferma e passa a uno stato di circuito definito. Ora entrambi i router DLSw sono pronti per l'elaborazione XID.

DLSw: START-FSM (1622182940): event:DLC-Id state:CKT_ESTABLISHED
DLSw: core: dlsw_action_f()
DLSw: 1622182940 sent FCA on  XID
%DLSWC-3-SENDSSP: SSP OP = 7(XID)  to peer 5.5.5.1(2065) success
DLSw: END-FSM (1622182940): state:CKT_ESTABLISHED->CKT_ESTABLISHED

Il router ha ricevuto un XID dopo aver inviato la risposta al test alla stazione. Questo XID viene salvato per un momento e poi trasmesso al peer attraverso il circuito. Ciò significa che si stanno inviando pacchetti a/da un peer con l'ID circuito contrassegnato. In questo modo, DLSw comprende l'attività tra le due stazioni. Tenere presente che DLSw termina la sessione LLC2 (Logical Link Control, tipo 2) su ciascun lato del cloud.

%DLSWC-3-RECVSSP: SSP OP = 7(XID)  from peer 5.5.5.1(2065)
DLSw: 1622182940 recv FCA on  XID   - s:20 so:0 r:20 ro:0
DLSw: START-FSM (1622182940): event:WAN-XID state:CKT_ESTABLISHED
DLSw: core: dlsw_action_g()
DISP Sent : CLSI Msg : ID.Rsp   dlen: 12
DLSw: END-FSM (1622182940): state:CKT_ESTABLISHED->CKT_ESTABLISHED
 
DLSW Received-ctlQ : CLSI Msg : ID.Ind   dlen: 39
DLSw: START-FSM (1622182940): event:DLC-Id state:CKT_ESTABLISHED
DLSw: core: dlsw_action_f()
%DLSWC-3-SENDSSP: SSP OP = 7(XID)  to peer 5.5.5.1(2065) success
DLSw: END-FSM (1622182940): state:CKT_ESTABLISHED->CKT_ESTABLISHED

Si nota innanzitutto una risposta al primo XID inviato in precedenza. In ID.Rsp, si vede che l'XID è stato inviato alla stazione, alla quale la stazione ha risposto con un ID.Ind. Questo è un altro XID inviato al peer DLSw.

%DLSWC-3-RECVSSP: SSP OP = 8(CONQ)  from peer 5.5.5.1(2065)
DLSw: START-FSM (1622182940): event:WAN-CONQ state:CKT_ESTABLISHED

Questa parte ci mostra che la stazione dall'altra parte ha risposto con una SABME (CONQ) alla XID. La negoziazione XID è stata terminata e il router è pronto per avviare la sessione.

DLSw: core: dlsw_action_i()
DISP Sent : CLSI Msg : CONNECT.Req   dlen: 16

Successivamente, il router invia il messaggio SABME alla stazione in CONNECT.Req.

DLSw: END-FSM (1622182940): state:CKT_ESTABLISHED->CONTACT_PENDING
 
DLSW Received-ctlQ : CLSI Msg : CONNECT.Cfm CLS_OK dlen: 8
DLSw: START-FSM (1622182940): event:DLC-Connect.Cnf state:CONTACT_PENDING
DLSw: core: dlsw_action_j()
%DLSWC-3-SENDSSP: SSP OP = 9( CONR )  to peer 5.5.5.1(2065) success
DISP Sent : CLSI Msg : FLOW.Req   dlen: 0
DLSw: END-FSM (1622182940): state:CONTACT_PENDING->CONNECTED

Quindi si riceve il messaggio di conferma senza numero (UA) dalla stazione, come mostrato nel messaggio CONNECT.Cfm. che viene inviato al peer remoto tramite CONR. Il processo relativo alla velocità (RR) viene quindi avviato con FLOW.Req.

%DLSWC-3-RECVSSP: SSP OP = 10(INFO)  from peer 5.5.5.1(2065)
DLSw: 1622182940 decr r - s:20 so:0 r:19 ro:0
DLSw: START-FSM (1622182940): event:WAN-INFO state:CONNECTED
DLSw: core: dlsw_action_m()
DISP Sent : CLSI Msg : DATA.Req   dlen: 34
DLSw: END-FSM (1622182940): state:CONNECTED->CONNECTED
 
DLSw: 1622182940 decr s - s:19 so:0 r:19 ro:0
DLSW Received-disp : CLSI Msg : DATA.Ind   dlen: 35
DLSw: sent RWO
DLSw: 1622182940 sent FCI 80 on  INFO  - s:19 so:0 r:39 ro:1
%DLSWC-3-SENDSSP: SSP OP = 10(INFO)  to peer 5.5.5.1(2065) success
%DLSWC-3-RECVSSP: SSP OP = 10(INFO)  from peer 5.5.5.1(2065)
DLSw: 1622182940 decr r - s:19 so:0 r:38 ro:1
DLSw: 1622182940 recv FCA on  INFO  - s:19 so:0 r:38 ro:0
DLSw: 1622182940 recv FCI 0 - s:19 so:0 r:38 ro:0
DLSw: recv RWO
DLSw: START-FSM (1622182940): event:WAN-INFO state:CONNECTED
DLSw: core: dlsw_action_m()
DISP Sent : CLSI Msg : DATA.Req   dlen: 28
DLSw: END-FSM (1622182940): state:CONNECTED->CONNECTED

Il comando DATA.Req indica che il router ha trasmesso un I-frame. Data.Ind indica che il router ha ricevuto un I-frame. È possibile utilizzare queste informazioni per determinare il flusso di pacchetti tra i router DLSw.

DLSW Received-ctlQ : CLSI Msg : DISCONNECT.Ind   dlen: 8
DLSw: START-FSM (1622182940): event:DLC-Disc.Ind state:CONNECTED

Questa parte contiene il file DISCONNECT.Ind. Il valore .Ind indica che il pacchetto proviene dalla LAN. In questo caso, la stazione invia un messaggio DISCONNECT, che indica al router di avviare la disconnessione del circuito.

DLSw: core: dlsw_action_n()
%DLSWC-3-SENDSSP: SSP OP = 14( HLTQ )  to peer 5.5.5.1(2065) success
DLSw: END-FSM (1622182940): state:CONNECTED->DISC_PENDING
 
%DLSWC-3-RECVSSP: SSP OP = 15( HLTR )  from peer 5.5.5.1(2065)
DLSw: START-FSM (1622182940): event:WAN-HLTR state:DISC_PENDING

Dopo aver ricevuto il comando DISCONNECT, il router invia un messaggio HALT al peer remoto e attende la risposta. Non resta che inviare un UA alla stazione e chiudere il circuito, come mostrato nel seguente debug con DISCONNECT.Rsp:

DLSw: core: dlsw_action_q()
DISP Sent : CLSI Msg : DISCONNECT.Rsp   dlen: 4
DISP Sent : CLSI Msg : CLOSE_STN.Req   dlen: 4
DLSw: END-FSM (1622182940): state:DISC_PENDING->CLOSE_PEND
 
DLSW Received-ctlQ : CLSI Msg : CLOSE_STN.Cfm CLS_OK dlen: 8
DLSw: START-FSM (1622182940): event:DLC-CloseStn.Cnf state:CLOSE_PEND
DLSw: core: dlsw_action_y()
DLSw: 1622182940 to dead queue
DLSw: END-FSM (1622182940): state:CLOSE_PEND->DISCONNECTED

L'ultima cosa che DLSw fa è mettere il circuito nella coda dei morti. Da lì, i puntatori sono ripuliti e pronti per un nuovo circuito.

Sessioni NetBIOS

DLSw gestisce le sessioni NetBIOS in modo diverso, ma i debug sono molto simili.

Nota: tenere presente che gli XID non vengono trasmessi alle stazioni NetBIOS e che i router DLSw scambiano i frame SSP (Query System Switch Processor) del nome NetBIOS e il nome NetBIOS riconosciuto. Questa è la differenza principale.

Informazioni correlate

• Risoluzione dei problemi DLSw
• IBM Technologies
• Documentazione e supporto tecnico – Cisco Systems