Bridging Token Ring e decodifica RIF

Introduzione

Questo documento spiega la decodifica Token Ring Bridging e Routing Information Field (RIF).

I frame Token Ring hanno una struttura simile ai frame 802.3 Ethernet e Fiber Distributed Data Interface (FDDI). Questi frame hanno indirizzi di destinazione e di origine, nonché una sequenza di controllo del frame (FCS) e una sezione per trasportare i dati. Anche i delimitatori iniziale e finale sono comuni.

Frame Token Ring, ma includono anche funzioni extra. Tra queste:

• Campo RIF (Routing Information Field) (facoltativo)

• Controllo dell'accesso (AC)

• Campi Frame Control (FC) e Frame Status (FS)

Inoltre, è possibile utilizzare il primo bit dell'indirizzo di origine per indicare la presenza di un RIF. Tuttavia, quando si studia Source-Route Bridging (SRB), un solo campo è relativo.

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.

Campi delle informazioni di instradamento

Per il supporto di un RIF, il primo bit dell'indirizzo di origine deve essere impostato su 1.

Il RIF è un campo abbastanza complicato. Memorizza la combinazione di numeri ad anello e di numeri di ponte che un frame attraversa tra le stazioni terminali. Il RIF ha anche un campo di controllo a due ottetti che fornisce varie caratteristiche del RIF stesso. Due stazioni che comunicano su una rete SRB o RSRB (Remote Source-Route Bridging) utilizzano sempre lo stesso RIF per la durata della sessione.

La parte ring-to-bridge del RIF tra PC A e PC B nel diagramma precedente è 00AF.00B0.

Revisione della struttura degli indirizzi MAC

Gli indirizzi LAA (Locally Administered Addresses) vengono visualizzati più comunemente sulle stazioni Token Ring, anche se è possibile assegnare i LAA alle stazioni Ethernet e FDDI. Nei LAA, il secondo bit del primo nibble è impostato su 1.

Una delle abilità richieste quando si supportano le reti Token Ring è la capacità di convertire gli schemi di numerazione esadecimale in binari quando necessario. Token Ring fornisce quasi tutte le informazioni in formato esadecimale, ma la struttura sottostante è basata su cifre binarie. La rappresentazione esadecimale in genere maschera parte della struttura sottostante. È necessario essere in grado di convertire la rappresentazione esadecimale in formato binario per interpretare correttamente i campi con cui si lavora.

In questo esempio viene illustrata la conversione.

1. Dividere il numero esadecimale in singole cifre:

   

2. Converte le cifre esadecimali nelle quattro cifre binarie (caratteri nibble) rappresentate da ogni cifra esadecimale:

   

3. Modificare le variabili binarie in ottetti binari:

   

Numerazione esadecimale

Se l'indirizzo precedente è un indirizzo di destinazione, il primo bit potrebbe essere impostato su 1, a indicare che è destinato a un indirizzo di gruppo o funzionale alle stazioni riceventi. Stranamente, il bit locale/universale è impostato su 1 così come il bit dell'indirizzo funzionale/di gruppo. Dal momento che è possibile avere un indirizzo funzionale amministrato localmente per Token Ring e un indirizzo assegnato universalmente, questa sembra una supervisione da parte del comitato IEEE 802.5. Gli indirizzi funzionali e di gruppo esulano dall'ambito di questo documento in quanto non sono direttamente applicabili al bridging di Token Ring. Per ulteriori informazioni, consultare il documento Obiettivi del capitolo Token Ring/IEEE 802.5.

Se l'indirizzo precedente è un indirizzo di origine e il frame Token Ring contiene un RIF, il primo bit è impostato su 1. Se anche questo è un LAA, l'indirizzo inizia con 0xC. Per determinare questa condizione, visualizzare il dump esadecimale del frame.

Ad eccezione di alcune implementazioni specializzate, la WAN in questione non ha alcun effetto sul concetto di RSRB. Nella maggior parte dei casi il traffico viene trasportato su reti IP. Se l'IP può viaggiare tra i router, RSRB funziona correttamente.

La WAN può essere Frame Relay come in questo esempio.

Come in questo esempio, la WAN può essere X.25.

La WAN può essere un anello virtuale, come in questo esempio.

Il tipo di WAN non è rilevante perché il frame Token Ring è collocato in modo sicuro in TCP/IP, o semplicemente in IP, prima di raggiungere l'interfaccia WAN. L'incapsulamento Fast-Sequenced Transport (FST) è supportato su quasi tutti i tipi di LAN o WAN.

