Recomendações de projeto LANE

Introduction

Este documento fornece diretrizes práticas de projeto de redes LAN emulation (LANE). Essas diretrizes ajudarão você no projeto de redes LANE de alto desempenho, escaláveis e alta disponibilidade. Embora este documento se concentre em equipamentos da Cisco, os mesmos conceitos podem ser aplicados na integração de produtos de terceiros.

Antes de Começar

Conventions

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

Prerequisites

Os leitores deste documento devem conhecer as operações básicas e as configurações das redes LANE.

Componentes Utilizados

Este documento se concentra nas configurações Ethernet LANE.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. 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 seus requisitos são apresentados abaixo.

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

A especificação Emulation Over ATM Version 1.0 exige que cada LAN Emulation Client (LEC) estabeleça um circuito virtual (VC) para o LAN Emulation Configuration Server (LECS) quando ele for ativado. Em seguida, o LEC solicita o endereço ATM do respectivo Servidor de Emulação de LAN (LES - LAN Emulation Server) correspondente. Quando o LEC tiver seu endereço de LES ATM, o VC entre o LEC e o LECS será removido e o LEC não tentará mais se comunicar com o LECS. Quando o ambiente é estável e todos os LECs estão ativos e operacionais, o LECS fica ocioso.

Quando os LECs se juntam à LAN emulada (ELAN), cada um deles entra em contato com o LECS individualmente. No entanto, quando a rede LANE sofre um desastre (por exemplo, quando o LECS principal falha), todos os clientes ficam inativos.

Observação: a exceção é quando o Fast Simple Server Redundancy Protocol (FSSRP) é usado.

Como todos os LECs ficam inativos ao mesmo tempo, todos entram em contato com o LECS de backup ao mesmo tempo. Portanto, para hospedar o LECS, você precisa de um dispositivo que:

• pode lidar com uma intermitência repentina de tráfego direcionada no nível do processo.

• pode aceitar quase todas as configurações de chamadas recebidas dos LECs simultaneamente.

• é conhecida pela sua estabilidade. Se o LECS ficar inativo, toda a rede ficará inativa (novamente, com exceção do FSSRP). Portanto, não é recomendável colocar o LECS em um dispositivo executando uma versão de software experimental.

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

Cada LEC manterá um VC bidirecional para o LES do ELAN (pode ser mais de um ELAN se o FSSRP for usado). Em um ambiente tipicamente altamente carregado, muitas solicitações do protocolo de resolução de endereços de emulação de LAN (LE_ARP) serão enviadas ao LES. A implementação do LES em dispositivos Cisco é bastante simples. Todos os quadros LE_ARP de entrada serão encaminhados para o controle distribute virtual channel connection (VCC).

Não é possível implementar uma replicação simples de célula de hardware de controle direto para controle de distribuição, pois alguns quadros (como as solicitações de junção) devem ser analisados pelo processo LES. Portanto, um dispositivo que pode atuar como um bom LES é um dispositivo que:

• tem uma CPU poderosa e pode aceitar muitas configurações de chamada em um curto período de tempo. Isso é necessário quando muitos clientes ingressam no ELAN ao mesmo tempo, mas menos vital que para o LECS, já que apenas os LECs no ELAN têm que ingressar.

• tem um forte suporte de hardware de segmentação e remontagem (SAR). Como todas as células de entrada precisam ser remontadas em quadros, se muitas solicitações de junção chegarem ao mesmo tempo, elas terão que ser remontadas muito rapidamente.

Lembre-se de que, na implementação da Cisco, os processos LES e Broadcast and Unknown Server (BUS) são combinados (ou seja, você não pode colocar o LES para ELAN-1 em um dispositivo e o BUS para ELAN-1 em outro dispositivo).

Outra coisa a ter em mente é um possível comportamento preventivo. Se a antecipação estiver habilitada, o LES/BUS com a prioridade mais alta (de acordo com o banco de dados LANE) sempre assumirá o dever básico de LES/BUS. Em outras palavras, se o LES/BUS principal falhar, todos os LECs do ELAN serão desativados e se reconectarão ao LES/BUS de backup. Se a preemptividade for configurada, se o LES/BUS principal for ativado novamente, todos os LECs serão desativados mais uma vez e se reconectarão ao LES/BUS com a prioridade mais alta. No LANE Module Software Release 3.2.8 ou posterior, e no Cisco IOS® Software Release 11.3(4) e posterior, o recurso de pré-emptividade pode ser ativado e desativado. O recurso de preemptividade pode ser configurado conforme descrito na documentação Configuração de Emulação de LAN.

