Modo de transferencia asíncrona (ATM) : IP por ATM

Rendimiento lento de la red ATM

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento discute las causas generales y del específico para el rendimiento lento en las redes ATM y los procedimientos para ayudar a resolver problemas el problema. El foco de este documento está en la localización de averías de los problemas de rendimiento IP, específicamente en las redes ATM. Típicamente, el funcionamiento se mide con el uso del retardo y de la producción. El funcionamiento se prueba a menudo con el uso del FTP o de otras aplicaciones TCP/IP de transferir un archivo entre los dispositivos del dos extremos y después de medir el tiempo que toma para transferir el archivo. Cuando el índice de rendimiento de procesamiento considerado con la transferencia de archivos no iguala el ancho de banda que está disponible sobre el circuito atmósfera, esto se percibe como problema de rendimiento. Hay muchos factores tales como configuraciones de la ventana TCP, MTU, pérdida del paquete, y retrasa que determinen la producción que se considera a través de un circuito atmósfera. Este documento aborda los problemas que afectan al funcionamiento sobre los circuitos virtuales permanentes ruteados atmósfera (PVC), los circuitos virtuales conmutados (SVC), y las implementaciones del LAN Emulation (LANE). La causa de los problemas de rendimiento es común entre el PVC ruteado, SVC, y las implementaciones LANE.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Antecedentes

El primer paso cuando usted resolver problemas cualquier asunto relacionado con el rendimiento es seleccionar la fuente única y los dispositivos de destino para probar en medio. Identifique las condiciones bajo las cuales el problema ocurre y las que no lo hagan. Seleccione los dispositivos de la prueba para reducir la complejidad del problema. Por ejemplo, no pruebe entre los dispositivos que son diez routers saltos aparte si existe el problema cuando usted pasa a través de dos Routers.

Una vez que se seleccionan los dispositivos de la prueba, determine si el funcionamiento se relaciona con la naturaleza inherente a las aplicaciones TCP o si el problema es causado por otros factores. Haga ping entre los dispositivos extremos para determinar si ocurre la pérdida del paquete y el retardo de ida y vuelta para los paquetes ping. Las pruebas de ping se deben lograr con diversos tamaños de paquetes para determinar si los tamaños del paquete afectan a la pérdida del paquete. Las pruebas de ping se deben hacer de los dispositivos extremos bajo prueba y no del Routers. El Round Trip Time (RTT) ese usted ve cuando usted hace ping a y desde un router no puede ser exacto. Esto es porque el proceso de ping es un proceso de baja prioridad en el router y puede no contestar inmediatamente al ping.

Problemas Comunes

Naturaleza inherente del TCP/IP

Un cliente tiene una atmósfera PVC entre Nueva York y Los Angeles. El virtual circuit (VC) se configura con una velocidad continua de celda (SCR) de 45 Mbps. El cliente prueba este circuito transfiriendo un archivo usando el FTP de un servidor FTP a un cliente y descubre que la producción para la transferencia de archivos está sobre el 7.3 Mbps. Cuando utilizan el TFTP, la producción cae a 58 kbps. El tiempo de la respuesta al ping entre el cliente y el servidor es el ms aproximadamente 70.

La primera cosa a entender en este ejemplo es que el TCP proporciona el transporte confiable de los datos entre los dispositivos. El remitente envía los datos en una secuencia en la cual los bytes sean identificados por los números de secuencia. El receptor reconoce que ha recibido los datos enviando el número de secuencia (número de acuse de recibo) del byte de dato siguiente que espera recibir. El receptor también hace publicidad de sus tamaños de la ventana al remitente para hacer publicidad de la cantidad de datos que pueda validar.

Los dispositivos extremos TCP/IP incluyen típicamente la capacidad de configurar los tamaños de la ventana TCP/IP.

Si los dispositivos tienen sus tamaños de la ventana TCP fijados demasiado bajos, esos dispositivos pueden no poder utilizar el ancho de banda entero de un VC atmósfera.

El RTT en un VC atmósfera puede reducir dramáticamente el rendimiento de procesamiento de TCP si los tamaños de la ventana son demasiado bajos.

Un dispositivo extremo envía aproximadamente un valor de los tamaños de la ventana del tráfico en los bytes por el RTT.

