Comprensione e risoluzione dei problemi di bridging di conversione origine-route
Sommario
Introduzione
Questo documento descrive Source-Route Translational Bridging (SR/TLB) e fornisce informazioni per la risoluzione dei problemi.
Prerequisiti
Requisiti
Nessun requisito specifico previsto per questo documento.
Componenti usati
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.
Convenzioni
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Bridging di conversione origine-route
Gli ambienti Ethernet vengono in genere utilizzati in combinazione con gli ambienti Token Ring nelle reti attuali. Questo mix porta una serie di problemi logici. La prima è che Ethernet non ha niente di simile al bridging origine-route e Token Ring ha un campo di informazioni di routing (RIF). Inoltre, i Token Ring hanno indirizzi funzionali, mentre le Ethernet molto spesso hanno broadcast.
Per unire i due ambienti, Cisco ha creato SR/TLB.
È possibile aggiungere gruppi di bridge alle interfacce dei router (sia Token Ring che Ethernet), per creare in modo trasparente un bridge Token Ring e Ethernet. In questo modo viene creato un dominio bridge trasparente tra i due ambienti. Se sul lato Token Ring è in esecuzione il bridging del percorso di origine, è presente un problema. Come è possibile collegare il bridging trasparente al routing di origine, in particolare considerando che sono le stazioni terminali a stabilire il percorso attraverso la rete?
Questo diagramma illustra la soluzione:
Quando il pc_1 desidera comunicare con il pc_3, invia una query nome NetBIOS con un pacchetto broadcast (FF-FF-FF-FF) al cavo. Il problema è che la stazione pc_3 è in ascolto di name_queries con indirizzo di destinazione (C0-00-00-00-00-80) e riceve la trasmissione e non la invia a NetBIOS perché non è una name_query (secondo la definizione di pc_3).
Ecco perché la conversione da Token Ring a Ethernet può essere complicata. La maggior parte dei dettagli viene gestita all'interno del router, e un problema che crea confusione è il bitswap. Token Ring ed Ethernet leggono i bit nell'adattatore in modi diversi. Il router non entra nel frame e cambia l'ordine dei bit, quindi gli indirizzi MAC sull'interfaccia Ethernet sono diversi dagli indirizzi MAC sul Token Ring.
Poiché la stazione Ethernet non può funzionare come stazione terminale con routing di origine, il router Cisco svolge questo ruolo. In base al diagramma precedente, questi eventi si verificano dopo che il router riceve il pacchetto da Ethernet:
-
Il router cisco1 riceve un pacchetto dall'interfaccia Ethernet. Questa operazione viene eseguita da pc_1 a host_1.
-
cisco1 ha bisogno di un RIF per raggiungere host_1, quindi crea un elenco di cartelle per determinare il percorso per raggiungere host_1.
-
Dopo aver ricevuto la risposta, cisco1 invia la risposta (senza un RIF) alla stazione Ethernet.
-
pc_1 invia un identificativo di scambio (XID) all'indirizzo MAC dell'host.
-
cisco1 riceve il pacchetto Ethernet, collega il RIF all'host e invia il pacchetto durante il trasferimento.
-
Questo processo continua.
Diverse condizioni rendono possibile questo processo. In primo luogo, per quanto riguarda l'host, Ethernet è posizionata in quello che è noto come pseudo-anello. Questa condizione viene configurata con il comando source-bridge transparent sul router:
source-bridge transparent ring-group pseudo-ring bridge-number tb-group [oui]
| Parametro | Descrizione |
|---|---|
| gruppo ad anello | Gruppo ad anello virtuale creato dal comando source-bridge ring-group. Anello virtuale del bridge di origine da associare al gruppo di bridge trasparente. Questo numero di gruppo ad anello deve corrispondere al numero specificato con il comando source-bridge ring-group. L'intervallo valido è compreso tra 1 e 4095. |
| pseudo-anello | Numero circolare utilizzato per rappresentare il dominio con bridging trasparente al dominio con bridging della route di origine. Questo numero deve essere univoco e non deve essere utilizzato da nessun altro anello della rete con bridging source-route. |
| numero-ponte | Numero di bridge che conduce al dominio di bridging trasparente, da un punto di vista con routing di origine Token Ring. |
| tb-group | Numero del gruppo di bridge trasparente che si desidera collegare al dominio con bridging della route di origine. La forma no di questo comando disabilita questa funzione. |
| oui | (Facoltativo) L'identificatore univoco dell'organizzazione (OUI), che può avere valori che includono:
|
Quando si configura SR/TLB, è necessario disporre prima di un gruppo ad anello nel router. Lo pseudo-anello visualizza la rete Ethernet come Token Ring, dal punto di vista host_1.
Configurare cisco1 nel modo seguente:
| cisco1 |
|---|
source-bridge ring-group 10 source-bridge transparent 10 11 1 1 ! interface tokenring 0 source-bridge 1 1 10 source-bridge spanning ! interface Ethernet 0 bridge-group 1 ! bridge 1 protocol ieee |
A partire dal software Cisco IOS® versione 11.2, SR/TLB è a commutazione rapida. Nelle versioni precedenti al software Cisco IOS versione 11.2, SR/TLB era a commutazione di contesto. Per disattivare l'opzione di commutazione veloce, usare questo comando:
no source-bridge transparent ring-group fastswitch
Comandi show
Due comandi show sono importanti per SR/TLB.
-
show bridge - Questo comando è molto utile per analizzare il lato trasparente. Indica se il router riceve pacchetti da un dispositivo specifico nella rete.
-
show rif - Questo comando mostra se il router ha generato un RIF per l'indirizzo MAC di destinazione.
Risoluzione dei problemi
In queste sezioni viene descritto come risolvere i problemi relativi allo swapping degli indirizzi MAC e ai loop SR/TLB.
Bitswapping
Una delle cause più comuni dei problemi con SR/TLB è lo scambio di bit degli indirizzi MAC. Il problema si verifica perché il router esegue uno scambio di bit sugli indirizzi MAC da Ethernet a Token Ring e da Token Ring a Ethernet. Di conseguenza, le stazioni terminali non sono in grado di riconoscere questi frame. Il diagramma mostra un esempio:
In questo diagramma, il fotogramma ha lo stesso identico schema di bit nell'indirizzo MAC di origine (SMAC) e nell'indirizzo MAC di destinazione (DMAC). Tuttavia, questo modello di bit viene letto in modo diverso in Token Ring rispetto a Ethernet. Per inviare i frame indirizzati attraverso questa rete, è necessario sostituirli con un bit prima dell'invio.
Per prima cosa, convertire l'indirizzo MAC originale in formato binario. Per semplificare l'operazione, è possibile utilizzare singolarmente i tre set da 2 byte. In questo esempio viene utilizzato 4000.3745.0001.
4000.3745.0001 ha questo valore binario:
0100 0000 0000 0000 0011 0111 0100 0101 0000 0000 0000 0001
Invertire ogni byte. Non invertire l'intera stringa. Numero binario separato in byte:
01000000 00000000 00110111 01000101 00000000 00000001 40 00 37 45 00 01
Per eseguire lo scambio di bit, spostare il primo bit sull'ultimo in ognuno dei byte e ripetere l'operazione fino al primo bit dell'ultimo bit:
00000010 00000000 11101100 10100010 00000000 10000000 02 00 EC A2 00 80
Al termine dell'operazione di bitswapping, si ottiene il nuovo indirizzo MAC, ovvero 0200.ECA2.0080.
Il software per molte stazioni Ethernet SNA (Systems Network Architecture) esegue lo scambio automaticamente. Se non si è sicuri, è meglio testarlo in entrambi i modi.
Nota: a volte le reti includono indirizzi MAC "non bitswappable" per i dispositivi più diffusi, perché gli indirizzi sono gli stessi scambiati o non scambiati. Ciò significa che non è necessario gestire la codifica dell'indirizzo FEP remoto. Ciò è comune negli ambienti con processori front-end (FEP) con molti siti remoti. Ad esempio, 4200.0000.4242 è un indirizzo MAC non bitswappable.
Inoltre, il router stesso, nella parte trasparente del bridge, tratta gli indirizzi MAC come formato Ethernet e la parte del codice con routing all'origine li tratta come formato Token Ring. In scenari come FDDI, dove i frame vengono letti esattamente nello stesso modo, il codice del router mostra gli indirizzi MAC tutti invertiti.
Supporto DHCP/BOOTP tra Token Ring ed Ethernet
DHCP/BOOTP non è supportato quando si utilizza SR/TLB o il Bridging trasparente (TB) e il server e il client si trovano in LAN di tipo diverso (canonico o non canonico). Ad esempio, se il client si trova in una LAN Token Ring e il server in una LAN Ethernet. Infatti, il client include il proprio indirizzo MAC nel pacchetto di richiesta BOOTP (campo chaddr).
Ad esempio, quando un client con indirizzo MAC 4000.1111.0000 invia una richiesta BOOTP e il pacchetto passa attraverso il bridge SR/TLB o TB, gli indirizzi MAC nell'intestazione MAC vengono scambiati in bit, ma gli indirizzi MAC incorporati nella richiesta BOOTP rimangono invariati. Di conseguenza, il pacchetto BOOTP raggiunge il server e quest'ultimo risponde con una risposta BOOTP. Questa risposta BOOTP viene inviata all'indirizzo di broadcast o all'indirizzo MAC del client, a seconda del flag di broadcast. Se questo flag di trasmissione non è impostato, il server invia un pacchetto unicast all'indirizzo MAC specificato nel campo chaddr. Il server sul lato Ethernet invia la risposta all'indirizzo MAC 4000.111.0000. Il pacchetto passa attraverso il bridge e il bridge scambia l'indirizzo MAC. Pertanto, la risposta BOOTP sul lato Token Ring termina con un indirizzo MAC di destinazione di 0200.888.0000. Di conseguenza, il client non riconoscerà questo frame.
Loop
Un'altra causa dei problemi SR/TLB è che non è possibile consentire al router di utilizzare percorsi diversi della stessa rete Ethernet.
Questo diagramma contiene un semilavoro:
Poiché il pacchetto proviene dallo stesso pseudo-ring e si trova nello stesso gruppo ring, i pacchetti provenienti dall'ambiente Token Ring vengono inviati alla rete Ethernet. In questo modo, il secondo router SR/TLB riterrà che un determinato indirizzo MAC si trovi sulla propria rete Ethernet locale. Quindi, una stazione su Ethernet non può più raggiungere quella stazione.
Inoltre, cisco1 prenderà lo stesso pacchetto e invierà un elenco di cartelle alla rete, in modo che la stazione possa apparire come se fosse su Ethernet (quando si trova nell'ambiente Token Ring).
Questo diagramma illustra uno scenario comune:
In questo caso, è sufficiente un solo pacchetto per creare un loop enorme. Poiché il pacchetto non verrà scartato né dal lato Ethernet né dal lato Token Ring, il pacchetto andrà all'infinito in modalità a ciclo continuo.
Debug
Il debug per SR/TLB è molto limitato. Un'opzione è quella di eseguire il debug del Token Ring, con i filtri, per vedere se i pacchetti passano attraverso il router. per ulteriori informazioni, fare riferimento a Descrizione e risoluzione dei problemi di Bridging percorso origine locale.
Feedback