Asynchronous Transfer Mode (ATM) : IP sobre ATM

Desempenho lento da rede ATM

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 discute causas gerais e do específico para o desempenho lento em redes ATM e em procedimentos para ajudar a pesquisar defeitos o problema. O foco deste documento está em pesquisar defeitos problemas de desempenho IP, especificamente em redes ATM. Tipicamente, o desempenho é medido com o uso do atraso e da taxa de transferência. O desempenho é testado frequentemente com o uso do FTP ou outros aplicativos TCP/IP transferir um arquivo entre dois dispositivos finais e medir então o tempo que toma para transferir o arquivo. Quando a taxa de throughput considerada com transferência de arquivo não iguala a largura de banda que está disponível sobre o circuito ATM, esta é percebida como um problema de desempenho. Há muitos fatores tais como os ajustes da janela TCP, o MTU, a perda de pacotes, e o atraso que determinam a taxa de transferência que é considerada através de um circuito ATM. Este documento endereça as edições que afetam o desempenho sobre os circuitos permanentes distribuídos ATM (PVC), os Circuitos Virtuais Comutados (SVC), e as aplicações do LAN Emulation (LANE). A causa dos problemas de desempenho é comum entre o PVC roteado, o SVC, e as implementações de lane.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Convenções

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

Informações de Apoio

A primeira etapa quando você pesquisa defeitos toda a questão relacionada ao desempenho é selecionar o origem única e os dispositivos de destino para testar no meio. Identifique as circunstâncias sob que o problema ocorre e aquelas que não fazem. Selecione dispositivos do teste para reduzir a complexidade do problema. Por exemplo, não teste entre os dispositivos que são saltos do roteador ten distante se o problema existe quando você dirige dois Roteadores.

Uma vez que os dispositivos do teste são selecionados, determine se o desempenho está relacionado à natureza inerente ao aplicativo TCP ou se o problema está causado por outros fatores. Sibile entre dispositivos finais para determinar se a perda de pacotes ocorre e o retardo de round trip para pacotes de ping. Os testes de ping devem ser realizados com tamanhos do pacote diferentes para determinar se o tamanho do pacote afeta a perda de pacotes. Os testes de ping devem ser feitos dos dispositivos finais sob o teste e não do Roteadores. O Round Trip Time (RTT) esse você vê quando você sibila a e de um roteador não pode ser exato. Isto é porque o processo ping é um processo de prioridade baixa no roteador e não pode imediatamente responder ao sibilo.

Problemas comuns

Natureza inerente do TCP/IP

Um cliente tem um ATM PVC entre New York e Los Angeles. O virtual circuit (VC) é configurado com uma taxa de célula sustentada (SCR) do 45 Mbps. O cliente testa este circuito transferindo um arquivo usando o FTP de um servidor FTP a um cliente e descobre que a taxa de transferência para transferência de arquivo é sobre o 7.3 Mbps. Quando usam o TFTP, a taxa de transferência deixa cair a 58 kbps. O tempo de resposta de ping entre o cliente e o server é a Senhora aproximadamente 70.

A primeira coisa a compreender neste exemplo é que o TCP fornece o transporte confiável de dados entre dispositivos. O remetente envia dados em um córrego em que os 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 reconhecimento) do byte de dados seguinte que espera receber. O receptor igualmente anuncia seu tamanho de janela ao remetente para anunciar a quantidade de dados que pode aceitar.

Os dispositivos finais TCP/IP incluem tipicamente a capacidade para configurar tamanhos de janela TCP/IP.

Se os dispositivos têm seus tamanhos da janela TCP ajustados demasiado baixos, aqueles dispositivos não podem poder utilizar a largura de banda inteira de um ATM VC.

O RTT em um ATM VC pode dramaticamente reduzir o throughput de tráfego se o tamanho de janela é demasiado baixo.

Um dispositivo final envia aproximadamente um valor do tamanho de janela do tráfego nos bytes pelo RTT.

