Este documento explica cómo resolver problemas de una configuración de switching de link de datos (DLSw).
No hay requisitos específicos para este documento.
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.
Si los peers no se conectan, verifique si existe conectividad IP entre los dos routers. Si es así, verifique si tiene las sentencias de peer DLSw adecuadas en el router local y remoto. Consulte Configuraciones básicas de DLSw+ y Resolución de Problemas de Conectividad IP de DLSw para obtener más información. Si no existen sentencias remotas, utilice la palabra clave promiscuo en la instrucción peer local en un extremo. Consulte Comandos de Configuración de DLSw+ para obtener más información.
Esta sección aborda algunos problemas comunes y proporciona consejos sobre cómo resolver problemas.
Recuerde que la terminación del campo de información de routing (RIF) es un aspecto importante de DLSw. RIF causa problemas importantes a través de la fácil creación de loops en la red.
A continuación se muestra una topología de ejemplo que rastrea la creación de un loop.
DLSw finaliza el RIF y el paquete da vueltas sin fin. Cada vez que se envía una trama CANUREACH (CUR) de igual a igual, el par receptor crea un nuevo explorador (NO RIF) y la envía.
Esta es la ruta de un explorador:
El 3174 en el anillo 11 envía un explorador para alcanzar el host.
Tanto San Francisco 1 (SF1) como el puente copian la trama.
SF1 crea una trama CUR en Los Ángeles 1 (LA1), que es el par, que indica a LA1 que el 3174 desea alcanzar el host.
San Francisco 2 (SF2) recibe el paquete y repite la acción.
LA1 y Los Ángeles 2 (LA2) crean el explorador y lo envían al anillo.
La1 y LA2 reciben cada uno un explorador (el que creó el otro).
Ahora surge un problema. Cada lado determina que el 3174 está conectado localmente, y cada router ve el 3174 tanto local como remotamente.
Cada lado envía una trama CUR a SF1 y SF2, y crea un explorador para el host desde el 3174.
Ambos routers (SF1 y SF2) copian la trama de nuevo y ven que el host es local y remoto. DLSw ahora se rompe y entra en un loop.
Lo mejor que puede hacer en esta situación es asegurarse de que los anillos virtuales de los routers sean exactamente los mismos en cada lado de la nube:
Los routers de cada lado de la nube se configuran con el mismo número de anillo virtual. Esta configuración asegura que un router que envía un explorador ya haya pasado a través del anillo y, por lo tanto, el router descarta el explorador. Cuando LA1 genera un explorador para una trama CUR que SF1 recibe, LA2 descarta el explorador porque el explorador ya pasó por el anillo 1. Los routers deben tener diferentes números de puente configurados, si se dirigen al mismo anillo. Este es el caso en el lado LA de esta red. Con Ethernet, debe inhabilitar un par:
Un paquete en la Ethernet no tiene un RIF en sí mismo. Por lo tanto, cuando el otro router en la LAN crea una difusión, el router no puede determinar si la transmisión es del otro router o de una estación de origen. En el caso de la arquitectura de red de sistemas (SNA), el router no puede determinar si el paquete se origina de forma local o remota. Los exploradores del Token Ring tienen direcciones MAC de origen y de destino. Por lo tanto, estos exploradores no son realmente una difusión en Ethernet. Más bien, se envían como una trama dirigida de una estación a otra.
Tenga en cuenta esta secuencia:
El 3174 envía un explorador al host.
Tanto SF1 como SF2 aceptan el explorador.
SF1 y SF2 generan cada uno un CUR hacia el otro lado, LA1 y LA2.
Estos CUR generan un explorador al que responde el host. Dado que se trata de un único explorador de rutas, el explorador de todas las rutas responde.
Tanto LA1 como LA2 crean una trama CUR para SF1 y SF2, que crea este paquete para el 3174.
El problema es que SF1 escucha la dirección MAC del host desde Ethernet y determina que el host reside en su propia LAN local. Pero, en la memoria caché SF1, el host parece responder desde un peer remoto. Por lo tanto, el router tiene el host definido como local y remoto.
DLSw ahora se rompe y entra en un loop.
Para corregir DLSw, debe inhabilitar un par o utilizar la función de redundancia Ethernet. Consulte Ejemplo de Configuración de Redundancia Ethernet DLSw para obtener más información.