O servidor de broadcast e desconhecido

O trabalho do BUS é bastante semelhante ao do LES. Cada LEC precisa ter um envio multicast para o BUS. O LEC envia todo o seu tráfego multicast, broadcast ou desconhecido para ele. O BUS tem uma VCC ponto a multiponto para todos os LECs na ELAN. Os quadros não precisam ser examinados em detalhes pelo BUS. Em outras palavras, cada quadro de entrada no envio multicast pode ser encaminhado cegamente para a frente multicast.

Um bom dispositivo de barramento:

• tem suporte de hardware para a cópia do quadro do multicast de entrada enviado para o multicast de saída. Se você tiver um hardware "inteligente", essa operação de cópia pode ser feita antes da remontagem. Isso significa que as células recebidas no envio multicast são encaminhadas no envio multicast. Isso salva uma segmentação e remontagem por quadro.

• exige uma CPU forte se não houver suporte de hardware para o BUS.

• deve ser capaz de processar muitas configurações de chamada ao mesmo tempo, mas com um limite inferior ao LECS.

Tabela 1: Desempenho do barramento por dispositivo

Dispositivo	Rendimento De BARRAMENTO (Kpps)
Módulo Catalyst 6K LANE/MPOA (OC-12)	600
Módulo Catalyst 5K LANE/MPOA (OC-12)	600
Módulo Catalyst 5K LANE/MPOA (OC-3)	166
Módulo LANE 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 abrange os recursos dos dispositivos Cisco mais comuns usados para executar LEC, LECS, LES e BUS. Esses dispositivos são os módulos Cisco LANE, o Lightstream 1010, o Catalyst 8510MSR e 8540MSR e o 7500/RSP. Seus recursos são comparados aos requisitos listados acima.

Módulos LANE

A arquitetura de todos os módulos LANE para o Catalyst 5000 e 6000 é basicamente baseada na seguinte visão de alto nível:

A segmentação e a remontagem são executadas pelo hardware. O chip SAR é um pouco inteligente e pode encaminhar diretamente os quadros remontados para o barramento de quadros do catalisador (o painel traseiro do catalisador). Para quadros de controle, o chip SAR pode encaminhar os quadros à CPU do módulo LANE. Um quadro de controle é qualquer quadro que precisa ser analisado (por exemplo, ILMI (Intercalação Local Management Interface), sinalização e quadros destinados ao LES), que chega ao módulo LANE através de um VC especificado.

O chip SAR também pode redirecionar as células que chegam no envio multicast para a frente multicast (ou seja, multicast, broadcast e células desconhecidas provenientes dos LECs). As células não são remontadas em quadros. Sua facilidade de implementação resulta em um desempenho de barramento muito bom.

Depois que um "data direct" e uma entrada na tabela de memória endereçável por conteúdo (CAM) forem criados, os quadros remontados serão enviados diretamente para o BUS do quadro e marcados com a ID de LAN virtual (VLAN) correta. Um módulo LANE faz um LEC muito bom porque, uma vez que o "direto de dados" foi estabelecido, a CPU não está mais envolvida.

LightStream 1010 e Catalyst 8510MSR

O LS1010 e o Catalyst 8510MSR não têm suporte de hardware para SAR. Consequentemente, esses dispositivos são opções inadequadas para implementar funcionalidades LES/BUS. No entanto, são adequados para a LECS (ver modelo de amostra 2 abaixo).

8540MSR

O 8540MSR não tem suporte de hardware para SAR. Ele também tem um poderoso processador Risc 5000. O 8540MSR não é recomendado para suportar o LES/BUS por dois motivos:

• O desempenho do barramento fica em torno de 50 Kpps para pacotes de 64 bytes, bem abaixo de qualquer módulo LANE. Isso porque não há aceleração de hardware para o BUS.