Con l'incapsulamento diretto, è necessario verificare che le MTU (Maximum Transmission Units) di tutte le interfacce nel percorso siano in grado di gestire l'intero frame 802.5, in quanto l'incapsulamento diretto non consente la frammentazione. Per ottenere la MTU corretta per tutte le interfacce non Token Ring del percorso, è necessario aggiungere altri 73 byte, ossia l'intestazione Cisco RSRB e un altro sovraccarico Token Ring. I collegamenti seriali richiedono che l'MTU sia 1573 se l'MTU del Token Ring è 1500. Per l'incapsulamento diretto è consentito un solo hop.

Nel diagramma precedente, il PC A non può raggiungere il PC B e il PC B non può raggiungere il PC A, a meno che il router B non abbia peer RSRB (non diretto) con il router A. Il router A ha peer RSRB con il router B. Anche i router A e B possono avere un incapsulamento diretto tra loro. Il router B può essere diretto al router A, ma non al router C. Il router C può essere diretto al router A, ma i router B e C hanno bisogno di peer reali per comunicare.

In questo diagramma è illustrato un altro modo per visualizzare questo aspetto:

Bridging trasparente origine-route

Source-Route Transparent Bridging (SRT) è stato aggiunto alla specifica 802.5. Consente ai frame 802.5 senza RIF di attraversare le interfacce Token Ring configurate per il bridging trasparente. SRT inoltre converte 802.3 in 802.5 per il bridging Token Ring Ethernet. Non risolve il problema del bridging dei protocolli indirizzabili su supporti diversi.

Le stazioni che utilizzano SRT non possono comunicare con le stazioni che eseguono SRB quando si trovano su anelli separati. I due scenari sono fondamentalmente incompatibili. Per comunicare con un PC SRB, è necessario acquistare la soluzione proprietaria Cisco.

Per comunicare con un PC Ethernet, è inoltre necessario disporre della soluzione Cisco.

Nota: nel diagramma precedente:

• 6 è il numero di anello falso utilizzato per il segmento Ethernet.

• 7 è il numero di ponte falso che punta al segmento Ethernet.

• I PC Token Ring presuppongono che i PC Ethernet siano su un Token Ring perché richiedono un RIF valido.

• Il router costituisce la parte falsa del RIF e aggiunge il RIF ai frame destinati ai PC A e B.

• I PC Ethernet non vengono informati che i PC A e B non sono su Ethernet. Il router rimuove i RIF dai frame PC A e PC B.

IEEE ha deciso di utilizzare uno schema di trasmissione dell'ordine di bit per Ethernet diverso da quello di Token Ring. Lo schema per FDDI Ethernet è inizialmente LSB (Least Significant Bit), mentre quello per FDDI e Token Ring sono per primi MSB (Most Significant Bit).

Bridging Source-Route

Questo è uno scenario semplice che illustra SRB:

I PC utilizzano il routing di origine e devono comunicare tra loro in qualche modo. La parola origine nel routing di origine indica questa condizione. Ma, con un bridging trasparente, questo non è un problema, in quanto un bridging trasparente è trasparente per le stazioni terminali. Le stazioni terminali trasmettono semplicemente i frame come se potessero comunicare con qualsiasi stazione. I PC inviano esploratori per aiutarli a raggiungere gli altri.

Esploratori

Considerare il RIF nel frame Token Ring per comprendere il concetto di esploratori. Il RIF è costituito da due sezioni principali:

• byte di controllo (2)

• byte ring-and-bridge (inferiori a 30)

Questa è la suddivisione dei byte di controllo:

• tre bit per il tipo di trasmissione (rappresentato da BBB in questo diagramma)

• cinque bit per la lunghezza dell'intero RIF (LLLL) (2*2*2*2=32 byte disponibili)

• un bit per la direzione (D)

• tre bit per l'MTU della rete Token Ring connessa (FFF)

• gli ultimi quattro bit per IBM (riservato [RRR])

Generalmente è rappresentato come BBLLL.DFFFRRR. Inoltre, BBBLNGTH.DMTURESV è un'altra utile rappresentazione dei byte di controllo.

Tenere presente che IBM funziona in modalità esadecimale e che il percorso origine-route dal PC A al PC B è 00AF.00B0. È necessario convertire l'espressione binaria dei bit di anello e ponte nell'espressione esadecimale utilizzata quando si utilizza SRB. Il percorso in formato binario è 0000000.10101111.0000000.10110000. Suddiviso in caratteri binari, è 0000.0000.1010.1111.0000.000.1011.0000. L'ultimo numero del ponte è sempre 0000, come percorsi terminano su anelli, non ponti. La regola è che tre nibble formano un anello, e uno nibble crea un ponte. Le gamme sono da 1 a 4095 per gli anelli e da 1 a 15 per i ponti.

