Desempenho lento da rede ATM

Introduction

Este documento discute as causas gerais e específicas do desempenho lento em redes ATM e os procedimentos para ajudar a solucionar o problema. O foco deste documento é na solução de problemas de desempenho de IP, especificamente em redes ATM. Geralmente, o desempenho é medido com o uso de atraso e throughput. O desempenho é frequentemente testado com o uso de FTP ou outros aplicativos TCP/IP para transferir um arquivo entre dois dispositivos finais e, em seguida, medir o tempo que leva para transferir o arquivo. Quando a taxa de transferência vista com a transferência de arquivos não é igual à largura de banda disponível no circuito ATM, isso é percebido como um problema de desempenho. Há muitos fatores, como configurações da janela TCP, MTU, perda de pacotes e atraso, que determinam o throughput observado em um circuito ATM. Este documento aborda problemas que afetam o desempenho sobre circuitos virtuais permanentes (PVCs - Permanent Virtual Circuits) roteados ATM, circuitos virtuais comutados (SVCs - Switched Virtual Circuits) e implementações de LAN Emulation (LANE - LAN Emulation). A causa dos problemas de desempenho é comum entre implementações roteadas de PVC, SVC e LANE.

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

A primeira etapa na identificação e solução de qualquer problema relacionado ao desempenho é selecionar dispositivos de origem e destino únicos a serem testados entre eles. Identifique as condições em que o problema ocorre e as condições em que ele não ocorre. Selecione os dispositivos de teste para reduzir a complexidade do problema. Por exemplo, não teste entre os dispositivos que estão dez saltos de distância do roteador se o problema existir quando você passar por dois roteadores.

Depois que os dispositivos de teste forem selecionados, determine se o desempenho está relacionado à natureza inerente dos aplicativos TCP ou se o problema é causado por outros fatores. Faça ping entre os dispositivos finais para determinar se ocorre perda de pacote e o atraso de round trip para os pacotes de ping. Os testes de ping devem ser realizados com tamanhos de pacote diferentes para determinar se o tamanho do pacote afeta a perda do pacote. Os testes de ping devem ser feitos dos dispositivos finais em teste e não dos roteadores. O tempo de ida e volta (RTT) que você vê ao fazer ping de e para um roteador pode não ser exato. Isso ocorre porque o processo de ping é um processo de baixa prioridade no roteador e pode não responder imediatamente ao ping.

Problemas comuns

Natureza inerente do TCP/IP

Um cliente tem um PVC ATM entre Nova York e Los Angeles. O circuito virtual (VC) é configurado com SCR (Sustained Cell Rate) de 45 Mbps. O cliente testa esse circuito transferindo um arquivo usando o FTP de um servidor FTP para um cliente e descobre que o throughput da transferência de arquivos é de cerca de 7,3 Mbps. Quando usam TFTP, o throughput cai para 58 Kbps. O tempo de resposta do ping entre o cliente e o servidor é de aproximadamente 70 ms.

A primeira coisa a entender neste exemplo é que o TCP fornece transporte confiável de dados entre dispositivos. O remetente envia dados em um fluxo no qual bytes são identificados por números de sequência. O receptor reconhece que recebeu os dados enviando o número de sequência (número de confirmação) do próximo byte de dados que espera receber. O receptor também anuncia seu tamanho de Janela ao remetente para anunciar a quantidade de dados que ele pode aceitar.

Os dispositivos finais TCP/IP normalmente incluem a capacidade de configurar tamanhos de Janela TCP/IP.

Se os dispositivos tiverem seus tamanhos de Janela TCP definidos como muito baixos, esses dispositivos podem não ser capazes de utilizar toda a largura de banda de um ATM VC.

O RTT em um ATM VC pode reduzir drasticamente o throughput do TCP se o tamanho da janela for muito baixo.

Um dispositivo final envia aproximadamente um tamanho de janela de tráfego em bytes por RTT.

Por exemplo, se o RTT for 70 ms, use esta fórmula para calcular o tamanho de janela necessário para preencher um DS3 inteiro de largura de banda:

• .07s * 45 Mbps * 1 byte/8 bits = 393.750 bytes

