Este documento descreve o Source-Route Translational Bridging (SR/TLB) e fornece informações para solucionar problemas.
Não existem requisitos específicos para este documento.
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.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
É comum que os ambientes Ethernet se misturem com os ambientes Token Ring nas redes atuais. Esta combinação traz vários problemas lógicos. A primeira é que a Ethernet não tem nada próximo ao Source-Route Bridging e a Token Ring tem um Campo de Informações de Roteamento (RIF - Routing Information Field). Além disso, os Token Rings têm endereços funcionais, enquanto as Ethernets têm mais frequentemente broadcasts.
Para unir os dois ambientes, a Cisco criou o SR/TLB.
Você pode adicionar grupos de bridge às interfaces dos roteadores (Token Ring e Ethernet), para fazer a ponte transparente entre Token Ring e Ethernet. Isso cria um domínio de bridge transparente entre os dois ambientes. Se o lado Token Ring estiver executando o Source-Route Bridging, haverá um problema. Como você conecta o bridging transparente ao roteamento de origem, especialmente considerando que as estações finais são as que estabelecem o caminho através da rede?
Este diagrama ilustra a solução:
Quando o pc_1 quer se comunicar com o pc_3, ele envia o nome_query do NetBIOS com um pacote de broadcast (FF-FF-FF-FF-FF) para o cabo. O problema é que a estação pc_3 está ouvindo name_queries com um endereço de destino (C0-00-00-00-00-80), e recebe esse broadcast e não o envia para o NetBIOS porque não é um name_query (pela definição do pc_3).
É por isso que a tradução de Token Ring para Ethernet pode ser complicada. A maioria dos detalhes é tratada dentro do roteador, e um problema que cria alguma confusão é a troca de bits. Token Ring e Ethernet leem os bits no adaptador de maneiras diferentes. O roteador não entra no quadro e muda a ordem dos bits, de modo que os endereços MAC na Ethernet são diferentes dos endereços MAC na Token Ring.
A estação Ethernet não pode atuar como a estação final roteada de origem, portanto, o roteador Cisco assume essa função. Com base no diagrama anterior, esses eventos ocorrem depois que o roteador recebe o pacote da Ethernet:
O roteador cisco1 recebe um pacote da Ethernet. Isto é do pc_1 ao host_1.
cisco1 precisa de um RIF para acessar host_1, portanto, cria um explorador para determinar o caminho para alcançar host_1.
Depois que cisco1 recebe a resposta, ele envia a resposta (sem RIF) para a estação Ethernet.
o pc_1 envia uma identificação de troca (XID) para o endereço MAC do host.
o cisco1 recebe o pacote Ethernet, conecta o RIF ao host e envia o pacote no caminho.
Esse processo continua.
Várias condições tornam esse processo possível. Primeiro, no que diz respeito ao host, a Ethernet está sentada no que é conhecido como pseudo-anel. Isso é configurado com o comando source-bridge transparent no roteador:
source-bridge transparent ring-group pseudo-ring bridge-number tb-group [oui]
Parâmetro | Descrição |
---|---|
ring-group | O grupo de anel virtual criado pelo comando source-bridge ring-group. Este é o anel virtual source-bridge a ser associado ao grupo de bridge transparente. Esse número de grupo de toque deve corresponder ao número especificado com o comando source-bridge ring-group. O intervalo válido é de 1 a 4095. |
pseudo-anel | O número de anel usado para representar o domínio de bridging transparente ao domínio de bridging de rota de origem. Esse número deve ser um número exclusivo que não é usado por nenhum outro anel na rede de ligação de rota de origem. |
bridge-number | O número da bridge que leva ao domínio de bridging transparente, do ponto de vista roteado pela origem Token Ring. |
tb-group | O número do grupo de bridge transparente que você deseja vincular ao domínio de bridge de rota de origem. A forma no deste comando desativa esta funcionalidade. |
oui | (Opcional) O identificador único organizacional (OUI), que pode ter valores que incluem estes:
|
Ao configurar o SR/TLB, você deve primeiro ter um grupo de anéis no roteador. O pseudo-anel faz parecer que a Ethernet é Token Ring, do ponto de vista host_1.
Configure cisco1 desta maneira:
cisco1 |
---|
source-bridge ring-group 10 source-bridge transparent 10 11 1 1 ! interface tokenring 0 source-bridge 1 1 10 source-bridge spanning ! interface Ethernet 0 bridge-group 1 ! bridge 1 protocol ieee |
A partir do Cisco IOS® Software Release 11.2, SR/TLB é fast-switched. Antes do Cisco IOS Software Release 11.2, o SR/TLB era comutado por processo. Para desativar a switching rápida, emita este comando:
no source-bridge transparent ring-group fastswitch
Há dois comandos show que são importantes para SR/TLB.
show bridge - Este comando é muito útil para analisar o lado transparente. Mostra se o roteador está recebendo pacotes de um dispositivo específico na rede.
show rif - Este comando mostra se o roteador criou um RIF para o endereço MAC de destino.
Estas seções discutem como solucionar problemas de bitswapping de endereço MAC e loops SR/TLB.
Uma das causas mais comuns de problemas com SR/TLB é a troca de bits de endereço MAC. O problema ocorre porque o roteador faz uma troca de bits em endereços MAC da Ethernet para a Token Ring e da Token Ring para a Ethernet. O resultado é que as estações finais não são capazes de reconhecer esses quadros. Este diagrama mostra um exemplo:
Neste diagrama, o quadro tem exatamente o mesmo padrão de bits no MAC de origem (SMAC) e no MAC de destino (DMAC). Entretanto, esse padrão de bit é lido de forma diferente no Token Ring do que na Ethernet. Para poder enviar quadros direcionados através dessa rede, você deve trocá-los em bits antes de enviá-los.
A primeira coisa a fazer é converter o endereço MAC original em binário. Você pode usar os três conjuntos de 2 bytes individualmente para facilitar isso. Este exemplo usa 4000.3745.0001.
4000.3745.0001 tem este valor binário:
0100 0000 0000 0000 0011 0111 0100 0101 0000 0000 0000 0001
Inverta cada byte. Não inverta a string inteira. Este é o número binário separado em bytes:
01000000 00000000 00110111 01000101 00000000 00000001 40 00 37 45 00 01
Para fazer a troca de bits, mova o primeiro bit para o último em cada um dos bytes e repita isso até que o último bit seja o primeiro:
00000010 00000000 11101100 10100010 00000000 10000000 02 00 EC A2 00 80
Depois que a troca de bits for feita, você terá o novo endereço MAC, que é 0200.ECA2.0080.
O software para muitas estações Ethernet SNA (Systems Network Architecture) faz a troca automaticamente. Se você não sabe ao certo, é melhor testá-lo de ambos os modos.
Observação: às vezes, as redes incluem endereços MAC "não intercambiáveis por bits" para dispositivos amplamente usados, pois os endereços são os mesmos trocados ou não. Isso significa que você não precisa lidar com a codificação do endereço FEP remoto. Isso é comum em ambientes de processador de front-end (FEP) com muitos locais remotos. Por exemplo, 4200.0000.4242 é um endereço MAC não substituível por bits.
Além disso, o próprio roteador - na parte da ponte transparente - trata os endereços MAC como formato Ethernet, e a parte roteada pela origem do código os trata como formato Token Ring. Em cenários como o FDDI, em que os quadros são lidos exatamente da mesma forma, o código do roteador mostra os endereços MAC invertidos.
O DHCP/BOOTP não é suportado quando você está usando SR/TLB ou Transparent Bridging (TB) e o servidor e o cliente estão em LANs de tipo de mídia diferente (canônica ou não canônica). Por exemplo, se o cliente estiver em uma LAN Token Ring e o servidor em uma LAN Ethernet. Isso ocorre porque o cliente inclui seu endereço MAC no pacote de solicitação BOOTP (campo chaddr).
Por exemplo, quando um cliente com endereço MAC 4000.1111.0000 envia uma solicitação BOOTP e o pacote passa pela ponte SR/TLB ou TB, os endereços MAC no cabeçalho MAC são trocados por bits, mas os endereços MAC incorporados na solicitação BOOTP permanecem inalterados. Consequentemente, o pacote BOOTP chega ao servidor e o servidor responde com uma resposta BOOTP. Essa resposta BOOTP é enviada ao endereço de broadcast ou ao endereço MAC do cliente, dependendo do flag de broadcast. Caso esse sinalizador de broadcast não esteja definido, o servidor envia um pacote unicast ao endereço MAC especificado no campo chaddr. O servidor no lado Ethernet envia a resposta ao endereço MAC 4000.1111.0000. O pacote passa pela bridge e a bridge troca de bits pelo endereço MAC. Assim, a resposta BOOTP no lado Token Ring termina com um endereço MAC de destino 0200.8888.0000. Consequentemente, o cliente não reconhecerá esse quadro.
Outra causa dos problemas de SR/TLB é que você não pode permitir que o roteador use caminhos diferentes para a mesma Ethernet.
Este diagrama contém um semiloop:
Como o pacote é originado do mesmo pseudo-anel e está no mesmo grupo de anéis, os pacotes que vêm do ambiente Token Ring são enviados para a Ethernet. Isso faz com que o segundo roteador SR/TLB acredite que um determinado endereço MAC está localizado em sua Ethernet local. Portanto, uma estação na Ethernet não pode alcançar aquela estação novamente.
Além disso, o cisco1 pegará o mesmo pacote e enviará um explorador à rede, o que pode fazer com que a estação apareça como se estivesse na Ethernet (quando estiver no ambiente Token Ring).
Este diagrama ilustra um cenário comum:
Nesse caso, é necessário apenas um pacote para criar um loop enorme. Como o pacote não será descartado pelo lado Ethernet ou pelo lado Token Ring, o pacote permanecerá infinitamente em um padrão em loop.
A depuração para SR/TLB é muito limitada. Uma opção é depurar o Token Ring, com filtros, para ver se os pacotes estão passando pelo roteador. Consulte Entendendo e Troubleshooting Local Source-Route Bridging para obter mais informações.