Este documento discute como pesquisar defeitos uma configuração do switching de link de dados (DLSw).
Não existem requisitos específicos para este documento.
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.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
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.
Esta seção endereça alguns problemas comuns e fornece pontas em como você pode pesquisar defeitos.
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.
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.
Esta é a rota de um explorador:
Os 3174 no anel 11 enviam um explorador para alcançar o host.
San Francisco 1 (SF1) e a ligação copiam o quadro.
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.
San Francisco 2 (SF2) recebe o pacote e repete a ação.
O LA1 e Los Angeles 2 (LA2) criam o explorador e enviam-no ao anel.
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.
Cada lado envia um cur frame ao SF1 e ao SF2, e cria um explorador para o host dos 3174.
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:
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:
Os 3174 enviam um explorador ao host.
o SF1 e o SF2 aceitam o explorador.
Cada SF1 e SF2 gera um CUR para o outro lado, LA1 e LA2.
Estes CUR ambos gerenciem um explorador a que o host responde. Porque este é um explorador de rota única, todo o explorador das rotas responde.
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.