Información y solución de problemas de conexiones en puente con traducción de ruteo de origen
Contenido
Introducción
Este documento describe el puente de traducción de ruta de origen (SR/TLB) y proporciona información para solucionar problemas.
Prerequisites
Requirements
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.
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.
Convenciones
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Puente ruteo de origen con traducción
Es común que los entornos Ethernet se combinen con los entornos Token Ring en las redes actuales. Esta combinación conlleva una serie de problemas lógicos. La primera es que Ethernet no tiene nada cercano al puente de ruta de origen y Token Ring tiene un campo de información de routing (RIF). Además, los Token Rings tienen direcciones funcionales, mientras que los EtherNet generalmente tienen broadcasts.
Para poder unir los dos entornos, Cisco creó SR/TLB.
Puede agregar grupos de puentes a las interfaces de los routers (tanto Token Ring como Ethernet), para establecer un puente transparente entre Token Ring y Ethernet. Esto crea un dominio de puente transparente entre los dos entornos. Si el lado Token Ring está ejecutando el bridging de ruta de origen, habría un problema. ¿Cómo vincula el puente transparente con el ruteo de origen, especialmente dado que las estaciones finales son las que establecen el trayecto a través de la red?
Este diagrama ilustra la solución:
Cuando pc_1 desea comunicarse con pc_3, envía una consulta de nombre NetBIOS con un paquete de difusión (FF-FF-FF-FF-FF-FF-FF) al cable. El problema es que la estación pc_3 escucha consultas_nombre con una dirección de destino de (C0-00-00-00-00-80), y recibe esa difusión y no la envía a NetBIOS porque no es una consulta_nombre (por definición de pc_3).
Esta es la razón por la que la traducción de Token Ring a Ethernet puede ser complicada. La mayoría de los detalles se manejan dentro del router, y un problema que crea cierta confusión es el intercambio de bits. Token Ring y Ethernet leen los bits en el adaptador de diferentes maneras. El router no entra en la trama y cambia el orden de bits, por lo que las direcciones MAC en la Ethernet son diferentes de las direcciones MAC en el Token Ring.
La estación Ethernet no puede actuar como la estación final de ruteo de origen, por lo que el router de Cisco asume esa función. Según el diagrama anterior, estos eventos ocurren después de que el router recibe el paquete de la Ethernet:
-
El router cisco1 recibe un paquete de la Ethernet. Esto es de pc_1 a host_1.
-
cisco1 necesita un RIF para alcanzar host_1, por lo que crea un explorador para determinar la trayectoria para alcanzar host_1.
-
Después de que cisco1 reciba la respuesta, envía la respuesta (sin un RIF) a la estación Ethernet.
-
pc_1 envía una identificación de intercambio (XID) a la dirección MAC del host.
-
cisco1 obtiene el paquete Ethernet, conecta el RIF al host y envía el paquete en su camino.
-
Este proceso continúa.
Varias condiciones hacen posible este proceso. En primer lugar, en lo que se refiere al host, Ethernet está sentado en lo que se conoce como un 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 |
|---|---|
| ring-group | El grupo en anillo virtual creado por el comando source-bridge ring-group. Este es el anillo virtual de source-bridge que se asociará con el grupo de bridges transparente. Este número de grupo en anillo debe coincidir con el número especificado con el comando source-bridge ring-group. El rango válido es de 1 a 4095. |
| seudoanillo | El número de anillo que se utiliza para representar el dominio de puente transparente al dominio puenteado de ruta de origen. Este número debe ser un número único que no sea utilizado por ningún otro anillo en la red puenteada de ruta de origen. |
| bridge-number | El número de bridge del bridge que lleva al dominio de bridging transparente, desde un punto de vista Token Ring ruteado de origen. |
| tb-group | El número del grupo de puentes transparentes que desea vincular al dominio puenteado de ruta de origen. La forma no de este comando inhabilita esta función. |
| oui | (Opcional) El identificador único de la organización (OUI), que puede tener valores que incluyen:
|
Cuando configura SR/TLB, primero debe tener un grupo de anillos en el router. El pseudo anillo hace que parezca que Ethernet es Token Ring, desde el punto de vista host_1.
Configure cisco1 de esta manera:
| 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 de Cisco IOS® Software Release 11.2, SR/TLB se conmuta rápidamente. Antes de la versión 11.2 del software del IOS de Cisco, SR/TLB se conmutó por proceso. Para desactivar fast switching, ejecute este comando:
no source-bridge transparent ring-group fastswitch
Comandos show
Hay dos comandos show importantes con SR/TLB.
-
show bridge - Este comando es muy útil para analizar el lado transparente. Muestra si el router está recibiendo paquetes de un dispositivo específico en la red.
-
show rif - Este comando muestra si el router ha construido un RIF para la dirección MAC de destino.
Resolución de problemas
En estas secciones se explica cómo resolver problemas de intercambio de bits de direcciones MAC y bucles SR/TLB.
Intercambio de bits
Una de las causas más comunes de problemas con SR/TLB es el intercambio de bits de direcciones MAC. El problema ocurre porque el router realiza un intercambio de bits en las direcciones MAC de Ethernet a Token Ring y de Token Ring a Ethernet. El resultado es que las estaciones finales no pueden reconocer esas tramas. Este diagrama muestra un ejemplo:
En este diagrama, la trama tiene exactamente el mismo patrón de bits en el MAC de origen (SMAC) y en el MAC de destino (DMAC). Sin embargo, este patrón de bits se lee de manera diferente en Token Ring que en Ethernet. Para poder enviar tramas dirigidas a través de esta red, debe intercambiarlas con bits antes de enviarlas.
Lo primero que hay que hacer es convertir la dirección MAC original en binaria. Puede utilizar los tres conjuntos de 2 bytes de forma individual para facilitarlo. 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
Invertir cada byte. No invierta toda la cadena. Este es el número binario separado en bytes:
01000000 00000000 00110111 01000101 00000000 00000001 40 00 37 45 00 01
Para realizar el intercambio de bits, mueva el primer bit al último en cada uno de los bytes y repita esto hasta que el último bit sea el primero:
00000010 00000000 11101100 10100010 00000000 10000000 02 00 EC A2 00 80
Después de que se realice el intercambio de bits, tendrá la nueva dirección MAC, que es 0200.ECA2.0080.
El software para muchas estaciones Ethernet de arquitectura de red de sistemas (SNA) realiza el intercambio automáticamente. Si no sabe con certeza, es mejor probarlo de ambas maneras.
Nota: A veces las redes incluyen direcciones MAC "no intercambiables por bits" para dispositivos ampliamente usados, porque las direcciones son las mismas intercambiadas o no. Esto significa que no necesita tratar la codificación de la dirección FEP remota. Esto es común en entornos de procesador frontal (FEP) con muchos sitios remotos. Por ejemplo, 4200.0000.4242 es una dirección MAC no intercambiable por bits.
Además, el router mismo - en la parte del puente transparente - trata las direcciones MAC como formato Ethernet, y la parte del código ruteada de origen las trata como formato Token Ring. En escenarios como FDDI, donde las tramas se leen exactamente igual, el código del router muestra todas las direcciones MAC invertidas.
Soporte DHCP/BOOTP entre anillo Token y Ethernet
DHCP/BOOTP no se admite cuando se utiliza SR/TLB o Transparent Bridging (TB) y el servidor y el cliente se encuentran en diferentes LAN de tipo de medio (canónicas o no canónicas). Por ejemplo, si el cliente está en una LAN Token Ring y el servidor en una LAN Ethernet. Esto se debe a que el cliente incluye su dirección MAC en el paquete de solicitud BOOTP (campo chaddr).
Por ejemplo, cuando un cliente con dirección MAC 4000.1111.0000 envía una solicitud BOOTP y el paquete pasa a través del puente SR/TLB o TB, las direcciones MAC en el encabezado MAC se intercambian por bits, pero las direcciones MAC incrustadas en la solicitud BOOTP se dejan sin cambios. En consecuencia, el paquete BOOTP llega al servidor y el servidor responde con una respuesta BOOTP. Esta respuesta BOOTP se envía a la dirección de broadcast o a la dirección MAC del cliente, según el indicador de broadcast. En el caso de que este indicador de broadcast no esté configurado, el servidor envía un paquete de unidifusión a la dirección MAC especificada en el campo chaddr. El servidor en el lado Ethernet envía la respuesta a la dirección MAC 4000.1111.0000. El paquete pasa a través del puente y el bridge bitswap la dirección MAC. Por lo tanto, la respuesta BOOTP en el lado Token Ring termina con una dirección MAC de destino de 0200.888.0000. En consecuencia, el cliente no reconocerá esta trama.
Loops
Otra causa de los problemas de SR/TLB es que no puede permitir que el router utilice diferentes trayectos a la misma Ethernet.
Este diagrama contiene un semi-bucle:
Debido a que el paquete se origina del mismo pseudo-anillo y está en el mismo grupo de anillo, los paquetes que vienen del entorno Token Ring se envían a Ethernet. Esto hace que el segundo router SR/TLB crea que una dirección MAC determinada se encuentra en su Ethernet local. Por lo tanto, una estación en el Ethernet no puede alcanzar esa estación de nuevo.
Además, cisco1 tomará el mismo paquete y enviará un explorador a la red, lo que puede hacer que esa estación aparezca como si estuviera en Ethernet (cuando está en el entorno Token Ring).
Este diagrama ilustra un escenario común:
En este caso, sólo se necesita un paquete para crear un loop enorme. Debido a que el paquete no será descartado ni por el lado Ethernet ni por el lado Token Ring, el paquete irá interminablemente en un patrón de loop.
Depuración
La depuración para SR/TLB es muy limitada. Una opción es depurar el Token Ring, con filtros, para ver si los paquetes lo están haciendo a través del router. Refiérase a Comprensión y Troubleshooting del Bridging de Ruta de Origen Local para obtener más información.
Comentarios