Pesquisando defeitos a configuração DLSw

Introdução

Este documento discute como pesquisar defeitos uma configuração do switching de link de dados (DLSw).

Pré-requisitos

Requisitos

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.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

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

Informações de Apoio

Se os pares não conectam, verifique se a conectividade IP existe entre os dois Roteadores. Em caso afirmativo, verifique se você tem as declarações de peer apropriadas de DLSw no lugar em ambos os roteadores locais e remotos. Refira configurações básicas e pesquisa de defeitos do DLSw+ de edições da conectividade IP de DLSw para mais informação. Se nenhuma indicação remota existe, use a palavra-chave promíscuo na indicação do peer local em uma extremidade. Refira comandos Configuration do DLSw+ para mais informação.

Topologia de rede

Esta seção endereça alguns problemas comuns e fornece pontas em como você pode pesquisar defeitos.

Circuitos

Recorde que a terminação do campo de informação de roteamento (RIF) é um aspecto importante de DLSw. O RIF causa questões principal através da criação fácil dos laços na rede.

Topologia de rede

Está aqui uma topologia de exemplo que siga a criação de um laço.

O DLSw encerra o RIF e o pacote fica circulando continuamente. Cada vez que isso um quadro CANUREACH (CUR) é enviado do par para espreitar, o par destinatário cria um explorador novo (NENHUM RIF) e envia-o.

Criação do laço: Cenário 1

Esta é a rota de um explorador:

1. Os 3174 no anel 11 enviam um explorador para alcançar o host.

   

2. San Francisco 1 (SF1) e a ligação copiam o quadro.

   

3. O SF1 cria um cur frame a Los Angeles 1 (LA1), que seja o par, que diz a LA1 que os 3174 querem alcançar o host.

   

4. San Francisco 2 (SF2) recebe o pacote e repete a ação.

   

5. O LA1 e Los Angeles 2 (LA2) criam o explorador e enviam-no ao anel.

   

6. O LA1 e o LA2 cada um recebem um explorador (um esse outro criado).

   

   Agora um problema elevara. Cada lado determina que os 3174 estão anexados localmente, e cada roteador vê os 3174 localmente e remotamente.

   

7. Cada lado envia um cur frame ao SF1 e ao SF2, e cria um explorador para o host dos 3174.

   

8. Ambo o Roteadores (SF1 e SF2) copia o quadro outra vez, e vê que o host é local e telecontrole. DLSw agora quebra e entra em um laço.

   

A melhor coisa que você pode fazer nesta situação é certificar-se de que os aneis virtuais para o Roteadores são exatamente os mesmos em cada lado da nuvem:

Criação do laço: Cenário 2

O Roteadores em cada lado da nuvem é configurado com o mesmo número de anel virtual. Esta configuração assegura-se de que um roteador que envie um explorador já passe através do anel e, consequentemente, do roteador deixe cair o explorador. Quando o LA1 gerencie um explorador para um cur frame que o SF1 receba, o LA2 deixa cair o explorador, porque o explorador já passou através do anel 1. O Roteadores deve ter números de Bridge diferentes configurados, se é dirigido para o mesmo anel. Esse é o caso no lado LA dessa rede. Com Ethernet, você deve desabilitar um par:

Um pacote nos Ethernet não tem um RIF em si mesmo. Consequentemente, quando o outro roteador no LAN cria uma transmissão, o roteador não pode determinar se a transmissão é do outro roteador ou de uma estação de origem. No caso do Systems Network Architecture (SNA), o roteador não pode determinar se o pacote origina localmente ou remotamente. Os exploradores do Token Ring têm ambos os endereços MAC de origem e de destino. Consequentemente, tais exploradores não são realmente uma transmissão nos Ethernet. Um pouco, são enviados como um directed frame de uma estação a outra.

Considere esta sequência:

1. Os 3174 enviam um explorador ao host.

   

2. o SF1 e o SF2 aceitam o explorador.

   

3. Cada SF1 e SF2 gera um CUR para o outro lado, LA1 e LA2.

   

4. Estes CUR ambos gerenciem um explorador a que o host responde. Porque este é um explorador de rota única, todo o explorador das rotas responde.

   

5. o LA1 e o LA2 criam um cur frame ao SF1 e ao SF2, que cria este pacote para os 3174.

   

   O problema é que o SF1 ouve o MAC address do host dos Ethernet e determina que o host reside em seu próprio LAN local. Mas, no esconderijo SF1, o host parece responder de um peer remoto. Assim, o roteador tem o host definido como o local e o telecontrole.

   

   DLSw agora quebra e entra em um laço.

   

A fim fixar DLSw, você deve desabilitar um par ou usar os recursos de redundância de Ethernet. Refira o exemplo da configuração de redundância do DLSw Ethernet para mais informação.

Informações Relacionadas

• Troubleshooting de DLSw
• Página de suporte do Data-Link Switching (DLSw) e Data-Link Switching Plus (DLSw+)
• Página de suporte das Tecnologias IBM
• Suporte Técnico e Documentação - Cisco Systems