La parte ad anello e ponte del RIF è già stata discussa. Per ulteriori informazioni, vedere la sezione Campi delle informazioni di instradamento. Se si aggiungono i due byte di controllo al file RIF originale, si otterrà 00AF.00B0. Il file RIF deve avere una lunghezza di almeno due byte in quanto richiede i byte di controllo. Si hanno due anelli, quindi è necessario aggiungere due combinazioni anello-ponte di due byte ciascuna. Il RIF è lungo sei byte. Tenere presente che la struttura binaria dei byte è BXLLL.DFFFXXXX.RRRRRR.RRRBBBB.RRRRRRR.RRRRBBBB.

Prendiamo l'esempio di un navigatore a percorso singolo da PC A a PC B.

Il RIF è C670.00AF.00B0. Il nibble C670 è sempre 0.

Il file RIF dell'elenco di cartelle a percorso singolo viene visualizzato nell'anello B come C610.00AF.00B0, che presuppone una MTU di 1500 e una lettura da sinistra a destra. Il RIF diretto è 0610.00AF.00B0, che presuppone una MTU di 1500 e presuppone che venga letta da sinistra a destra. I bit MTU vengono diminuiti da 111 (0x7) alla MTU massima che ogni ponte può gestire mentre l'esploratore attraversa il ponte nel suo viaggio. Il bridge analizza il valore corrente dei bit MTU e, se il valore è maggiore di quello supportato dal bridge, questo deve diminuire il valore fino alla MTU più grande che può supportare. Per il bridging transazionale su Ethernet, l'MTU massima è 1500.

Quando un bridge a più porte sostituisce il bridge a due porte, sono possibili più RIF:

• Da PC A a PC C: 0610.00AF.00C0

• Da PC A a PC B: 0610.00AF.00B0

• Da PC B a PC C: 0610.00BF.00C0

  Nota: questi tre non sono RIF di explorer. Sono rif dirette con MTU di 1500 e sono lette da sinistra a destra.

• Da PC A a PC B: 0690.00AF.00B0

  Nota: questo è lo stesso RIF descritto nel diagramma precedente, ma con il bit D impostato su 1 in lettura da destra a sinistra.

Quando un router Cisco a più porte sostituisce il bridge a due porte, il router svolge la funzione di anello virtuale per interconnettere gli anelli reali. Aggiunge bridge alle interfacce Token Ring. Nella maggior parte dei casi, tutti i numeri di ponte possono essere 1. L'eccezione sono i ponti paralleli che collegano due anelli. Da PC A a PC C è ora 0810.00A1.00F1.00C0.

Router Cisco con tre interfacce Token Ring

È possibile avere un router con solo due interfacce Token Ring, nel qual caso non è necessario un anello virtuale. È configurato in modo simile a un bridge a due interfacce, ma non è in grado di eseguire RSRB.

Il diagramma mostra un router Cisco con due interfacce Token Ring. Questo router non può eseguire RSRB.

Il RIF è l'aspetto più difficile e fondamentale del Token Ring SRB. Nella parte restante di questo documento vengono illustrati altri modi per raggiungere i frame Token Ring su diverse topologie di rete quando vengono visualizzati come Token Ring nel RIF. A meno che il RIF non sia terminato, la tecnologia per spostare i frame da una stazione all'altra deve in qualche modo mantenere un RIF accurato. DLSw (Data-Link Switching) è l'implementazione principale che termina il RIF. Questo documento si riferisce solo alle implementazioni in cui il RIF viene trasferito da un'estremità all'altra nell'intera rete.

Ecco alcune regole generali da tenere a mente:

• I dispositivi Systems Network Architecture (SNA) tendono a inviare esploratori di tutti i percorsi alla ricerca del dispositivo di destinazione scelto. Questi sono unicast negli indirizzi MAC di destinazione. In genere, i dispositivi di destinazione invertono il bit di direzione (D) e restituiscono il frame come frame diretto, non come explorer. La SNA non ha traffico di broadcast in background. Ad esempio, i Front End Processor (FEP) non inviano frame che trasmettono la loro posizione in modo che possano essere trovati.

• I sistemi NetBIOS (Network Basic Input/Output System) inviano gli elenchi di cartelle a percorso singolo e prevedono che la stazione di destinazione risponda con una risposta dell'elenco di cartelle su tutti i percorsi. NetBIOS esegue anche una grande quantità di trasmissioni in background. I dispositivi inviano costantemente frame che comunicano la propria posizione e altri messaggi importanti. In genere, NetBIOS invia i propri elenchi di cartelle all'indirizzo funzionale NetBIOS per il quale tutte le stazioni NetBIOS sono in ascolto: C000.0000.0080

• La maggior parte degli altri protocolli invia i propri navigatori come trasmissioni MAC, ad esempio FFFF.FFFF.FFFF o C000.FFFF.FFFF.