Por exemplo, se o RTT é a Senhora 70, use esta fórmula para calcular o tamanho de janela necessário para encher acima um DS3 inteiro da largura de banda:

  • .07s * 45 Mbps * bit 1byte/8 = 393,750 bytes

O padrão TCP permite um tamanho máximo de janela de 64,000 bytes. A opção WinScale TCP permite que o tamanho de janela seja muito mais alto se os dispositivos no ambas as extremidades apoiam esta opção e o aplicativo de FTP igualmente apoia esta opção.

Use esta fórmula para ajustar o tamanho de janela em 64,000 bytes e para usar o RTT da Senhora 70 para resolver a taxa de transferência.

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

    onde 7.31428 Mbps do x=

Se o aplicativo de FTP apoia somente um tamanho de janela de 32,000 bytes, use esta fórmula.

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

    onde 3.657142 Mbps do x=

Com TFTP, o remetente envia 512 pacotes de bytes e deve receber um reconhecimento para trás para cada pacote antes que enviem o próximo pacote. O melhor cenário de caso é enviar a 1 pacote cada Senhora 70. Use este cálculo de ritmo de transferência.

  • 1 pacote /.070s = 14.28571 pacotes/em segundo

    512 bytes/pacote * 8 bit/byte * 14.28571 pacotes/em segundo = 58.514 kbps

Este cálculo de ritmo de transferência demonstra que o atraso através de um link e do tamanho da janela TCP pode dramaticamente afetar a taxa de transferência através desse link quando usa aplicativos TCP/IP medir a taxa de transferência. Identifique a taxa de transferência prevista para cada conexão de TCP. Se o FTP é usado para testar a taxa de transferência, comece acima transferências de arquivo múltiplo entre clientes e servidor diferentes identificar se a taxa de transferência está limitada pela natureza inerente do TCP/IP, ou se há outros problemas com o circuito ATM. Se o aplicativo de TCP/IP limita a taxa de transferência, você deve poder ter os servidores múltiplos que enviam ao mesmo tempo e em taxas similares.

Em seguida, mostre que você pode transmitir o tráfego através do link na taxa scr do circuito. Para fazer isto, use um origem de tráfego e ligue-o que não use o TCP e envie um fluxo de dados através do ATM VC. Igualmente verifique que a taxa recebida é igual à taxa enviada. Envie pacotes do ping estendido de um roteador com uns 0 valores de intervalo para gerar o tráfego através de um circuito ATM. Isto mostra que você pode enviar o tráfego através do link na taxa configurada do circuito.

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

Importante: Com um RTT muito pequeno e um tamanho de janela grandes bastante para encher teoricamente o SCR, você nunca poderá alcançar o SCR devido ao overhead de ATM. Se você considera o exemplo dos pacotes do 512-byte enviados através de um 4 Mbps (SCR=PCR) AAL5SNAP PVC, calcule a taxa de transferência real IP que é medida. Supõe-se que o tamanho da janela TCP e o RTT são tal que a fonte pode enviar dados no 4 Mbps. Antes de mais nada, a camada de adaptação ATM 5 (AAL5) e a PRESSÃO introduzem cada 8 bytes de sobrecarga. Devido a isto, pode ser necessário acolchoar a fim certificar-se que a unidade de dados de protocolo (PDU) AAL5 pode ser dividida por 48. Então, em cada pilha, os bytes de sobrecarga 5 são introduzidos pela pilha. Neste caso significa que a camada AAL5 é os bytes 512+8+8=528 (nenhum estofamento necessário). Estes 528 bytes exigem 11 pilhas ser transmitidos. Isto significa aquele para que cada pacote do 512-byte envie, 583 bytes é enviado no fio (11 * 53). Ou seja 71 bytes de sobrecarga são introduzidos. Isto significa que somente 88% da largura de banda pode ser usado pelos pacotes IP. Consequentemente, com o 4 Mbps PVC, significa que a taxa de transferência útil IP é somente sobre o 3.5 Mbps.

Menor o tamanho do pacote, mais grande o aéreo e mais baixo a taxa de transferência.

