Tecnologías IBM : Source-Route Translational Bridging (SR/TLB)

Información y solución de problemas de conexiones en puente con traducción de ruteo de origen

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento describe el Source-Route Translational Bridging (SR/TLB) y proporciona la información para resolverla problemas.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Puente ruteo de origen con traducción

Es común para que los entornos Ethernet se mezclen con los entornos Token Ring en las redes de hoy. Esta mezcla trae varios problemas lógicos. El primer es que el Ethernet no tiene cualquier cosa cerca del Source-Route Bridging, y el Token Ring tiene un (RIF) del campo routing information. También, los Token Ring tienen las direcciones funcionales, mientras que el Ethernets tiene lo más a menudo posible broadcasts.

Para poder unir los dos entornos, Cisco creó el SR/TLB.

Usted puede agregar a los Grupos de Bridge a las interfaces del Routers (Token Ring y los Ethernetes), transparente para interligar el Token Ring y los Ethernetes. Esto crea un dominio del Bridge transparente entre los dos entornos. Si costado del Token Ring es el Source-Route Bridging corriente, habría un problema. ¿Cómo usted ata Puente transparente con el Source Routing, dado especialmente que las estaciones terminales son las que establecen la trayectoria a través de la red?

Este diagrama ilustra la solución:

/image/gif/paws/12248/48a.gif

Cuando pc_1 quiere comunicar con pc_3, envía el name_query del NetBios con un paquete del broadcast (FF-FF-FF-FF-FF-FF) al alambre. El problema es que la estación pc_3 está escuchando los name_queries con una dirección destino de (C0-00-00-00-00-80), y recibe que lo transmite y no envía al NetBios porque no es un name_query (por la definición pc_3).

Esta es la razón por la cual la traducción del Token Ring a los Ethernetes puede ser complicada. La mayor parte de los detalles se manejan dentro del router, y un problema que crea una cierta confusión es bitswapping. El Token Ring y los Ethernetes leyeron los bits en el adaptador en las maneras diferentes. El router no entra la trama y cambia la orden del bit, así que las direcciones MAC en los Ethernetes son diferentes de las direcciones MAC en el Token Ring.

La estación Ethernet no puede actuar como el Source-Routed End-Station, por lo tanto el router Cisco asume ese papel. De acuerdo con el diagrama anterior, estos eventos ocurren después de que el router reciba el paquete de los Ethernetes:

  1. El router cisco1 recibe un paquete de los Ethernetes. Esto es de pc_1 al host_1.

  2. cisco1 necesita un RIF alcanzar el host_1, así que crea a un explorador para determinar la trayectoria para alcanzar el host_1.

  3. Después de que cisco1 reciba la respuesta, envía la respuesta (sin un RIF) a la estación Ethernet.

  4. pc_1 envía un Identificación de intercambio (XID) a la dirección MAC del host.

  5. cisco1 consigue el paquete Ethernet, asocia el RIF al host, y envía el paquete en su manera.

  6. Este proceso continúa.

Varias condiciones hacen este proceso posible. Primero, por lo que el host, el Ethernet se está sentando en qué se conoce como seudo anillo. Esto se configura con el comando source-bridge transparent en el router:

source-bridge transparent ring-group pseudo-ring bridge-number tb-group [oui]
Parámetro Descripción
timbre-grupo El grupo en anillo virtual que es creado por el comando source-bridge ring-group. Éste es el Source-Bridge Virtual Ring a asociarse al grupo de Bridge transparente. Este número de grupo en anillo debe hacer juego el número que se especifica con el comando source-bridge ring-group. El intervalo válido es 1 a 4095.
seudo anillo El número de anillo que se utiliza para representar el Transparent Bridging Domain al dominio interligado por Source-Route. Este número debe ser un número único que no es utilizado por ningún otro timbre en la red interligada por Source-Route.
bridge-number El número de Bridge del Bridge que eso lleva al Transparent Bridging Domain, desde un punto de vista Source Routed del Token Ring.
TB-grupo El número del grupo de Bridge transparente que usted quiere ató en el dominio interligado por Source-Route. La ninguna forma de este comando inhabilita esta característica.
oui (Opcional) el Identificador organizacional único (OUI), que puede tener valores que incluyan éstos:
  • 90-compatible
  • estándar
  • Cisco

Cuando usted está configurando el SR/TLB, usted debe primero tener un grupo en anillo en el router. El seudo anillo hace que aparece que el Ethernet es Token Ring, del punto de vista del host_1.

/image/gif/paws/12248/48b.gif

Configuración cisco1 de este modo:

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 partir del Software Release 11.2 del½ del¿Â del Cisco IOSïÂ, el SR/TLB es Fast-Switched. Anterior que el Cisco IOS Software Release 11.2, el SR/TLB era process-switched. Para apagar el Fast-Switching, publique este comando:

no source-bridge transparent ring-group fastswitch

Comandos show

Hay dos comandos show que son importantes con el SR/TLB.

  • Bridge de la demostración - Este comando es muy útil para analizar al lado transparente. Muestra si el router está recibiendo los paquetes de un dispositivo específico en la red.

  • rif de la demostración - Este comando muestra si el router ha construido un RIF para la dirección MAC del destino.

Resolución de problemas

Esto secciona discute cómo resolver problemas el bitswapping de la dirección MAC y los loopes SR/TLB.

Intercambio de bits