O TCP padrão permite um tamanho máximo de janela de 64.000 bytes. A opção WINScale TCP permite que o tamanho da janela seja muito maior se os dispositivos em ambas as extremidades suportarem essa opção e o aplicativo FTP também suportar essa opção.

Use esta fórmula para definir o tamanho da janela em 64.000 bytes e use o RTT de 70 ms para resolver o throughput.

• .07x * 1byte/8bits = 64000 bytes

  onde x= 7,31428 Mbps

Se o aplicativo FTP suportar apenas um tamanho de janela de 32.000 bytes, use esta fórmula.

• .07x * 1byte/8bits = 32000

  onde x= 3,657142 Mbps

Com o TFTP, o remetente envia pacotes de 512 bytes e deve receber uma confirmação para cada pacote antes de enviar o próximo pacote. O melhor cenário é enviar 1 pacote a cada 70 ms. Use este cálculo de throughput.

• 1 pacote /.070s = 14,28571 pacotes/segundo

  512 bytes/pacote * 8 bits/byte * 14,28571 pacotes/segundo = 58,514 Kbps

Esse cálculo de throughput demonstra que o atraso em um link e o tamanho da Janela TCP podem afetar drasticamente o throughput nesse link quando ele usa aplicativos TCP/IP para medir o throughput. Identificar o throughput esperado para cada conexão TCP. Se o FTP for usado para testar o throughput, inicie várias transferências de arquivos entre diferentes clientes e servidores para identificar se o throughput é limitado pela natureza inerente do TCP/IP ou se há outros problemas com o circuito ATM. Se o aplicativo TCP limitar o throughput, você deve ser capaz de ter vários servidores que enviam ao mesmo tempo e a taxas semelhantes.

Em seguida, prove que você pode transmitir tráfego através do link na taxa SCR do circuito. Para fazer isso, use uma origem de tráfego e um link que não usam TCP e enviam um fluxo de dados através do ATM VC. Verifique também se a taxa recebida é igual à taxa enviada. Envie pacotes de ping estendido de um roteador com um valor de tempo limite 0 para gerar tráfego através de um circuito ATM. Isso prova que você pode enviar tráfego através do link na taxa configurada do circuito.

Solução: Aumente o tamanho da janela TCP/IP.

Importante: Com um RTT muito pequeno e um tamanho de janela grande o suficiente para, teoricamente, preencher o SCR, você nunca poderá alcançar o SCR devido à sobrecarga ATM. Se você considerar o exemplo dos pacotes de 512 bytes enviados através de um PVC AAL5SNAP de 4 Mbps (SCR=PCR), calcule o throughput IP real que é medido. Pressupõe-se que o tamanho da janela TCP e o RTT sejam tais que a origem possa enviar dados a 4 Mbps. Primeiro, a camada de adaptação ATM 5 (AAL5) e o SNAP apresentam cada 8 bytes de sobrecarga. Por causa disso, pode ser necessário colar para garantir que a unidade de dados do protocolo AAL5 (PDU) possa ser dividida por 48. Em seguida, em cada célula, 5 bytes de sobrecarga são introduzidos por célula. Nesse caso, significa que a camada AAL5 é de 512+8+8=528 bytes (sem preenchimento necessário). Esses 528 bytes exigem que 11 células sejam transmitidas. Isso significa que para cada pacote de 512 bytes a enviar, 583 bytes são enviados no fio (11 * 53). Em outras palavras, 71 bytes de sobrecarga são apresentados. Isso significa que apenas 88% da largura de banda pode ser usada pelos pacotes IP. Portanto, com o PVC de 4 Mbps, significa que o throughput IP utilizável é de apenas 3,5 Mbps.

Quanto menor o tamanho do pacote, maior a sobrecarga e menor o throughput.

Perda de pacote

A razão mais comum para problemas de desempenho é a perda de pacotes em circuitos ATM. Qualquer perda de célula em um circuito ATM resulta em degradação de desempenho. Perda de pacote significa retransmissão e também redução do tamanho da janela TCP. Isso resulta em um throughput mais baixo. Geralmente, um teste de ping simples identifica se há perda de pacotes entre os dois dispositivos. Erros de verificação de redundância cíclica (CRC - Cyclic Redundancy Check) e quedas de célula/pacote em circuitos ATM resultam na retransmissão de dados. Se as células ATM forem descartadas por um switch ATM devido à exaustão do policiamento ou do buffer, erros de CRC são vistos no dispositivo final quando as células são reagrupadas em pacotes. Os dispositivos de borda ATM podem descartar ou atrasar pacotes quando a taxa de pacotes de saída em um VC excede a taxa de modelagem de tráfego configurada no VC.