Por ejemplo, si el RTT es el ms 70, utilice esta fórmula para calcular los tamaños de la ventana necesarios para llenar un DS3 entero del ancho de banda:

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

El TCP estándar permite los tamaños de ventana máximos de 64,000 bytes. Opción WINScale TCP permite que los tamaños de la ventana sean mucho más altos si los dispositivos en los ambos extremos soportan esta opción y la aplicación FTP también soporta esta opción.

Utilice esta fórmula para fijar los tamaños de la ventana en 64,000 bytes y para utilizar el RTT del ms 70 para solucionar la producción.

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

    donde 7.31428 Mbps del x=

Si la aplicación FTP soporta solamente los tamaños de la ventana de 32,000 bytes, utilice esta fórmula.

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

    donde 3.657142 Mbps del x=

Con el TFTP, el remitente envía 512 paquetes de bytes y debe recibir un acuse de recibo detrás para cada paquete antes de que envíen el próximo paquete. El mejor de los casos es enviar 1 paquete a cada ms 70. Utilice este cálculo del caudal.

  • 1 paquete /.070s = 14.28571 paquetes/en segundo lugar

    512 bytes/paquete * 8 bits/byte * 14.28571 paquetes/en segundo lugar = 58.514 kbps

Este cálculo del caudal demuestra que el retardo a través de un link y de los tamaños de la ventana TCP puede afectar dramáticamente a la producción a través de ese link cuando utiliza las aplicaciones TCP/IP para medir la producción. Identifique la producción prevista para cada conexión TCP. Si el FTP se utiliza al rendimiento total de la prueba, comience para arriba las transferencias de Archivo múltiple entre diversos clientes y servidor para identificar si la producción es limitada por la naturaleza inherente del TCP/IP, o si hay otros problemas con el circuito atmósfera. Si la aplicación TCP limita la producción, usted debe poder tener servidores múltiples que envíen al mismo tiempo y a las tarifas similares.

Después, pruebe que usted puede transmitir el tráfico a través del link a la velocidad de SCR del circuito. Para hacer esto, utilice una fuente del tráfico y conecte que no utilice el TCP y envíe un flujo de datos a través del VC atmósfera. También verifique que la tarifa recibida sea igual a la tarifa enviada. Envíe los paquetes del ping extendido de un router con el valor del time out del a0 para generar el tráfico a través de un circuito atmósfera. Esto prueba que usted puede enviar el tráfico a través del link a la velocidad configurada del circuito.

Solución: Aumente los tamaños de la ventana TCP/IP.

Importante: Con un RTT muy pequeño y los tamaños de la ventana bastante grandes llenar teóricamente el SCR, usted nunca podrá alcanzar el SCR debido a la overhead de ATM. Si usted considera el ejemplo de los paquetes del 512-byte enviados a través de un AAL5SNAP PVC del 4 Mbps (SCR=PCR), calcule la producción real IP se mide que. Se asume que los tamaños de la ventana TCP y el RTT son tales que la fuente puede enviar los datos en el 4 Mbps. En primer lugar, el capa 5 de adaptación del ATM (AAL5) y la BROCHE introducen cada 8 bytes de tara. Debido a esto, puede ser necesario completar para aseegurar el unidad de datos del protocolo (PDU) AAL5 puede ser dividido por 48. Entonces, en cada célula, 5 bytes de tara se introducen por la célula. En este caso significa que la capa AAL5 es los bytes 512+8+8=528 (ningún relleno necesario). Estos 528 bytes requieren 11 células ser transmitidos. Esto significa eso para que cada paquete del 512-byte envíe, 583 bytes se envía en el alambre (11 * 53). Es decir 71 bytes de tara se introducen. Esto significa que el solamente 88% del ancho de banda se pueden utilizar por los paquetes IP. Por lo tanto, con el 4 Mbps PVC, significa que la producción usable IP está solamente sobre el 3.5 Mbps.

Cuanto más pequeños es los tamaños de paquetes, más grande es el de arriba y más bajo es la producción.

Pérdida del paquete

