Data Link Switching Plus

Introducción

La conmutación de enlace de datos (DLSw) es un estándar implementado por IBM que admite el transporte de control de enlace lógico (LLC) a través de WAN. DLSw es una forma más elaborada de conexión en puente de ruta de origen remota (RSRB) y es más específica en cuanto a lo que puede o no puede conectar en puente. DLSw requiere que el router transporte una sesión LLC2 válida o una sesión NetBIOS.

Los routers de Cisco implementan RFC 1795 (estándar DSLw) y 2166 (versión 2 de DLSw). Además, DLSw implementa más funciones para el control de difusión y transporta menos información a través de la WAN que otros métodos.

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.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Comandos generales

En esta sección se tratan los comandos importantes de DLSw, los comandos para configurar DLSw y los comandos para solucionar problemas de DLSw.

source-bridge ring-group

El primer paso en la configuración de DLSw es agregar el comando source-bridge ring-group. Esto conecta las interfaces Token Ring que realizan bridging de ruta de origen (SRB).

Nota: Al realizar DLSw en un router que sólo tiene interfaces Ethernet, no es necesario configurar un grupo en anillo.

Definir la identificación de par local

La siguiente opción es definir la identificación de peer local. Se trata de una dirección IP del mismo cuadro. Básicamente, esto inicia DLSw en el router.

La opción más básica en la configuración de DLSw es establecer la dirección IP de peer-id local. Estas son descripciones de los parámetros del comando:

• group y border: estos comandos se ejecutan juntos para crear pares de borde en la red.

• cost: este comando se ejecuta cuando hay varias trayectorias a la misma ubicación. Este comando indica al router cómo alcanzar estos sitios remotos utilizando primero la trayectoria de menor costo.

• lf: este comando determina el tamaño de trama más grande que este par puede manejar. Los tamaños de trama pueden ser:

  • El tamaño máximo de la trama es 516-516 byte

  • El tamaño máximo de la trama es 1470-1470 byte

  • El tamaño máximo de la trama es 1500-1500 byte

  • tamaño máximo de trama de 2052-2052 bytes

  • El tamaño máximo de la trama es 4472-4472 byte

  • El tamaño máximo de la trama es 8144-8144 byte

  • tamaño máximo de trama de 11407-11407 bytes

  • Tamaño máximo de trama en bytes de 11454-11454

  • El tamaño máximo de la trama es 17800-17800 byte

• keepalive: este comando define el intervalo entre paquetes keepalive. El intervalo puede oscilar entre 0 y 1200 segundos. Normalmente se establece en 0 al configurar DLSw para Dial-on-Demand Routing (DDR).

• passive: este comando configura el router para que no inicie un inicio de peer desde el router.

• promiscuous: este comando significa que el router acepta conexiones de cualquier peer remoto que solicite un inicio de peer. Este comando es útil en sitios grandes que tienen muchos pares, porque no tiene que definir todos los pares remotos en el router de núcleo.

• biu-segment: este comando es una opción para DLSw que permite que DLSw controle el tamaño de segmento superior en las capas de Arquitectura de red del sistema (SNA). Este comando permite a las estaciones finales creer que pueden enviar mayores cantidades de datos.

Definir el par remoto

Después de definir el peer local, se define el peer remoto. Puede definir tres tipos de pares: TCP, Fast-Sequenced Transport (FST) y control directo de enlace de alto nivel (HDLC) y Frame Relay. Estas son explicaciones de los comandos emitidos para definir el peer remoto:

Estas son las descripciones de las opciones de comando:

• backup peer: esta opción de comando define el peer que realiza una copia de seguridad de este peer en caso de que el primer peer falle.

• cost: esta opción de comando define el costo de este par. Este comando se utiliza cuando hay varias trayectorias a un destino y cuando se necesita un escenario con capacidad preferida.

• dest-mac, dynamic, no-llc e inactivity: estas opciones de comando se discuten en la sección Copia de seguridad/Peer de costo de este documento.

• dmac-output-list: esta opción de comando se ejecuta para definir una lista de acceso que indica al router qué direcciones MAC de destino remoto permite o deniega el tráfico del explorador.

• host-netbios-out: esta opción de comando se ejecuta para aplicar nombres de filtro de host NetBIOS.

• keepalive: esta opción de comando se ejecuta para determinar el intervalo en segundos entre keepalive. Se utiliza principalmente para configuraciones DDR.

• lf: esta opción de comando especifica el tamaño máximo permitido para el par.

• linger: esta opción de comando especifica la cantidad de tiempo que el router deja abierto el par de respaldo que se vuelve activo (debido a una falla primaria) después de que el link primario se vuelve a activar.

• priority: esta opción de comando crea múltiples peers para la priorización del tráfico DLSw.

• tcp-queue-max: esta opción de comando cambia el valor predeterminado de 200 para las colas TCP.

• timeout: esta opción de comando es el número de segundos que TCP espera un reconocimiento antes de interrumpir la conexión.

• V2-single-tcpM: esta opción de comando está diseñada para utilizarse en entornos de traducción de direcciones de red (NAT). Cada par piensa que tiene la dirección IP más alta para evitar que cada par desconecte una de las conexiones TCP.

Temporizadores utilizados en DLSw

Estas son explicaciones de los temporizadores utilizados en DLSw:

Estos parámetros son muy útiles. Por ejemplo, puede cambiar el intervalo en segundos que el router envía a un explorador. Esto ayuda a reducir la cantidad de exploradores en la red al aumentar el tiempo entre ellos. Además, puede cambiar los valores en los que el router agota el tiempo de espera de las entradas de la memoria caché.

Comandos DLSw adicionales

Estos son comandos adicionales importantes de DLSw:

• dlsw allroute-sna/netbios: este comando se ejecuta para cambiar el comportamiento de DLSw de modo que se utilicen todos los exploradores de ruta en lugar de exploradores de ruta únicos.