Perda de pacote

A maioria de motivo comum para problemas de desempenho é devido à perda de pacotes através dos circuitos ATM. Toda a perda de célula através de um circuito ATM conduz à degradação do desempenho. A perda de pacotes significa a retransmissão e igualmente a redução de tamanho da janela TCP. Isto conduz ao throughput mais baixo. Geralmente, um teste do ping simples identifica se há uma perda de pacotes entre os dois dispositivos. Os erros e a pilha/quedas de pacote de informação da verificação de redundância cíclica (CRC) no ATM circuitam o resultado na retransmissão dos dados. Se as células ATM são rejeitadas por um switch ATM devido ao policiamento ou protegem a exaustão, os erros CRC estão considerados no dispositivo final quando as pilhas são remontadas em pacotes. Os dispositivos de ponta ATM podem deixar cair ou atrasar pacotes quando a taxa do pacote externo em um VC excede a taxa de molde de tráfego configurada no VC.

Veja estes documentos para detalhes em pesquisar defeitos a maioria de causas comum da perda de pacotes através das redes ATM:

Solução: Pesquise defeitos e elimine toda a perda de pacotes.

Atraso/latência

A quantidade de tempo que toma para que um pacote viaje da fonte ao destino, e então para que um reconhecimento retorne ao remetente, pode dramaticamente afetar a taxa de transferência que é considerada sobre esse circuito. O atraso sobre um circuito ATM pode ser o resultado do retardo de transmissão normal. Toma menos tempo enviar um pacote de New York a Washington do que de New York a Los Angeles quando o circuito ATM está à mesma velocidade. Outras fontes para o atraso são retardo de enfileiramento através do Roteadores e do Switches e retardo de processamento através dos dispositivos de roteamento da camada 3. O retardo de processamento associado com os dispositivos de roteamento depende pesadamente da plataforma usada e do trajeto de switching. Os detalhes associados com o atraso do roteamento e o atraso do hardware interno são além do alcance deste documento. Este atraso afeta todo o roteador apesar dos tipos de interface. É igualmente insignificante comparado ao atraso associado com a transmissão de pacotes e o Enfileiramento. Contudo, se os processos de roteador que comutam o tráfego, ele podem conduzir a um atraso significativo e devem ser tomados na consideração.

O atraso é medido tipicamente com o uso dos pacotes de ping entre dispositivos finais determinar o retardo round trip médio e máximo. As medidas do atraso devem ser conduzidas durante o uso máximo assim como períodos de inatividade. Isto ajuda a determinar se o atraso pode ser atribuído ao retardo de enfileiramento em interfaces congestionadas.

Congestão de resultados das relações em um retardo de enfileiramento. A congestão resulta tipicamente das más combinações da largura de banda. Por exemplo, se você tem um circuito através de um switch ATM que atravessasse de uma relação OC-12 a uma interface ATM DS3, você pôde experimentar um retardo de enfileiramento. Isto acontece como as pilhas chegam na relação OC-12 mais rapidamente do que eles pode ser output na relação DS3. Os roteadores de ponta ATM que sãos para o modelagem de tráfego restringido a taxa em que output o tráfego na relação. Se a taxa de chegada do tráfego que está destinado ao ATM VC é maior do que as taxas de molde de tráfego na relação, a seguir os pacotes/pilhas estão enfileirados na relação. Tipicamente, o atraso introduzido com o retardo de enfileiramento é o atraso que causa problemas de desempenho.

Solução: Execute características da Classe de serviço IP ao ATM (CoS) para o serviço diferenciado. Utilize características como o Class Based Weighted Fair Queuing (CBWFQ) e o Low Latency Queuing (LLQ) para reduzir ou eliminar o retardo de enfileiramento para o tráfego crítico da missão. Aumente a largura de banda dos circuitos virtuais para eliminar a congestão.

Configuração traffic shaping