La mayoría de las razones comunes por problemas de rendimiento son debido a la pérdida del paquete a través de los circuitos atmósfera. Cualquier pérdida de celda a través de un circuito atmósfera da lugar a la degradación del rendimiento. La pérdida del paquete significa la retransmisión y también la reducción de tamaños de la ventana TCP. Esto da lugar al menor rendimiento. Generalmente, una prueba del ping simple identifica si hay pérdida de paquetes entre los dos dispositivos. Los errores y la célula/las caídas de paquetes de la verificación por redundancia cíclica (CRC) en los circuitos atmósfera dan lugar a la retransmisión de los datos. Si un switch ATM desechan debido al policing o mitigan a las células ATM el agotamiento, los errores CRC se consideran en el dispositivo extremo cuando las células se vuelven a montar en los paquetes. Los dispositivos de borde atmósfera pueden caer o retrasar los paquetes cuando la tarifa del paquete saliente en un VC excede la velocidad de modelado de tráfico configurada en el VC.

Vea estos documentos para los detalles en la localización de averías de la mayoría de las causas comunes de la pérdida del paquete a través de las redes ATM:

Solución: Resolver problemas y elimine cualquier pérdida del paquete.

Retardo/tiempo de espera

La cantidad de tiempo que toma para que un paquete viaje de la fuente al destino, y después para que un acuse de recibo vuelva al remitente, puede afectar dramáticamente a la producción que se considera sobre ese circuito. El retardo sobre un circuito atmósfera puede ser el resultado del retraso de la transmisión normal. Lleva menos tiempo para enviar un paquete de Nueva York Washington que de Nueva York a Los Angeles cuando el circuito atmósfera es la misma velocidad. Otras fuentes para el retardo son retardo de colocación en cola a través de Routers y de Switches y retardo de procesamiento a través de los dispositivos de ruteo de la capa 3. El retardo de procesamiento asociado a los dispositivos de ruteo depende pesadamente de la plataforma usada y del trayecto de Switching. Los detalles asociados al retardo de la encaminamiento y al retardo del hardware interno están fuera del alcance de este documento. Este retardo afecta a cualquier router sin importar los tipos de interfaz. Es también insignificante comparado al retardo asociado a la transmisión de paquetes y a los Datos en espera. Sin embargo, si los procesos del router que conmutan el tráfico, él pueden dar lugar a un retraso importante y se deben tomar en la consideración.

El retardo se mide típicamente con el uso de los paquetes ping entre los dispositivos extremos de determinar el retardo de ida y vuelta medio y máximo. Las medidas del retardo se deben conducir durante el uso máximo así como los períodos de inactividad. Esto ayuda a determinar si el retardo se puede atribuir al retardo de colocación en cola en las interfaces congestionadas.

Congestión de los resultados de las interfaces en un retardo de colocación en cola. La congestión resulta típicamente de las discordancías del ancho de banda. Por ejemplo, si usted tiene un circuito a través de un switch ATM que atraviese de una interfaz OC-12 a una interfaz ATM DS3, usted puede ser que experimente un retardo de colocación en cola. Esto sucede como las células llegan en la interfaz OC-12 más rápidamente que ellos se puede hacer salir en la interfaz DS3. Los routeres de borde atmósfera que se configuran para el modelado de tráfico restringen la tarifa en la cual hacen salir el tráfico en la interfaz. Si la velocidad de llegada del tráfico que se destina al VC atmósfera es mayor que las velocidades de modelado de tráfico en la interfaz, después los paquetes/las células se hacen cola en la interfaz. Típicamente, el retardo introducido con el retardo de colocación en cola es el retardo que causa los problemas de rendimiento.

Solución: Implemente las características del (CoS) de la Clase de Servicio IP a ATM para el servicio diferenciado. Utilice las características como el Class Based Weighted Fair Queuing (CBWFQ) y el Low Latency Queuing (LLQ) para reducir o para eliminar el retardo de colocación en cola para el tráfico crítico de la misión. Aumente el ancho de banda de los circuitos virtuales para eliminar la congestión.

Configuración de modelado del tráfico

