Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Conventions

Pontage de traduction de route source

Commandes show

Dépannage

Bitswap

Support DHCP/BOOTP entre Token Ring et Ethernet

Boucles

Débogage

Informations connexes

Introduction

Ce document décrit le pontage source-route translational (SR/TLB) et fournit des informations pour le dépanner.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Pontage de traduction de route source

Il est courant que les environnements Ethernet se mélangent aux environnements Token Ring dans les réseaux actuels. Ce mélange soulève un certain nombre de problèmes logiques. La première est qu’Ethernet n’a rien de proche du pontage de route source et que Token Ring a un champ d’informations de routage (RIF). En outre, les Token Rings ont des adresses fonctionnelles, tandis que les réseaux Ethernet ont le plus souvent des diffusions.

Pour pouvoir unifier les deux environnements, Cisco a créé SR/TLB.

Vous pouvez ajouter des groupes de pontage aux interfaces des routeurs (Token Ring et Ethernet), pour relier de manière transparente Token Ring et Ethernet. Cela crée un domaine de pont transparent entre les deux environnements. Si le côté Token Ring exécute le pontage de route source, il y aurait un problème. Comment lier le pontage transparent au routage par la source, d'autant plus que les stations d'extrémité sont celles qui établissent le chemin à travers le réseau ?

Ce schéma illustre la solution :

Quand pc_1 veut communiquer avec pc_3, il envoie une requête de nom NetBIOS avec un paquet de diffusion (FF-FF-FF-FF-FF-FF) au câble. Le problème est que la station pc_3 écoute les requêtes name_query avec une adresse de destination de (C0-00-00-00-00-80), et elle reçoit cette diffusion et ne l'envoie pas à NetBIOS car il ne s'agit pas d'une requête name (selon la définition de pc_3).

C’est pourquoi la traduction de Token Ring vers Ethernet peut être compliquée. La plupart des détails sont traités à l’intérieur du routeur, et un problème qui crée une certaine confusion est l’échange de bits. Token Ring et Ethernet lisent les bits dans la carte de différentes manières. Le routeur n’entre pas dans la trame et ne modifie pas l’ordre des bits. Les adresses MAC sur Ethernet sont donc différentes des adresses MAC sur la Token Ring.

La station Ethernet n’est pas en mesure d’agir en tant que station d’extrémité routée par la source. C’est pourquoi le routeur Cisco assume ce rôle. D’après le schéma précédent, ces événements se produisent après que le routeur a reçu le paquet d’Ethernet :

1. Le routeur cisco1 reçoit un paquet d’Ethernet. Ceci provient de pc_1 vers host_1.

2. cisco1 a besoin d’un RIF pour atteindre l’hôte 1. il crée donc un explorateur pour déterminer le chemin d’accès à l’hôte 1.

3. Après réception de la réponse, cisco1 envoie la réponse (sans RIF) à la station Ethernet.

4. pc_1 envoie une identification d'échange (XID) à l'adresse MAC hôte.

5. cisco1 obtient le paquet Ethernet, relie le RIF à l’hôte et envoie le paquet sur son chemin.

6. Ce processus se poursuit.

Plusieurs conditions rendent ce processus possible. Tout d’abord, en ce qui concerne l’hôte, l’Ethernet est installé dans ce qu’on appelle un pseudo-anneau. Ceci est configuré avec la commande source-bridge transparent sur le routeur :

source-bridge transparent ring-group pseudo-ring bridge-number tb-group [oui]

Paramètre

Description

ring-group

Groupe d'anneau virtuel créé par la commande source-bridge ring-group. Il s'agit de l'anneau virtuel du pont source à associer au groupe de ponts transparents. Ce numéro de groupe de sonneries doit correspondre au numéro spécifié avec la commande source-bridge ring-group. La plage valide est comprise entre 1 et 4 095.

pseudo-anneau

Numéro de sonnerie utilisé pour représenter le domaine de pontage transparent au domaine de pontage de route source. Ce numéro doit être un numéro unique qui n'est utilisé par aucun autre anneau dans le réseau ponté de la route source.

numéro de pont

Numéro de pont du pont qui mène au domaine de pontage transparent, d'un point de vue de la source routée par Token Ring.

tb-group

Numéro du groupe de ponts transparents que vous voulez lier au domaine ponté de la route source. La forme no de cette commande désactive cette fonctionnalité.

oui

(Facultatif) L'identifiant unique d'organisation (OUI), qui peut avoir des valeurs comprenant les suivantes :

- Compatible 90

- standard

- cisco

Lorsque vous configurez SR/TLB, vous devez d'abord avoir un groupe de sonneries dans le routeur. Le pseudo-anneau fait apparaître que l’Ethernet est Token Ring, du point de vue de l’hôte 1.

Configurez cisco1 de la manière suivante :

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

Depuis la version 11.2 du logiciel Cisco IOS®, SR/TLB est à commutation rapide. Avant la version 11.2 du logiciel Cisco IOS, SR/TLB était commuté par processus. Pour désactiver la commutation rapide, exécutez la commande suivante :

no source-bridge transparent ring-group fastswitch

Commandes show

Deux commandes show sont importantes avec SR/TLB.

- show bridge - Cette commande est très utile pour analyser le côté transparent. Elle indique si le routeur reçoit des paquets d'un périphérique spécifique du réseau.

- show rif - Cette commande indique si le routeur a créé un RIF pour l'adresse MAC de destination.

Dépannage

Cette section explique comment dépanner le bitswap d'adresse MAC et les boucles SR/TLB.

Bitswap

