Data Link Switching Plus

Introduction

O Data-Link Switching (DLSw) é um padrão implementado pela IBM que suporta o transporte de Logical Link Control (LLC) sobre WANs. O DLSw é uma forma mais elaborada de Source-Route Bridging (RSRB) remoto e é mais específico quanto ao que ele pode ou não fazer bridge. O DLSw exige que o roteador transporte uma sessão LLC2 válida ou uma sessão NetBIOS.

Os roteadores Cisco implementam RFC 1795 (padrão DSLw) e 2166 (DLSw versão 2). Além disso, o DLSw implementa mais recursos para controle de broadcast e transporta menos informações através da WAN do que outros métodos.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Comandos gerais

Esta seção aborda comandos DLSw importantes, comandos para configurar o DLSw e comandos para solucionar problemas do DLSw.

source-bridge ring-group

A primeira etapa na configuração do DLSw é adicionar o comando source-bridge ring-group. Isso conecta as interfaces Token Ring que executam Source-Route Bridging (SRB).

Observação: ao executar DLSw em um roteador que tem apenas interfaces Ethernet, não há necessidade de configurar um grupo de anéis.

Definir a Identificação de Par Local

A próxima opção é definir a identificação de peer local. Este é um endereço IP na mesma caixa. Isso basicamente inicia o DLSw no roteador.

A opção mais básica na configuração do DLSw é estabelecer o endereço IP peer-id local. Estas são descrições dos parâmetros de comando:

• group e border— Esses comandos são emitidos juntos para criar peers de borda na rede.

• cost— Este comando é emitido quando há vários caminhos para o mesmo local. Esse comando informa ao roteador como acessar esses locais remotos usando primeiro o caminho de menor custo.

• lf— Este comando determina o maior tamanho de quadro que este peer pode manipular. Os tamanhos de quadro podem ser:

  • Tamanho máximo de estrutura: 516-516 bytes

  • Tamanho máximo de estrutura: 1470-1470 bytes

  • Tamanho máximo de estrutura: 1500-1500 bytes

  • Tamanho máximo de quadro 2052-2052 bytes

  • Tamanho máximo de estrutura: 4472-4472 bytes

  • Tamanho máximo de estrutura: 8144-8144 bytes

  • Tamanho máximo do quadro de 11407-11407 bytes

  • Tamanho máximo de estrutura 11454 a 11454 bytes

  • Tamanho máximo de estrutura: 17800-17800 bytes

• keepalive— Este comando define o intervalo entre os pacotes keepalive. O intervalo pode variar de 0 a 1200 segundos. Geralmente é definido como 0 ao configurar DLSw para Dial-on-Demand Routing (DDR).

• passive— Este comando configura o roteador para não iniciar uma inicialização de peer a partir do roteador.

• promíscuo— Este comando significa que o roteador aceita conexões de qualquer peer remoto que solicite uma inicialização de peer. Esse comando é útil em sites grandes que têm muitos peers, porque você não precisa definir todos os peers remotos no roteador de núcleo.

• biu-segment— Este comando é uma opção para DLSw que permite que o DLSw controle o tamanho do segmento mais alto nas camadas da Arquitetura de Rede do Sistema (SNA). Esse comando permite que as estações finais acreditem que podem enviar maiores quantidades de dados.

Definir o peer remoto

Após definir o peer local, você define o peer remoto. Você pode definir três tipos de peers: TCP, Transporte em Rápida Sequência (FST - Fast-Sequenced Transport) e Controle Direto de Enlace de Alto Nível (HDLC - High-Level Link Control) e Frame Relay. Estas são explicações dos comandos emitidos para definir o peer remoto:

Estas são as descrições das opções de comando:

• backup peer — Esta opção de comando define o peer que faz backup desse peer em caso de falha do primeiro peer.

• cost— Esta opção de comando define o custo deste peer. Esse comando é usado quando há vários caminhos para um destino e quando você precisa de um cenário com capacidade preferencial.