El ATM PVC y los SVC tienen parámetros de Calidad de Servicio (QoS) asociados a cada circuito. Un contrato de tráfico se establece entre el dispositivo de borde atmósfera y la red. Cuando se utilizan los PVC, este contrato se configura manualmente en la red ATM (Switches ATM). Con los SVC, la Señalización ATM se utiliza para establecer este contrato. Los dispositivos de borde atmósfera trafican los datos de la dimensión de una variable para conformar con el contrato especificado. Los dispositivos de la red ATM (Switches ATM) monitorean el tráfico en el circuito para la conformidad con el contrato especificado y marcan (marca) o desechan el tráfico (de la policía con etiqueta) que no conforma.

Si un dispositivo de borde atmósfera tiene velocidad de célula de cresta (PCR) /SCR configurada para una tarifa más arriba que el aprovisionado en la red, la pérdida del paquete es un resultado probable. Las velocidades de modelado de tráfico configuradas en el dispositivo de borde deben hacer juego cuál es de punta a punta configurado a través de la red. Verifique que la configuración haga juego a través de todos los dispositivos configurados. Si el dispositivo de borde envía las células en la red que no se ajustan al contrato que es aprovisionado en la red, las células desechadas dentro de la red se consideran típicamente. Esto se puede detectar generalmente por el recibo de los errores CRC en el otro extremo cuando el receptor intenta volver a montar el paquete.

Un dispositivo de borde atmósfera con el PCR/SCR configurado para una tarifa más bajo que el aprovisionado en el rendimiento disminuido de las causas de la red. En esta situación, la red se configura para proporcionar más ancho de banda que el dispositivo de borde envía. Esta condición puede dar lugar al retardo de colocación en cola e incluso a las pérdidas de la cola de salida adicionales en la interfaz de egreso del router de ATM del borde.

Los SVC se configuran en los dispositivos de borde pero la red puede no establecer SVC de punta a punta con los mismos parámetros del tráfico. Los mismos conceptos y problemas se aplican a los SVC que se aplican con los PVC. La red puede no configurar SVC de punta a punta con las mismas clases y parámetros de QoS. Causan este tipo de problema típicamente con un bug o los problemas de interoperabilidad. Cuando se señala SVC, la parte llamadora especifica los parámetros de modelado del tráfico de QoS en la dirección hacia adelante y hacia atrás. Puede suceder que la Parte llamada no instala SVC con los parámetros de modelado apropiados. La configuración del modelado de tráfico estricto en las interfaces del router puede evitar que los SVC sean puestos con los parámetros de modelado que están con excepción de ésos configurados.

El usuario debe localizar la trayectoria de SVC a través de la red y verificarla que está establecido con el uso de la clase y de los parámetros de QoS que se configuran en el dispositivo de origen.

Solución: Elimine las discordancías del modelado de tráfico/de la configuración de la política. Si se utilizan los SVC, verifique que sean de punta a punta puesto con el shaping/los parámetros de regulación de tráfico correctos. Configure el modelado de tráfico estricto en las interfaces del router ATM con el comando atm sig-traffic-shaping strict.

SVC que rutean sobre las trayectorias no óptimas

Los SVC que se configuran para la Velocidad de bit sin especificar (UBR) pueden conseguir la configuración sobre las trayectorias no óptimas. UN VC UBR se limita en el ancho de banda a la línea tarifa de los links que el VC atraviesa. Por lo tanto, si un link de alta velocidad era ir abajo, el VCs que transversal que el link puede conseguir restableció sobre un link más lento. Incluso cuando se restablece el link de alta velocidad, el VCs no se derriba y se restablece sobre el link más rápido. Esto es porque la trayectoria más lenta satisface los parámetros de QoS (sin especificar) pedidos. Este problema es muy común en las redes LANe que tienen trayectos alternos a través de la red. En los casos en los cuales los trayectos alternos son la misma velocidad del link, el error de uno de los links hace todos los SVC ser ruteado sobre la misma trayectoria. Esta situación puede afectar dramáticamente a la producción y al funcionamiento de la red puesto que el ancho de banda efectivo de la red se corta por la mitad.