L’une des causes les plus courantes des problèmes liés à SR/TLB est l’échange d’adresses MAC. Le problème se produit parce que le routeur effectue un échange de bits sur les adresses MAC d’Ethernet à Token Ring et de Token Ring à Ethernet. En conséquence, les stations d’extrémité ne sont pas en mesure de reconnaître ces trames. Ce schéma présente un exemple :

Dans ce schéma, la trame a exactement le même modèle de bit dans l’adresse MAC source (SMAC) et l’adresse MAC de destination (DMAC). Cependant, ce modèle de bit est lu différemment dans Token Ring et dans Ethernet. Pour pouvoir envoyer des trames dirigées sur ce réseau, vous devez les échanger en bits avant de les envoyer.

La première chose à faire est de convertir l'adresse MAC d'origine en adresse binaire. Vous pouvez utiliser les trois ensembles de deux octets individuellement pour le rendre plus facile. Cet exemple utilise 4000.3745.0001.

4000.3745.0001 a cette valeur binaire :

0100 0000 0000 0000 0011 0111 0100 0101 0000 0000 0000 0001

Inverser chaque octet. Ne pas inverser la chaîne entière. Il s'agit du nombre binaire divisé en octets :

01000000  00000000  00110111  01000101  00000000  00000001

40        00        37        45        00        01

Pour effectuer l’échange de bits, déplacez le premier bit vers le dernier bit de chacun des octets, puis répétez cette opération jusqu’à ce que le dernier bit soit premier :

00000010  00000000  11101100  10100010  00000000  10000000

02        00        EC        A2        00        80

Une fois le transfert de bits terminé, vous avez la nouvelle adresse MAC, qui est 0200.ECA2.0080.

Le logiciel de nombreuses stations Ethernet SNA (Systems Network Architecture) effectue l'échange automatiquement. Si vous ne savez pas avec certitude, il est préférable de tester les deux façons.

Remarque : Parfois, les réseaux incluent des adresses MAC « non remplaçables par bits » pour les périphériques largement utilisés, car les adresses sont les mêmes échangées ou non. Cela signifie que vous n'avez pas besoin de gérer le codage de l'adresse FEP distante. Cela est courant dans les environnements de processeurs frontaux (FEP) avec de nombreux sites distants. Par exemple, 4200.000.4242 est une adresse MAC non remplaçable par bits.

En outre, le routeur lui-même, dans la partie pont transparent, traite les adresses MAC comme un format Ethernet et la partie routée par la source du code les traite comme un format Token Ring. Dans des scénarios tels que FDDI, où les trames sont lues exactement de la même manière, le code du routeur affiche les adresses MAC toutes inversées.

Support DHCP/BOOTP entre Token Ring et Ethernet

DHCP/BOOTP n'est pas pris en charge lorsque vous utilisez SR/TLB ou Transparent Bridging (To) et que le serveur et le client se trouvent dans des réseaux locaux de différents types de support (canoniques ou non canoniques). Par exemple, si le client se trouve dans un réseau local Token Ring et le serveur dans un réseau local Ethernet. Ceci est dû au fait que le client inclut son adresse MAC dans le paquet de requête BOOTP (champ chaddr).

Par exemple, lorsqu’un client avec l’adresse MAC 4000.111.0000 envoie une requête BOOTP et que le paquet passe par le pont SR/TLB ou TB, les adresses MAC de l’en-tête MAC sont échangées en bits, mais les adresses MAC incorporées dans la requête BOOTP restent inchangées. Par conséquent, le paquet BOOTP parvient au serveur et celui-ci répond par une réponse BOOTP. Cette réponse BOOTP est envoyée à l'adresse de diffusion ou à l'adresse MAC du client, selon l'indicateur de diffusion. Si cet indicateur de diffusion n'est pas défini, le serveur envoie un paquet de monodiffusion à l'adresse MAC spécifiée dans le champ chaddr. Le serveur côté Ethernet envoie la réponse à l’adresse MAC 4000.1111.0000. Le paquet passe par le pont et le pont échange en bits l’adresse MAC. Ainsi, la réponse BOOTP du côté Token Ring se termine par l’adresse MAC de destination 0200.8888.0000. Par conséquent, le client ne reconnaîtra pas cette trame.

Boucles

Une autre cause des problèmes de SR/TLB est que vous ne pouvez pas autoriser le routeur à utiliser différents chemins vers le même Ethernet.

Ce diagramme contient une semi-boucle :

Comme le paquet provient du même pseudo-anneau et se trouve dans le même groupe d’anneau, les paquets provenant de l’environnement Token Ring sont envoyés à Ethernet. Cela fait croire au deuxième routeur SR/TLB qu’une certaine adresse MAC se trouve sur son Ethernet local. Ainsi, une station sur Ethernet ne peut plus atteindre cette station.

En outre, cisco1 prend ce même paquet et envoie un explorateur au réseau, ce qui peut faire apparaître cette station comme si elle se trouvait sur Ethernet (lorsqu’elle se trouve dans l’environnement Token Ring).

Ce schéma illustre un scénario commun :

Dans ce cas, il suffit d’un seul paquet pour créer une énorme boucle. Comme le paquet ne sera pas abandonné du côté Ethernet ou du côté Token Ring, le paquet ira sans fin en boucle.

Débogage

Le débogage pour SR/TLB est très limité. Une option consiste à déboguer la Token Ring, avec des filtres, pour voir si les paquets passent par le routeur. Référez-vous à Compréhension et dépannage du pontage source-route local pour plus d'informations.

Informations connexes

- Assistance technique IBM SNA Networking

- Prise en charge de la technologie Token Ring

- Support et documentation techniques - Cisco Systems