• dest-mac, dynamic, no-llc e inactivity— Essas opções de comando são discutidas na seção Backup/Cost Peer deste documento.

• dmac-output-list— Esta opção de comando é emitida para definir uma lista de acesso que informa ao roteador quais endereços MAC de destino remoto você permite, ou nega, o tráfego do explorador.

• host-netbios-out— Esta opção de comando é emitida para aplicar nomes de filtro de host NetBIOS.

• keepalive— Esta opção de comando é emitida para determinar o intervalo em segundos entre keepalives. É usado principalmente para configurações DDR.

• lf— Esta opção de comando especifica o maior tamanho permitido para o peer.

• linger— Esta opção de comando especifica o tempo que o roteador deixa o peer de backup aberto que se torna ativo (devido à falha primária) depois que o link primário se torna ativo novamente.

• priority— Esta opção de comando cria vários peers para priorização do tráfego DLSw.

• tcp-queue-max— Essa opção de comando altera o valor padrão de 200 para as filas TCP.

• timeout— Esta opção de comando é o número de segundos que o TCP espera por uma confirmação antes de desativar a conexão.

• V2-single-tcpM — Essa opção de comando foi projetada para uso em ambientes de Tradução de Endereço de Rede (NAT). Cada peer acha que tem o endereço IP mais alto para evitar que cada peer derrube uma das conexões TCP.

Temporizadores usados em DLSw

Estas são explicações dos temporizadores usados em DLSw:

Esses parâmetros são muito úteis. Por exemplo, você pode alterar o intervalo em segundos em que o roteador envia um explorador. Isso ajuda a reduzir a quantidade de exploradores na rede, aumentando o tempo entre eles. Além disso, você pode alterar os valores nos quais o roteador expira as entradas de cache.

Comandos DLSw adicionais

Estes são comandos DLSw importantes adicionais:

• dlsw allroute-sna/netbios— Este comando é emitido para alterar o comportamento do DLSw de modo que todos os exploradores de rota sejam usados em vez de exploradores de rota única.

• dlsw bridge-group— Este comando é emitido para ligar domínios transpostos de forma transparente com DLSw. É amplamente usado na configuração do NetBIOS com Ethernet.

• dlsw explorerq-depth— Este comando define o valor da fila do explorador DLSw. Esse comando é emitido após o comando regular source-bridge explorer-queue, mas se refere a todos os quadros CANUREACH (CUR) que precisam ser processados. Esse comando é importante porque cobre os pacotes da Ethernet, mesmo que não seja abordado no comando source-bridge explorerq-depth. Consulte Compreendendo e Troubleshooting de Source-Route Bridging para obter mais informações sobre esse comando.

comandos show

Os comandos show e as saídas descritas nesta seção são úteis ao Troubleshoot DLSw.

show dlsw peer

Esse comando fornece informações sobre os peers. Cada peer remoto configurado é exibido aqui, incluindo a quantidade de pacotes transmitidos e recebidos.

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

Estes são os estados possíveis:

• CONNECT— Este estado significa que o peer DLSw está ativo e em execução.

• DISCONNECT- Este estado significa que o peer está desativado ou não está conectado.

• CAP_EXG— Este estado significa que o DLSw está em intercâmbio de capacidades com o peer remoto.

• WAIT_RD— Este estado é a etapa final na inicialização do peer. Esse peer está aguardando que o peer remoto abra a porta de leitura. Consulte a seção debugging deste documento para obter mais informações sobre quando o peer é inicializado e emite o comando debug dlsw peer.

• WAN_BUSY— Este estado significa que a fila de saída TCP está cheia e que o pacote não pode ser transmitido.

O comando show dlsw peer também mostra o número de quedas, a quantidade de circuitos no peer específico, a fila TCP e o tempo de atividade. O contador de queda aumenta pelos seguintes motivos:

• A interface WAN não está ativa para um peer direto.

• O DLSw tenta enviar um pacote antes que o peer esteja totalmente conectado (aguardando evento TCP ou evento de recursos). Fila TCP de saída cheia.

• Contagem de números de seqüência FST incompatível.