• dlsw bridge-group: este comando se ejecuta para vincular dominios con puente transparente con DLSw. Se utiliza ampliamente al configurar NetBIOS con Ethernet.

• dlsw explorerq-depth: este comando establece el valor de la cola del explorador DLSw. Este comando se ejecuta después del comando regular source-bridge explorer-queue, pero se refiere a todas las tramas CANUREACH (CUR) que deben procesarse. Este comando es importante porque cubre los paquetes de Ethernet, aunque no esté cubierto en el comando source-bridge explorerq-depth. Consulte Comprensión y Troubleshooting del Bridging de Ruta de Origen para obtener más información sobre este comando.

Comandos show

Los comandos show y los resultados que se describen en esta sección son útiles para resolver problemas de DLSw.

show dlsw peer

Este comando proporciona información acerca de los pares. Aquí se muestra cada par remoto configurado, incluida la cantidad de paquetes transmitidos y recibidos.

Peers:                state     pkts_rx   pkts_tx  type  drops ckts TCP   uptime
 TCP 5.5.5.1         CONNECT          2         2  conf      0    0   0 00:00:06

Estos son los estados posibles:

• CONNECT: este estado significa que el par DLSw está en funcionamiento.

• DISCONNECT: Este estado significa que el par está inactivo o no está conectado.

• CAP_EXG: este estado significa que DLSw está en intercambio de capacidades con el peer remoto.

• WAIT_RD: este estado es el paso final para iniciar el par. Este par está esperando que el par remoto abra el puerto de lectura. Refiérase a la sección debugging de este documento para obtener más información sobre cuándo se inicia el peer y la ejecución del comando debug dlsw peer.

• WAN_BUSY: este estado significa que la cola de salida TCP está llena y el paquete no se puede transmitir.

El comando show dlsw peer también muestra el número de caídas, la cantidad de circuitos a través del peer específico, la cola TCP y el tiempo de actividad. El contador de caídas aumenta por estas razones:

• La interfaz WAN no esta activa para un par directo.

• DLSw intenta enviar un paquete antes de que el par esté completamente conectado (esperando un evento TCP o un evento de capacidades). Cola TCP saliente llena.

• Discordancia en el conteo de secuencia de números FST.

• No se puede obtener el búfer para el paquete FST del switch lento.

• falla del controlador CiscoBus en el extremo superior; no puede mover el paquete del búfer de recepción al búfer de transmisión o viceversa.

• La dirección IP de destino del paquete FST no coincide con el ID de peer local.

• Interfaz WAN no funciona para un par FST.

• No se configuró ningún comando SRB route cache.

• El búfer del anillo Madge está lleno en los sistemas de gama baja: La WAN alimenta a la LAN demasiado rápido.

show dlsw capabilities

DLSw: Capabilities for peer 5.5.5.1(2065)
  vendor id (OUI)         : '00C' (cisco)
  version number          : 1
  release number          : 0
  init pacing window      : 20
  unsupported saps        : none
  num of tcp sessions     : 1
  loop prevent support    : no
  icanreach mac-exclusive : no
  icanreach netbios-excl. : no
  reachable mac addresses : none
  reachable netbios names : none
  cisco version number    : 1
  peer group number       : 0
  border peer capable     : no
  peer cost               : 3
  biu-segment configured  : no
  local-ack configured    : yes
  priority configured     : no
  version string          :
Cisco Internetwork Operating System Software
IOS (tm) 4500 Software (C4500-J-M), Version 10.3(13), RELEASE SOFTWARE (fc2)
Copyright (c) 1986-1996 by cisco Systems, Inc.

alcance de show dlsw

DLSw MAC address reachability cache list
Mac Addr        status     Loc.    peer/port            rif
0800.5a0a.c51d  FOUND      LOCAL   TokenRing3/0     06B0.0021.00F0
0800.5a49.1e38  FOUND      LOCAL   TokenRing3/0     06B0.0021.00F0
0800.5a95.3a13  FOUND      REMOTE  5.5.5.1(2065)
 
DLSw NetBIOS Name reachability cache list
NetBIOS Name    status     Loc.    peer/port            rif
PIN-PIN         FOUND      LOCAL   TokenRing3/0     06B0.0021.00F0
QUENEPA         FOUND      LOCAL   TokenRing3/0     06B0.0021.00F0
WIN95           FOUND      REMOTE  5.5.5.1(2065)

El campo status es la parte más importante del comando show dlsw reach. Estos son los estados posibles:

• ENCONTRADO: el router ha localizado el dispositivo.

• BUSCANDO: el router está buscando el recurso.

• NOT_FOUND: el almacenamiento en caché negativo está activado y la estación no ha respondido a las consultas.

• UNCONFIRMED: la estación está configurada, pero DLSw no la ha verificado.

• VERIFY: verificando la información de caché porque la caché se está quedando obsoleta o porque se está verificando la configuración del usuario.

show dlsw circuit

Index           local addr(lsap)    remote addr(dsap)  state
1622193728      4001.68ff.0001(04)  4000.0000.0001(04) CONNECTED
        PCEP: 60A545B4   UCEP: 60B0B640
        Port:To3/0          peer 5.5.5.1(2065)
        Flow-Control-Tx CW:20, Permitted:32; Rx CW:20, Granted:32
        RIF = 06B0.0021.00F0

Cuando ejecute el comando show dlsw circuit, preste atención al control de flujo. El control de flujo existe por circuito. Esta es una comunicación que ocurre mientras los dos pares DLSw asignan al circuito una ventana de posible transferencia. Este valor aumenta y disminuye en función de la cantidad de tráfico por el que el circuito intenta moverse. El valor puede cambiar en función de la congestión de la nube.

El comando show dlsw circuit es más extenso a partir de IOS 11.1. El comando ahora le permite observar el circuito DLSw en un valor de punto de acceso de servicio (SAP) o valor MAC, lo que simplifica la localización de circuitos al resolver problemas. Éste es un ejemplo de salida:

ibu-7206#sh dlsw cir
Index           local addr(lsap)    remote addr(dsap)  state
1622193728      4001.68ff.0001(04)  4000.0000.0001(04) CONNECTED
ibu-7206#sh dls cir det ?
  <0-4294967295>  Circuit ID for a specific remote circuit
  mac-address     Display all remote circuits using a specific MAC
  sap-value       Display all remote circuits using a specific SAP
  <cr>
 
ibu-7206#show dlsw circuit detail mac 4000.0000.0001
Index           local addr(lsap)    remote addr(dsap)  state
1622193728      4001.68ff.0001(04)  4000.0000.0001(04) CONNECTED
        PCEP: 60A545B4   UCEP: 60B0B640
        Port:To3/0          peer 5.5.5.1(2065)
        Flow-Control-Tx CW:20, Permitted:29; Rx CW:20, Granted:29
        RIF = 06B0.0021.00F0
241-00  4000.0000.0001(04)  4001.68ff.0000(04) CONNECTED
        Port:To0          peer 5.5.7.1(2065)
        Flow-Control-Tx CW:20, Permitted:27; Rx CW:20, Granted:27
        RIF = 0630.00F1.0010
s5e#sh cls
DLU user: DLSWDLU
      SSap:0x63       type:  llc0   class:0
        DTE:0800.5a95.3a13 0800.5a0a.c51d F0 F0
        T1 timer:0      T2 timer:0      Inact timer:0
        max out:0       max in:0        retry count:0
        XID retry:0     XID timer:0     I-Frame:0
 
        DTE:4000.0000.0001 4001.68ff.0000 04 04
        T1 timer:0      T2 timer:0      Inact timer:0
        max out:0       max in:0        retry count:0
        XID retry:0     XID timer:0     I-Frame:0
TokenRing0 DTE: 4000.0000.0001 4001.68ff.0000 04 04 state NORMAL
   V(S)=23, V(R)=23, Last N(R)=22, Local window=7, Remote Window=127
   akmax=3, n2=8, Next timer in 1240
   xid-retry timer      0/0       ack timer    1240/1000
   p timer              0/1000    idle timer  10224/10000
   rej timer            0/3200    busy timer      0/9600
   akdelay timer        0/100     txQ count       0/200

Resolución de problemas

De forma predeterminada, DLSw termina las sesiones LLC en los routers (local-ack). Además, dado que finaliza el campo de información de routing (RIF), hay otros problemas de diseño que deben tenerse en cuenta. Los problemas más comunes de DLSw se describen en esta sección.

Loops

Una de las cosas más importantes a recordar sobre DLSw es la terminación RIF. Esto supone un problema, ya que se pueden crear fácilmente bucles importantes en la red. Este diagrama muestra un loop:

En este caso, dado que DLSw termina el RIF, el paquete gira indefinidamente. Esto se debe a que cada vez que se envía una trama CUR de igual a igual, el par receptor crea un nuevo explorador (NO RIF) y lo envía. Se describen los pasos del explorador:

1. El 3174 en el anillo 11 envía un explorador para alcanzar el host.

2. Tanto SF1 como el puente copian la trama.

3. SF1 crea una trama CUR a LA1 (su par) para decirle a LA1 que el 3174 quiere alcanzar el HOST.

4. SF2 recibe el paquete y hace lo mismo.

5. Ahora, LA1 y LA2 crean el explorador y lo envían al anillo.

6. LA1 y LA2 reciben un explorador que se crearon mutuamente.

7. Ahora hay un dilema, porque cada lado cree que el 3174 está conectado localmente.

8. Cada router tiene el 3174, tanto local como remoto.

9. Ahora envían una trama Icanreach a SF1 y SF2, respectivamente, lo que crea una respuesta del host hacia el 3174.

10. Tanto SF1 como SF2 colocan la respuesta del explorador en el Token Ring y cada uno aprende que la dirección MAC del host es accesible local y remotamente.

11. DLSw alcance eficazmente firewalls contra looping del explorador indefinidamente. Sin embargo, con las tramas de información no numerada (IU), esto puede generar bucles y, a continuación, impulsar la utilización de la CPU y la línea hasta en un 100%.

Si esto ocurre, verifique que el anillo virtual en los routers sea exactamente el mismo en cada lado de la nube, como se muestra en este diagrama:

Los routers de cada lado de esta nube tienen exactamente el mismo número de anillo virtual. Esto garantiza que uno de los routers envía un explorador que ya ha pasado a través del anillo y, a continuación, el router lo descarta. Cuando LA1 genera un explorador para una trama CUR recibida por SF1, LA2 lo descarta porque el explorador ya pasó a través del anillo 1. En este escenario, es importante que el router tenga un puente diferente configurado si el paquete se dirige al mismo anillo, que es el caso del lado LA de la red.

En una versión Ethernet del mismo escenario, debe inhabilitar un par. En este diagrama se muestra un ejemplo:

Debido a que un paquete en la Ethernet no tiene un RIF, el router no puede determinar si la transmisión, creada por el otro router en la LAN, proviene del otro router o de una estación de origen. Con SNA, el paquete se origina localmente o es remoto. Debido a que los exploradores de un entorno Token Ring en efecto tienen direcciones MAC de origen y destino, no son una transmisión en Ethernet, sino una trama dirigida a una estación desde otra.

Lo que ocurre en el diagrama anterior se explica en estos pasos:

1. Se envía un explorador desde el 3174 al host.

2. Este explorador es aceptado por SF1 y SF2.

3. SF1 y SF2 generan cada uno un CUR hacia el otro lado, LA1 y LA2.

4. Generan un explorador al que responde el host; como se trata de un explorador de ruta única, se responde a él con un explorador de ruta completa.

5. Tanto LA1 como LA2 crean una trama CUR para SF1 y SF2, que crean el paquete para el 3174.

