Asynchronous Transfer Mode (ATM) : LAN Emulation (LANE)

Recomendações de projeto LANE

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


Índice


Introdução

Este documento fornece diretrizes de design de rede práticas do LAN Emulation (LANE). Estas diretrizes ajudar-lhe-ão no projeto do alto desempenho, escalável, e das redes lane de alta disponibilidade. Quando este documento focalizar no equipamento da Cisco, os mesmos conceitos podem ser aplicados ao integrar produtos de terceira parte.

Antes de Começar

Convenções

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

Pré-requisitos

Os leitores deste documento devem ser conhecedors das operações básicas e das configurações das redes de pista.

Componentes Utilizados

Este documento centra-se sobre configurações de Ethernet lane.

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 você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Compreendendo requisitos do servidor

Os vários servidores LANE e suas exigências são apresentados abaixo.

O servidor de configuração de simulação de LAN (LECS)

O LAN Emulation sobre a especificação da Versão do ATM 1.0leavingcisco.com exige que cada cliente de LAN Emulation (LEC) estabelece um virtual circuit (VC) ao servidor de configuração de LAN Emulation (LECS) quando vai acima. O LEC pede então o endereço ATM de seu servidor de LAN Emulation correspondente (LES). Uma vez que o LEC tem seu endereço ATM LES, o VC entre o LEC e o LECS está removido, e o LEC já não tenta comunicar-se com o LECS. Quando o ambiente é estável e todos os LEC são ascendentes e operacionais, o LECS é inativo.

Quando os LEC se juntarem à LAN simulada (ELAN), eles cada contato o LECS individualmente. Contudo, quando a rede de pista se submete a um desastre (por exemplo, quando o lecs principal falha), todos os clientes vão para baixo.

Nota: A exceção a esta é quando o protocolo fast simple server redundancy (FSSRP) é usado.

Desde que todos os LEC vão para baixo ao mesmo tempo, todo o contato o lecs de backup ao mesmo tempo. Consequentemente, para hospedar o LECS, você precisa um dispositivo isso:

  • pode segurar um estouro de tráfego repentino dirigido a nível de processo.

  • pode aceitar quase todas as instalações de chamada recebida dos LEC simultaneamente.

  • é sabido para sua estabilidade. Se o LECS vai para baixo, a rede inteira vai para baixo (outra vez, à excecpção do FSSRP). Consequentemente, pôr o LECS sobre um dispositivo que executa uma versão de software experimental não é recomendada.

O Servidor de Simulação de LAN (LES)

Cada LEC manterá um VC bidirecional ao LES do ELAN (pode ser mais de um ELAN se o FSSRP é usado). Em um ambiente típico altamente carregado, muitos pedidos do protocolo lan emulation address resolution (LE_ARP) serão enviados ao LES. A aplicação do LES em dispositivos Cisco é bastante direta. Todos os quadros entrantes LE_ARP serão enviados ao controle distribuem a conexão de canal virtual (VCC).

Você não pode executar uma replicação simples de célula de hardware do controle direto para controlar distribui desde que alguns quadros (tais como os pedidos da junta) têm que ser analisados pelo processo de LES. Consequentemente, um dispositivo que possa atuar como um bom LES é um dispositivo isso:

  • tem um CPU potente e pode aceitar muitas configurações de chamada em uma quantidade de tempo curta. Isto é necessário quando muitos clientes se juntam ao ELAN ao mesmo tempo, mas menos vital do que para o LECS, desde que somente os LEC no ELAN têm que se juntar.

  • tem o suporte a hardware forte do Segmentation And Reassembly (SAR). Como todas as células recebidas têm que ser remontadas em quadros, se muito se junte os pedidos chegam ao mesmo tempo, eles terão que ser remontados muito rapidamente.

Recorde que na aplicação de Cisco, o LES e os processos da transmissão e servidor desconhecido (BARRAMENTO) estão combinados (isto é, você não pode pôr o LES para o ELAN-1 sobre um dispositivo, e o BARRAMENTO para o ELAN-1 em um outro dispositivo).

