Configurando a switching de enlace de dados e a conversão de endereços de rede

Opções de download

PDF (98.8 KB)
Ver no Adobe Reader em vários dispositivos
ePub (100.4 KB)
Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
Mobi (Kindle) (101.9 KB)
Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos

Atualizado:9 de setembro de 2005

ID do documento:12344

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introduction

Prerequisites

Requirements

Componentes Utilizados

Conventions

Informações de Apoio

Problema

Soluções

Solução 1

Solução 2

Informações Relacionadas

Introduction

Este documento descreve a solução para um cenário de switching de enlace de dados (DLSw) usando NAT (tradução de endereço de rede) (com base nesta ilustração) que envolve auto-desconexão de peers sem razão aparente.

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

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Informações de Apoio

As depurações nos roteadores A e C mostram que a conexão passa do CAP_EXG e alcança o estado CONNECT. A implementação Cisco de DLSw especifica isso, em vez de usar duas sessões TCP entre o roteador A e o roteador C, uma conexão TCP é liberada quando uma conexão é estabelecida entre os dois roteadores.

A conexão TCP que é descartada é determinada pela seção 7.6.7 do RFC 1795 :

"O vetor de controle de conexões TCP indica o suporte de um número alternativo de conexões TCP para o tráfego de switching de enlace de dados. A implementação básica de Data Link Switching suporta duas conexões TCP, uma para cada direção do tráfego de dados.

Esse vetor de controle é opcional. Se ele for omitido em um intercâmbio de capacidades de DLSw, duas conexões de TCP são assumidas. Supõe-se ainda que se um Data Link Switching pode suportar uma conexão TCP, ele pode suportar duas conexões TCP.

Se os valores CV das conexões TCP concordarem e o número de conexões for um, o DLSw com o endereço IP mais alto deverá destruir as conexões TCP na porta local 2065."

Problema

Os pares DLSw mais (DLSw+) estabelecem uma conexão entre os roteadores A e C, mas não permanecem conectados.

O roteador A acha que sua sessão TCP DLSw está entre si (123.112.5.10) e 123.112.1.19, que é o endereço IP do roteador C depois de passar pelo NAT. O roteador A conclui que tem o endereço IP mais alto e, portanto, acha que deve desconectar a conexão TCP de sua porta local 2065.

O Roteador C pensa que a sessão DLSw TCP é entre ele mesmo (172.10.1.1) e 123.112.5.10. O Roteador C acha que tem o endereço IP mais alto e que deve destruir a conexão TCP na porta local 2065.

Como conseqüência, as duas sessões de TCP foram destruídas, deixando os roteadores no estado DISCONNECT (DESCONECTAR).

Soluções

Solução 1

Altere o NAT para converter 172.10.1.1 em 123.112.6.1, evitando assim confusão sobre qual endereço IP é maior.

Solução 2

Use a nova opção de configuração v2-single-tcp nas configurações do comando dlsw peer. Este recurso foi introduzido com o bug da Cisco ID CSCeb47150 (somente clientes registrados) e integrado nas versões 12.3(04.04)B, 12.2(19.04)S, 12.3(03.03)T, 012 003(003.003), 12.3(03.02)T e 12.002(018.002).

O DLSw versão 2, RFC 2166 , define o peer de ligação TCP DLSw com uma única sessão TCP. Com isso, o problema descrito acima não existe mais, pois há apenas uma sessão TCP e não faz diferença qual extremidade tem o endereço IP numericamente mais alto ou mais baixo.

A palavra-chave v2-single-tcp instrui esse roteador a ativar um peer DLSw versão 2 e, por isso, ambos os roteadores usam automaticamente apenas uma sessão TCP para estabelecer o peer.

O uso da nova palavra-chave deve ser semelhante a este para a topologia descrita neste documento:

O roteador C da filial tenta estabelecer um peer DLSw para o roteador A do data center. O Roteador A de Data Center está executando o Cisco IOS Software versão 12.0 ou posterior, que já suporta DLSw versão 2. A configuração do comando dlsw local-peer no Roteador A do data center é promissora, para permitir qualquer conexão de peer de entrada ou, se você tiver que configurar cada conexão individualmente, o Roteador C de peer para filial está configurado para ser passivo.

O Roteador da Filial C é configurado nesse comando dlsw remote-peer com a nova palavra-chave v2-single-tcp, que inicia um peer da versão 2 para o Roteador A do data center central: