Présentation et dépannage du pontage SR/TLB Contenu Introduction Conditions préalables Conditions requises Composants utilisés Conventions Pontage SR/TLB Commandes show Dépannage Bitswapping Support DHCP/BOOTP entre l'anneau à jeton et les Ethernets Boucles Débogage Informations connexes Introduction Ce document décrit le Pontage SR/TLB et fournit des informations pour les dépanner. Conditions préalables Conditions requises Aucune spécification déterminée n'est requise pour ce document. Composants utilisés Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques. Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande. Conventions Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco. Pontage SR/TLB Il est commun pour que les environnements d'ethernets se mélangent aux environnements Token Ring dans les réseaux d'aujourd'hui. Ce mélange apporte un certain nombre de problèmes logiques. Le premier est que l'ethernet n'a rien près du par la source pont, et l'anneau à jeton a un champ des informations de routage (RIF). En outre, les Anneaux à jeton ont des adresses fonctionnelles, alors que les Ethernet ont le plus souvent des émissions. Pour pouvoir unir les deux environnements, Cisco a créé SR/TLB. Vous pouvez ajouter des groupes de passerelle aux interfaces des Routeurs (Anneau à jeton et Ethernets), pour jeter un pont sur d'une manière transparente l'anneau à jeton et les Ethernets. Ceci crée un domaine transparent de passerelle entre les deux environnements. Si le côté d'anneau à jeton est par la source courant pont, il y aurait un problème. Comment attachez-vous le Pontage transparent avec le source-routage, particulièrement étant donné que les stations d'extrémité sont celles qui établissent le chemin par le réseau? Ce diagramme montre la solution :
Quand pc_1 veut communiquer avec pc_3, il envoie le name_query de Netbios avec un paquet de l'émission (FF-FF-FF-FF-FF-FF) au fil. Le problème est que la station pc_3 écoute des name_queries avec une adresse de destination de (C0-00-00-00-00-80), et il reçoit cette émission et ne l'envoie pas à Netbios parce que ce n'est pas un name_query (par définition pc_3). C'est pourquoi la traduction de l'anneau à jeton aux Ethernets peut être compliquée. La plupart des détails sont manipulées à l'intérieur du routeur, et une question qui crée une certaine confusion bitswapping. L'Anneau à jeton et les Ethernets ont indiqué les bits dans l'adaptateur dans différentes manières. Le routeur n'entre pas dans la trame et change la commande de bit, ainsi les adresses MAC sur les Ethernets sont différentes des adresses MAC sur l'anneau à jeton. La station Ethernet ne peut pas agir en tant que station d'extrémité source-conduite, donc le routeur de Cisco assume ce rôle. Basé sur le diagramme précédent, ces événements se produisent après que le routeur reçoive le paquet des Ethernets : 1. 2. 3. 4. 5. 6. Le routeur cisco1 reçoit un paquet des Ethernets. C'est de pc_1 à host_1. cisco1 a besoin d'un RIF pour atteindre host_1, ainsi il crée un explorateur pour déterminer le chemin à atteindre host_1. Après que cisco1 reçoive la réponse, il envoie la réponse (sans RIF) à la station Ethernet. pc_1 envoie une identification d'échange (XID) à l'adresse MAC d'hôte. cisco1 obtient le paquet Ethernet, relie le RIF à l'hôte, et envoie le paquet sur son chemin. Ce processus continue. Plusieurs conditions rendent ce processus possible. D'abord, en ce qui concerne l'hôte, l'ethernet se repose dans ce qui est connu comme pseudo anneau. Ceci est configuré avec la commande de source-bridge transparent sur le routeur : source-bridge transparent ring-group pseudo-ring bridge-number tb-group [oui] Paramètre groupe d'anneau pseudo anneau numéro de pont TB-groupe oui Description Le groupe d'anneau virtuel qui est créé par l'ordre de source-bridge ring-group. C'est la sonnerie virtuelle de source-bridge à s'associer avec le groupe transparent de passerelle. Ce nombre de groupe d'anneau doit apparier le nombre qui est spécifié avec l'ordre de source-bridge ring-group. La plage valide est de 1 à 4095. Le ring number qui est utilisé pour représenter le domaine de Pontage transparent au domaine de pont avec routage par la source. Ce nombre doit être un numéro unique qui n'est utilisé par aucun autre anneau dans le réseau de pont avec routage par la source. Le numéro de pont de la passerelle que cela mène au domaine de Pontage transparent, d'un point de vue source-conduit par Anneau à jeton. Le nombre du groupe transparent de passerelle que vous voulez a attaché dans le domaine de pont avec routage par la source. Le forme no de cette commande désactive cette configuration. (Facultatif) l'identifiant unique d'organisation (OUI), qui peut avoir des valeurs qui incluent ces derniers : 90-compatible standard Cisco Quand vous configurez SR/TLB, vous devez d'abord avoir un groupe d'anneau dans le routeur. Le pseudo anneau le fait être évident que l'ethernet est Anneau à jeton, du point de vue host_1.
Configurez cisco1 de cette manière : source-bridge ring-group 10 cisco1 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 En date de la version de logiciel 11.2 de ï ½de Cisco IOS, SR/TLB est à commutation rapide. Plus tôt que le Logiciel Cisco IOS version 11.2, SR/TLB était commuté par processus. Pour arrêter la commutation rapide, émettez cette commande : no source-bridge transparent ring-group fastswitch Commandes show Il y a deux commandes show qui sont importantes avec SR/TLB. show bridge - Cette commande est très utile pour analyser le côté transparent. Il affiche si le routeur reçoit des paquets d'un appareil spécifique dans le réseau. show rif - Cette commande montre si le routeur a construit un RIF pour l'adresse MAC de destination. Dépannage Ceci sectionne discutent comment dépanner bitswapping d'adresse MAC et boucles SR/TLB. Bitswapping Une des la plupart des causes classiques des problèmes avec SR/TLB est adresse MAC bitswapping. Le problème se pose parce que le routeur fait un bitswap sur des adresses MAC des Ethernets à l'anneau à jeton et d'anneau à jeton aux Ethernets. Le résultat est que les stations d'extrémité ne peuvent pas identifier ces trames. Ce diagramme affiche un exemple : Dans ce diagramme, la trame a le précis la même séquence de bits dans le MAC de source (SMAC) et le MAC de destination (DMAC). Cette
séquence de bits est lue différemment dans l'anneau à jeton que dans les Ethernets, cependant. Pour pouvoir envoyer a dirigé des trames à travers ce réseau, vous doit bitswap elles avant qu'elles soient envoyées. La première chose à faire est de convertir l'adresse MAC d'origine à la binaire. Vous pouvez employer les trois positionnements 2-byte individuellement pour le faciliter. 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 Inversez chaque octet. N'inversez pas la chaîne entière. C'est le nombre binaire séparé dans des octets : 01000000 00000000 00110111 01000101 00000000 00000001 40 00 37 45 00 01 Pour faire le bitswap, déplacez le premier bit au bout sur chacun des octets, et répétez ceci jusqu'à ce que le dernier bit soit premier : 00000010 00000000 11101100 10100010 00000000 10000000 02 00 EC A2 00 80 Après que bitswapping soit fait, vous avez la nouvelle adresse MAC, qui est 0200.ECA2.0080. Le logiciel pour beaucoup de stations Ethernet du Systems Network Architecture (SNA) fait l'échange automatiquement. Si vous ne savez pas à coup sûr, il est le meilleur de le tester de deux manières. Remarque: Parfois les réseaux incluent les adresses MAC «non-bitswappable» pour les périphériques très utilisés, parce que les adresses sont identiques permutées ou non-troquées. Ceci signifie que vous n'avez pas besoin de traiter le codage de l'adresse du distant FEP. C'est commun dans des environnements du processeur frontal (FEP) avec beaucoup de sites distants. Par exemple, 4200.0000.4242 est une adresse MAC nonbitswappable. En outre, le routeur lui-même - dans la partie pont transparente - traite les adresses MAC comme format Ethernet, et la partie source-conduite du code les traite comme format d'anneau à jeton. Dans les scénarios comme le FDDI, où les trames sont lues exactement les mêmes, le code de routeur affiche les adresses MAC tout inversées. Support DHCP/BOOTP entre l'anneau à jeton et les Ethernets DHCP/BOOTP n'est pas pris en charge quand vous utilisez SR/TLB ou Pontage transparent (TB) et le serveur et le client sont dans des réseaux locaux de type de supports différents (canonique ou non-canonique). Par exemple, si le client est dans un RÉSEAU LOCAL d'anneau à jeton et le serveur dans un LAN Ethernet. C'est parce que le client inclut son adresse MAC dans le paquet de demande BOOTP (champ de chaddr). Par exemple, quand un client avec l'adresse MAC 4000.1111.0000 envoie une demande BOOTP et le paquet passe par la passerelle SR/TLB ou TB, les adresses MAC dans l'en-tête MAC bitswapped, mais les adresses MAC incluses dans la demande BOOTP sont laissées inchangées. En conséquence, le paquet BOOTP arrive au serveur, et les réponses de serveur avec un Protocole BOOTP répondent. Cette réponse de Protocole BOOTP est envoyée à l'adresse d'émission ou à l'adresse MAC du client, selon l'indicateur d'émission. Au cas où cet indicateur d'émission ne serait pas placé, le serveur envoie un paquet monodiffusion à l'adresse MAC qui est spécifiée dans le domaine de chaddr. Le serveur du côté Ethernet envoie la réponse à l'adresse MAC 4000.1111.0000. Le paquet passe par la passerelle et les bitswaps de passerelle l'adresse MAC. Ainsi, la réponse de Protocole BOOTP du côté d'anneau à jeton finit par avec une adresse MAC de destination de 0200.8888.0000. En conséquence, le client n'identifiera pas cette trame. Boucles Une autre cause des problèmes SR/TLB est que vous ne pouvez pas permettre au routeur pour utiliser des différents chemins aux mêmes Ethernets. Ce diagramme contient une semi-boucle :
Puisque le paquet provient du même pseudo anneau et est au même groupe d'anneau, des paquets qui proviennent l'environnement Token Ring sont envoyés aux Ethernets. Ceci fait croire le deuxième routeur SR/TLB qu'une certaine adresse MAC se trouve sur ses Ethernets locaux. Ainsi, une station sur les Ethernets ne peut pas atteindre cette station de nouveau. En outre, cisco1 prendra ce même paquet et enverra un explorateur au réseau, qui peut faire cette station être évident comme si il est sur les Ethernets (quand il est dans l'environnement Token Ring). Ce diagramme montre un scénario commun : Dans ce cas, il prend seulement un paquet pour créer une boucle énorme. Puisque le paquet ne sera pas lâché par le côté Ethernet ou le côté d'anneau à jeton, le paquet entrera sans fin dans un modèle fait une boucle. Débogage L'élimination des imperfections pour SR/TLB est très limitée. Une option est de mettre au point l'anneau à jeton, avec des filtres, pour voir si les paquets le font par le routeur. Référez-vous en comprenant et dépannage du par la source local pont le pour en savoir plus. Informations connexes Notes techniques de dépannage 1992-2010 Cisco Systems Inc. Tous droits réservés. Date du fichier PDF généré: 15 décembre 2015 http://www.cisco.com/cisco/web/support/ca/fr/109/1092/1092770_48.html