Uma outra coisa a manter-se na mente é comportamento preemptivo possível. Se a prioridade de compra é permitida, o LES/BUS com a prioridade mais alta (de acordo com a base de dados de LAN) tomará sempre sobre o dever do les/barramento principal. Ou seja se o les/barramento principal falha, todos os LEC do ELAN irã0 para baixo e reconectarão ao les/barramento de backup. Se o PRE-emptivity é configurado, deve o les/barramento principal ir acima outra vez, todos os LEC irã0 para baixo uma vez mais e reconectarão ao LES/BUS com a prioridade mais alta. No Software Release 3.2.8 e Mais Recente do módulo LANE, e no Software Release 11.3(4) e Mais Recente de Cisco IOS�, os recursos de pre-emptivity podem ser desligados sobre e. Os recursos de pre-emptivity podem ser configurados como descrito em configurar a documentação do LAN Emulation.

O servidor de broadcast e desconhecido

O trabalho do BARRAMENTO é bastante similar ao trabalho do LES. Cada LEC é exigido para mandar um Multicast enviar ao BARRAMENTO. O LEC envia-lhe todo seu Multicast, transmissão ou tráfego desconhecido. O BARRAMENTO tem um ponto a multiponto VCC a todos os LEC no ELAN. Os quadros não têm que ser examinados em detalhe pelo BARRAMENTO. Ou seja cada frame de entrada no Multicast envia pode cegamente ser enviado ao Multicast para a frente.

Um bom dispositivo do BARRAMENTO:

  • tem o suporte a hardware para a cópia do quadro do Multicast entrante enviado ao Multicast que parte para a frente. Se você tem o hardware “esperto”, esta operação de cópia pode ser feita antes da remontagem. Isto significa que as células recebidas no Multicast enviam estão enviadas no Multicast para a frente. Isto salvar um Segmentation And Reassembly pelo quadro.

  • exige um CPU forte se não há nenhum suporte a hardware para o BARRAMENTO.

  • deve poder processar ao mesmo tempo muitas configurações de chamada, mas com um limite mais baixo do que o LECS.

Tabela 1: Desempenho de barramento pelo dispositivo

Dispositivo Ritmo de transferência de barramento (kpps)
Módulo do Catalyst 6K LANE/MPOA (OC-12) 600
Módulo do Catalyst 5K LANE/MPOA (OC-12) 600
Módulo do Catalyst 5K LANE/MPOA (OC-3) 166
Módulo LANE do Catalyst 5K (OC-3) 122
RSP4 - VIP-2-50+PA-A1 92
RSP4 - VIP-2-500+PA-A3 84
RSP4 - VIP-2-40+PA-A3 78
RSP4 - VIP-2-40+PA-A1 77
4700 40
LS1010 30

Entendendo os recursos do dispositivo Cisco

Esta seção cobre as capacidades dos dispositivos Cisco os mais comuns usados para executar o LEC, o LECS, o LES, e o BARRAMENTO. Estes dispositivos são os módulos LANE de Cisco, o LightStream 1010, o Catalyst 8510MSR e os 8540MSR, e os 7500/RSP. Suas capacidades são comparadas contra as exigências alistadas acima.

Módulos LANE

A arquitetura de todos os módulos LANE para o catalizador 5000 e 6000 é baseada aproximadamente no seguinte visualização de alto nível:

/image/gif/paws/10459/LANEdesign.gif

O Segmentation And Reassembly é executado pelo hardware. A microplaqueta SAR é um tanto inteligente, e pode diretamente enviar os frames remontados ao barramento do quadro do catalizador (a placa mãe do Catalyst). Para frames de controle, a microplaqueta SAR pode enviar os quadros ao CPU do módulo LANE. Um frame de controle é todo o quadro que tiver que ser analisado (por exemplo, Interim Local Management Interface (ILMI), sinalização, e quadros destinados ao LES), vindo ao módulo LANE através de um VC especificado.

A microplaqueta SAR pode igualmente reorientar as pilhas que vêm no Multicast envia ao Multicast para a frente (isto é, Multicast, transmissão, e as pilhas desconhecidas que vêm dos LEC). As pilhas não são remontadas em quadros. Sua facilidade da aplicação conduz ao desempenho de barramento muito bom.

Uma vez que uns “dados dirigem” e uma entrada na tabela de memória de conteúdo endereçável (CAM) esteve criada, os frames remontados estão enviados diretamente ao BARRAMENTO do quadro e etiquetados com o LAN virtual (VLAN) correto ID. Um módulo LANE faz um LEC muito bom porque uma vez que os “dados diretos” foram estabelecidos, o CPU é envolvido já não.

LightStream 1010 e Catalyst 8510MSR

