Solução de problemas de configuração de DLSw
Contents
Introduction
Este documento discute como solucionar problemas de uma configuração de DLSw (Data-Link Switching).
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.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
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 peers não se conectarem, verifique se há conectividade IP entre os dois roteadores. Em caso afirmativo, verifique se você tem as instruções de peer DLSw apropriadas em vigor nos roteadores local e remoto. Consulte Configurações Básicas de DLSw+ e Troubleshooting de Conectividade IP DLSw para obter mais informações. Se não houver instruções remotas, use a palavra-chave promíscua na instrução local peer em uma extremidade. Consulte Comandos de Configuração DLSw+ para obter mais informações.
Topologia de rede
Esta seção aborda alguns problemas comuns e fornece dicas sobre como solucionar problemas.
Circuitos
Lembre-se de que a terminação do Campo de Informações de Roteamento (RIF) é um aspecto importante do DLSw. O RIF causa grandes problemas através da fácil criação de loops na rede.
Topologia de rede
Aqui está um exemplo de topologia que rastreia a criação de um loop.
O DLSw encerra o RIF e o pacote fica circulando continuamente. Cada vez que um quadro CANUREACH (CUR) é enviado de peer para peer, o peer do destinatário cria um novo explorador (SEM RIF) e o envia.
Criação de loop: Cenário 1
Esta é a rota de um explorador:
-
O 3174 no anel 11 envia um explorador para acessar o host.
-
San Francisco 1 (SF1) e a ligação copiam o quadro.
-
SF1 cria um quadro CUR para Los Angeles 1 (LA1), que é o peer, que diz a LA1 que o 3174 quer alcançar o host.
-
São Francisco 2 (SF2) recebe o pacote e repete a ação.
-
LA1 e Los Angeles 2 (LA2) criam o explorador e o enviam ao anel.
-
LA1 e LA2 recebem cada um um um explorador (um que o outro criou).
Agora surge um problema. Cada lado determina que o 3174 está conectado localmente e cada roteador visualiza o 3174 tanto local quanto remotamente.
-
Cada lado envia um quadro CUR para SF1 e SF2 e cria um explorador para o host do 3174.
-
Ambos os roteadores (SF1 e SF2) copiam o quadro novamente e verificam se o host é local e remoto. O DLSw agora se divide e entra em um loop.
O melhor que você pode fazer nessa situação é garantir que os anéis virtuais dos roteadores sejam exatamente os mesmos em cada lado da nuvem:
Criação de loop: Cenário 2
Os roteadores em cada lado da nuvem são configurados com o mesmo número de anel virtual. Essa configuração garante que um roteador que envia um explorador já tenha passado pelo anel e, portanto, o roteador descarta o explorador. Quando o LA1 gera um explorador para um quadro CUR recebido pelo SF1, o LA2 descarta o explorador, porque o explorador já passou pelo anel 1. Os roteadores devem ter números de bridge diferentes configurados, se forem direcionados para o mesmo anel. Esse é o caso no lado LA dessa rede. Com a Ethernet, você deve desativar um peer:
Um pacote na Ethernet não tem um RIF em si. Portanto, quando o outro roteador na LAN cria um broadcast, o roteador não pode determinar se o broadcast é do outro roteador ou de uma estação de origem. No caso da Arquitetura de Rede de Sistemas (SNA - Systems Network Architecture), o roteador não pode determinar se o pacote é originado local ou remotamente. Os exploradores do Token Ring têm endereços MAC origem e destino. Portanto, esses exploradores não são realmente um broadcast na Ethernet. Em vez disso, eles são enviados como um quadro direcionado de uma estação para outra.
Considere esta sequência:
-
O 3174 envia um explorador ao host.
-
SF1 e SF2 aceitam o explorador.
-
Cada SF1 e SF2 gera um CUR para o outro lado, LA1 e LA2.
-
Esses CURs geram um explorador ao qual o host responde. Como esse é um explorador de rota única, um explorador de todas as rotas responde.
-
Tanto LA1 como LA2 criam um quadro CUR para SF1 e SF2, o que cria esse pacote para o 3174.
O problema é que SF1 ouve o endereço MAC do host a partir da Ethernet e determina se o host reside em sua própria LAN local. Mas, no cache SF1, o host parece responder de um peer remoto. Assim, o roteador tem o host definido como local e remoto.
O DLSw agora se divide e entra em um loop.
Para corrigir o DLSw, você deve desativar um peer ou usar o recurso de redundância Ethernet. Consulte Exemplo de Configuração de Redundância de Ethernet DLSw para obter mais informações.
Feedback