Incluso el Velocidad de bits variable (VBR) y Velocidad de bits constante (CBR) los SVC puede conseguir ruteado sobre las trayectorias no óptimas. Los dispositivos extremos piden los parámetros del tráfico específicos (PCR, SCR, los tamaños máximos de ráfaga {MBS}). La meta del Private Network-Network Interface (PNNI) y de la Señalización ATM es proporcionar una trayectoria que cumpla los requisitos de QoS de la petición. En el caso de las llamadas CBR y VBR-rt, esto también incluye el retardo de transferencia de célula máximo. Una trayectoria puede satisfacer los requisitos especificados por el solicitante desde el punto de vista del ancho de banda, pero no ser el trayecto óptimo. Este problema es común cuando hay las trayectorias con un retardo más largo que todavía cumplen los requerimientos de ancho de banda para VBR y CBR VCs. Esto se puede percibir como problema de rendimiento al cliente que ahora ve características de retraso más grandes a través de la red.

Solución: Los SVC a través de una red ATM se establecen a pedido y típicamente no se derriban y se rerrutean sobre una diversa trayectoria a menos que se derribe SVC (debido a la inactividad o liberado por otros motivos). El Cisco lightstream 1010 y el Switches ATM del Catalyst 8500 proporcionan la característica de la optimización de la ruta del PVC de software. Esta característica proporciona la capacidad de rerrutear dinámicamente un PVC de software cuando una mejor ruta está disponible. Las funciones similares no están disponibles para los SVC que no terminan en el Switches ATM.

Una Solución posible a este problema es utilizar los PVC entre los dispositivos de borde atmósfera y el Switches ATM conectado. Los PVC suaves con la optimización de la ruta configurada entre el Switches ATM proporcionan la capacidad de rerrutear el tráfico de las trayectorias no óptimas después de la falla de link y de la recuperación posterior.

Configure el intervalo del tiempo de espera para que los SVC sean bajos para derribar los SVC y restablezcan más con frecuencia. Utilice el comando del [minimum-rate] de los segundos del ocioso-descanso de cambiar la cantidad de tiempo y las relaciones del tráfico que hacen SVC ser derribadas. Esto puede no probar muy eficaz puesto que el VC tiene que estar inactivo para conseguir rerruteado sobre el trayecto óptimo.

Si todo falla, aseegure que el trayecto óptimo se ha restablecido a la operación y después despida una de las interfaces ATM asociadas al trayecto redundante despacio o una de las interfaces del router que terminen SVC.

‘Problemas del hardware

Problemas de rendimiento PA-A1

La arquitectura del adaptador de puerto ATM PA-A1 y de la falta de memoria integrada a la placa puede dar lugar al rendimiento disminuido. Este problema puede manifestarse en el aborto, sobra, ignora, y los CRC en la interfaz. Se compone el problema cuando está utilizado con un Cisco 7200 Router con el NPE-100/175/225/300.

Refiera a los errores de entrada del troubleshooting en los adaptadores de puerto ATM PA-A1 para la información adicional.

Solución: Adaptadores de puerto ATM del reemplace PA-A1 con los adaptadores de puerto ATM PA-A3 (por lo menos revisión 2) o PA-A6.

Versión 1 PA-A3

PA-A3 la revisión de hardware 1 no vuelve a montar las células en los paquetes que utilizan el a bordo RAM estática (SRAM) en el adaptador de puerto. El adaptador adelante las células a través del bus del Interconexión de componentes periféricos (PCI) memoria al host del Versatile Interface Processor (VIP) o del Network Processing Engine (NPE) donde vuelve a montar los paquetes. Esto da lugar a los problemas relacionados con el rendimiento similares como ésos vistos con el adaptador de puerto ATM PA-A1.

Refiera a los errores de la entrada y salida del troubleshooting en los adaptadores de puerto ATM PA-A3 para la información adicional.

Solución: Substituya PA-A3 los adaptadores de puerto ATM de la revisión de hardware 1 por los adaptadores de puerto ATM PA-A3 (por lo menos revisión 2) o PA-A6.

Se dobla el PA-A3 PA en el VIP2-50

El PA-A3-OC3SMM, el PA-A3-OC3SMI, y el PA-A3-OC3SML se diseñan para proporcionar el rendimiento de Switching máximo cuando un adaptador del puerto único está instalado en un solo VIP2-50. Un solo PA-A3-OC3SMM, PA-A3-OC3SMI, o PA-A3-OC3SML en un VIP2-50 proporciona hasta aproximadamente 85,000 paquetes por segundo de Switching Capacity en cada dirección usando 64 paquetes de bytes. Observe que un solo PA-A3-OC3SMM, PA-A3-OC3SMI, o PA-A3-OC3SML solamente pueden utilizar el Switching Capacity entero de un solo VIP2-50.