O ATM PVCs e os SVC têm os parâmetros do Qualidade de Serviço (QoS) associados com cada circuito. Um contrato de tráfego é estabelecido entre o dispositivo de ponta ATM e a rede. Quando os PVC são usados, este contrato está configurado manualmente na rede ATM (Switches ATM). Com SVC, a Sinalização ATM é usada para estabelecer este contrato. Os dispositivos de ponta ATM traficam dados da forma para conformar-se com o contrato especificado. Os dispositivos da rede ATM (Switches ATM) monitoram o tráfego no circuito para a conformidade com o contrato especificado e etiquetam (marca) ou rejeitam o tráfego (da polícia) que não se conforma.

Se um dispositivo de ponta ATM tem a taxa de célula de pico (PCR) /SCR configurada para uma taxa mais altamente do que é fornecida na rede, a perda de pacotes é um resultado provável. As taxas de molde de tráfego configuradas no dispositivo de ponta devem combinar o que é fim-a-fim configurado através da rede. Verifique que a configuração combina através de todos os dispositivos configurados. Se o dispositivo de ponta envia as pilhas na rede que não se conformam ao contrato que é fornecida durante todo a rede, as pilhas rejeitadas dentro da rede são consideradas tipicamente. Isto pode geralmente ser detectado pelo recibo dos erros CRC na ponta oposta quando o receptor tenta remontar o pacote.

Um dispositivo de ponta ATM com o PCR/SCR configurado para uma taxa mais baixo do que é fornecida no desempenho degradado das causas da rede. Nesta situação, a rede é configurada para fornecer mais largura de banda do que o dispositivo de ponta envia. Esta circunstância pode conduzir ao retardo de enfileiramento e mesmo às quedas da fila de saída adicionais na interface de saída do ATM Router da borda.

Os SVC são configurados nos dispositivos de ponta mas a rede não pode estabelecer o SVC fim-a-fim com os mesmos parâmetros de tráfego. Os mesmos conceitos e problemas aplicam-se aos SVC que se aplicam com PVC. A rede não pode estabelecer o SVC fim-a-fim com as mesmos classes e parâmetros de QoS. Este tipo de problema é causado tipicamente com um erro ou questões de interoperabilidade. Quando um SVC é sinalizado, a chamada originada especifica os parâmetros de modelagem de tráfego de QoS na direção de avanço e retrocesso. Pode acontecer que o número chamado não instala o SVC com os parâmetros moldados apropriados. A configuração do modelagem de tráfego restrito em interfaces do roteador pode impedir que os SVC estado setup com parâmetros moldados que são diferentes daqueles configurados.

O usuário deve seguir o trajeto do SVC através da rede e verificar que se estabelece com o uso da classe e dos parâmetros de QoS que são configurados no dispositivo de origem.

Solução: Elimine más combinações do modelagem de tráfego/configuração das normas. Se os SVC são usados, verifique que são fim-a-fim setup com dar forma/parâmetros de vigilância corretos. Configurar o modelagem de tráfego restrito em interfaces do ATM Router com o comando atm sig-traffic-shaping strict.

SVC que distribuem sobre trajetos não-otimizados

Os SVC que são configurados para a taxa de bits não especificada (CBR) podem obter a instalação sobre trajetos não-otimizados. UM UBR VC é limitado na largura de banda à linha taxa dos links que o VC atravessa. Consequentemente, se um link de alta velocidade era ir para baixo, os VC que transversal que o link pudesse obter restabeleceu sobre um link mais lento. Mesmo quando o link de alta velocidade é restaurado, os VC não estão rasgados para baixo e estão restabelecidos sobre o link mais rápido. Isto é porque o trajeto mais lento satisfaz os parâmetros de QoS (não especificads) pedidos. Este problema é muito comum nas redes de pista que têm caminhos alternativos através da rede. Nos casos em que os caminhos alternativos estão à mesma velocidade do link, a falha de um dos links faz com que todos os SVC sejam distribuídos sobre o mesmo trajeto. Esta situação pode dramaticamente afetar a taxa de transferência e o desempenho da rede desde que a largura de banda efetiva da rede é cortada ao meio.