Consulte estes documentos para obter detalhes sobre a solução de problemas das causas mais comuns de perda de pacotes nas redes ATM:

• Manual de Troubleshooting de CRC para Interfaces ATM

• Troubleshooting de Quedas de Saída em Interfaces do ATM Router

• Troubleshooting de Quedas de Entrada em Interfaces do ATM Router

• Entendendo os contadores de células rejeitadas/descartadas em roteadores de Switch ATM

Solução: Solucione problemas e elimine qualquer perda de pacote.

Atraso/Latência

A quantidade de tempo que um pacote leva para trafegar da origem para o destino e, em seguida, para que uma confirmação retorne para o remetente, pode afetar drasticamente o throughput visto nesse circuito. O atraso em um circuito ATM pode ser o resultado de um atraso normal de transmissão. Leva menos tempo para enviar um pacote de Nova York para Washington do que de Nova York para Los Angeles quando o circuito ATM é da mesma velocidade. Outras fontes de atraso são o atraso de enfileiramento através de roteadores e switches e o atraso de processamento através dos dispositivos de roteamento da Camada 3. O atraso de processamento associado aos dispositivos de roteamento depende muito da plataforma usada e do caminho de switching. Os detalhes associados ao atraso de roteamento e ao atraso interno de hardware estão além do escopo deste documento. Esse atraso afeta qualquer roteador, independentemente dos tipos de interface. Também é insignificante quando comparado ao atraso associado à transmissão de pacotes e ao enfileiramento. No entanto, se um roteador processa o tráfego de switching, ele pode resultar em um atraso significativo e deve ser considerado.

O atraso é tipicamente medido com o uso de pacotes de ping entre os dispositivos finais para determinar o atraso de ida e volta médio e máximo. As medições de atraso devem ser realizadas durante o pico de utilização, bem como durante os períodos de inatividade. Isso ajuda a determinar se o atraso pode ser atribuído ao atraso de enfileiramento em interfaces congestionadas.

O congestionamento de interfaces resulta em um atraso de enfileiramento. O congestionamento geralmente resulta de incompatibilidades de largura de banda. Por exemplo, se você tiver um circuito através de um switch ATM que atravessa de uma interface OC-12 para uma interface ATM DS3, poderá experimentar um atraso de enfileiramento. Isso acontece quando as células chegam à interface OC-12 mais rápido do que podem ser saídas na interface DS3. Os roteadores de borda ATM configurados para modelagem de tráfego restringem a taxa na qual eles enviam tráfego na interface. Se a taxa de chegada do tráfego destinado ao ATM VC for maior que as taxas de modelagem de tráfego na interface, os pacotes/células serão enfileirados na interface. Geralmente, o atraso introduzido pelo atraso de enfileiramento é o atraso que causa problemas de desempenho.

Solução: Implementar recursos de Classe de Serviço (CoS - Class of Service) de IP para ATM para serviços diferenciados. Utilize recursos como Class Based Weighted Fair Queuing (CBWFQ) e Low Latency Queuing (LLQ) para reduzir ou eliminar o atraso de enfileiramento para tráfego de missão crítica. Aumente a largura de banda dos circuitos virtuais para eliminar o congestionamento.

Configuração de modelagem de tráfego

PVCs ATM e SVCs têm parâmetros de Qualidade de Serviço (QoS - Quality of Service) associados a cada circuito. Um contrato de tráfego é estabelecido entre o dispositivo de borda ATM e a rede. Quando os PVCs são usados, esse contrato é configurado manualmente na rede ATM (switches ATM). Com SVCs, a sinalização ATM é usada para estabelecer este contrato. Os dados de forma de tráfego dos dispositivos de borda ATM devem estar em conformidade com o contrato especificado. Os dispositivos de rede ATM (comutadores ATM) monitoram o tráfego no circuito para verificar a conformidade com o contrato especificado e o tráfego de tag (marca) ou descarte (polícia) que não está em conformidade.