6. SF1 escucha la dirección MAC del HOST que proviene de Ethernet y ahora cree que el HOST se encuentra en la LAN local. Pero en la memoria caché de SF1, el ID de HOST responde desde un peer remoto.

7. Esto obliga al router a tener el HOST local y remoto, lo que significa que DLSw está dañado.

Pares de respaldo/costo

Los pares de respaldo agregan tolerancia a fallas a DLSw en el caso de que se pierda un par. Esto se configura generalmente en entornos de núcleo de modo que cuando falla un router de núcleo, otro router puede aceptar el router que falla. Las configuraciones y el diagrama de esta sección ilustran una configuración de par de respaldo.

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3b
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.14.1
   cost 2 promiscuous
!
interface Loopback0
 ip address 1.1.14.1 255.255.255.0
!
interface Serial0
 ip address 1.1.6.2 255.255.255.0
 bandwidth 125000
 clockrate 125000
!
interface TokenRing0
 ip address 1.1.5.1 255.255.255.0
 ring-speed 16
 source-bridge 3 1 2
 source-bridge spanning
!

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3c
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.12.1
   cost 4 promiscuous
!
interface Loopback0
 ip address 1.1.12.1 255.255.255.0
!
interface Serial0
 ip address 1.1.4.1 255.255.255.0
 bandwidth 500000
 clockrate 500000
!
interface TokenRing0
 ip address 1.1.5.2 255.255.255.0
 ring-speed 16
 source-bridge 3 2 2
 source-bridge spanning
!

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3a
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.13.1
dlsw remote-peer 0 tcp 1.1.14.1
dlsw remote-peer 0 tcp 1.1.12.1
dlsw timer explorer-wait-time 2
!
interface Loopback0
 ip address 1.1.13.1 255.255.255.0
!
interface Serial0
 ip address 1.1.6.1 255.255.255.0
 bandwidth 500000
!
interface Serial1
 ip address 1.1.4.2 255.255.255.0
 bandwidth 125000
!
interface TokenRing0
 ip address 1.1.1.1 255.255.255.0
 ring-speed 16
 source-bridge 3 1 2
 source-bridge spanning
!

Lo primero que hay que recordar acerca de los pares de costo DLSw es que ambos pares están activos. El router mantiene solamente un par de respaldo. Puede tener dos al mismo tiempo si se configura linger. Esto es lo que ocurrió en el diagrama anterior:

1. D3a recibe un explorador e inicia el proceso enviando una trama CUR a cada par remoto.

2. D3B y D3C reciben las tramas CUR. Cada una genera un explorador para el host, que responde a D3B y D3C.

3. Tanto D3B como D3C responden a D3A con Icanreach.

4. D3A envía la respuesta del explorador a la estación final.

5. La estación remota inicia el circuito dlsw, con identificación de intercambio (XID) para SNA y establece el modo equilibrado asíncrono extendido (SABME) para NetBIOS.

6. D3A selecciona un coste menor dentro del alcance.

Hay un temporizador en D3A que se puede definir para decirle al router cuánto tiempo debe esperar a que todos los exploradores regresen a D3A. Esto evita problemas con los costos que pueden ocurrir cuando el router utiliza el primer explorador que vuelve a él. Ejecute el comando dlsw timer explorer-wait-time <seconds> para establecer este temporizador.

Además, al realizar peers de borde, DLSw envía solamente una trama CUR al peer de menor costo. Se comporta de manera diferente que cuando realiza el costo sin pares de borde.

Los pares de respaldo funcionan un poco diferente. Usted especifica el par de respaldo en el par que se va a respaldar para el par especificado. Esto significa que el par que tiene la sentencia de respaldo es el mismo par de respaldo.

Especifique la opción linger para que cuando el peer primario vuelva a estar operativo, los circuitos no se puedan desactivar inmediatamente. Esto es útil si el peer primario varía hacia arriba y hacia abajo, porque no desea utilizar el peer defectuoso.

Esto demuestra la configuración de pares de respaldo:

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3b
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.14.1
   promiscuous
!
interface Loopback0
 ip address 1.1.14.1 255.255.255.0
!
interface Serial0
 ip address 1.1.6.2 255.255.255.0
 bandwidth 125000
 clockrate 125000
!
interface TokenRing0
 ip address 1.1.5.1 255.255.255.0
 ring-speed 16
 source-bridge 3 1 2
 source-bridge spanning
!

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3c
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.12.1
   promiscuous
!
interface Loopback0
 ip address 1.1.12.1 255.255.255.0
!
interface Serial0
 ip address 1.1.4.1 255.255.255.0
 bandwidth 500000
 clockrate 500000
!
interface TokenRing0
 ip address 1.1.5.2 255.255.255.0
 ring-speed 16
 source-bridge 3 2 2
 source-bridge spanning
!

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3a
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.13.1
dlsw remote-peer 0 tcp 1.1.14.1
dlsw remote-peer 0 tcp 1.1.12.1 backup-peer 1.1.14.1 linger 5
dlsw timer explorer-wait-time 2
!
interface Loopback0
 ip address 1.1.13.1 255.255.255.0
!
interface Serial0
 ip address 1.1.6.1 255.255.255.0
 bandwidth 500000
!
interface Serial1
 ip address 1.1.4.2 255.255.255.0
 bandwidth 125000
!
interface TokenRing0
 ip address 1.1.1.1 255.255.255.0
 ring-speed 16
 source-bridge 3 1 2
 source-bridge spanning
!

El par se desconecta mediante la ejecución del comando show dlsw peer:

d3a#sh dls peer
Peers:                state     pkts_rx   pkts_tx  type  drops ckts TCP   uptime
 TCP 1.1.14.1        CONNECT        464      1286  conf      0    0   0 03:17:02
 TCP 1.1.12.1        DISCONN          0         0  conf      0    0   -        -

Pares de bordes