Mesmo a taxa de bits variável (CBR) e a taxa de bits constante (CBR) SVC podem obter roteados sobre trajetos não-otimizados. Os dispositivos finais pedem os parâmetros de tráfego específicos (PCR, SCR, tamanho de intermitência máxima {MBS}). O objetivo do Private Network-Network Interface (PNNI) e da Sinalização ATM é fornecer um trajeto que cumpra os requisitos de QoS do pedido. No caso dos atendimentos CBR e VBR-rt, isto igualmente inclui o retardo de transferência máxima de célula. Um trajeto pode satisfazer as exigências especificadas pelo solicitador do ponto de vista da largura de banda, mas não ser o caminho ótimo. Este problema é comum quando há os trajetos com atraso mais longo que ainda cumprem os requisitos de largura de banda para VBR e CBR VC. Isto pode ser percebido como um problema de desempenho ao cliente que vê agora características de retardo maiores através da rede.

Solução: Os SVC através de uma rede ATM são por encomenda estabelecido e não estão rasgados tipicamente para baixo e estão redistribuídos sobre um trajeto diferente a menos que o SVC for rasgado para baixo (devido à inatividade ou liberado por outras razões). O Cisco lightstream 1010 e o Catalyst 8500 Switches ATM fornecem a característica macia da otimização da rota PVC. Esta característica fornece a capacidade para redistribuir dinamicamente um PVC macio quando uma rota melhor está disponível. Uma funcionalidade similar não está disponível para os SVC que não terminam em Switches ATM.

Uma solução possível a este problema é usar PVC entre os dispositivos de ponta ATM e Switches ATM conectado. O Soft PVCs com a otimização da rota configurada entre Switches ATM fornece a capacidade para redistribuir o tráfego dos trajetos não-otimizados após a falha do link e a recuperação subsequente.

Configurar o intervalo de idle timeout para que os SVC sejam baixos de modo que os SVC sejam rasgados para baixo e restabeleçam mais frequentemente. Use o comando do [minimum-rate] dos segundos do quietude-intervalo mudar a quantidade de tempo e as taxas de tráfego que fazem com que o SVC seja rasgado para baixo. Isto não pode provar muito eficaz desde que o VC tem que ser inativo a fim obter redistribuído sobre o caminho ótimo.

Se falha toda mais, certifique-se de que o caminho ótimo esteve restaurado à operação e salte-se então uma das interfaces ATM associadas com o caminho redundante da velocidade lenta ou uma das interfaces do roteador que terminam o SVC.

Problemas de hardware

Problemas de desempenho PA-A1

A arquitetura do adaptador da porta ATM PA-A1 e da falta da memória integrada pode conduzir ao desempenho degradado. Este problema pode manifestar-se no aborto, passa, ignora, e CRC na relação. O problema é combinado quando usado com um Cisco 7200 Router com NPE-100/175/225/300.

Refira pesquisando defeitos erros de entrada nos adaptadores da porta ATM PA-A1 para a informação adicional.

Solução: Substitua os adaptadores da porta ATM PA-A1 com os adaptadores da porta ATM PA-A3 (pelo menos Revision 2) ou PA-A6.

Versão 1 PA-A3

PA-A3 a revisão de hardware 1 não remonta pilhas nos pacotes que usam o ram estática (SRAM) a bordo no adaptador de porta. O adaptador para a frente as pilhas através do barramento da interconexão de componente periférico (PCI) memória ao host do Versatile Interface Processor (VIP) ou do Network Processing Engine (NPE) onde remonta os pacotes. Isto conduz aos problemas relacionados ao desempenho similares como aqueles vistos com o adaptador da porta ATM PA-A1.

Refira pesquisando defeitos erros da entrada e saída nos adaptadores da porta ATM PA-A3 para a informação adicional.

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

Dual o PA-A3 PA no VIP2-50