• Se o 8540MSR for usado com placas ATM e Ethernet, a CPU pode ser usada principalmente para conversar com placas de linha Ethernet. Nesse caso, a CPU do 8540MSR não deve ser usada como um LES.

Plataformas de roteador

O roteador mais comumente usado para o roteamento entre ELANs é a plataforma Cisco 7500 (o Route Switch Module (RSM) e o Cisco 7200 também são amplamente usados). O adaptador de porta contém o chip de hardware SAR. Os Processadores de Rota/Switch (RSPs), como o RSP4, têm potência de CPU suficiente para processar quadros de entrada muito rapidamente; por conseguinte, são uma boa escolha para o LES. O desempenho do barramento, no entanto, está abaixo do dos módulos LANE.

Exemplo de projeto

A LANE é usada principalmente em redes grandes e críticas. Como tal, a redundância é obrigatória. O Simple Server Redundancy Protocol (SSRP) é o protocolo de redundância mais amplamente usado. Se o software for recente, o FSSRP é o protocolo preferido (consulte a Orientação nº 11).

Vamos supor que temos uma rede bastante grande, por exemplo, 100 VLANs/ELANs e 100 catalisadores, cada um com um módulo LANE de uplink duplo. Isso significa que, em cada módulo LANE, podemos precisar de um LEC por ELAN, neste caso 10.000 LECs. Além disso, supomos que o IP é usado e que o projeto inclui uma classe C segura (254 endereços IP de host, 254 endereços MAC) por VLAN.

Projeto 1: Simples, mas para evitar...

Neste design, um módulo LANE foi escolhido para executar os 100 servidores LES/BUS. Ao mesmo tempo, o LECS principal está no mesmo módulo LANE. Isso é ilustrado no desenho abaixo:

Ao criar os LECs no módulo LANE, todos os LECs são ativados assim que são configurados. Durante a operação, o processo LES pode ficar sobrecarregado e o módulo LANE ficará sem memória. O Design 2 abaixo resolve ambos os problemas.

O principal problema nessa rede é quando ocorre um problema grave. Suponha que o módulo LANE que hospeda LECS, LES ou BUS se torne inalcançável. Isso pode acontecer, por exemplo, se o módulo LANE do catalyst 1 se tornar defeituoso. Você pode ver a redundância ocorrendo, mas o tempo de redundância (ou seja, o tempo entre a falha primária de LECS, LES ou BUS e o último LEC que está operando novamente) pode durar até duas horas! Um bom projeto pode reduzir esse número para algumas dezenas de segundos, ou alguns minutos em redes grandes.

O problema está na sinalização envolvida com os LECs que se juntam ao ELAN. Se o LECS precisar ser contatado por cada LEC, ele receberá 10.000 configurações de chamada (100 módulos LANE com 100 LECs em cada um) quase simultaneamente. O módulo LANE foi projetado para fazer uma ponte eficiente entre o barramento de quadro e o link da célula, mas não para lidar com muitas configurações de chamada por segundo. A CPU do módulo LANE não é potente o suficiente para lidar com esse volume de configurações de chamada. A saída a seguir ilustra o tempo de redundância em uma rede LANE com aproximadamente 1600 LECs (somente parte do comando show processes cpu é exibida):

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 é superutilizado devido à atividade de sinalização recebida. O que é responsável pelo tempo de redundância de duas horas? A resposta está na noção de tempo limite. As especificações de sinalização mencionam claramente que se o dispositivo não receber uma mensagem de "conexão" depois de um período de tempo especificado quando uma "configuração de chamada" é enviada, ele deve começar de novo. As especificações LANE exigem que o LEC retorne ao seu estado inicial e comece tudo novamente. Isso significa que, se um LEC puder entrar em contato com o LECS e se conectar a ele, sua configuração de chamada para o LES poderá expirar e voltará ao seu estado inicial de tentar entrar em contato com o LECS! Isso também pode acontecer com conexões do LES e de/para o BUS.

Com base nas explicações acima, aqui estão algumas recomendações básicas de projeto:

• Tente espalhar o LES/BUS para os diferentes ELANs nos vários dispositivos que podem implementá-lo com eficiência. Idealmente, um LES/BUS principal em cada módulo LANE, com os próximos fazendo backup do primeiro. Na prática, isso geraria um banco de dados LECS muito longo. A experiência mostra que 10 servidores LES/BUS por módulo LANE parecem ser um número seguro.