Una de la mayoría de las causas comunes de los problemas con el SR/TLB es bitswapping de la dirección MAC. El problema ocurre porque el router hace un bitswap en las direcciones MAC de los Ethernetes al Token Ring y del Token Ring a los Ethernetes. El resultado es que las estaciones terminales no pueden reconocer esas tramas. Este diagrama muestra un ejemplo:

/image/gif/paws/12248/48c.gif

En este diagrama, la trama tiene el exacto el mismo patrón de bits en MAC de origen (SMAC) y el MAC de destino (DMAC). Leen a este patrón de bits diferentemente en el Token Ring que en los Ethernetes, sin embargo. Para poder enviar dirigió las tramas a través de esta red, usted debe bitswap ellas antes de que se envíen.

La primera cosa a hacer es convertir la dirección MAC original al binario. Usted puede utilizar los tres conjuntos 2-byte individualmente para hacerla más fácil. Este ejemplo utiliza 4000.3745.0001.

4000.3745.0001 tiene este valor binario:

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

Invierta cada byte. No invierta la cadena entera. Éste es el número binario separado en los bytes:

01000000  00000000  00110111  01000101  00000000  00000001
   40        00        37        45        00        01

Para hacer el bitswap, mueva el primer bit al último en cada uno de los bytes, y relance esto hasta que el bit más reciente sea primer:

00000010  00000000  11101100  10100010  00000000  10000000 
   02        00        EC        A2        00        80

Después de que se haga el bitswapping, usted tiene la nueva dirección MAC, que es 0200.ECA2.0080.

El software para muchas estaciones Ethernet de la Arquitectura de red de sistemas (SNA) hace el intercambio automáticamente. Si usted no sabe con seguridad, es el mejor probarlo ambas maneras.

Nota: Las redes incluyen a veces las direcciones MAC “NON-bitswappable” para los dispositivos ampliamente utilizados, porque los direccionamientos son lo mismo intercambiados o NON-intercambiados. Esto significa que usted no necesita ocuparse de la codificación del direccionamiento del telecontrol FEP. Esto es común en los entornos del Procesador frontal (FEP) con muchos sitios remotos. Por ejemplo, 4200.0000.4242 es un MAC Address sin intercambio de bits.

Además, el router sí mismo - en la parte de Bridge transparente - trata las direcciones MAC como formato Ethernet, y a la parte de Source Routed que el código las trata como formato del Token Ring. En los escenarios como el FDDI, donde las tramas se leen exactamente lo mismo, el código del router muestra las direcciones MAC invertidas todo.

Compatibilidad DHCP/BOOTP entre Token Ring y Ethernet

El DHCP/BOOTP no se soporta cuando usted está utilizando el SR/TLB o el transparent bridging (TB) y el servidor y el cliente están en diverso tipo de media LAN (canónico o no canónico). Por ejemplo, si el cliente está en un Token Ring LANE y el servidor en un LAN Ethernet. Esto es porque el cliente incluye su dirección MAC en el paquete de pedido de BOOTP (campo del chaddr).

Por ejemplo, cuando un cliente con la dirección MAC 4000.1111.0000 envía un pedido de BOOTP y el paquete pasa a través del Bridge SR/TLB o TB, las direcciones MAC en el encabezado MAC son bitswapped, pero las direcciones MAC integradas en el pedido de BOOTP se dejan sin cambios. Por lo tanto, el paquete BOOTP consigue al servidor, y el servidor contesta con a Respuesta de BOOTP. Esto Respuesta de BOOTP se envía a la dirección de broadcast o a la dirección MAC del cliente, dependiendo del indicador de broadcast. En caso que este indicador de broadcast no se fije, el servidor envía un paquete de unidifusión a la dirección MAC que se especifica en el campo del chaddr. El servidor en el lado Ethernet envía la contestación a la dirección MAC 4000.1111.0000. El paquete pasa a través del Bridge y de los bitswaps del Bridge la dirección MAC. Así, Respuesta de BOOTP encendido costado del Token Ring termina para arriba con una dirección MAC del destino de 0200.8888.0000. Por lo tanto, el cliente no reconocerá esta trama.

Loops

Otra causa de los problemas SR/TLB es que usted no puede permitir que el router utilice diversas trayectorias a los mismos Ethernetes.

Este diagrama contiene un semi-loop:

48d.gif

Porque el paquete origina del mismo seudo anillo y está en el mismo grupo en anillo, los paquetes que están viniendo del entorno Token Ring se envían a los Ethernetes. Esto hace al segundo router SR/TLB creer que cierta dirección MAC está situada en sus Ethernetes locales. Así pues, una estación en los Ethernetes no puede alcanzar esa estación otra vez.

También, cisco1 tomará ese mismo paquete y enviará a un explorador a la red, que puede hacer que aparece esa estación como si esté en los Ethernetes (cuando está en el entorno Token Ring).

Este diagrama ilustra un escenario frecuente:

48e.gif

En este caso, toma solamente un paquete para crear un loop enorme. Porque el paquete no será caído por o el lado Ethernet o costado del Token Ring, el paquete entrará sin fin en un modelo colocado.

Depuración

El debugging para el SR/TLB es muy limitado. Una opción es hacer el debug del Token Ring, con los filtros, para considerar si los paquetes lo están haciendo a través del router. Refiera a entender y a resolver problemas el Local Source-Route Bridging para más información.


Información Relacionada


Document ID: 12248