O PA-A3-OC3SMM, o PA-A3-OC3SMI, e o PA-A3-OC3SML estão projetados fornecer o desempenho de switching máximo quando um adaptador da porta única é instalado em um único VIP2-50. Um único PA-A3-OC3SMM, PA-A3-OC3SMI, ou PA-A3-OC3SML em um VIP2-50 fornecem até aproximadamente 85,000 pacotes por segundo de capacidade de switching em cada sentido usando 64 pacotes de bytes. Note que um único PA-A3-OC3SMM, PA-A3-OC3SMI, ou PA-A3-OC3SML apenas podem usar a capacidade de switching inteira de um único VIP2-50.

Para os aplicativos que exigem a densidade máxima de porta ou uns mais baixos custos de sistema, as configurações de adaptador da porta dual com a versão OC-3/STM-1 do PA-A3 no mesmo VIP2-50 são apoiadas agora. Os dois adaptadores de porta no mesmo VIP2-50 compartilham de aproximadamente 95,000 pacotes por segundo de capacidade de switching em cada sentido usando 64 pacotes de bytes.

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

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

Estas advertências de desempenho devem ser consideradas quando você designa redes ATM com o PA-A3-OC3SMM, o PA-A3-OC3SMI, ou o PA-A3-OC3SML. Segundo o projeto, o desempenho de adaptadores da porta dual no mesmo VIP2-50 pode ou não pode ser aceitável.

Refira as configurações PA-A1 e PA-A3 VIP2 apoiadas para a informação adicional.

Problemas NA LANE

Domínio de transmissão LANE

Os números excessivos de sistemas finais em único LANE ELAN podem significativamente degradar o desempenho de todas as estações final. Um ELAN representa um domínio de transmissão. Todas as estações de trabalho e server dentro do ELAN recebem a transmissão, e possivelmente o tráfego multicast de todos os outros dispositivos no ELAN. Se o nível do tráfego de broadcast é alto relativo à capacidade de processamento da estação de trabalho, o desempenho das estações de trabalho sofre.

Solução: Restrinja o número de estações final dentro de um único ELAN a menos de 500. Monitore a rede para a transmissão/tempestades de transmissão múltiplas que podem adversamente afetar o server/desempenho de estação de trabalho.

Refira recomendações de projeto da pista para a informação adicional.

Tráfego e alterações de topologia de Spanning Tree excessivos do LE-ARP

Outros problemas que podem conduzir aos desempenhos ruim em uma rede de pista são atividade e alterações de topologia de Spanning Tree do LANE excessivo ARP (LE-ARP). Estes problemas conduzem aos LE-ARP não resolvidos que conduzem para traficar enviado sobre o barramento. Isto pode igualmente conduzir à utilização elevada da CPU nos LEC na rede que pode igualmente causar problemas relacionados ao desempenho. Mais informação sobre estes problemas pode ser encontrada na medida do Troubleshooting - árvore sobre o LANE.

Configurar o portfast de Spanning Tree nas portas de host de Switch Ethernet anexados LANE para reduzir alterações de topologia de Spanning Tree. Configurar a nova verificação local do LE-ARP nos Catalyst 5000 e 6000 Switches configurados para que o LANE reduza o tráfego do LE-ARP.

Os dados VBR-NRT dirigem SVC

Usando a versão LANE 1, os SVC são categoria de serviço estabelecida UBR. A versão LANE 2 apoia a capacidade aos dados SVC diretos para ser estabelecido com o uso de categorias de outro serviço como o VBR-NRT. Um terço de vendedor do partido tem um erro em sua aplicação do cliente LANE que pode causar aos dados os SVC diretos que se estabelecem aos dispositivos Cisco para ser VBR-NRT com um SCR de 4 kbps. Se seu backbone ATM consiste em OC-3 (155 Mbps) e (622 Mbps) os enlaces de tronco OC-12 e você estabelecem o SVC sobre aqueles troncos com uma taxa de célula sustentada de 4 kbps, seu desempenho sofre. Quando este problema particular não for comum, indica uma necessidade importante quando você pesquisa defeitos problemas de desempenho sobre circuitos ATM. Você deve seguir o trajeto que seus SVC atravessam através da rede e confirma que o VC foi estabelece com a categoria e os parâmetros de tráfego de serviço desejado.

Os dados VC diretos não são estabelecidos

A direção de dados lane VC é os SVC pontos a ponto bidirecionais que se estabelecem entre dois clientes de LAN Emulation (LEC) e se são usados aos dados de intercâmbio entre aqueles clientes. Os clientes LANE enviam pedidos do LE-ARP aprender os endereços ATM associados com um MAC address. Tentam então estabelecer um VC de dados direitos a esse endereço ATM. Antes do estabelecimento do VC de dados direitos, pacotes do unicast desconhecido da inundação dos clientes LANE à transmissão e servidor desconhecido (BARRAMENTO). Um cliente LANE pode não estabelece um VC de dados direitos a um outro LEC com a finalidade de enviar-lhe dados do unicast. Se isto acontece, a degradação do desempenho pode resultar. O problema é significativo se o dispositivo escolhido executar os serviços de barramento é de fraca potência, inadequado, ou sobrecarregado. Além, algumas Plataformas podem os unicasts do limite de taxa que são enviados ao BARRAMENTO. O módulo LANE do Catalyst 2900XL é uma tal caixa que estrangula o tráfego de unicast enviado ao BARRAMENTO quando o Catalyst 5000 and Catalyst 6000 não fizer.

Os dados SVC direto podem não estabelecem nem não se usam para qualqueras um razões:

  • O LEC não recebe uma resposta ao pedido do LE-ARP.

  • O SVC não pode ser criado devido às edições do roteamento ou da sinalização ATM.

  • Falha do protocolo de mensagem do resplendor LANE. Uma vez que o VC de dados direitos é estabelecido, o LEC envia um pedido nivelado no Muticast envia o VC para assegurar-se de que todos os frames de dados que foram enviados sobre o BARRAMENTO alcancem seu destino. Quando o LEC que enviou o pedido nivelado recebe uma resposta para trás, começa a enviar dados sobre o VC de dados direitos. O mecanismo nivelado pode ser desabilitado com o comando no lane client flush.

Problemas no IMA

UBR PVC em relações IMA

O UBR VC em relações do inverse multiplexing (IMA) estabelece-se com um PCR do 1.5 Mbps em vez da soma de todas as interfaces física do Up/Up que são configuradas no grupo IMA. Esta circunstância degrada o desempenho desde que o VC é tráfego dado forma em uma taxa mais baixo do que a largura de banda combinada de todos os links no grupo IMA.

Originalmente, a largura de banda de uma relação do grupo IMA foi limitada ao número mínimo de links IMA ativos necessários manter acima a relação IMA. O comando definir este valor é Ative-links-minimum IMA. Por exemplo, se quatro interfaces ATM físicas estão configuradas como membros do grupo IMA zero e o valor do Ative-links-minimum IMA está ajustado a um, a largura de banda é igual a um T1 ou a 1.5 Mbps, não 6 Mbps.

O CSCdr12395 da identificação de bug Cisco (clientes registrados somente) muda este comportamento. O adaptador PA-A3-8T1IMA usa agora a largura de banda de todas as interfaces física do Up/Up ATM configuradas como membros do grupo IMA.

O Bug da Cisco ID CSCdt67354 (clientes registrados somente) e CSCdv67523 (clientes registrados somente) é requisições de aprimoramento subsequentes atualizar a largura de banda do grupo IMA VC quando uma relação é adicionada ou removida do grupo IMA, de shut/no fechado ou de saltos devido a uma falha do link, ou mudança na extremidade remota. As mudanças executadas no Bug da Cisco IDCSCDR12395 (clientes registrados somente) configuram a largura de banda do grupo IMA à largura de banda total de seus enlaces membros somente quando o grupo IMA vem acima. Mudanças ao grupo IMA depois que a inicial acima do estado não é refletida.

Refira pesquisando defeitos enlaces ATM no Adaptador da Porta IMA 7x00 para a informação adicional.

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: 42360