• Tente não colocar o LECS no mesmo local que outros servidores LES/BUS importantes. Tente também colocar o LECS em um dispositivo com energia de CPU suficiente para que ele possa lidar com as informações de sinalização de forma eficiente. O LECS deve estar em um roteador (o Cisco 7200 ou 7500 é recomendado, de preferência sem LES/BUS) ou em um switch ATM.

• Supondo que IP e um intervalo de Classe C sejam usados para cada VLAN, aproximadamente 250 endereços MAC são um bom número para a função LES. Para 10 LES em um módulo LANE, isso significa a CPU de um módulo LANE para um máximo de 2.500 endereços MAC. Lembrem-se de que não existem números fixos e oficiais, mas esta é uma estimativa segura e conservadora. Por outro lado, 200 LES/BUS em um módulo LANE, com cada ELAN contendo 1000 estações finais, estarão seguros enquanto a estação permanecer praticamente inativa (consulte a Diretriz nº 3 para obter mais detalhes).

Design 2: Mais complexo, mas mais seguro e mais eficiente...

Neste design, colocamos o LECS no switch ATM. Distribuímos o LES/BUS em diferentes módulos LANE. Valores de CPU de alto processo não são vistos em nenhum módulo LANE, e a redundância é normal.

Diretrizes

As diretrizes apresentadas abaixo são apenas recomendações práticas, baseadas na implantação de redes LANE de produção. Embora existam exemplos de redes bem-sucedidas que excedem as recomendações, é necessário um entendimento completo de como elas afetarão a rede antes de exceder essas diretrizes.

Diretriz #1

Se você planeja usar o HSRP (Hot Standby Router Protocol) sobre LANE, certifique-se de atualizar para uma versão recente e ler Implementando HSRP sobre LANE.

Diretriz nº2

Distribua o LANE BUS em dispositivos com a maior capacidade de throughput do barramento e onde terá impacto mínimo em outros processos no dispositivo.

O LANE BUS é responsável por encaminhar todos os quadros unicast de broadcast, multicast e destino desconhecido recebidos dos membros de uma ELAN para todos os membros da ELAN. Como o LANE usa a camada de adaptação ATM 5 (AAL5), que não permite a intercalação de células de diferentes unidades de dados de protocolo (PDUs), o BUS deve serializar os quadros antes do encaminhamento. Isso exige que o BUS remonte os quadros recebidos, segmente cada quadro um por um e encaminhe as células. O requisito de reagrupar e segmentar cada quadro limita significativamente o throughput de encaminhamento do BUS, o que influencia consideravelmente a escalabilidade de um ELAN. A proliferação de aplicativos multicast IP intensifica ainda mais essa tarefa. Lembre-se de que somente os módulos LANE podem receber as células em envio multicast e encaminhá-las no envio multicast. Isso é feito sem remontagem.

Diretriz nº 3

Distribua os serviços LANE em vários módulos e dispositivos.

Afirmamos acima que 10 LES/BUS com cada ELAN correspondente a uma rede IP de classe C (aproximadamente 250 usuários) são seguros e conservadores; entretanto, existem redes LANE bem-sucedidas com 10 a 60 pares LES/BUS por módulo. Isso depende um pouco do módulo, mas a verificação do design sempre envolverá a verificação da utilização da CPU (usando o comando show processes cpu) e a menor memória disponível (usando o comando show memory). Isso deve, claro, ser realizado durante o pico de utilização da rede, já que a utilização geral da CPU do LES está diretamente relacionada ao processo LE_ARP.

Em um ambiente LANE, é comum ver os pares LES/BUS localizados em um único dispositivo que suporta toda a rede LANE. Isso não só representa um único ponto de falha, como também limita o desempenho do barramento em cada ELAN.

A distribuição de serviços LANE em várias plataformas fornece maior escalabilidade em ambientes com várias ELANs, bem como maior disponibilidade do sistema e maior desempenho agregado do BUS (por exemplo, o desempenho agregado do BUS na rede aumenta à medida que mais dispositivos e interfaces são configurados para suporte a BUS). Para a capacidade máxima de BUS de uma perspectiva de projeto, os módulos ATM do Catalyst 5000 e 6000 podem ser dedicados a serviços LES e BUS.