• È possibile configurare Novell per l'invio di trasmissioni a route singola o a tutte le route. Per le stazioni potrebbe essere necessario route.com. I server potrebbero richiedere route.nlm.

Quando si collegano due anelli con ponti paralleli, i numeri dei ponti devono essere univoci.

Riconoscimento locale

Con la conferma locale (local-ack), il router viene coinvolto in una sessione LLC2 (Logical Link Control) 802.2 che si verifica sul livello di controllo del collegamento dati tra due stazioni terminali. È necessario comprendere alcuni dei principi fondamentali del livello di controllo del collegamento dati 802.2 per comprendere il livello locale. 802.2 è uno standard internazionale IEEE e OSI (Open System Interconnection) per la comunicazione a livello di collegamento dati. Il numero di specifica ISO (International Organization for Standardization) è 8802.2. Sebbene molte persone facciano riferimento al modello a sette livelli OSI durante le discussioni sulle LAN, un modello più appropriato è il modello di riferimento LAN IEEE.

Ad eccezione dei protocolli OSI (Connection Mode Network Service [CMNS] e Connectionless Network Service [CLNS]) e dei protocolli International Telecommunication Unit (ITU), ad esempio X.25, la maggior parte dei protocolli al di sopra del livello di collegamento dati è proprietaria, ad esempio Internetwork Packet Exchange (IPX), AppleTalk e Digital Equipment Corporation Network (DECnet), oppure è standardizzata da un organismo diverso (TCP/IP e Internet Engineering Task Force [IETF]). Né l'IEEE né l'ITU controllano le specifiche della maggior parte dei protocolli utilizzati sulle LAN.

Modello di riferimento LAN IEEE

L'IEEE ha scelto di suddividere il livello di collegamento dati OSI in due livelli. Il layer 802.2 prevede tre tipi di servizio:

1. senza connessione

2. orientato alla connessione

3. senza connessione riconosciuta

Il tipo 3 non viene quasi mai utilizzato. Il tipo 2 è utilizzato da SNA e NetBIOS. I protocolli di routing come IP, IPX e AppleTalk configurati per 802.2 utilizzano il tipo 1.

Formato 802.2

In questa sezione vengono descritte alcune delle aree chiave del livello 802.2.

I Service Access Point (SAP) vengono usati per multiplex e demultiplex dei protocolli di livello superiore attraverso il layer 802.2. Gli SAP sono in genere 04 (SNA), F0 (NetBIOS) e E0 (IPX). Il campo di controllo è costituito da due ottetti in 802.2 e viene utilizzato per l'inizializzazione e la terminazione delle sessioni, il controllo del flusso e la supervisione delle sessioni. Local-ack gestisce principalmente il controllo del flusso e la supervisione della sessione. Si applica solo alle sessioni di tipo 2 orientate alla connessione.

Una sessione orientata alla connessione riconosce i frame ricevuti e indica il numero di frame inviati. Ad esempio, il terzo frame di informazioni destinato a un partner della sessione che non ha ancora inviato un frame I viene inviato come I NR0 NS3. Questo comunica che il frame di informazioni 3 deve essere inviato e che il frame I successivo è previsto come numero di sequenza 0. Se il partner della sessione ha già inviato i frame 0-4, il frame I viene inviato come I NR5 NS3. Questo riconosce che i frame 0-4 sono stati ricevuti e indica al partner che è possibile inviare altri frame. Se, per qualsiasi motivo, un partner della sessione non è in grado di ricevere più frame per un periodo temporaneo, può inviare un frame di supervisione per terminare la sessione (ad esempio, S RNR5). L'NR5 comunica all'altro partner che cosa è stato ricevuto e l'RNR comunica che il ricevitore non è pronto.

I frame di supervisione vengono usati anche quando i timer impostati nelle stazioni terminali scadono prima di ricevere un riconoscimento dei frame IP in sospeso. Le stazioni possono inviare un frame di controllo pronto per la ricezione che richiede che il partner risponda immediatamente. Ad esempio, le stazioni possono inviare S RR NR4 POLL, che presuppone che il frame successivo previsto sia 4. In questa situazione, local-ack è utile.

A volte, il ritardo di propagazione sulla WAN può superare le impostazioni del timer nei sistemi terminali. In questo modo, le stazioni terminali ritrasmettono i frame I, anche se i frame originali vengono consegnati e le conferme vengono restituite. Local-ack invia i frame S RR alla stazione terminale da cui ha origine, mentre il codice RSRB invia il frame all'altro sistema terminale.

La decodifica automatica del RIF può essere eseguita con lo strumento di decodifica RIF.

Informazioni correlate

• Descrizione e risoluzione dei problemi di Local Source-Route Bridging
• RIF PassThru nel supplemento per la formazione DLSw+
• Documentazione e supporto tecnico – Cisco Systems