Se um dispositivo de borda ATM tiver Taxa de Célula de Pico (PCR - Peak Cell Rate)/SCR configurado para uma taxa superior à prevista na rede, a perda de pacotes será um resultado provável. As taxas de modelagem de tráfego configuradas no dispositivo de borda devem corresponder ao que é configurado de ponta a ponta através da rede. Verifique se a configuração corresponde a todos os dispositivos configurados. Se o dispositivo de borda envia células para a rede que não estão em conformidade com o contrato que é provisionado em toda a rede, as células descartadas dentro da rede são vistas normalmente. Isso geralmente pode ser detectado pelo recebimento de erros de CRC na extremidade oposta quando o receptor tenta remontar o pacote.

Um dispositivo de borda ATM com PCR/SCR configurado para uma taxa inferior à provisionada na rede causa desempenho degradado. Nessa situação, a rede é configurada para fornecer mais largura de banda do que o dispositivo de borda envia. Essa condição pode resultar em atraso de enfileiramento adicional e até mesmo quedas de fila de saída na interface de saída do roteador ATM de borda.

Os SVCs são configurados nos dispositivos de borda, mas a rede pode não estabelecer o SVC fim-a-fim com os mesmos parâmetros de tráfego. Os mesmos conceitos e problemas se aplicam aos SVCs que se aplicam aos PVCs. A rede não pode configurar o SVC fim-a-fim com as mesmas classes e parâmetros de QoS. Normalmente, esse tipo de problema é causado por problemas de bug ou interoperabilidade. Quando um SVC é sinalizado, a parte chamadora especifica os parâmetros de modelagem de tráfego de QoS na direção de avanço e retrocesso. Pode acontecer que a parte chamada não instale o SVC com os parâmetros de modelagem apropriados. A configuração de Formatação Restrita de Tráfego nas interfaces do roteador pode impedir que os SVCs sejam configurados com parâmetros de modelagem diferentes dos configurados.

O usuário deve rastrear o caminho do SVC através da rede e verificar se ele é estabelecido com o uso da classe de QoS e dos parâmetros configurados no dispositivo de origem.

Solução: Elimine incompatibilidades de configuração de política/modelagem de tráfego. Se os SVCs forem usados, verifique se estão configurados de ponta a ponta com os parâmetros corretos de modelagem/vigilância. Configure a formatação de tráfego estrita nas interfaces do roteador ATM com o comando atm sig-traffic-shaping strict.

SVCs que roteiam em caminhos não otimizados

Os SVCs configurados para Taxa de Bits Não Especificada (UBR - Unspecified Bit Rate) podem ser configurados em caminhos não ideais. Um VC UBR é limitado em largura de banda à taxa de linha dos links que o VC atravessa. Portanto, se um link de alta velocidade for desativado, os VCs que atravessam esse link podem ser restabelecidos em um link mais lento. Mesmo quando o link de alta velocidade é restaurado, os VCs não são desmontados e restabelecidos no link mais rápido. Isso ocorre porque o caminho mais lento atende aos parâmetros de QoS solicitados (não especificados). Esse problema é muito comum em redes LANE que têm caminhos alternativos através da rede. Nos casos em que os caminhos alternativos são a mesma velocidade de link, a falha de um dos links faz com que todos os SVCs sejam roteados pelo mesmo caminho. Essa situação pode afetar drasticamente o throughput e o desempenho da rede, pois a largura de banda efetiva da rede é reduzida pela metade.

Mesmo SVCs de Taxa de Bits Variável (VBR - Variable Bit Rate) e Taxa de Bits Constante (CBR - Constant Bit Rate) podem ser roteados sobre caminhos não ideais. Os dispositivos finais solicitam parâmetros de tráfego específicos (PCR, SCR, Tamanho máximo de intermitência {MBS}). O objetivo da PNNI (Private Network-Network Interface) e da sinalização ATM é fornecer um caminho que atenda aos requisitos de QoS da solicitação. No caso de chamadas CBR e VBR-rt, isso também inclui o atraso máximo de transferência de célula. Um caminho pode satisfazer os requisitos especificados pelo solicitante do ponto de vista da largura de banda, mas não pode ser o caminho ideal. Esse problema é comum quando há caminhos com atraso maior que ainda atendem aos requisitos de largura de banda para VCs VBR e CBR. Isso pode ser percebido como um problema de desempenho para o cliente que agora vê características de atraso maiores na rede.