Conhecendo a capacidade do BUS e estimando a quantidade de tráfego de broadcast ou multicast esperada em cada ELAN, você pode calcular o número de pares LES/BUS que podem ser aplicados a uma determinada interface. Você também pode medir a capacidade do barramento.

A estimativa da quantidade de tráfego de broadcast ou multicast para cada ELAN é, no entanto, mais desafiadora. Um método para estimar a quantidade de tráfego de broadcast ou multicast para cada ELAN é medir esse tráfego na rede existente. Um analisador de rede ou dispositivo de prova de Monitoração Remota (RMON - Remote Monitoring) pode ser inserido na LAN existente para medir a quantidade de tráfego de broadcast e multicast. Outra forma é consultar os objetos mib "ifOutMulticastPkts" e "ifOutBroadcastPkts". Verifique primeiro se eles são ou não suportados no IOS/plataforma.

Como alternativa, você pode, até certo ponto, calcular a quantidade de tráfego de broadcast ou multicast calculando a largura de banda consumida por broadcasts do protocolo de roteamento, por exemplo. Para o Internetwork Packet Exchange (IPX), Routing Information Protocol (RIP) e Service Advertising Protocol (SAP), o consumo de largura de banda pode ser determinado com precisão se o número de rotas IPX e SAPs forem conhecidos. O mesmo vale para o IP e para o protocolo de roteamento específico que está sendo usado.

Espaço de capacidade adicional do barramento deve ser reservado para:

• Suportando o tráfego unicast enquanto um VC direto de dados está sendo estabelecido e até que um pacote flush seja confirmado no LEC receptor.

• Aplicativos multicast IP sob demanda que são utilizados em várias horas do dia (devem ser considerados no volume multicast geral).