Para las aplicaciones que requieren la densidad de puerto máxima o el costo del sistema, las configuraciones del adaptador del puerto doble con la versión OC-3/STM-1 del PA-A3 en el mismo VIP2-50 ahora se soportan. Los adaptadores cuadripolos en el mismo VIP2-50 comparten aproximadamente 95,000 paquetes por segundo de Switching Capacity en cada dirección usando 64 paquetes de bytes.

El VIP-50 proporciona hasta 400 megabits por segundo (mbps) del ancho de banda total dependiendo de las combinaciones del adaptador de puerto. En la mayoría de las configuraciones del adaptador del puerto doble con el PA-A3-OC3SMM, el PA-A3-OC3SMI, o el PA-A3-OC3SML, la combinación de adaptadores de puerto excede esta capacidad del ancho de banda total.

Por lo tanto, el funcionamiento compartido entre los adaptadores cuadripolos instalados en el mismo VIP2-50 es limitado por el Switching Capacity global (95 kpps) en los pequeños tamaños de paquetes, y por el ancho de banda total (400 mbps) en los tamaños de paquetes grandes.

Estas advertencias de rendimiento deben ser consideradas cuando usted señala las redes ATM con el PA-A3-OC3SMM, el PA-A3-OC3SMI, o el PA-A3-OC3SML. Dependiendo del diseño, el funcionamiento de los adaptadores del puerto doble en el mismo VIP2-50 puede o no puede ser aceptable.

Refiera a las configuraciones PA-A1 y PA-A3 VIP2 soportadas para la información adicional.

Problemas LANE

Dominio de broadcast LANE

Las cantidades excesivas de sistemas extremos en solo LANE ELAN pueden degradar perceptiblemente el funcionamiento de todas las estaciones terminales. Un ELAN representa un dominio de broadcast. Todos los puestos de trabajo y servidores dentro del ELAN reciben el broadcast, y posiblemente el tráfico Multicast de todos los otros dispositivos en el ELAN. Si el nivel de tráfico de broadcast es alto en relación con la Capacidad de procesamiento del puesto de trabajo, el funcionamiento de los puestos de trabajo sufre.

Solución: Restrinja el número de estaciones terminales dentro de un solo ELAN a menos de 500. Monitoree la red para el broadcast/las tormentas de multidifusión que pueden afectar al contrario al servidor/al rendimiento de la estación de trabajo.

Refiera a las recomendaciones de diseño de LANe para la información adicional.

Tráfico y cambia la topología del árbol de expansión excesivos del LE-ARP

Otros problemas que pueden llevar a los rendimientos pobres en una red LANe son actividad y cambia la topología del árbol de expansión del excessive LANE ARP (LE-ARP). Estos problemas llevan LE-ARPs a ese sin resolver llevan para traficar enviado sobre el bus. Esto puede también llevar CPU elevada a la utilización en los LEC en la red que puede también causar los problemas relacionados con el rendimiento. Más información sobre estos problemas se puede encontrar en el Spanning-tree del troubleshooting sobre el LANE.

Configure el árbol de expansión Portfast en los puertos de host de switches de Ethernet asociados LANE para reducir los cambia la topología del árbol de expansión. Configure el reverification local del LE-ARP en los Catalyst 5000 y 6000 Switches configurados para que el LANE reduzca el tráfico del LE-ARP.

VBR-NRT vía directa de datos SVC

Usando la versión LANE 1, los SVC se configuran como categoría de servicio UBR. La versión LANE 2 soporta la capacidad a la vía directa de datos SVC de ser establecido con el uso de las categorías de otro servicio como el VBR-NRT. Una mitad vendedor del partido tiene un bug en su implementación del cliente LANE que pueda causar la vía directa de datos SVC que se configura a los dispositivos de Cisco para ser VBR-NRT con un SCR de 4 kbps. Si su estructura básica de ATM consiste en OC-3 (155 Mbps) y los links de troncal OC-12 (622 Mbps) y usted configuran SVC sobre esos trunks con una velocidad continua de celda de 4 kbps, su funcionamiento sufre. Mientras que este problema determinado no es común, señala una necesidad importante cuando usted resolver problemas los problemas de rendimiento sobre los circuitos atmósfera. Usted debe seguir la trayectoria que sus SVC atraviesan a través de la red y confirma que ha sido el VC establece con la categoría y los parámetros del tráfico de servicio deseado.