O LS1010 e o Catalyst 8510MSR não têm o suporte a hardware para o SAR. Consequentemente, aqueles dispositivos são escolhas ruim para executar funcionalidades LES/BUS. São, contudo, apropriados para o LECS (refira o exemplo de design 2 abaixo).

8540MSR

O 8540MSR tem o suporte a hardware para o SAR. Igualmente tem um processador poderoso Risc 5000. 8540MSR não é recomendado apoiar por duas razões o LES/BUS:

  • O desempenho de barramento é em torno de 50Kpps para 64 pacotes de bytes, distante abaixo de todo o módulo LANE. Isto é porque não há nenhuma aceleração de hardware para o BARRAMENTO.

  • Se o 8540MSR é usado com ATM e placas do Ethernet, o CPU pode ser usado primeiramente para falar com placas de linha dos Ethernet. Neste caso, o 8540MSR's CPU não deve ser usado como um LES.

Plataformas de roteador

O roteador o mais de uso geral para o roteamento inter-ELAN é a plataforma do Cisco 7500 (o módulo de switch de rota (RS) e o Cisco 7200 são igualmente amplamente utilizados). O adaptador de porta contém a microplaqueta do hardware SAR. A rota/processadores de switch (RSP) como o RSP4 tem bastante potência de CPU processar muito rapidamente frames de entrada; consequentemente, são uma boa escolha para o LES. O desempenho de barramento, contudo, está abaixo isso dos módulos LANE.

Exemplo de projeto