• Tráfego de roteamento adicional quando um protocolo está em execução e em um estado de convergência (ou seja, anúncios de estado do enlace (LSAs) trocados durante uma alteração de topologia do OSPF (Open Shortest Path First).

• Altos volumes de solicitações ARP (Address Resolution Protocol Protocolo de Resolução de Endereços), especificamente pela manhã, quando as estações de trabalho fazem login pela primeira vez nos servidores de rede e LAN.

Usando qualquer método disponível, o objetivo é ter uma representação precisa da quantidade de tráfego de broadcast e multicast que existirá em cada ELAN. Infelizmente, essas informações raramente estão disponíveis para o projetista de rede por vários motivos. Diante dessa situação, algumas diretrizes conservadoras gerais podem ser usadas. Como recomendação, uma rede típica com 250 usuários por ELAN, executando os aplicativos mais comuns, deve receber pelo menos 10 Kpps de capacidade de barramento. A Tabela 1 ilustra o número máximo recomendado de pares LES/BUS por interface.

Esses números devem ser usados em conjunto com a Diretriz nº 4, que limita a 250 o número de LECs em serviço por todos os pares LES/BUS configurados em uma interface. Além disso, esses números devem ser ajustados de acordo com o número real de usuários em cada ELAN, prestando atenção especial a qualquer aplicativo de broadcast ou multicast que será executado na ELAN.

Diretriz nº 4

Limite o número total de LECs servidos pelo par LES/BUS a um máximo de 250. Durante a inicialização e após uma falha de rede, para que os clientes LANE ingressem em seus ELAN, eles devem estabelecer várias conexões e fazer solicitações para seus componentes de serviço LANE. Como os dispositivos que suportam os serviços LANE possuem uma taxa finita na qual podem processar as conexões e solicitações, recomenda-se que os pares LES/BUS configurados em um serviço de interface tenham no máximo 250 clientes LANE. Por exemplo, uma interface pode ser configurada com 10 pares LES/BUS, cada um servindo 25 LECs para um total de 250 LECs sendo servidos pela interface. Isso garantirá a inicialização oportuna e a recuperação de falhas.

Diretriz nº 5

Coloque o LES/BUS de um determinado ELAN próximo de qualquer fonte de tráfego de transmissão ou multicast principal.

Em um ambiente LANE, especificamente onde os aplicativos multicast estão em uso (ou seja, IP/TV), é uma boa prática de projeto colocar o barramento o mais próximo possível da fonte multicast conhecida. Como o tráfego multicast deve primeiro ser enviado para o BUS, que por sua vez encaminha o tráfego para todos os clientes, situando o BUS próximo à origem multicast, o tráfego não pode cruzar o backbone ATM duas vezes.

Isso permite que a rede LANE seja dimensionada para uma magnitude maior. Além disso, o BUS não deve estar localizado na mesma interface que o LEC que suporta a origem multicast, já que o tráfego multicast cruzaria o link de transmissão duas vezes.

Tenha cuidado ao considerar a LANE como a tecnologia de rede para suportar um ambiente multicast. Embora a LANE suporte o tráfego multicast, ela o faz de forma bastante ineficiente. A LANE simplesmente inunda o tráfego multicast para todos os clientes na ELAN, independentemente de serem ou não parte do grupo multicast. O excesso de tráfego multicast pode degradar significativamente o desempenho das estações de trabalho (conforme discutido na Diretriz nº 6), enquanto o comportamento de inundação desperdiça a largura de banda do backbone.

Diretriz nº 6

Limite o número de sistemas finais em um determinado ELAN a 500 ou menos, caso a rede transporte somente pacotes IP. A tabela 2 abaixo fornece algumas recomendações básicas com base na quantidade de broadcast gerada pelo protocolo. Novamente, caso você não tenha certeza absoluta de quais protocolos serão necessários, lembre-se da recomendação de 250 estações finais que fizemos no passado.

Por definição, um ELAN representa um domínio de broadcast. Portanto, em uma ELAN, todos os pacotes de broadcast e multicast são inundados para todos os membros da ELAN. As estações de trabalho devem processar cada pacote de broadcast e multicast recebido para determinar se ele é de interesse. O processamento de pacotes de broadcast "desinteressantes" desperdiça ciclos da CPU da estação de trabalho. Quando o nível de atividade de broadcast se torna alto (em relação à capacidade de processamento das estações de trabalho), eles podem ser seriamente afetados e impedidos de executar suas tarefas desejadas.

O número de sistemas finais, aplicativos e o(s) protocolo(s) em uso determinam o nível de transmissão em uma ELAN. Os testes mostraram que, na ausência de aplicativos com uso intenso de broadcast, o número de sistemas finais que podem ser configurados com segurança em um único ELAN varia de 200 a 500, dependendo da combinação de protocolos.

Tabela 2: Número máximo de sistemas finais recomendados por ELAN com base na combinação de protocolos

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

Diretriz #7

Calcule o uso do VC de rede para garantir que ele esteja dentro da capacidade dos dispositivos ATM.

Uso de VC

Os switches ATM e os dispositivos de borda suportam um número limitado de VCs. Ao projetar redes ATM, é importante garantir que a capacidade de VC do equipamento não seja excedida. Isso é particularmente importante em redes LANE, já que a LANE não é notada por sua eficiência de VC. Durante a fase de projeto de rede, você deve calcular o uso antecipado do VC para o backbone, bem como para cada dispositivo de borda individual. O uso de VC do backbone corresponde ao número total de VCs esperados na rede. Essa quantidade deve ser comparada ao número de VCs suportados pelos switches ATM.

Como nem todos os VCs cruzam um determinado switch, esse número serve como um limite superior. A topologia real do backbone e dos padrões de tráfego deve ser considerada, em relação ao número total de VCs, para determinar se a capacidade do VC dos switches ATM será excedida.

Da mesma forma, o uso do VC para cada dispositivo de borda deve ser calculado. Isso se refere ao número de VCs que terminarão em uma determinada interface de um dispositivo de borda. Esse número deve ser comparado à capacidade VC da interface.

As fórmulas a seguir podem ser usadas para calcular o uso do VC da rede. Essas fórmulas assumem o uso de serviços e clientes Cisco LANE e se aplicam ao SSRP e ao FSSRP. Quando presentes, as diferenças no uso de VC entre os dois protocolos são indicadas.

Uso de VC de backbone

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 de VC da interface do dispositivo de borda

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

Depois de calcular o uso do VC, compare os resultados com a capacidade do VC dos dispositivos relevantes usando a Tabela 3.

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

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

Diretriz #8

Se você quiser conectar diferentes redes ATM de campus com caminhos virtuais permanentes (PVPs), sempre "roteie" entre os sites, em vez de permitir que as ELANs nativas englobem diferentes redes ATM de campus.

Diretriz #9

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

A quantidade de capacidade de roteamento necessária em uma determinada rede LANE varia muito. Portanto, a quantidade de capacidade de roteamento deve ser estimada durante o processo de projeto da rede. Após determinar a capacidade necessária, o número de roteadores e interfaces de roteador necessários pode ser determinado usando a seguinte tabela de throughput de encaminhamento:

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

Dispositivo	Cisco Express Forwarding (CEF) Distribuído (Kpps)	Encaminhamento expresso Cisco (CEF - Cisco Express Forwarding) (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

Embora a configuração do roteador "com um único braço" seja popular em projetos LANE, normalmente, isso não fornece a capacidade de roteamento adequada. Em vez disso, são necessárias várias interfaces e/ou vários roteadores. As taxas de encaminhamento CEF listadas na tabela acima assumem uma configuração de roteador com um único braço. Para alcançar essas taxas, o processador central do roteador é empurrado para uma utilização de quase 100%. Por outro lado, as taxas de encaminhamento distribuído são obtidas usando o processador que reside no Versatile Interface Processor (VIP), praticamente sem impacto no processador de roteador centralizado. Como resultado, várias interfaces ATM podem ser instaladas no roteador, levando a um throughput agregado muito maior.

Diretriz #10

Forneça dispositivos edge ATM dual-home para pelo menos dois switches ATM diferentes para redundância.

Em uma rede LANE, o switch ATM que suporta os dispositivos de borda pode ser um ponto único de falha para a conectividade com o backbone. Os Catalyst 6K e 5K fornecem módulos de uplink OC-12/OC-3 de subcamada física dupla (PHY) para conectividade redundante com switches ATM downstream. Os módulos LANE dual-homed fornecem um recurso PHY dual "Fiber Distributed Data Interface (FDDI)". Este módulo de uplink PHY duplo fornece uma interface ATM primária e secundária. Se a interface primária perder a conectividade do link com o switch ATM, o módulo alternará automaticamente a conexão para a interface secundária.

É altamente recomendado que o projetista de rede aproveite as interfaces PHY duplas nos módulos LANE e forneça uplinks dual-homed para dois switches ATM diferentes no núcleo. Isso protegerá os dispositivos de borda da falha de um único switch ATM.

Diretriz #11

Use o FSSRP, a menos que o orçamento do VC tenha restrições.

Como os vários componentes do serviço LANE são pontos únicos de falha em uma rede LANE, as redes de produção devem ser projetadas com redundância. A Cisco oferece suporte a dois esquemas de redundância para serviços LANE: Simple Server Redundancy Protocol (SSRP) e Fast SSRP (FSSRP).

O FSSRP é o esquema de redundância recomendado na maioria dos casos. Ele oferece failover quase imediato sem perda de dados, mesmo em redes grandes. Por outro lado, o SSRP resultará em perda durante um failover, e os tempos de recuperação podem ser substanciais (às vezes, minutos) em grandes redes.

Existe uma situação em que o SSRP é recomendado no FSSRP: quando a rede é restrita a VC. Ao contrário do SSRP, os LECs FSSRP mantêm conexões de backup para os pares LES/BUS redundantes. Até três pares LES/BUS de backup podem ser configurados em comparação a um total de quatro por ELAN. O aumento de uso do VC que a rede viverá no FSSRP pode ser calculado usando a seguinte fórmula:

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

Portanto, se a rede atingir sua capacidade de VC, o SSRP é recomendado sobre o FSSRP. Se você usar o FSSRP, deverá reduzir o número de componentes LES/BUS redundantes. Na maioria das circunstâncias, um total de dois pares LES/BUS por ELAN oferece um equilíbrio aceitável entre o uso do VC e a eliminação de pontos únicos de falha.

Informações Relacionadas

• Implementando HSRP sobre LANE
• Suporte ATM - LAN Emulation (LANE)
• Informações gerais ATM
• Suporte Técnico e Documentação - Cisco Systems