Solução: Os SVCs em uma rede ATM são estabelecidos sob demanda e geralmente não são desmontados e redirecionados por um caminho diferente, a menos que o SVC seja desligado (devido à inatividade ou liberado por outros motivos). Os switches ATM Cisco LightStream 1010 e Catalyst 8500 fornecem o recurso de otimização de rota de PVC soft. Esse recurso permite redirecionar dinamicamente um PVC suave quando uma rota melhor estiver disponível. Uma funcionalidade semelhante não está disponível para SVCs que não terminam nos switches ATM.

Uma solução possível para esse problema é usar PVCs entre os dispositivos de borda ATM e os switches ATM conectados. PVCs soft com otimização de rota configurada entre switches ATM fornecem a capacidade de redirecionar o tráfego de caminhos não otimizados após falha de link e recuperação subsequente.

Configure o Intervalo de Tempo Limite de Ociosidade para SVCs para que eles sejam desligados e restabelecidos com mais frequência. Use o comando idle-timeout seconds [minimum-rate] para alterar a quantidade de tempo e as taxas de tráfego que fazem com que o SVC seja destruído. Isso pode não ser muito eficaz, pois o VC precisa estar inativo para ser redirecionado pelo caminho ideal.

Se tudo o mais falhar, certifique-se de que o caminho ideal tenha sido restaurado para a operação e, em seguida, devolva uma das interfaces ATM associadas ao caminho redundante de velocidade lenta ou a uma das interfaces do roteador que termina o SVC.

Problemas de hardware

Problemas de desempenho do PA-A1

A arquitetura do adaptador de porta ATM PA-A1 e a falta de memória onboard podem resultar em desempenho degradado. Esse problema pode se manifestar em aborto, overrun, ignora e CRCs na interface. O problema é agravado quando usado com um roteador Cisco 7200 com NPE-100/175/225/300.

Consulte Troubleshooting de Erros de Entrada em Adaptadores de Porta ATM PA-A1 para obter informações adicionais.

Solução: Substitua os adaptadores de porta ATM PA-A1 por adaptadores de porta ATM PA-A3 (pelo menos, revisão 2) ou PA-A6.

PA-A3 Versão 1

A revisão 1 do hardware do PA-A3 não reagrupa células em pacotes que usam a RAM estática integrada (SRAM) no adaptador de porta. O adaptador encaminha as células através do barramento de interconexão de componentes periféricos (PCI) para a memória de host do Versatile Interface Processor (VIP) ou Network Processing Engine (NPE) onde reagrupa os pacotes. Isso resulta em problemas relacionados ao desempenho semelhantes aos observados com o adaptador de porta ATM PA-A1.

Consulte Troubleshooting de Erros de Entrada e Saída em Adaptadores de Porta ATM PA-A3 para obter informações adicionais.

Solução: Substitua os adaptadores de porta ATM revisão 1 de hardware PA-A3 por adaptadores de porta ATM PA-A3 (pelo menos revisão 2) ou PA-A6.

PAs PA-A3 duplos no VIP2-50

O PA-A3-OC3SMM, PA-A3-OC3SMI e PA-A3-OC3SML são projetados para fornecer desempenho máximo de switching quando um único adaptador de porta é instalado em um único VIP2-50. Um único PA-A3-OC3SMM, PA-A3-OC3SMI ou PA-A3-OC3SML em um VIP2-50 fornece aproximadamente 85.000 pacotes por segundo de capacidade de comutação em cada direção usando pacotes de 64 bytes. Observe que um único PA-A3-OC3SMM, PA-A3-OC3SMI ou PA-A3-OC3SML pode usar somente a capacidade de switching inteira de um único VIP2-50.