• Não é possível obter buffer para pacote FST de switch lento.

• Falha do controlador CiscoBus no high-end; não é possível mover o pacote do buffer de recepção para o buffer de transmissão, ou vice-versa.

• O endereço IP de destino do pacote FST não corresponde à ID de peer local.

• Interface WAN não conectada para um correspondente FST.

• Nenhum comando de cache de rota SRB configurado.

• O buffer de toque Madge está cheio em sistemas low-end: A WAN está alimentando a LAN muito 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.

exibir capacidade de alcance de 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)

O campo status é a parte mais importante do comando show dlsw reach. Estes são os possíveis status:

• ENCONTRADO— O roteador localizou o dispositivo.

• PESQUISANDO— O roteador está procurando o recurso.

• NOT_FOUND— Cache negativo está ativado e a estação não respondeu às consultas.

• NÃO CONFIRMADO—A estação está configurada, mas o DLSw não verificou.

• VERIFICAR— Verificar as informações de cache porque o cache está obsoleto ou porque a configuração do usuário está sendo verificada.

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

Ao emitir o comando show dlsw circuit, preste atenção ao controle de fluxo. O controle de fluxo existe por circuito. Essa é uma comunicação que ocorre enquanto os dois pares DLSw atribuem ao circuito uma janela de possível transferência. Esse valor aumenta e diminui dependendo da quantidade de tráfego que o circuito está tentando passar. O valor pode mudar dependendo do congestionamento da nuvem.

O comando show dlsw circuit é mais extenso a partir do IOS 11.1. O comando agora permite que você examine o circuito DLSw em um valor de Service Access Point (SAP) ou valor MAC, o que simplifica a localização de circuitos durante o Troubleshooting. Esta é uma saída de exemplo:

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

Troubleshooting

Por padrão, o DLSw encerra sessões LLC nos roteadores (local-ack). Além disso, como ele encerra o campo de informações de roteamento (RIF), há outros problemas de projeto a serem considerados. Os problemas de DLSw mais comuns são descritos nesta seção.

Circuitos

Uma das coisas mais importantes a serem lembradas sobre DLSw é a terminação RIF. Isso é um problema porque os loops principais na rede podem ser facilmente criados. Este diagrama demonstra um loop:

Nesse caso, como o DLSw termina o RIF, o pacote fica indefinidamente. Isso ocorre porque toda vez que um quadro CUR é enviado de um ponto a outro, o peer receptor cria um novo explorador (NO RIF) e o envia. As etapas do explorador são descritas:

1. O 3174 no anel 11 envia um explorador para alcançar o host.

2. O SF1 e o bridge copiam o frame

3. O SF1 cria um quadro CUR para LA1 (seu peer) para informar ao LA1 que o 3174 deseja acessar o HOST.

4. O SF2 recebe o pacote e faz o mesmo.

5. Agora, LA1 e LA2 criam o explorador e o enviam ao anel.

6. LA1 e LA2 recebem um explorador criado entre si.

7. Agora há um dilema, porque cada lado acredita que o 3174 está anexado localmente.

8. Cada roteador tem o 3174, tanto local quanto remoto.

9. Agora eles enviam um quadro Icanreach para SF1 e SF2, respectivamente, que cria uma resposta do host para o 3174.

10. Tanto o SF1 como o SF2 colocam a resposta do explorador no Token Ring e aprendem cada um que o endereço MAC do host pode ser alcançado local e remotamente.

11. O alcance do DLSw se conecta com eficiência a loops de explorador indefinidos. No entanto, com quadros de informações não numeradas (UI), isso pode gerar um loop e, em seguida, orientar a utilização da CPU e da linha em até 100%.

Se isso ocorrer, verifique se o anel virtual nos roteadores é exatamente o mesmo em cada lado da nuvem, conforme exibido neste diagrama:

Os roteadores em cada lado dessa nuvem têm exatamente o mesmo número de anel virtual. Isso garante que um dos roteadores envie um explorador que já tenha passado pelo anel e o roteador o abandone. Quando LA1 gera um explorador para um quadro CUR recebido por SF1, LA2 o descarta porque o explorador já passou pelo anel 1. Nesse cenário, é importante que o roteador tenha uma ponte diferente configurada se o pacote for direcionado para o mesmo anel, que é o caso do lado LA da rede.

Em uma versão Ethernet do mesmo cenário, você deve desativar um peer. Um exemplo é exibido neste diagrama:

Como um pacote na Ethernet não tem um RIF, o roteador não pode determinar se o broadcast, criado pelo outro roteador na LAN, é do outro roteador ou de uma estação de origem. Com o SNA, o pacote é originado localmente ou remoto. Como os exploradores de um ambiente Token Ring têm, na verdade, endereços MAC de origem e de destino, eles não são um broadcast na Ethernet, mas um quadro direcionado de uma estação para outra.

O que ocorre no diagrama anterior é explicado nestas etapas:

1. Um explorador é enviado do 3174 para o host.

2. Esse explorador é aceito por SF1 e SF2.

3. SF1 e SF2 geram, cada um, uma CUR para LA1 e LA2 do outro lado.

4. Eles geram um explorador ao qual o host responde; como é um explorador de rota única, ele é respondido com um explorador de todas as rotas.

5. Tanto LA1 como LA2 criam um quadro CUR para SF1 e SF2, que criam o pacote para o 3174.

6. SF1 ouve o endereço MAC do HOST que vem da Ethernet e agora acredita que o HOST está localizado na LAN local. Mas no cache de SF1, o ID do HOST está respondendo de um peer remoto.

7. Isso força o roteador a ter o HOST local e remoto, o que significa que o DLSw está quebrado.

Correspondentes de backup/custo

Os pares de backup adicionam tolerância a falhas ao DLSw no caso de um par ser perdido. Geralmente, isso é configurado em ambientes de núcleo para que, quando um roteador de núcleo falhar, outro roteador possa aceitar o roteador com falha. As configurações e o diagrama nesta seção ilustram uma configuração de peer de backup.

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
!

A primeira coisa a ser lembrada sobre os peers de custo DLSw é que ambos os peers estão ativos. O roteador mantém apenas um peer de backup. Ele pode ter dois no momento se linger estiver configurado. Isso é o que ocorreu no diagrama anterior:

1. O D3a recebe um explorador e inicia o processo enviando um quadro CUR para cada peer remoto.

2. D3B e D3C recebem os quadros CUR. Cada um gera um explorador para o host, que responde para o D3B e o D3C.

3. Tanto o D3B como o D3C respondem de volta ao D3A com o Icanreach.

4. D3A envia a resposta do explorador para a estação final.

5. A estação remota inicia o circuito dlsw, com XID (exchange identification) para SNA e define o SABME (asynchronous balanced mode extended) para o NetBIOS.

6. O D3A seleciona um custo mais baixo dentro da acessibilidade.

Há um temporizador no D3A que pode ser definido para informar ao roteador quanto tempo esperar que todos os exploradores retornem ao D3A. Isso evita problemas com custos que podem ocorrer quando o roteador usa o primeiro explorador que volta para ele. Emita o comando dlsw timer explorer-wait-time <seconds> para definir esse temporizador.

Além disso, ao executar border peers, o DLSw envia apenas um quadro CUR para o peer de menor custo. Ele se comporta de forma diferente do que quando executa o custo sem os peers de borda.

Os pares de backup operam de forma um pouco diferente. Você especifica o peer de backup no peer que será o backup do peer especificado. Isso significa que o peer que tem a instrução de backup é o próprio peer de backup.

Especifique a opção linger para que quando o peer primário se tornar operacional novamente, os circuitos não possam ser desmontados imediatamente. Isso é útil se o peer principal variar entre ativo e inativo, pois você não deseja usar o peer com falha.

Isso demonstra a configuração de peers de backup:

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
!

O peer é desconectado emitindo o 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   -        -

Correspondentes de borda

Os peers de borda são um recurso DLSw importante porque resolvem o problema de controle de broadcast em uma rede. Este exemplo ilustra como os peers de borda são configurados e o que ocorre quando uma sessão surge:

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
!

A primeira parte da configuração de peers de borda é criar peers promíscuos. Peers promíscuos aceitam conexões de qualquer roteador DLSw tentando abrir um peer com esse roteador. Por exemplo, no diagrama anterior, você deseja que o D3A abra um peer com o D3F. Se não houver nenhum par de borda, você precisará configurar pares estáticos na rede. Isso funciona bem, mas quando você tem centenas de sites e usa pares estáticos quando um roteador precisa encontrar uma estação remotamente, o roteador precisa enviar um quadro CUR para cada par. Isso pode causar uma grande sobrecarga.

Por outro lado, quando você usa peers de borda, esse roteador remoto precisa enviar apenas uma solicitação ao peer de borda. Essa solicitação é propagada pelos grupos e o roteador remoto abre um peer com o outro roteador remoto para iniciar um circuito e estabelecer uma conexão. Este processo é explicado neste diagrama:

1. Quando o D3A recebe o explorador, ele envia um broadcast para o D3C. D3C é o peer de borda ao qual o D3A está conectado.

2. Quando o D3C recebe o quadro CUR, ele envia o quadro CUR para todos os peers no grupo. O D3C também envia um quadro de teste para todas as interfaces locais configuradas para fazer isso e envia um quadro CUR para os peers de borda no outro grupo.

3. O D3E recebe o CUR do D3C em outro grupo. Em seguida, o D3E faz o mesmo enviando o CUR para todos os peers no grupo e todas as interfaces locais.

4. O D3F recebe o quadro CUR e envia uma pesquisa de teste à interface local. Se o D3F tiver um peer apontando para outro roteador, ele não poderá fazer eco desse quadro CUR para outro roteador.

5. Quando o D3F recebe uma resposta para a estação final, ele retorna o quadro Icanreach para o D3E.

6. O D3E o envia para o D3C, que o encaminha para o D3A. O D3A envia uma resposta de teste ao dispositivo.

7. Quando a estação final inicia um circuito dlsw, com XID para SNA e SABME para NetBIOS, o D3A inicia uma conexão peer com o D3F e inicia a sessão.

Esta é a depuração do D3C e do D3A durante este processo:

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)

O quadro de teste que entra no roteador é visto. Em seguida, o roteador gera um quadro CUR para D3C. A atividade D3C exibe esta saída:

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

Quando o D3C recebe o pacote do D3A, ele encaminha o pacote para o núcleo. Mais tarde, você verá a resposta do peer remoto que está sendo retransmitido de volta para D3A. Em seguida, o D3A inicia a conexão (peer on demand) com o peer remoto D3F nesta depuração:

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

Depois que o roteador recebe o pacote retransmitido do peer de borda, ele abre um peer sob demanda com o peer remoto D3F (1.1.10.1) e inicia o circuito.

depuração

A primeira etapa em qualquer rede DLSw é ativar os correspondentes. Sem os pares, não há troca de dados. A maioria dos detalhes do que ocorre entre os peers DLSw é explicada no RFC 1795.

Observação: se você falar com equipamentos que não são da Cisco via DLSw, use DLSw. No entanto, entre roteadores Cisco, use DLSw+.

Essa saída é da emissão de debug dlsw peers e da ativação dos peers entre dois roteadores 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 saída mostra o roteador inicializando o peer e abrindo uma sessão TCP com o outro roteador. Em seguida, ele começa a trocar recursos. Após a troca positiva de recursos, o peer é conectado. Ao contrário do RSRB, o DLSw não move o peer para um estado fechado quando não há atividade, como o tráfego. Eles sempre permanecem conectados. Se os peers estiverem desconectados, emita debug dlsw peer para determinar por que eles não são capazes de abrir.

Ao Troubleshoot uma sessão que está sendo ativada, emita debug dlsw core para observar a falha da sessão e verificar se o circuito está sendo ativado.