Los pares de borde son una función importante de DLSw porque resuelven el problema del control de broadcast en una red. Este ejemplo ilustra cómo se configuran los pares de borde y qué ocurre cuando se inicia una sesión:

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3e
!
!
dlsw local-peer peer-id 1.1.11.1 group 1
   border promiscuous
dlsw remote-peer 0 tcp 1.1.12.1
!
interface Loopback0
 ip address 1.1.11.1 255.255.255.0
!
interface Serial0
 ip address 1.1.3.1 255.255.255.0
!
interface Serial1
 ip address 1.1.2.2 255.255.255.0
 clockrate 500000
!
interface TokenRing0
 ip address 10.17.1.189 255.255.255.0
 ring-speed 16
!
router ospf 100
 network 1.0.0.0 0.255.255.255 area 0
!

Current configuration:
!
version 11.1

service udp-small-servers
service tcp-small-servers
!
hostname d3c
!
!
dlsw local-peer peer-id 1.1.12.1 group 2
   border promiscuous
dlsw remote-peer 0 tcp 1.1.11.1
!
interface Loopback0
 ip address 1.1.12.1 255.255.255.0
!
interface Serial0
 ip address 1.1.4.1 255.255.255.0
 no fair-queue
 clockrate 500000
!
interface Serial1
 ip address 1.1.3.2 255.255.255.0
 clockrate 500000
!
interface TokenRing0
 no ip address
 shutdown
 ring-speed 16
!
router ospf 100
 network 1.0.0.0 0.255.255.255 area 0
!

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3f
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.10.1 group 1
   promiscuous
dlsw remote-peer 0 tcp 1.1.11.1
dlsw peer-on-demand-defaults inactivity 1
!
interface Loopback0
 ip address 1.1.10.1 255.255.255.0
!
interface Serial0
 ip address 1.1.2.1 255.255.255.0
 no fair-queue
!!
interface TokenRing0
 ip address 1.1.1.1 255.255.255.0
 ring-speed 16
 source-bridge 1 1 2
 source-bridge spanning
!
router ospf 100
 network 1.0.0.0 0.255.255.255 area 0

Current configuration:
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname d3a
!
!
source-bridge ring-group 2
dlsw local-peer peer-id 1.1.13.1 group 2
   promiscuous
dlsw remote-peer 0 tcp 1.1.12.1
dlsw peer-on-demand-defaults inactivity 1
!
interface Loopback0
 ip address 1.1.13.1 255.255.255.0
!
interface Serial0
 ip address 1.1.4.2 255.255.255.0
!
interface TokenRing0
 ip address 1.1.5.1 255.255.255.0
 ring-speed 16
 source-bridge 3 1 2
 source-bridge spanning
!
router ospf 100
 network 1.0.0.0 0.255.255.255 area 0
!

La primera parte de la configuración de pares de borde es crear pares promiscuos. Los peers promiscuos aceptan conexiones de cualquier router DLSw que intente abrir un peer con este router. Por ejemplo, en el diagrama anterior, desea que D3A abra un par con D3F. Si no hay pares de borde, debe configurar pares estáticos en la red. Esto funciona bien, pero cuando tiene cientos de sitios y utiliza peers estáticos cuando un router necesita encontrar una estación remotamente, el router tiene que enviar una trama CUR a cada peer. Esto puede causar una gran cantidad de sobrecarga.

Por otro lado, cuando utiliza pares de borde, ese router remoto necesita enviar solamente una solicitud al par de borde. Esta solicitud se propaga a través de los grupos y el router remoto abre un par con el otro router remoto para iniciar un circuito y establecer una conexión. Este proceso se explica en este diagrama:

1. Cuando D3A recibe el explorador, envía una difusión a D3C. D3C es el par de borde al que está conectado D3A.

2. Cuando D3C recibe la trama CUR, envía la trama CUR a todos los pares del grupo. D3C también envía una trama de prueba a cualquier interfaz local que esté configurada para hacerlo y envía una trama CUR a los pares de borde del otro grupo.

3. D3E recibe el CUR de D3C en otro grupo. Entonces D3E hace lo mismo enviando el CUR a todos los peers del grupo y a cualquier interfaz local.

4. D3F recibe la trama CUR y envía un sondeo de prueba a la interfaz local. Si D3F tiene un par apuntando a otro router, no puede repetir esa trama CUR a otro router.

5. Cuando D3F recibe una respuesta para la estación final, devuelve la trama Icanreach a D3E.

6. D3E lo envía a D3C, que lo reenvía a D3A. D3A envía una respuesta de prueba al dispositivo.

7. Cuando la estación final inicia un circuito dlsw, con XID para SNA y SABME para NetBIOS, D3A inicia una conexión de peer con D3F e inicia la sesión.

Esta es la depuración de D3C y D3A durante este proceso:

d3a#
DLSW Received-ctlQ : CLSI Msg : TEST_STN.Ind   dlen: 40
CSM: Received CLSI Msg : TEST_STN.Ind   dlen: 40 from TokenRing0
CSM:   smac c001.68ff.0000, dmac 4000.0000.0001, ssap 4 , dsap 0
DLSw: sending bcast to BP peer 1.1.12.1(2065)

Se observa la trama de prueba que entra en el router. Luego, el router genera una trama CUR a D3C. La actividad D3C muestra este resultado:

DLSw: Pak from peer 1.1.13.1(2065) with op DLX_MEMBER_TO_BP
DLSw: recv_member_to_border() from peer 1.1.13.1(2065)
DLSw: passing pak to core originally from 1.1.13.1 in group 2
%DLSWC-3-RECVSSP: SSP OP = 3( CUR  ) -explorer from peer 1.1.13.1(2065)
DLSw: Pak from peer 1.1.11.1(2065) with op DLX_RELAY_RSP
DLSW: relaying pak to member 1.1.13.1 in group 2

Cuando D3C recibe el paquete de D3A, lo reenvía al núcleo. Más adelante, verá la respuesta del par remoto que se está retransmitiendo de nuevo a D3A. Luego D3A inicia la conexión (peer on demand) con el peer remoto D3F en esta depuración:

DLSw: Pak from peer 1.1.12.1(2065) with op DLX_RELAY_RSP
DLSW: creating a peer-on-demand for 1.1.10.1
DLSw: passing pak to core originally from 1.1.10.1 in group 1
%DLSWC-3-RECVSSP: SSP OP = 4( ICR  ) -explorer from peer 1.1.10.1(2065)
DISP Sent : CLSI Msg : TEST_STN.Rsp   dlen: 44
DLSW Received-ctlQ : CLSI Msg : ID_STN.Ind   dlen: 54
CSM: Received CLSI Msg : ID_STN.Ind   dlen: 54 from TokenRing0
CSM:   smac c001.68ff.0000, dmac 4000.0000.0001, ssap 4 , dsap 4
DLSw: new_ckt_from_clsi(): TokenRing0 4001.68ff.0000:4->4000.0000.0001:4
DLSw: action_a() attempting to connect peer 1.1.10.1(2065)
DLSw: action_a(): Write pipe opened for peer 1.1.10.1(2065)
DLSw: peer 1.1.10.1(2065), old state DISCONN, new state WAIT_RD
DLSw: passive open 1.1.10.1(11003) -> 2065
DLSw: action_c(): for peer 1.1.10.1(2065)
DLSw: peer 1.1.10.1(2065), old state WAIT_RD, new state CAP_EXG
DLSw: CapExId Msg sent to peer 1.1.10.1(2065)
DLSw: Recv CapExId Msg from peer 1.1.10.1(2065)
DLSw: Pos CapExResp sent to peer 1.1.10.1(2065)
DLSw: action_e(): for peer 1.1.10.1(2065)
DLSw: Recv CapExPosRsp Msg from peer 1.1.10.1(2065)
DLSw: action_e(): for peer 1.1.10.1(2065)
DLSw: peer 1.1.10.1(2065), old state CAP_EXG, new state CONNECT
DLSw: peer_act_on_capabilities() for peer 1.1.10.1(2065)
DLSw: action_f(): for peer 1.1.10.1(2065)
DLSw: closing read pipe tcp connection for peer 1.1.10.1(2065)
DLSw: new_ckt_from_clsi(): TokenRing0 4001.68ff.0000:4->4000.0000.0001:4
DLSw: START-FSM (1474380): event:DLC-Id state:DISCONNECTED
DLSw: core: dlsw_action_a()
DISP Sent : CLSI Msg : REQ_OPNSTN.Req   dlen: 106
DLSw: END-FSM (1474380): state:DISCONNECTED->LOCAL_RESOLVE

Una vez que el router recibe el paquete transmitido del peer de borde, abre un peer a demanda con el peer remoto D3F (1.1.10.1) y enciende el circuito.

depuración

El primer paso en cualquier red DLSw es educar a los pares. Sin los pares, no hay intercambio de datos. La mayoría de los detalles de lo que ocurre entre los pares DLSw se explican en RFC 1795.

Nota: Si habla con un equipo que no es de Cisco mediante DLSw, utilice DLSw. Sin embargo, entre routers Cisco, utilice DLSw+.

Este resultado proviene de la ejecución de debug dlsw peers y la activación de los peers entre dos routers Cisco:

DLSw: passive open 5.5.5.1(11010) -> 2065
DLSw: action_b(): opening write pipe for peer 5.5.5.1(2065)
DLSw: peer 5.5.5.1(2065), old state DISCONN, new state CAP_EXG
DLSw: CapExId Msg sent to peer 5.5.5.1(2065)
DLSw: Recv CapExId Msg from peer 5.5.5.1(2065)
DLSw: Pos CapExResp sent to peer 5.5.5.1(2065)
DLSw: action_e(): for peer 5.5.5.1(2065)
DLSw: Recv CapExPosRsp Msg from peer 5.5.5.1(2065)
DLSw: action_e(): for peer 5.5.5.1(2065)
shSw: peer 5.5.5.1(2065), old state CAP_EXG, new state CONNECT
DLSw: peer_act_on_capabilities() for peer 5.5.5.1(2065)
DLSw: action_f(): for peer 5.5.5.1(2065)
DLSw: closing read pipe tcp connection for peer 5.5.5.1(2065)

Esta salida muestra el router iniciando el par y abriendo una sesión TCP con el otro router. A continuación, comienza a intercambiar capacidades. Después de un intercambio positivo de capacidades, el par se conecta. A diferencia de RSRB, DLSw no mueve el peer a un estado cerrado cuando no hay actividad, como el tráfico. Siempre permanecen conectados. Si los peers están desconectados, ejecute debug dlsw peer para determinar por qué no pueden abrirse.

Al resolver problemas de una sesión que se está iniciando, ejecute debug dlsw core para observar la falla de la sesión y verificar si el circuito se está activando.

Este es el flujo para un controlador de comunicaciones 3174 al host a través de DLSw+:

El resultado de debug dlsw muestra el flujo de la sesión que se está activando correctamente:

ibu-7206#debug dlsw
DLSw reachability debugging is on at event level for all protocol traffic
DLSw peer debugging is on
DLSw local circuit debugging is on
DLSw core message debugging is on
DLSw core state debugging is on
DLSw core flow control debugging is on
DLSw core xid debugging is on
ibu-7206#
DLSW Received-ctlQ : CLSI Msg : UDATA_STN.Ind   dlen: 208
CSM: Received CLSI Msg : UDATA_STN.Ind   dlen: 208 from TokenRing3/0
CSM:   smac 8800.5a49.1e38, dmac c000.0000.0080, ssap F0, dsap F0
CSM: Received frame type NETBIOS DATAGRAM from 0800.5a49.1e38, To3/0
DLSw: peer_put_bcast() to non-grouped peer 5.5.5.1(2065)
DLSw: Keepalive Request sent to peer 5.5.5.1(2065))
DLSw: Keepalive Response from peer 5.5.5.1(2065)
DLSW Received-ctlQ : CLSI Msg : TEST_STN.Ind   dlen: 41
CSM: Received CLSI Msg : TEST_STN.Ind   dlen: 41 from TokenRing3/0
CSM:   smac c001.68ff.0001, dmac 4000.0000.0001, ssap 4 , dsap 0

