In questo documento viene descritto come risolvere i problemi relativi a una configurazione DLSw (Data-Link Switching).
Nessun requisito specifico previsto per questo documento.
Il documento può essere consultato per tutte le versioni software o hardware.
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.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Se i peer non si connettono, verificare che tra i due router sia disponibile la connettività IP. In tal caso, verificare di disporre delle istruzioni peer DLSw appropriate sui router locale e remoto. per ulteriori informazioni, fare riferimento a Configurazioni DLSw+ di base e Risoluzione dei problemi di connettività DLSw IP. Se non esistono istruzioni remote, utilizzare la parola chiave promiscua sull'istruzione peer locale su un lato. per ulteriori informazioni, fare riferimento a Comandi di configurazione DLSw+.
In questa sezione vengono illustrati alcuni problemi comuni e vengono forniti suggerimenti per la risoluzione dei problemi.
Tenere presente che la terminazione RIF (Routing Information Field) è un aspetto importante di DLSw. Il RIF causa problemi importanti facilitando la creazione di loop nella rete.
Di seguito è riportata una topologia di esempio che traccia la creazione di un loop.
DLSw termina il RIF e il pacchetto continua a circolare all'infinito. Ogni volta che un frame CANUREACH (CUR) viene inviato da un peer all'altro, il peer destinatario crea un nuovo explorer (NO RIF) e lo invia.
Questo è il percorso di un elenco di cartelle:
Il 3174 nel ring 11 invia un esploratore per raggiungere l'host.
Sia San Francisco 1 (SF1) che il ponte copiano la cornice.
SF1 crea un frame CUR per Los Angeles 1 (LA1), che è il peer, che indica A1 che il 3174 vuole raggiungere l'host.
San Francisco 2 (SF2) riceve il pacchetto e ripete l'azione.
LA1 e Los Angeles 2 (LA2) creano l'esploratore e lo inviano al ring.
LA1 e LA2 ricevono ciascuna un explorer (l'altro creato).
Ora sorge un problema. Ciascun lato determina che lo switch 3174 è collegato localmente e ciascun router visualizza lo switch 3174 sia localmente che in remoto.
Ciascun lato invia un frame CUR a SF1 e SF2 e crea un explorer per l'host dal 3174.
Entrambi i router (SF1 e SF2) copiano nuovamente il frame e verificano che l'host sia locale e remoto. DLSw si interrompe e si avvia in un loop.
La cosa migliore da fare in questa situazione è assicurarsi che gli anelli virtuali per i router siano esattamente gli stessi su ogni lato del cloud:
I router su ciascun lato del cloud sono configurati con lo stesso numero di anello virtuale. Questa configurazione assicura che un router che invia un elenco di cartelle abbia già attraversato il ring e che, pertanto, il router scarti l'elenco di cartelle. Quando LA1 genera un elenco di cartelle per un frame CUR ricevuto da SF1, LA2 lo scarta, in quanto l'elenco di cartelle è già passato attraverso il ring 1. I router devono avere numeri di bridge diversi configurati, se sono diretti allo stesso ring. Questo è il caso della parte LAN di questa rete. Con Ethernet, è necessario disabilitare un peer:
Un pacchetto su Ethernet non dispone di un RIF. Pertanto, quando l'altro router della LAN crea una trasmissione, il router non può determinare se la trasmissione proviene dall'altro router o da una stazione di origine. Nel caso dell'architettura di rete (SNA), il router non può determinare se il pacchetto ha origine in locale o in remoto. Gli esploratori del Token Ring hanno sia indirizzi MAC di origine che di destinazione. Pertanto, tali esploratori non sono realmente una trasmissione su Ethernet. Piuttosto, vengono inviati come frame diretto da una stazione all'altra.
Considerate questa sequenza:
Lo switch 3174 invia un elenco di cartelle all'host.
Sia SF1 che SF2 accettano l'elenco delle cartelle.
SF1 e SF2 generano ciascuna un CUR sull'altro lato, LA1 e LA2.
Entrambi questi CUR generano un elenco di cartelle al quale l'host risponde. Poiché si tratta di un singolo navigatore di route, un esploratore di tutte le route risponde.
Sia LA1 che LA2 creano un frame CUR per SF1 e SF2, che crea questo pacchetto per 3174.
Il problema è che SF1 sente l'indirizzo MAC dell'host dalla rete Ethernet e determina che l'host risiede sulla propria LAN locale. Tuttavia, nella cache SF1, l'host sembra rispondere da un peer remoto. Pertanto, sul router l'host è definito sia locale che remoto.
DLSw si interrompe e si avvia in un loop.
Per correggere DLSw, è necessario disabilitare un peer o utilizzare la funzionalità di ridondanza Ethernet. Per ulteriori informazioni, fare riferimento all'esempio di configurazione della ridondanza DLSw Ethernet.