Para aplicativos que exigem densidade máxima de porta ou custo de sistema menor, as configurações de adaptador de porta dupla com a versão OC-3/STM-1 do PA-A3 no mesmo VIP2-50 agora são suportadas. Os dois adaptadores de porta no mesmo VIP2-50 compartilham aproximadamente 95.000 pacotes por segundo de capacidade de comutação em cada direção usando pacotes de 64 bytes.

O VIP-50 fornece até 400 megabits por segundo (mbps) de largura de banda agregada, dependendo das combinações do adaptador de porta. Na maioria das configurações de adaptador de porta dupla com PA-A3-OC3SMM, PA-A3-OC3SMI ou PA-A3-OC3SML, a combinação de adaptadores de porta excede essa capacidade de largura de banda agregada.

Consequentemente, o desempenho compartilhado entre os dois adaptadores de porta instalados no mesmo VIP2-50 é limitado pela capacidade de comutação agregada (95 kpps) em pequenos tamanhos de pacote e pela largura de banda agregada (400 mbps) em grandes tamanhos de pacote.

Essas advertências de desempenho devem ser consideradas quando você designar redes ATM com PA-A3-OC3SMM, PA-A3-OC3SMI ou PA-A3-OC3SML. Dependendo do design, o desempenho de adaptadores de porta dupla no mesmo VIP2-50 pode ou não ser aceitável.

Consulte Configurações PA-A1 e PA-A3 VIP2 suportadas para obter informações adicionais.

Problemas de LANE

Domínio de broadcast LANE

O número excessivo de sistemas finais em uma única LAN ELAN pode degradar significativamente o desempenho de todas as estações finais. Um ELAN representa um domínio de broadcast. Todas as estações de trabalho e servidores no ELAN recebem tráfego de broadcast e, possivelmente, multicast de todos os outros dispositivos no ELAN. Se o nível de tráfego de broadcast for alto em relação à capacidade de processamento da estação de trabalho, o desempenho das estações de trabalho sofrerá.

Solução: Restrinja o número de estações finais em um único ELAN para menos de 500. Monitore a rede em busca de tempestades de broadcast/multicast que possam afetar negativamente o desempenho do servidor/estação de trabalho.

Consulte as recomendações de projeto LANE para obter informações adicionais.

Tráfego LE-ARP excessivo e alterações de topologia de árvore de abrangência

Outros problemas que podem levar a um desempenho ruim em uma rede LANE são atividades LANE ARP (LE-ARP) excessivas e alterações na topologia Spanning Tree. Esses problemas levam a LE-ARPs não resolvidos que levam ao tráfego enviado pelo barramento. Isso também pode levar à alta utilização da CPU nos LECs na rede, o que também pode causar problemas relacionados ao desempenho. Mais informações sobre esses problemas podem ser encontradas em Troubleshooting Spanning-Tree over LANE.

Configure o Spanning Tree PortFast nas portas de host dos switches Ethernet conectados à LANE para reduzir as alterações na topologia do Spanning Tree. Configure a reverificação de LE-ARP local nos switches Catalyst 5000 e 6000 configurados para LANE para reduzir o tráfego LE-ARP.

VBR-nrt Data Direct SVCs

Usando a versão 1 do LANE, os SVCs são configurados como Categoria de serviço UBR. A LANE versão 2 suporta a capacidade de estabelecer SVCs de Data Direct com o uso de outras categorias de serviço como VBR-nrt. Um fornecedor terceirizado tem um bug na implementação do cliente LANE que pode fazer com que os SVCs do Data Direct configurados para dispositivos Cisco sejam VBR-nrt com um SCR de 4 Kbps. Se o seu backbone ATM consiste em links de tronco OC-3 (155 Mbps) e OC-12 (622 Mbps) e você configura SVC sobre esses troncos com uma taxa de célula sustentada de 4 Kbps, seu desempenho sofrerá. Embora esse problema em particular não seja comum, ele aponta uma necessidade importante quando você soluciona problemas de desempenho em circuitos ATM. Você deve rastrear o caminho percorrido pelos SVCs através da rede e confirmar se o VC foi estabelecido com a categoria de serviço e os parâmetros de tráfego desejados.

Os VCs de dados diretos não estão estabelecidos