Observe la trama de prueba proveniente de la LAN (localmente) desde la estación c001.68ff.0001 hasta la dirección MAC de 4000.0000.0001. Cada .Ind indica que un paquete está entrando desde la LAN. Cuando el router envía un paquete a la LAN, aparece un .RSP.

DLSw: peer_put_bcast() to non-grouped peer 5.5.5.1(2065)
%DLSWC-3-RECVSSP: SSP OP = 4( ICR  ) -explorer from peer 5.5.5.1(2065)
DISP Sent : CLSI Msg : TEST_STN.Rsp   dlen: 44

Ahora puede ver la difusión enviada al par remoto y la respuesta de velocidad de celda inicial (ICR). Esto significa que el router remoto identificó a la estación como alcanzable. TEST_STN.Rsp es el router que envía una respuesta de prueba a la estación.

DLSW Received-ctlQ : CLSI Msg : ID_STN.Ind   dlen: 54
CSM: Received CLSI Msg : ID_STN.Ind   dlen: 54 from TokenRing3/0
CSM:   smac c001.68ff.0001, dmac 4000.0000.0001, ssap 4 , dsap 4

Una vez que la estación recibe la respuesta de prueba, envía el primer XID. Puede observar esto con IS_STN.Ind. Ahora el router tiene que mantener esta trama temporalmente hasta que borre un par de detalles entre los dos routers DLSw.

DLSw: new_ckt_from_clsi(): TokenRing3/0 4001.68ff.0001:4->4000.0000.0001:4
DLSw: START-FSM (1622182940): event:DLC-Id state:DISCONNECTED
DLSw: core: dlsw_action_a()
DISP Sent : CLSI Msg : REQ_OPNSTN.Req   dlen: 108
DLSw: END-FSM (1622182940): state:DISCONNECTED->LOCAL_RESOLVE
 
DLSW Received-ctlQ : CLSI Msg : REQ_OPNSTN.Cfm CLS_OK dlen: 108
DLSw: START-FSM (1622182940): event:DLC-ReqOpnStn.Cnf state:LOCAL_RESOLVE
DLSw: core: dlsw_action_b()
CORE: Setting lf size to 30
%DLSWC-3-SENDSSP: SSP OP = 3(CUR)  to peer 5.5.5.1(2065) success
DLSw: END-FSM (1622182940): state:LOCAL_RESOLVE->CKT_START
 
%DLSWC-3-RECVSSP: SSP OP = 4(ICR)  from peer 5.5.5.1(2065)
DLSw: 1622182940 recv FCI 0 - s:0 so:0 r:0 ro:0
DLSw: recv RWO
DLSw: START-FSM (1622182940): event:WAN-ICR state:CKT_START
DLSw: core: dlsw_action_e()
DLSw: sent RWO
DLSw: 1622182940 sent FCI 80 on  ACK   - s:20 so:1 r:20 ro:1
%DLSWC-3-SENDSSP: SSP OP = 5(ACK)  to peer 5.5.5.1(2065) success
DLSw: END-FSM (1622182940): state:CKT_START->CKT_ESTABLISHED

Aquí puede observar el flujo interno de DLSw entre los dos peers. Estos paquetes son normales para cada inicio de sesión. La primera etapa consiste en pasar de un estado desconectado a un estado CKT_ESTABLISHED. Ambos routers transmiten una trama CUR para el propio circuito. Esto se denomina configuración de circuito de alcance CAN u (CURCS). Cuando el peer que inicia la trama CURCS recibe una trama ICRCS, envía un reconocimiento y se mueve a un estado establecido de circuito. Ahora, ambos routers DLSw están listos para el procesamiento XID.

DLSw: START-FSM (1622182940): event:DLC-Id state:CKT_ESTABLISHED
DLSw: core: dlsw_action_f()
DLSw: 1622182940 sent FCA on  XID
%DLSWC-3-SENDSSP: SSP OP = 7(XID)  to peer 5.5.5.1(2065) success
DLSw: END-FSM (1622182940): state:CKT_ESTABLISHED->CKT_ESTABLISHED

El router recibió un XID después de enviar la respuesta de prueba a la estación. Guarda este XID por un momento, luego lo transmite al par a través del circuito. Esto significa que está enviando paquetes hacia/desde el par con el ID de circuito etiquetado a ellos. De esta manera, DLSw entiende la actividad entre las dos estaciones. Recuerde que DLSw termina la sesión de Control de link lógico, tipo 2 (LLC2), a cada lado de la nube.

%DLSWC-3-RECVSSP: SSP OP = 7(XID)  from peer 5.5.5.1(2065)
DLSw: 1622182940 recv FCA on  XID   - s:20 so:0 r:20 ro:0
DLSw: START-FSM (1622182940): event:WAN-XID state:CKT_ESTABLISHED
DLSw: core: dlsw_action_g()
DISP Sent : CLSI Msg : ID.Rsp   dlen: 12
DLSw: END-FSM (1622182940): state:CKT_ESTABLISHED->CKT_ESTABLISHED
 
DLSW Received-ctlQ : CLSI Msg : ID.Ind   dlen: 39
DLSw: START-FSM (1622182940): event:DLC-Id state:CKT_ESTABLISHED
DLSw: core: dlsw_action_f()
%DLSWC-3-SENDSSP: SSP OP = 7(XID)  to peer 5.5.5.1(2065) success
DLSw: END-FSM (1622182940): state:CKT_ESTABLISHED->CKT_ESTABLISHED