Este é o fluxo de um controlador de comunicação 3174 para o host via DLSw+:

A saída de debug dlsw exibe o fluxo da sessão que está sendo ativada corretamente:

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 o quadro de teste vindo da LAN (localmente) da estação c001.68ff.0001 para o endereço MAC de 4000.0000.0001. Cada .Ind indica que um pacote está vindo da LAN. Quando o roteador envia um pacote à LAN, você vê um .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

Agora você pode ver o broadcast enviado ao peer remoto e a resposta da taxa de célula inicial (ICR) de volta. Isto significa que o roteador remoto identificou a estação como alcançável. O TEST_STN.Rsp é o roteador que envia uma resposta de teste à estação.

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

Depois que a estação recebe a resposta de teste, ela envia o primeiro XID. Você pode observar isso com IS_STN.Ind. Agora, o roteador precisa se manter nesse quadro temporariamente até que ele limpe alguns detalhes entre os dois roteadores 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

Aqui você pode observar o fluxo interno de DLSw entre os dois peers. Esses pacotes são normais para cada inicialização de sessão. O primeiro estágio é passar de um estado desconectado para um estado CKT_ESTABLISHED. Ambos os roteadores transmitem um quadro CUR para o próprio circuito. Isso é chamado de CAN u reach circuit setup (CURCS). Quando o peer que inicia o quadro CURCS recebe um quadro ICRCS, ele envia uma confirmação e passa para um estado de circuito estabelecido. Agora, ambos os roteadores DLSw estão prontos para o processamento 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

O roteador recebeu um XID após enviar a resposta de teste à estação. Ele salva esse XID por um momento e depois o transmite ao peer pelo circuito. Isso significa que você está enviando pacotes para/do peer com o ID de circuito marcado para eles. Dessa forma, o DLSw compreende a atividade entre as duas estações. Lembre-se de que o DLSw encerra a sessão Logical Link Control, tipo 2 (LLC2), em cada lado da nuvem.

%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

Você primeiro observa uma resposta para o primeiro XID que foi enviado antes. Em ID.Rsp, você vê que o XID foi enviado à estação, à qual a estação respondeu com um ID.Ind. Este é outro XID que foi enviado para o peer 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 mostra que a estação do outro lado respondeu com um SABME (CONQ) ao XID. A negociação XID foi encerrada e o roteador está pronto para iniciar a sessão.

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

Depois, o roteador envia o SABME à estação no 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

Em seguida, você recebe o reconhecimento não numerado (UA) da estação, que é mostrado na mensagem CONNECT.Cfm. Isso é enviado ao peer remoto através de um CONR. Em seguida, o processo de taxa relativa (RR) é iniciado com 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

O DATA.Req indica que o roteador transmitiu um quadro I. Data.Ind indica que o roteador recebeu um quadro I. Você pode usar essas informações para determinar o fluxo de pacotes através dos roteadores DLSw.

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

Esta parte contém um DISCONNECT.Ind. Um .Ind indica um pacote vindo da LAN. Nesse caso, a estação envia um DISCONNECT, que faz com que o roteador comece a destruir o 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

Depois que o roteador recebe o comando DISCONNECT, ele envia uma mensagem HALT ao peer remoto e espera pela resposta. Resta apenas enviar um UA à estação e encerrar o circuito, o que é mostrado na seguinte depuração com o 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

A última coisa que o DLSw executa é colocar o circuito na fila inativa. A partir daí, os ponteiros são limpos e estão prontos para um novo circuito.

Sessões de NetBIOS

O DLSw manipula as sessões NetBIOS de maneira diferente, mas as depurações são bem semelhantes.

Observação: lembre-se de que os XIDs não fluem para as estações NetBIOS e que os roteadores DLSw trocam quadros do processador de switch do sistema de consulta de nomes NetBIOS (SSP) e o nome NetBIOS é reconhecido. Esta é a principal diferença.

Informações Relacionadas

• Troubleshooting de DLSw
• Tecnologias IBM
• Suporte Técnico e Documentação - Cisco Systems