La vía directa de datos VCs no se establece

La vía directa de datos de LANE VCs es el Punto a punto bidireccional SVC que se configura entre dos (LECs) de los LAN Emulation Clients y se utiliza a los intercambiares datos entre esos clientes. Los clientes LANE envían las peticiones del LE-ARP de aprender los ATM Address asociados a una dirección MAC. Entonces intentan configurar un VC de la vía directa de datos a ese ATM Address. Antes del establecimiento del VC de la vía directa de datos, paquetes de la unidifusión desconocida de la inundación de los clientes LANE al broadcast y servidor desconocidos (BUS). Un cliente LANE puede no poder establecer un VC de la vía directa de datos a otro LEC con el fin de enviarle los datos de unidifusión. Si sucede esto, la degradación del rendimiento puede resultar. El problema es significativo si el dispositivo elegido para llevar a cabo los servicios de BUS es inframotorizado, inadecuado, o sobrecargado. Además, algunas Plataformas pueden unicasts del límite de velocidad que se remiten al BUS. El módulo LANE del Catalyst 2900XL es un tal cuadro que estrangula el tráfico de unidifusión enviado al BUS mientras que no lo hace el Catalyst 5000 and Catalyst 6000.

La vía directa de datos SVC puede no poder ser establecido o ser utilizado por ninguno de estos razones:

  • El LEC no recibe una respuesta a la petición del LE-ARP.

  • SVC no se puede crear debido a los problemas de la encaminamiento o de la señalización atmósfera.

  • Error del protocolo de mensaje del rubor LANE. Una vez que se establece el VC de la vía directa de datos, el LEC envía una petición rasante en el Muticast envía el VC para asegurarse de que todo el marco de datos que se ha enviado sobre el BUS ha alcanzado su destino. Cuando el LEC que envió la petición rasante recibe una respuesta detrás, comienza a enviar los datos sobre el VC de la vía directa de datos. El mecanismo rasante se puede inhabilitar con el comando no lane client flush.

Problemas de IMA

UBR PVC en las interfaces IMA

El UBR VCs en las interfaces del multiplexión inversa (IMA) se configura con un PCR del 1.5 Mbps en vez de la suma de todas las interfaces físicas del up/up que se configuran en el grupo IMA. Esta condición degrada el funcionamiento puesto que el VC es tráfico formado a una tarifa más bajo que el ancho de banda combinado de todos los links en el grupo IMA.

Originalmente, el ancho de banda de un grupo IMA que la interfaz fue limitada al número mínimo de IMA activo conecta necesario para guardar la interfaz IMA para arriba. El comando de definir este valor es Active-links-minimum IMA. Por ejemplo, si cuatro interfaces ATM físicas se configuran como miembros del grupo IMA cero y el valor del Active-links-minimum IMA se fija a uno, el ancho de banda es igual a un T1 o al 1.5 Mbps, no 6 Mbps.

El CSCdr12395 del Id. de bug Cisco (clientes registrados solamente) cambia este comportamiento. El adaptador PA-A3-8T1IMA ahora utiliza el ancho de banda de todas las interfaces físicas atmósfera del up/up configuradas como miembros del grupo IMA.

El bug Cisco ID CSCdt67354 (clientes registrados solamente) y CSCdv67523 (clientes registrados solamente) es pedidos de mejora subsiguientes de poner al día el ancho de banda del VC del grupo IMA cuando una interfaz se agrega o se quita del grupo IMA, de shut/no cerrado o de las despedidas debido a una falla de link, o cambio en el extremo remoto. Los cambios implementados en el bug Cisco IDCSCDR12395 (clientes registrados solamente) configuran el ancho de banda del grupo IMA al ancho de banda total de sus links de miembro solamente cuando sube el grupo IMA. Cambios al grupo IMA después de que la inicial encima del estatus no se refleje.

Refiera a los vínculos ATM del troubleshooting en el adaptador de puerto IMA 7x00 para la información adicional.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 42360