En primer lugar, observará una respuesta al primer XID que se envió antes. En ID.Rsp, verá que el XID fue enviado a la estación, a la cual la estación respondió con un ID.Ind. Este es otro XID que se envió al par DLSw.

%DLSWC-3-RECVSSP: SSP OP = 8(CONQ)  from peer 5.5.5.1(2065)
DLSw: START-FSM (1622182940): event:WAN-CONQ state:CKT_ESTABLISHED

Esta parte nos muestra que la estación del otro lado respondió con un SABME (CONQ) al XID. La negociación XID ha finalizado y el router está listo para iniciar la sesión.

DLSw: core: dlsw_action_i()
DISP Sent : CLSI Msg : CONNECT.Req   dlen: 16

Luego, el router envía SABME a la estación en CONNECT.Req.

DLSw: END-FSM (1622182940): state:CKT_ESTABLISHED->CONTACT_PENDING
 
DLSW Received-ctlQ : CLSI Msg : CONNECT.Cfm CLS_OK dlen: 8
DLSw: START-FSM (1622182940): event:DLC-Connect.Cnf state:CONTACT_PENDING
DLSw: core: dlsw_action_j()
%DLSWC-3-SENDSSP: SSP OP = 9( CONR )  to peer 5.5.5.1(2065) success
DISP Sent : CLSI Msg : FLOW.Req   dlen: 0
DLSw: END-FSM (1622182940): state:CONTACT_PENDING->CONNECTED

A continuación, recibirá la confirmación sin número (UA) de la estación, que se muestra en el mensaje CONNECT.Cfm. Esto se envía al peer remoto a través de un CONR. A continuación, el proceso de velocidad relativa (RR) se inicia con FLOW.Req.

%DLSWC-3-RECVSSP: SSP OP = 10(INFO)  from peer 5.5.5.1(2065)
DLSw: 1622182940 decr r - s:20 so:0 r:19 ro:0
DLSw: START-FSM (1622182940): event:WAN-INFO state:CONNECTED
DLSw: core: dlsw_action_m()
DISP Sent : CLSI Msg : DATA.Req   dlen: 34
DLSw: END-FSM (1622182940): state:CONNECTED->CONNECTED
 
DLSw: 1622182940 decr s - s:19 so:0 r:19 ro:0
DLSW Received-disp : CLSI Msg : DATA.Ind   dlen: 35
DLSw: sent RWO
DLSw: 1622182940 sent FCI 80 on  INFO  - s:19 so:0 r:39 ro:1
%DLSWC-3-SENDSSP: SSP OP = 10(INFO)  to peer 5.5.5.1(2065) success
%DLSWC-3-RECVSSP: SSP OP = 10(INFO)  from peer 5.5.5.1(2065)
DLSw: 1622182940 decr r - s:19 so:0 r:38 ro:1
DLSw: 1622182940 recv FCA on  INFO  - s:19 so:0 r:38 ro:0
DLSw: 1622182940 recv FCI 0 - s:19 so:0 r:38 ro:0
DLSw: recv RWO
DLSw: START-FSM (1622182940): event:WAN-INFO state:CONNECTED
DLSw: core: dlsw_action_m()
DISP Sent : CLSI Msg : DATA.Req   dlen: 28
DLSw: END-FSM (1622182940): state:CONNECTED->CONNECTED

DATA.Req indica que el router transmitió una trama I. Data.Ind indica que el router recibió una trama I. Puede utilizar esta información para determinar el flujo de paquetes a través de los routers DLSw.

DLSW Received-ctlQ : CLSI Msg : DISCONNECT.Ind   dlen: 8
DLSw: START-FSM (1622182940): event:DLC-Disc.Ind state:CONNECTED

Esta parte contiene un DISCONNECT.Ind. Un .Ind indica que un paquete proviene de la LAN. En este caso, la estación envía un mensaje DISCONNECT, que hace que el router comience a desconectar el circuito.

DLSw: core: dlsw_action_n()
%DLSWC-3-SENDSSP: SSP OP = 14( HLTQ )  to peer 5.5.5.1(2065) success
DLSw: END-FSM (1622182940): state:CONNECTED->DISC_PENDING
 
%DLSWC-3-RECVSSP: SSP OP = 15( HLTR )  from peer 5.5.5.1(2065)
DLSw: START-FSM (1622182940): event:WAN-HLTR state:DISC_PENDING

Una vez que el router recibe la DESCONEXIÓN, envía una DETENCIÓN al par remoto y espera la respuesta. Todo lo que queda es enviar un UA a la estación y cerrar el circuito, que se muestra en la siguiente depuración con DISCONNECT.Rsp:

DLSw: core: dlsw_action_q()
DISP Sent : CLSI Msg : DISCONNECT.Rsp   dlen: 4
DISP Sent : CLSI Msg : CLOSE_STN.Req   dlen: 4
DLSw: END-FSM (1622182940): state:DISC_PENDING->CLOSE_PEND
 
DLSW Received-ctlQ : CLSI Msg : CLOSE_STN.Cfm CLS_OK dlen: 8
DLSw: START-FSM (1622182940): event:DLC-CloseStn.Cnf state:CLOSE_PEND
DLSw: core: dlsw_action_y()
DLSw: 1622182940 to dead queue
DLSw: END-FSM (1622182940): state:CLOSE_PEND->DISCONNECTED

Lo último que DLSw realiza es poner el circuito en la cola muerta. A partir de ahí, los punteros están limpios y listos para un nuevo circuito.

Sesiones de NetBIOS

DLSw administra sesiones NetBIOS en forma diferente, pero las depuraciones son muy similares.

Nota: Recuerde que los XID no fluyen para las estaciones NetBIOS y que los routers DLSw intercambian tramas del procesador de conmutación del sistema de consulta de nombres (SSP) NetBIOS y el nombre NetBIOS reconocido. Esta es la principal diferencia.

Información Relacionada

• Resolución de problemas de DLSw
• Tecnologías IBM
• Soporte Técnico y Documentación - Cisco Systems