Os LANE Data Direct VCs são SVCs bidirecionais ponto-a-ponto configurados entre dois LAN Emulation Clients (LECs) e usados para trocar dados entre esses clientes. Os clientes LANE enviam solicitações LE-ARP para aprender os endereços ATM associados a um endereço MAC. Em seguida, eles tentam configurar um VC de Data Direct para esse endereço ATM. Antes do estabelecimento do Data Direct VC, os clientes LANE inundavam pacotes unicast desconhecidos para o Servidor de Transmissão e Desconhecido (BUS). Um cliente LANE pode falhar ao estabelecer um VC de Data Direct para outro LEC com a finalidade de enviar dados unicast para ele. Se isso acontecer, poderá ocorrer degradação do desempenho. O problema é significativo se o dispositivo escolhido para executar os serviços de BUS estiver com pouca energia, inadequado ou sobrecarregado. Além disso, algumas plataformas podem limitar as taxas dos unicasts que são encaminhados ao BUS. O módulo LANE do Catalyst 2900XL é uma dessas caixas que restringe o tráfego unicast enviado ao BUS, enquanto o Catalyst 5000 e o Catalyst 6000 não o fazem.

O Data Direct SVC pode não ser estabelecido ou ser utilizado por qualquer uma das seguintes razões:

• O LEC não recebe uma resposta para a solicitação LE-ARP.

• O SVC não pode ser criado devido a problemas de roteamento ou sinalização ATM.

• Falha no protocolo LANE Flush Message. Quando o Data Direct VC é estabelecido, o LEC envia uma solicitação de liberação no VC de envio de multicast para garantir que todos os quadros de dados enviados pelo BUS chegaram ao destino. Quando o LEC que enviou a solicitação de liberação recebe uma resposta de volta, ele começa a enviar dados pelo VC de Data Direct. O mecanismo Flush pode ser desativado com o comando no lane client flush.

Problemas de IMA

PVCs UBR em interfaces IMA

Os VCs UBR em interfaces IMA (Inverse Multiplexing) são configurados com um PCR de 1,5 Mbps em vez da soma de todas as interfaces físicas up/up configuradas no grupo IMA. Essa condição degrada o desempenho, pois o VC é modelado de tráfego em uma taxa inferior à largura de banda combinada de todos os links no grupo IMA.

Originalmente, a largura de banda de uma interface de grupo IMA era limitada ao número mínimo de links IMA ativos necessários para manter a interface IMA ativada. O comando para definir esse valor é IMA ative-links-minimum. Por exemplo, se quatro interfaces ATM físicas forem configuradas como membros do grupo IMA zero e o valor IMA ative-links-minimum for definido como um, a largura de banda será igual a um T1 ou 1,5 Mbps, não 6 Mbps.

A ID de bug da Cisco CSCdr12395 (somente clientes registrados) altera esse comportamento. O adaptador PA-A3-8T1IMA agora usa a largura de banda de todas as interfaces físicas ATM up/up configuradas como membros do grupo IMA.

Os IDs de bug da Cisco CSCdt67354 (somente clientes registrados) e CSCdv67523 (somente clientes registrados) são solicitações de aprimoramento subsequentes para atualizar a largura de banda do VC do grupo IMA quando uma interface é adicionada ou removida do grupo IMA, shut/no shut ou bounces devido a uma falha de link, ou alterar na extremidade remota. As alterações implementadas no bug da Cisco IDCSCdr12395 (somente clientes registrados) configuram a largura de banda do grupo IMA para a largura de banda total de seus links membros somente quando o grupo IMA é ativado. As alterações no grupo IMA após o status inicial de ativação não são refletidas.

Consulte Troubleshooting de Links ATM no Adaptador de Porta IMA 7x00 para obter informações adicionais.

Informações Relacionadas

• Seleção de rota de Interface de rede a rede privada (PNNI)
• Dimensionamento da janela TCP
• Troubleshooting de Links ATM no IMA 7x00 Port Adapter
• Configurações de PA-A1 e PA-A3 VIP2 suportadas
• Detalhes da implementação TCP/IP do Microsoft Windows 2000
• Solução de problemas de TCP/IP
• Suporte Técnico - Cisco Systems

Histórico de revisões