O LANE é usado principalmente em grande e em redes crítica. Como tal, a Redundância é imperativa. O Simple Server Redundancy Protocol (SSRP) é o protocolo de redundância o mais amplamente utilizado. Se o software é recente, o FSSRP é o protocolo de preferência (refira a diretriz #11).

Deixe-nos supor-nos têm razoavelmente uma rede grande, por exemplo 100 VLAN/ELAN e 100 catalizadores, cada um com um módulo LANE duplo do uplink. Isto significa que em cada módulo LANE, nós pudemos precisar um LEC pelo ELAN, neste caso 10,000 LEC. Além, nós supomos que o IP está usado, e que o projeto inclui um C da classe do cofre forte (254 endereços do Host IP, 254 endereços MAC) pelo VLAN.

Projeto 1: Simples, mas para ser evitado…

Neste projeto, um módulo LANE foi escolhido executar os 100 server LES/BUS. Ao mesmo tempo, o lecs principal está no mesmo módulo LANE. Isto é ilustrado no desenho abaixo:

LANEdesign1.gif

Ao criar os LEC no módulo LANE, todos os LEC vão acima assim que forem configurados. Durante a operação, o processo de LES pôde tornar-se sobrecarregado, e o módulo LANE será executado fora da memória. O projeto 2 abaixo resolve ambos estes problemas.

A questão principal nesta rede é quando um problema principal ocorre. Supõe que o módulo LANE que hospeda o LECS, o LES, ou o BARRAMENTO se torna inacessível. Isto pôde acontecer, por exemplo, se o módulo LANE do catalizador 1 se torna defeituoso. Você pode ver a Redundância ocorrer, mas o tempo de redundância (isto é, o tempo entre o lecs principal, LES, ou falha de barramento, e o último LEC que se torna operacional outra vez) pôde durar até duas horas! Um bom projeto pôde derrubar este número a algumas dúzias dos segundos, ou dos alguns minutos nas redes grandes.

O problema encontra-se na sinalização envolvida com os LEC que juntam-se ao ELAN. Se o LECS deve ser contactado por cada LEC, receberá 10,000 configurações de chamada (100 módulos LANE com os 100 LEC em cada um) quase simultaneamente. O módulo LANE é projetado construir uma ponte sobre eficientemente entre o barramento do quadro e o link da pilha, mas não segurar por segundo muitas configurações de chamada. O CPU do módulo LANE não é poderoso bastante segurar este volume de configurações de chamada. A seguinte saída ilustra o tempo de redundância em uma rede de pista com os appproximately 1600 LEC (somente o comando show processes cpu é indicado parte de):

ATM#show processes cpu

CPU utilization for five seconds: 99%/0%; one minute: 98%; five minutes: 69%

 PID  Runtime(ms)  Invoked   uSecs     5Sec     1Min    5Min   TTY      Process

<snip>
 7       13396       207   64714   16.55%   10.85%   3.77%     0      ATM ILMI Input 
 8       13600       188   72340   13.45%   10.54%   3.72%     0      ILMI Process 

<snip>
35      107892       553  195103   68.94%   55.34%  26.72%     0      ATMSIG Input 
36       34408      1125   30584   12.29%    9.45%   6.63%     0      ATMSIG Output 

<snip>

Como você pode ver, o módulo LANE é utilizado devido à atividade de sinalização recebida. Que esclarece o tempo de redundância de duas horas? A resposta encontra-se na noção do intervalo. As especificações de sinalização mencionam claramente que se o dispositivo não recebe uma mensagem do " conectar " para trás após uma quantidade de tempo especificada quando uma “configuração de chamada” está enviada, deve começar sobre. As especificações de pista exigem que o LEC deve ir para trás a seu estado inicial, e começam-no mais uma vez. Isto significa que se um LEC pode contactar o LECS e o obter conectado a ele, sua configuração de chamada ao LES pôde intervalo, e vai para trás a seu estado inicial da tentativa contactar o LECS! Isto pode igualmente acontecer com conexões do LES, e desde/até o BARRAMENTO.

São baseadas nas explicações acima, aqui algumas recomendações do design básico:

  • Tente espalhar o LES/BUS para os ELAN diferentes nos vários dispositivos que podem o executar eficientemente. Idealmente, um les/barramento principal em cada módulo LANE, com seguintes que suportam os primeiros. Na prática, isto geraria um banco de dados LECS muito longo. A experiência mostra que os server 10 LES/BUS pelo módulo LANE parecem ser um número seguro.

  • Tente não pôr o LECS no mesmo lugar que outros server importantes LES/BUS. Igualmente a tentativa para pôr o LECS sobre um dispositivo com suficiente potência de CPU assim que ela pode segurar a informação de sinalização eficientemente. O LECS deve estar em um roteador (o Cisco 7200 ou os 7500 são recomendados, idealmente sem LES/BUS), ou em um switch ATM.

  • O IP de suposição e uma escala do C da classe são usados para cada VLAN, aproximadamente 250 endereços MAC são um bom número para a operação de LES. Para 10 LES em um módulo LANE, isto significa o CPU de um módulo LANE para um máximo de 2500 endereços MAC. Tenha que há uns números não fixos e oficiais, mas esta é um cofre forte e uma estimativa conservadora. Por outro lado, 200 LES/BUS em um módulo LANE, com cada ELAN que contém 1000 estações final, são seguros enquanto as sobras da estação rodam em marcha lenta praticamente (refira a diretriz #3 para mais detalhes).

Projeto 2: Mais complexo, mas mais seguro e mais eficiente…

Neste projeto, nós pusemos o LECS sobre o switch ATM. Nós espalhamos o LES/BUS nos módulos LANE diferentes. Os valores altos do processo CPU não são considerados em nenhuns módulos LANE, e a Redundância é normal.

LANEdesign2.gif

Diretrizes

As diretrizes apresentadas abaixo são recomendações prática somente, com base nas redes de pista da distribuição de produção. Quando os exemplos das redes bem sucedidas que excedem as recomendações existirem, uma compreensão total como afetarão da rede está exigida antes de exceder estas diretrizes.

Diretriz #1

Se você planeia usar o Hot Standby Router Protocol (HSRP) sobre LANE, certifique-se de que você promove a uma versão recente e leiam-se a aplicação do HSRP over LANE.

Diretriz nº2

Distribua o BARRAMENTO DE PISTA em dispositivos com a capacidade de ritmo de transferência de barramento a mais alta, e onde terá o impacto mínimo em outros processos no dispositivo.

O BARRAMENTO DE PISTA é responsável para enviar toda a transmissão, Multicast, e frames de unicast do destino desconhecido recebidos dos membros de um ELAN, a todos os membros do ELAN. Desde que o LANE usa a camada de adaptação ATM 5 (AAL5) que não permite a intercalação das pilhas das unidades de dados de protocolo diferentes (PDU), o BARRAMENTO deve fabricar os quadros antes da transmissão. Isto exige o BARRAMENTO remontar os frames recebidos, segmenta cada quadro um por um, e envia as pilhas. A exigência remontar e segmentar cada quadro limita significativamente o throughput de encaminhamento do BARRAMENTO, que influencia consideravelmente a escalabilidade de um ELAN. A proliferação dos aplicativos do Protocolo IP multicast mais adicionais intensifica esta tarefa. Recorde que somente os módulos LANE podem receber as pilhas no Multicast enviam e envie-as no Multicast para a frente. Isto é feito sem remontagem.

Diretriz nº 3

Distribua os serviços de pista através dos módulos múltiplos e dos dispositivos.

Nós indicamos acima que o 10 LES/BUS com cada ELAN que corresponde a uma rede IP do C da classe (aproximadamente 250 usuários) é seguro e conservador; contudo, as redes de pista bem sucedidas com 10-60 pares LES/BUS pelo módulo existem. Isto depende levemente do módulo, mas verificar o projeto envolverá sempre verificar a utilização CPU (que usam o comando show processes cpu), e a mais baixa memória disponível (que usa o comando show memory). Isto deve, naturalmente, ser realizado durante a utilização de rede máxima, porque a utilização CPU total do LES é relacionada diretamente ao processo LE_ARP.

Em um ambiente de pista, é comum ver os pares LES/BUS situados em um dispositivo único que apoia a rede de pista inteira. Não somente isto representa um ponto de falha único, mas limita o desempenho de barramento dentro de cada ELAN.

Distribuir serviços de pista através das plataformas múltiplas fornece a maior escalabilidade nos ambientes multi-ELAN, assim como uma Disponibilidade do sistema mais alta e desempenho de barramento agregado aumentado (por exemplo, o desempenho de barramento agregado na rede aumenta enquanto mais dispositivos e relações são configurados para o apoio do BARRAMENTO). Para a capacidade de barramento máxima de uma perspectiva do projeto, dos módulos ATM do catalizador 5000 e 6000 pode ser dedicado ao LES e aos serviços de barramento.

Conhecendo a capacidade do BARRAMENTO, e calculando a quantidade de transmissão ou de tráfego multicast esperada em cada ELAN, você pode calcular o número de pares LES/BUS que podem ser aplicados a uma dada interface. Você pode igualmente medir a capacidade do BARRAMENTO.

Calcular a quantidade de transmissão ou o tráfego multicast para cada ELAN é, contudo, mais desafiante. Um método para calcular a quantidade de transmissão ou o tráfego multicast para cada ELAN é medir este tráfego na rede existente. Dispositivo um analisador de rede ou de uma ponta de prova do Remote Monitoring (RMON) podem ser introduzidos no LAN existente para medir a quantidade de transmissão e de tráfego multicast. Uma outra maneira é perguntar os objetos MIB dos “ifOutMulticastPkts” e dos “ifOutBroadcastPkts”. Verifique primeiramente mesmo se estejam apoiados em seu IOS/platform.

Alternativamente, você pode, em certa medida, calcular a quantidade de transmissão ou de tráfego multicast calculando a largura de banda consumida por transmissões do protocolo de roteamento, por exemplo. Para Trocas de Pacote Entre Redes IPX (IPX), Routing Information Protocol (RIP), e protocolo service advertising (SAP), o consumo de largura de banda pode exatamente ser determinado se o número de rotas do IPX e as seivas são sabidos. O mesmo é verdadeiro para o IP e o protocolo de roteamento particular que está sendo usado.

A altura livre adicional da capacidade de barramento deve ser reservada para:

  • Tráfego de unicast de apoio quando um VC de dados direitos for estabelecido e até que um pacote nivelado estiver reconhecido no LEC de recepção.

  • Os aplicativos por encomenda do Protocolo IP multicast que são utilizados em diferentes épocas do dia (estes devem ser considerados no volume total de transmissão múltipla).

  • Tráfego adicional do roteamento quando um protocolo for executado e em um estado da convergência (isto é, anúncios link states (LSA) trocados durante uma alteração de topologia do Open Shortest Path First (OSPF)).

  • Volumes altos das requisições de protocolo de resolução de endereço (ARP), especificamente na manhã em que as estações de trabalho registram primeiramente no LAN e nos servidores de rede.

Usando-se o que método está disponível, o objetivo é ter uma ilustração precisa da quantidade de transmissão e de tráfego multicast que existirá em cada ELAN. Infelizmente, esta informação está raramente disponível ao projetista de rede por razões diversas. Quando enfrentadas com esta situação, algumas diretrizes conservadoras gerais podem ser usadas. Como uma recomendação, uma rede típica com os 250 usuários pelo ELAN, executando mais aplicativos comuns, deve ser pelo menos os kpps 10 atribuídos da capacidade de barramento. A tabela 1 ilustra o número recomendado máximo de pares LES/BUS pela relação.

Estes números devem ser usados conjuntamente com a diretriz #4, que limita a 250 o número de LEC prestados serviços de manutenção por todos os pares LES/BUS configurados em uma relação. Também, estes números devem ser ajustados de acordo com o número real de usuários em cada ELAN, ao pagar a atenção particular a toda a transmissão ou aplicativos multicast que sejam executados no ELAN.

Diretriz nº 4

Limite o número total de LEC prestado serviços de manutenção pelos pares LES/BUS a um máximo de 250. Durante a iniciação, e depois de uma falha de rede, para que os clientes LANE juntem-se a seu ELAN, devem estabelecer conexões múltiplas e fazer pedidos a seus componentes de serviço de pista. Desde que os dispositivos que apoiam os serviços de pista possuem uma taxa finita em que podem processar as conexões e os pedidos, recomenda-se que os pares LES/BUS configurados em uma relação prestam serviços de manutenção a um máximo de 250 clientes LANE. Por exemplo, uma relação pode ser configurada com os pares 10 LES/BUS, cada 25 LEC de conservação para um total de 250 LEC sendo prestado serviços de manutenção pela relação. Isto assegurará a inicialização apropriada e a recuperação da falha.

Diretriz nº 5

Põe o LES/BUS para um ELAN dado na proximidade final a todo o origem principal de tráfego de transmissão ou de transmissão múltipla.

Em um ambiente de pista, especificamente onde os aplicativos multicast estão no uso (isto é, IP/TV), é boa prática do projeto colocar tão perto o BARRAMENTO ao origem de transmissão múltipla conhecido como possível. Desde que o tráfego multicast deve primeiramente ser enviado ao BARRAMENTO, que por sua vez para a frente o tráfego a todos os clientes, situar o BARRAMENTO na proximidade final ao origem de transmissão múltipla salvar o tráfego de cruzar o backbone ATM duas vezes.

Isto permite que a rede de pista escale a uma magnitude maior. Além, o BARRAMENTO não deve ser ficado situado na mesma relação que o LEC que apoia o origem de transmissão múltipla, desde que o tráfego multicast cruzaria o link transmitir duas vezes.

Exercite o cuidado se você está considerando o LANE como a Tecnologia de Rede apoiar um ambiente do Multicast. Quando o LANE apoiar o tráfego multicast, faz tão um pouco incapazmente. O LANE inunda simplesmente o tráfego multicast a todos os clientes no ELAN apesar de mesmo se são parte do grupo de transmissão múltipla. O tráfego multicast adicional pode significativamente degradar o exemplo de estações de trabalho (como discutido na diretriz #6), quando o comportamento de inundação desperdiçar a largura de banda de backbone.

Diretriz nº 6

Limite o número de sistemas finais em um ELAN dado a 500 ou menos, se a rede levar somente pacotes IP. A tabela 2 abaixo dá alguma recomendação básica baseada na quantidade de transmissão gerada pelo protocolo. Além disso, caso que você não é inteiramente certo que protocolos estarão precisados, mantenha na mente a recomendação que de 250 estações final nós demos no passado.

Por definição, um ELAN representa um domínio de transmissão. Consequentemente, dentro de um ELAN, toda a transmissão e pacotes de transmissão múltipla são inundados a todos os membros do ELAN. As estações de trabalho devem processar cada transmissão e pacote de transmissão múltipla recebidos para determinar se é do interesse. O processamento de pacotes de transmissão “sem interesse” desperdiça ciclos de CPU da estação de trabalho. Quando o nível da atividade de transmissão se tornar alto (relativo à capacidade de processamento das estações de trabalho), podem seriamente ser impactados e impedido de executar suas tarefas pretendidas.

O número de sistemas finais, os aplicativos, e os protocolos no uso determinam o nível da transmissão dentro de um ELAN. Os testes ilustraram que, na ausência dos aplicativos intensivos da transmissão, o número de sistemas finais que podem com segurança ser configurados em um único ELAN varia de 200 a 500 segundo a mistura de protocolo.

Tabela 2: Número máximo de sistemas finais recomendados pelo ELAN baseado na mistura de protocolo

Tipo de protocolo Número de sistemas finais
IP 500
IPX 300
Apple Talk 200
Misto 200

Diretriz #7

Calcule o uso da rede VC para assegurar-se de que esteja dentro da capacidade dos dispositivos ATM.

Uso VC

Switches ATM e os dispositivos de ponta apoiam um número limitado de VC. Ao projetar redes ATM, é importante assegurar-se de que a capacidade VC do equipamento não esteja excedida. Isto é particularmente importante nas redes de pista, desde que o LANE não é notado para sua eficiência VC. Durante a fase de projeto de rede, você deve calcular o uso antecipado VC para o backbone, assim como para cada dispositivo de ponta individual. O uso VC do backbone corresponde ao número total de VC esperados na rede. Esta quantidade deve ser comparada ao número de VC apoiados por Switches ATM.

Desde não todos os VC cruze um interruptor dado, saques deste número como um limite superior. A topologia real do backbone e os testes padrão de tráfego devem ser considerados, com relação ao número total de VC, para determinar se a capacidade VC de Switches ATM será excedida.

Similarmente, o uso VC para cada dispositivo de ponta deve ser calculado. Isto relaciona-se ao número de VC que terminarão em uma dada interface de um dispositivo de ponta. Este número deve então ser comparado à capacidade VC da relação.

As seguintes fórmulas podem ser usadas em calcular o uso VC da rede. Estas fórmulas supõem o uso de serviços de pista e de clientes de Cisco, e aplicam-se ao SSRP e ao FSSRP. Quando o presente, diferenças no uso VC entre os dois protocolos for indicado.

Uso do backbone VC

a. LEC-LANE Service VCs:

       SSRP: 4 (#LEC_per_ELAN)(#ELAN)
       FSSRP: 4 (#LEC_per_ELAN)(#LES/BUS_per_ELAN)(#ELAN) 

b. LECS-LES Control VCs:

       (#LES/BUS_per_ELAN)(#ELAN)

c. LECS-LECS Control VCs:

       (#LECS)(#LECS - 1) / 2 

d. LEC-LEC Data Direct VCs:

       If mesh_factor < 1.0:

         (#LEC_per_ELAN) [(#LEC_per_ELAN)(mesh_factor)/2](#ELAN)

       If mesh_factor = 1.0: (recommended in most designs) 

         (#LEC_per_ELAN) [((#LEC_per_ELAN) - 1)/2](#ELAN) 

       where: 

       mesh_factor = fraction of LECs within an ELAN communicating a given time. (When determining the fraction of 
       LECs within an ELAN communicating at a given time, the data direct timeout period must be considered. 
       Even a brief conversation between two LECs will cause a data direct connection to be maintained for the 
       timeout period. Therefore, unless the traffic patterns are very clearly understood, a mesh_factor = 1.0
       is highly recommended).

       Backbone VC Usage = a + b + c + d

Uso da relação de dispositivo de ponta VC

a. LEC-LANE Service VCs: 

       SSRP: (#active_LES/BUS_on_interface) (2 * #LEC_per_ELAN + 2) 
       FSSRP: (#LES/BUS_on_interface) (2 * #LEC_per_ELAN + 2)

b. LECS-LES Control VC's:

       (#LES/BUS_on_interface)

c. LECS-LECS Control VCs 

       (#LECS - 1)

d. LEC-LEC Data Direct VCs:

       (#LEC)[(#LEC_per_ELAN)(#LEC_per_ELAN)(mesh_factor)/2] 

       Interface VC usage = a + b + c + d

Uma vez que você calculou o uso VC, compare os resultados à capacidade VC dos dispositivos relevantes usando a tabela 3.

Tabela 3: Roteamento Inter-ELAN - Capacidade VC para vários dispositivos Cisco

Dispositivo Orçamento dos circuitos virtuais
Catalyst 8540MSR 256k
Catalyst 8510 MSR/LS1010 Memória dinâmica de acesso aleatório do 16 MB (DRAM) = 4k
32 MB DRAM = 16k
64 MB DRAM = 32k
Cisco 7500/7200 ATM de luxe 4k
ATM lite do Cisco 7500/7200 2k
Catalyst 6K - LANE/MPOA OC-12 4k
Catalyst 5K - LANE/MPOA OC-12 4k
Catalyst 5K - LANE/MPOA OC-3 4k
Catalyst 5K - LANE OC-3 4k
Catalyst 2900 XL - LANE OC-3 1k

Diretriz #8

Se você quer ligar redes de ATM do campus diferentes com os caminhos virtuais permanentes (PVP), sempre a “rota” entre os locais um pouco do que permitem que os ELAN nativos meçam redes de ATM do campus diferentes.

Diretriz #9

Avalie a capacidade de roteador necessária calculando a quantidade do roteamento inter-ELAN exigida.

A quantidade de capacidade de roteamento exigida em uma rede de pista dada varia extensamente. Consequentemente, a quantidade de capacidade de roteamento deve ser calculada durante o processo de projeto de rede. Após ter determinado a capacidade exigida, o número de Roteadores e as interfaces do roteador necessárias podem ser determinados usando a seguinte tabela do throughput de encaminhamento:

Tabela 4: Capacidade de roteamento Inter-ELAN para vários dispositivos Cisco

Dispositivo Cisco Express Forwarding (CEF) distribuído (kpps) Transmissão do Cisco Express Forwarding (CEF) (kpps)
RSP4/VIP2-50 ATM PA-A3 118 101
RSP4/VIP2-50 ATM PA-A1 91 91
RSP4/VIP2-40 ATM PA-A3 83 60
RSP4/VIP2-40 ATM PA-A1 66 66

Quando a configuração de roteador “unidirecional” for popular nos projetos de pista, tipicamente esta não fornece a capacidade de roteamento adequada. Em lugar de, as interfaces múltiplas e/ou os roteadores múltiplos são exigidos. As taxas de encaminhamento CEF alistadas na tabela acima supõem uma configuração de roteador unidirecional. Para alcançar estas taxas, o processador central do roteador é empurrado para a utilização de quase 100%. Pelo contraste, as taxas de encaminhamento distribuídas são conseguidas usando o processador que reside no Versatile Interface Processor (VIP), com essencialmente nenhum impacto no processador de roteador centralizado. Em consequência, as interfaces ATM múltiplas podem ser instaladas no roteador que conduz a um ritmo de tranferência agregado muito mais alto.

Diretriz #10

Forneça dispositivos de ponta da duplo-HOME ATM pelo menos a dois Switches ATM diferentes para a Redundância.

Em uma rede de pista, o switch ATM que apoia os dispositivos de ponta pode ser um ponto de falha único para a Conectividade ao backbone. Os catalizadores 6K e 5K fornecem os módulos de uplink duplo-físicos do sublayer OC-12/OC-3 (PHY) para a conectividade redundante a Switches ATM a jusante. Os módulos LANE dirigidos duplos fornecem uma “Fiber Distributed Data Interface (FDDI) - como” a característica do PHY dual. Este módulo de uplink do PHY dual fornece uma interface ATM preliminar e secundária. Se a interface principal perde a Conectividade do link ao switch ATM, o módulo comutará automaticamente a conexão sobre à interface secundária.

É altamente recomendado que o projetista de rede se aproveita das relações do PHY dual nos módulos LANE e se fornece uplinks dirigidos duplos a dois Switches ATM diferentes no núcleo. Isto protegerá os dispositivos de ponta da falha de um único switch ATM.

Diretriz #11

Use o FSSRP a menos que o orçamento VC tiver limitações.

Desde que os vários componentes de serviço de pista são pontos de falha únicos em uma rede de pista, as redes de produção devem ser projetadas com Redundância. Cisco apoia dois esquemas de redundância para serviços de pista: Simple Server Redundancy Protocol (SSRP) e Fast SSRP (FSSRP).

O FSSRP é o esquema de redundância recomendado na maioria dos casos. Fornece quase o failover imediato sem a perda de dados, mesmo nas redes grandes. Por outro lado, o SSRP conduzirá à perda durante um Failover, e o tempo de recuperação pode ser substancial (às vezes minutos) nas redes grandes.

Existe uma situação onde o SSRP é recomendado sobre o FSSRP: quando a rede VC-for forçada. Em contraste com o SSRP, o FSSRP LEC mantém conexões de backup aos pares redundantes LES/BUS. Até três pares do les/barramento de backup podem ser configurados compararam a um total de quatro pelo ELAN. O aumento do uso VC que a rede experimentará sob o FSSRP pode ser calculado usando a seguinte fórmula:

4 (#LEC_per_ELAN) (#LES/BUS_per_ELAN - 1) (#ELAN) 

Consequentemente, se a rede alcança sua capacidade VC, o SSRP é recomendado sobre o FSSRP. Se você usa o FSSRP, a seguir você deve reduzir o número de componentes redundantes LES/BUS. Na maioria de circunstâncias, um total de dois pares LES/BUS pelo ELAN oferece um equilíbrio aceitável entre o uso VC e pontos de falha únicos da eliminação.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 10459