Tecnologias IBM : Source-Route Translational Bridging (SR/TLB)

Entendendo e Troubleshooting do Source-Route Translational Bridging

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento descreve o Source-Route Translational Bridging (SR/TLB) e fornece a informação para pesquisá-la defeitos.

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

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Source-Route Translational Bridging

É comum para que os ambientes de Ethernet misturem com os ambientes de token ring em redes de hoje. Esta mistura traz um número de problemas lógicos. O primeiro é que o Ethernet não tem qualquer coisa perto da rota de origem que constrói uma ponte sobre, e o Token Ring tem um campo de informação de roteamento (RIF). Também, os Token Ring têm endereços funcionais, quando Ethernets tiver o mais frequentemente transmissões.

Para poder unir os dois ambientes, Cisco criou o SR/TLB.

Você pode adicionar grupos de bridge às relações do Roteadores (Token Ring e Ethernet), para construir uma ponte sobre transparentemente o Token Ring e os Ethernet. Isto cria um domínio do Transparent Bridge entre os dois ambientes. Se o lado de token ring é rota de origem running que constrói uma ponte sobre, haveria um problema. Como você amarra o Bridging transparente com o roteamento de origem, dado especialmente que as estações final são essas que estabelecem o trajeto através da rede?

Este diagrama ilustra a solução:

/image/gif/paws/12248/48a.gif

Quando pc_1 quer se comunicar com o pc_3, envia o name_query de NetBIOS com um pacote da transmissão (FF-FF-FF-FF-FF-FF) ao fio. O problema é que a estação pc_3 está escutando name_queries com um endereço de destino de (C0-00-00-00-00-80), e recebe essa transmissão e não a envia a NetBIOS porque não é um name_query (pela definição pc_3).

Eis porque a tradução do Token Ring aos Ethernet pode ser complicada. A maioria dos detalhes são segurados dentro do roteador, e uma edição que crie alguma confusão é bitswapping. O Token Ring e os Ethernet leram os bit no adaptador em maneiras diferentes. O roteador não entra no quadro e muda a ordem do bit, assim que os endereços MAC nos Ethernet são diferentes dos endereços MAC no Token Ring.

A estação de Ethernet não pode atuar como a estação final do origem roteado, consequentemente o roteador Cisco supõe esse papel. Baseado no diagrama precedente, estes eventos ocorrem depois que o roteador recebe o pacote dos Ethernet:

  1. O roteador cisco1 recebe um pacote dos Ethernet. Isto é de pc_1 ao host_1.

  2. cisco1 precisa um RIF de alcançar o host_1, assim que cria um explorador para determinar o trajeto alcançar o host_1.

  3. Depois que cisco1 recebe a resposta, envia a resposta (sem um RIF) à estação de Ethernet.

  4. pc_1 envia uma identificação de intercâmbio (XID) ao MAC address do host.

  5. cisco1 obtém o pacote de Ethernet, anexa o RIF ao host, e envia o pacote em sua maneira.

  6. Este processo continua.

Diversas circunstâncias tornam este processo possível. Primeiramente, tanto quanto o host, o Ethernet está sentando-se no que é sabido como um pseudo anel. Isto é 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
anel-grupo O grupo de chamada virtual que é criado pelo comando source-bridge ring-group. Este é o anel virtual de Bridge de origem a associar com o grupo de transparent bridge. Este número de grupo de anel deve combinar o número que é especificado com o comando source-bridge ring-group. O intervalo válido é 1 a 4095.
pseudo anel O número de anel que é usado para representar o domínio de Transparent Bridging ao Source-Route Bridged Domain. Este número deve ser um número exclusivo que não seja usado por nenhum outro anel no Source-Route Bridged Network.
número de bridges O número de Bridge da ponte que isso conduz ao domínio de Transparent Bridging, de um ponto de vista do origem roteado do Token Ring.
TB-grupo O número do grupo de transparent bridge que você quer amarrou no Source-Route Bridged Domain. Nenhum formulário deste comando desabilita esta característica.
oui (Opcional) o identificador exclusivo organizacional (OUI), que pode ter os valores que incluem estes:
  • 90-compatible
  • padrão
  • cisco

Quando você está configurando o SR/TLB, você deve primeiramente ter um grupo de anel no roteador. O pseudo anel fá-lo parecer que o Ethernet é Token Ring, do ponto de vista do host_1.

/image/gif/paws/12248/48b.gif

Configurar cisco1 desse modo:

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

Até à data do Software Release 11.2 do½ do¿Â do Cisco IOSïÂ, o SR/TLB é fast-switched. Mais cedo do que o Cisco IOS Software Release 11.2, o SR/TLB era comutado por processo. Para desligar o switching rápido, emita este comando:

no source-bridge transparent ring-group fastswitch

comandos show

Há dois comandos show que são importantes com SR/TLB.

  • ponte da mostra - Este comando é muito útil analisar o lado transparente. Mostra se o roteador está recebendo pacotes de um dispositivo específico na rede.

  • rif da mostra - Este comando mostra se o roteador construiu um RIF para o endereço MAC de destino.

Troubleshooting

Isto seciona discute como pesquisar defeitos o bitswapping do MAC address e os laços SR/TLB.

Permuta de bit

Uma da maioria de causas comum dos problemas com SR/TLB é bitswapping do MAC address. O problema ocorre porque o roteador faz um bitswap em endereços MAC dos Ethernet ao Token Ring e do Token Ring aos Ethernet. O resultado é que as estações final não podem reconhecer aqueles quadros. Este diagrama mostra um exemplo:

/image/gif/paws/12248/48c.gif

Neste diagrama, o quadro tem o exato o mesmo padrão de bit no MAC de origem (S AC) e no MAC de destino (DMAC). Este padrão de bit é lido diferentemente no Token Ring do que nos Ethernet, contudo. Para poder enviar dirigiu quadros através desta rede, você deve bitswap eles antes que estejam enviados.

A primeira coisa a fazer é converter o MAC address original ao binário. Você pode usar os três grupos 2-byte individualmente para facilitá-la. Este exemplo usa 4000.3745.0001.

4000.3745.0001 têm este valor binário:

0100 0000 0000 0000 0011 0111 0100 0101 0000 0000 0000 0001

Inverta cada byte. Não inverta a corda inteira. Este é o número binário separado em bytes:

01000000  00000000  00110111  01000101  00000000  00000001
   40        00        37        45        00        01

Para fazer o bitswap, mova o primeiro bit para o último em cada um dos bytes, e repita isto até que o último bit esteja primeiro:

00000010  00000000  11101100  10100010  00000000  10000000 
   02        00        EC        A2        00        80

Depois que o bitswapping é feito, você tem o MAC address novo, que é 0200.ECA2.0080.

O software para muitas estações de Ethernet do Systems Network Architecture (SNA) faz a troca automaticamente. Se você não sabe certamente, é o melhor testá-lo ambas as maneiras.

Nota: Às vezes as redes incluem endereços MAC “NON-bitswappable” para dispositivos amplamente utilizados, porque os endereços são os mesmos trocados ou NON-trocados. Isto significa que você não precisa de tratar a codificação do endereço remoto FEP. Isto é comum em ambientes do processador de front end (FEP) com muitos locais remotos. Por exemplo, 4200.0000.4242 são um endereço MAC sem permuta de bits.

Além, o roteador próprio - na parcela do Transparent Bridge - trata os endereços MAC como o formato Ethernet, e o origem roteado parte de que o código os trata como o formato do Token Ring. Nas encenações como o FDDI, onde os quadros são lidos exatamente o mesmos, o código de roteador mostra que o MAC endereça invertido toda.

Suporte a DHCP/BOOTP entre Token Ring e Ethernet

O DHCP/BOOTP não está apoiado quando você está usando o SR/TLB ou o transparent bridging (TB) e o server e o cliente estão no tipo de mídia diferente LAN (canônico ou não-canônico). Por exemplo, se o cliente está em um LAN de token ring e no server em um LAN de Ethernet. Isto é porque o cliente inclui seu MAC address no pacote de pedido do BOOTP (campo do chaddr).

Por exemplo, quando um cliente com MAC address 4000.1111.0000 envia um pedido do BOOTP e o pacote atravessa a ponte SR/TLB ou TB, os endereços MAC no cabeçalho de MAC são bitswapping, mas os endereços MAC encaixados no pedido do BOOTP são deixados inalterados. Consequentemente, o pacote BOOTP obtém ao server, e o server responde com uma resposta de BOOTP (inicialização). Esta resposta de BOOTP (inicialização) é enviada ao endereço de broadcast ou ao MAC address do cliente, segundo o flag de transmissão. Caso este flag de transmissão não for ajustado, o server envia um pacote do unicast ao MAC address que é especificado no campo do chaddr. O server no lado de Ethernet envia a resposta ao MAC address 4000.1111.0000. O pacote atravessa a ponte e os bitswaps da ponte o MAC address. Assim, a resposta de BOOTP (inicialização) no lado de token ring termina acima com um endereço MAC de destino de 0200.8888.0000. Consequentemente, o cliente não reconhecerá este quadro.

Circuitos

Uma outra causa de problemas SR/TLB é que você não pode permitir o roteador usar trajetos diferentes aos mesmos Ethernet.

Este diagrama contém um semi-laço:

48d.gif

Porque o pacote origina do mesmo pseudo anel e está no mesmo grupo de anel, os pacotes que estão vindo do ambiente de token ring são enviados aos Ethernet. Isto faz com que o segundo roteador SR/TLB acredite que um determinado MAC address está ficado situado em seus Ethernet locais. Assim, uma estação nos Ethernet não pode alcançar essa estação outra vez.

Também, cisco1 tomará esse mesmo pacote e enviará um explorador à rede, que pode fazer essa estação parecer como se está nos Ethernet (quando está no ambiente de token ring).

Este diagrama ilustra um cenário comum:

48e.gif

Neste caso, toma somente um pacote para criar um laço enorme. Porque o pacote não será deixado cair pelo lado de Ethernet ou pelo lado de token ring, o pacote irá infinitamente em um teste padrão dado laços.

Depuração

A eliminação de erros para o SR/TLB é muito limitada. Uma opção é debugar o Token Ring, com filtros, para considerar se os pacotes o estão fazendo através do roteador. Refira a compreensão e pesquisando defeitos o Local Source-Route Bridging para mais informação.


Informações Relacionadas


Document ID: 12248