Rendimiento lento de la red ATM

Introducción

Este documento trata las causas generales y específicas del rendimiento lento en las redes ATM y los procedimientos para ayudar a resolver el problema. El objetivo de este documento es solucionar problemas de rendimiento de IP, específicamente en redes ATM. Normalmente, el rendimiento se mide con el uso del retardo y el rendimiento. El rendimiento se prueba a menudo con el uso de FTP u otras aplicaciones TCP/IP para transferir un archivo entre dos dispositivos finales y, a continuación, medir el tiempo que se tarda en transferir el archivo. Cuando la velocidad de rendimiento vista con la transferencia de archivos no iguala el ancho de banda disponible sobre el circuito ATM, esto se percibe como un problema de rendimiento. Hay muchos factores como la configuración de la ventana TCP, la MTU, la pérdida de paquetes y el retraso que determinan el rendimiento que se ve en un circuito ATM. Este documento aborda los problemas que afectan al rendimiento de los circuitos virtuales permanentes enrutados ATM (PVC), los circuitos virtuales conmutados (SVC) y las implementaciones de LAN Emulation (LANE). La causa de los problemas de rendimiento es común entre las implementaciones ruteadas de PVC, SVC y LANE.

Prerequisites

Requirements

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

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Antecedentes

El primer paso para resolver cualquier problema relacionado con el rendimiento es seleccionar dispositivos de origen y destino únicos para probar entre ellos. Identifique las condiciones bajo las cuales se produce el problema y las que no ocurre. Seleccione dispositivos de prueba para reducir la complejidad del problema. Por ejemplo, no pruebe entre los dispositivos que son diez saltos de router si el problema existe cuando pasa por dos routers.

Una vez seleccionados los dispositivos de prueba, determine si el rendimiento está relacionado con la naturaleza inherente de las aplicaciones TCP o si el problema es causado por otros factores. Ping entre los dispositivos finales para determinar si se produce la pérdida de paquetes y el retraso del viaje de ida y vuelta para los paquetes ping. Las pruebas de ping deben realizarse con diferentes tamaños de paquete para determinar si el tamaño del paquete afecta la pérdida del paquete. Las pruebas de ping se deben realizar desde los dispositivos finales sometidos a prueba y no desde los routers. Es posible que el tiempo de viaje de ida y vuelta (RTT) que se muestra al realizar un ping hacia y desde un router no sea exacto. Esto se debe a que el proceso ping es un proceso de baja prioridad en el router y es posible que no responda inmediatamente al ping.

Problemas Comunes

Naturaleza inherente de TCP/IP

Un cliente tiene un PVC ATM entre Nueva York y Los Ángeles. El circuito virtual (VC) se configura con una velocidad de celda sostenida (SCR) de 45 Mbps. El cliente prueba este circuito transfiriendo un archivo mediante FTP de un servidor FTP a un cliente y descubre que el rendimiento de la transferencia de archivos es de aproximadamente 7,3 Mbps. Cuando utilizan TFTP, el rendimiento cae a 58 Kbps. El tiempo de respuesta de ping entre el cliente y el servidor es de aproximadamente 70 ms.

Lo primero que se debe entender en este ejemplo es que TCP proporciona transporte confiable de datos entre dispositivos. El remitente envía datos en una secuencia en la que los bytes se identifican por números de secuencia. El receptor reconoce que ha recibido los datos enviando el número de secuencia (número de reconocimiento) del siguiente byte de datos que espera recibir. El receptor también anuncia su tamaño de ventana al remitente para anunciar la cantidad de datos que puede aceptar.

Los dispositivos finales TCP/IP normalmente incluyen la capacidad de configurar los tamaños de las ventanas TCP/IP.

Si los dispositivos tienen sus tamaños de ventana TCP configurados demasiado bajos, es posible que esos dispositivos no puedan utilizar todo el ancho de banda de un VC ATM.

El RTT en un VC ATM puede reducir drásticamente el rendimiento de TCP si el tamaño de la ventana es demasiado bajo.

Un dispositivo final envía aproximadamente un tamaño de ventana en bytes por RTT.

Por ejemplo, si el RTT es de 70 ms, utilice esta fórmula para calcular el tamaño de ventana necesario para llenar un DS3 completo de ancho de banda:

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

TCP estándar permite un tamaño máximo de ventana de 64.000 bytes. La opción WINScale TCP permite que el tamaño de la ventana sea mucho mayor si los dispositivos de ambos extremos admiten esta opción y la aplicación FTP también admite esta opción.

Utilice esta fórmula para establecer el tamaño de la ventana en 64.000 bytes y utilice el RTT de 70 ms para resolver el rendimiento.

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

  donde x= 7,31428 Mbps

Si la aplicación FTP sólo admite un tamaño de ventana de 32 000 bytes, utilice esta fórmula.

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

  donde x= 3,657142 Mbps

Con TFTP, el remitente envía paquetes de 512 bytes y debe recibir un reconocimiento de vuelta para cada paquete antes de enviar el siguiente paquete. El mejor escenario es enviar 1 paquete cada 70 ms. Utilice este cálculo de rendimiento.

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

  512 bytes/paquete * 8 bits/byte * 14.28571 paquetes/segundo = 58.514 Kbps

Este cálculo de rendimiento demuestra que el retraso a través de un link y el tamaño de la ventana TCP pueden afectar drásticamente el rendimiento a través de ese link cuando utiliza aplicaciones TCP/IP para medir el rendimiento. Identifique el rendimiento esperado para cada conexión TCP. Si FTP se utiliza para probar el rendimiento, inicie varias transferencias de archivos entre diferentes clientes y servidores para identificar si el rendimiento está limitado por la naturaleza inherente de TCP/IP, o si hay otros problemas con el circuito ATM. Si la aplicación TCP limita el rendimiento, debería poder tener varios servidores que envíen al mismo tiempo y a velocidades similares.

A continuación, demuestre que puede transmitir el tráfico a través del link a la velocidad SCR del circuito. Para ello, utilice un origen de tráfico y un link que no utilice TCP y envíe un flujo de datos a través del VC ATM. Verifique también que la velocidad recibida sea igual a la velocidad enviada. Envíe paquetes ping extendidos desde un router con un valor de tiempo de espera 0 para generar tráfico a través de un circuito ATM. Esto prueba que puede enviar tráfico a través del link a la velocidad configurada del circuito.

Solución: Aumente el tamaño de la ventana TCP/IP.

Importante: Con un RTT muy pequeño y un tamaño de ventana lo suficientemente grande como para llenar teóricamente el SCR, nunca podrá alcanzar el SCR debido a la sobrecarga ATM. Si considera el ejemplo de los paquetes de 512 bytes enviados a través de un PVC AAL5SNAP de 4 Mbps (SCR=PCR), calcule el rendimiento IP real que se mide. Se asume que el tamaño de la ventana TCP y el RTT son tales que el origen puede enviar datos a 4 Mbps. En primer lugar, la capa 5 de adaptación ATM (AAL5) y SNAP introducen cada 8 bytes de sobrecarga. Debido a esto, puede ser necesario rellenar para asegurarse de que la unidad de datos del protocolo AAL5 (PDU) se pueda dividir por 48. Luego, en cada celda, se introducen 5 bytes de sobrecarga por celda. En este caso, significa que la capa AAL5 es 512+8+8=528 bytes (no es necesario relleno). Estos 528 bytes requieren que se transmitan 11 celdas. Esto significa que para cada paquete de 512 bytes que se envíe, se envían 583 bytes en el cable (11 * 53). En otras palabras, se introducen 71 bytes de sobrecarga. Esto significa que sólo el 88% del ancho de banda puede ser utilizado por los paquetes IP. Por lo tanto, con el PVC de 4 Mbps, significa que el rendimiento de IP utilizable es sólo de unos 3,5 Mbps.

Cuanto menor sea el tamaño del paquete, mayor será la sobrecarga y menor será el rendimiento.

Pérdida del paquete

La razón más común para los problemas de rendimiento se debe a la pérdida de paquetes en los circuitos ATM. Cualquier pérdida de celda en un circuito ATM provoca una degradación del rendimiento. La pérdida de paquetes significa retransmisión y también reducción del tamaño de la ventana TCP. Esto da como resultado un menor rendimiento. Normalmente, una simple prueba de ping identifica si hay pérdida de paquetes entre los dos dispositivos. Los errores de verificación de redundancia cíclica (CRC) y las caídas de celdas/paquetes en los circuitos ATM dan lugar a la retransmisión de datos. Si las celdas ATM son descartadas por un switch ATM debido a la regulación del tráfico o al agotamiento del búfer, se observan errores CRC en el dispositivo final cuando las celdas se vuelven a ensamblar en paquetes. Los dispositivos de borde ATM pueden descartar o retrasar paquetes cuando la velocidad de paquetes salientes en un VC excede la velocidad de modelado de tráfico configurada en el VC.

Consulte estos documentos para obtener detalles sobre la solución de problemas de las causas más comunes de pérdida de paquetes en las redes ATM:

• Guía de resolución de problemas CRC para interfaces ATM

• Resolución de problemas de caídas de colas de salida en interfaces de router ATM

• Resolución de problemas de caídas de entrada en interfaces de router ATM

• Introducción a los contadores de celdas rechazadas/descartadas en routers de switch ATM

Solución: Solucione y elimine cualquier pérdida de paquetes.

Retraso/Latencia

La cantidad de tiempo que tarda un paquete en viajar de origen a destino, y luego para que un reconocimiento regrese al remitente, puede afectar drásticamente el rendimiento que se ve en ese circuito. El retraso sobre un circuito ATM puede ser el resultado de un retraso normal de transmisión. Se tarda menos tiempo en enviar un paquete de Nueva York a Washington que de Nueva York a Los Ángeles cuando el circuito ATM es la misma velocidad. Otras fuentes de retraso son el retraso en la cola a través de routers y switches y el retraso en el procesamiento a través de los dispositivos de ruteo de Capa 3. La demora de procesamiento asociada con los dispositivos de ruteo depende en gran medida de la plataforma utilizada y de la trayectoria de conmutación. Los detalles asociados con la demora de ruteo y el retraso interno del hardware están fuera del alcance de este documento. Este retraso afecta a cualquier router independientemente de los tipos de interfaz. También es insignificante comparado con el retraso asociado con la transmisión de paquetes y colas. Sin embargo, si un router procesa el tráfico de conmutación, puede dar lugar a un retraso significativo y debe tenerse en cuenta.

La demora se mide normalmente con el uso de paquetes ping entre los dispositivos finales para determinar la demora promedio y máxima de ida y vuelta. Las mediciones de los retrasos deben realizarse durante el uso máximo, así como durante los períodos de inactividad. Esto ayuda a determinar si el retraso se puede atribuir a un retraso en cola en interfaces congestionadas.

La congestión de las interfaces produce un retraso en la cola. La congestión suele ser el resultado de discordancias de ancho de banda. Por ejemplo, si tiene un circuito a través de un switch ATM que atraviesa desde una interfaz OC-12 a una interfaz DS3 ATM, puede experimentar un retraso en la cola. Esto sucede cuando las celdas llegan a la interfaz OC-12 más rápido de lo que se puede obtener en la interfaz DS3. Los routers de borde ATM configurados para modelado de tráfico restringen la velocidad a la que producen tráfico en la interfaz. Si la velocidad de llegada del tráfico destinado al VC ATM es mayor que las velocidades de modelado del tráfico en la interfaz, entonces los paquetes/celdas se ponen en cola en la interfaz. Normalmente, el retraso introducido a través de la demora de envío a cola es el retraso que causa problemas de rendimiento.

Solución: Implemente funciones de clase de servicio (CoS) de IP a ATM para un servicio diferenciado. Utilice funciones como Class Based Weighted Fair Queuing (CBWFQ) y Low Latency Queuing (LLQ) para reducir o eliminar el retraso en las colas para el tráfico crítico. Aumente el ancho de banda de los circuitos virtuales para eliminar la congestión.

Configuración del modelado del tráfico

Los PVC ATM y los SVC tienen parámetros de calidad de servicio (QoS) asociados a cada circuito. Se establece un contrato de tráfico entre el dispositivo de borde ATM y la red. Cuando se utilizan PVC, este contrato se configura manualmente en la red ATM (switches ATM). Con los SVC, se utiliza la señalización ATM para establecer este contrato. El tráfico de dispositivos de borde ATM modela los datos para ajustarse al contrato especificado. Los dispositivos de red ATM (switches ATM) supervisan el tráfico del circuito para cumplir con el contrato especificado y etiquetar (mark) o descartar el tráfico (police) que no se ajusta.

Si un dispositivo de borde ATM tiene la Velocidad de célula pico (PCR)/SCR configurada para una velocidad superior a la que se suministra en la red, la pérdida de paquetes es un resultado probable. Las velocidades de modelado de tráfico configuradas en el dispositivo de borde deben coincidir con lo que se configura de extremo a extremo a través de la red. Verifique que la configuración coincida con todos los dispositivos configurados. Si el dispositivo de borde envía celdas a la red que no cumplen con el contrato que se aprovisiona en toda la red, las celdas descartadas dentro de la red se ven normalmente. Esto normalmente puede ser detectado por la recepción de errores CRC en el extremo lejano cuando el receptor intenta reensamblar el paquete.

Un dispositivo de borde ATM con PCR/SCR configurado para una velocidad inferior a la que se aprovisiona en la red causa un rendimiento degradado. 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 a un retraso adicional en la cola e incluso a caídas de la cola de salida en la interfaz de salida del router ATM de borde.

Los SVC se configuran en los dispositivos de borde, pero es posible que la red no establezca el SVC de extremo a extremo con los mismos parámetros de tráfico. Los mismos conceptos y problemas se aplican a los SVC que se aplican a los PVC. Es posible que la red no configure el SVC de extremo a extremo con las mismas clases y parámetros de QoS. Este tipo de problema suele estar causado por un error o problemas de interoperabilidad. Cuando se señala un SVC, la parte que llama especifica los parámetros de modelado de tráfico de QoS en la dirección hacia adelante y hacia atrás. Puede ocurrir que la parte llamada no instale el SVC con los parámetros de modelado adecuados. La configuración del modelado de tráfico estricto en las interfaces del router puede evitar que los SVC se configuren con parámetros de modelado que no sean los configurados.

El usuario debe rastrear la trayectoria del SVC a través de la red y verificar que se establece con el uso de la clase QoS y los parámetros configurados en el dispositivo de origen.

Solución: Elimine las discordancias de configuración de políticas/modelado del tráfico. Si se utilizan los SVC, verifique que estén configurados de extremo a extremo con los parámetros de modelado/regulación correctos. Configure el Modelado de Tráfico Estricto en las interfaces del router ATM con el comando atm sig-traffic-shaping strict.

SVC que enrutan rutas no óptimas

Los SVC configurados para la velocidad de bits no especificada (UBR) pueden configurarse en trayectos no óptimos. Un VC UBR está limitado en ancho de banda a la velocidad de línea de los links que atraviesa el VC. Por lo tanto, si un link de alta velocidad se desactivara, los VC que atraviesan ese link podrían restablecerse a través de un link más lento. Incluso cuando se restaura el link de alta velocidad, los VC no se desactivan ni se restablecen sobre el link más rápido. Esto se debe a que la ruta más lenta satisface los parámetros QoS solicitados (no especificados). Este problema es muy común en las redes LANE que tienen trayectos alternativos a través de la red. En los casos en que las trayectorias alternativas son la misma velocidad de link, la falla de uno de los links hace que todos los SVC se rutee sobre la misma trayectoria. Esta situación puede afectar drásticamente el rendimiento y el rendimiento de la red, ya que el ancho de banda efectivo de la red se reduce a la mitad.

Incluso los SVC de Velocidad de bits variable (VBR) y Velocidad de bits constante (CBR) pueden enrutarse a través de rutas no óptimas. Los dispositivos finales solicitan parámetros de tráfico específicos (PCR, SCR, Tamaño máximo de ráfaga {MBS}). El objetivo de la interfaz de red privada (PNNI) y la señalización ATM es proporcionar una ruta que cumpla los requisitos de QoS de la solicitud. En el caso de las llamadas CBR y VBR-rt, esto también incluye el Retraso máximo de transferencia de celda. Una trayectoria puede satisfacer los requisitos especificados por el solicitante desde el punto de vista del ancho de banda, pero no ser la ruta óptima. Este problema es común cuando hay trayectos con retardo mayor que aún cumplen los requisitos de ancho de banda para VBR y CBR VC. Esto puede percibirse como un problema de rendimiento para el cliente que ahora ve características de demora más grandes en la red.

Solución: Los SVC a través de una red ATM se establecen a petición y normalmente no se desmontan y se redirigen a través de una trayectoria diferente a menos que el SVC se desconecte (debido a la inactividad o se libera por otras razones). Los switches Cisco LightStream 1010 y Catalyst 8500 ATM proporcionan la función Soft PVC Route Optimization. Esta función proporciona la capacidad de volver a enrutar dinámicamente un PVC de software cuando hay una mejor ruta disponible. Una funcionalidad similar no está disponible para los SVC que no terminan en los switches ATM.

Una solución posible para este problema es utilizar PVC entre los dispositivos de borde ATM y los switches ATM conectados. Los PVC de software con Optimización de rutas configurada entre switches ATM proporcionan la capacidad de re-enrutar el tráfico de trayectos no óptimos después de la falla del link y la recuperación subsiguiente.

Configure el Intervalo de tiempo de espera inactivo para que los SVC sean bajos de modo que los SVC se desactiven y se restablezcan con más frecuencia. Utilice el comando idle-timeout seconds [minimum-rate] para cambiar la cantidad de tiempo y las velocidades de tráfico que provocan que el SVC se desactive. Esto puede no resultar muy efectivo ya que el VC debe estar inactivo para volver a rutear sobre la trayectoria óptima.

Si todo lo demás falla, asegúrese de que la trayectoria óptima se haya restablecido en funcionamiento y luego rebote una de las interfaces ATM asociadas con la trayectoria redundante de velocidad lenta o una de las interfaces del router que termina el SVC.

‘Problemas del hardware

Problemas de Rendimiento de PA-A1

La arquitectura del adaptador de puerto ATM PA-A1 y la falta de memoria integrada pueden provocar un rendimiento degradado. Este problema puede manifestarse en abort, overrun, ignores y CRC en la interfaz. El problema se agrava cuando se utiliza con un router Cisco 7200 con NPE-100/175/225/300.

Refiérase a Troubleshooting de Errores de Entrada en Adaptadores de Puerto ATM PA-A1 para obtener información adicional.

Solución: Reemplace los adaptadores de puerto ATM PA-A1 por adaptadores de puerto ATM PA-A3 (al menos revisión 2) o PA-A6.

PA-A3 Versión 1

La revisión 1 del hardware PA-A3 no reensambla las celdas en paquetes que utilizan la RAM estática integrada (SRAM) en el adaptador de puerto. El adaptador reenvía las celdas a través del bus de interconexión de componentes periféricos (PCI) a la memoria host del Procesador de interfaz versátil (VIP) o del Motor de procesamiento de red (NPE), donde se reensamblan los paquetes. Esto da como resultado problemas relacionados con el rendimiento similares a los observados con el adaptador de puerto ATM PA-A1.

Refiérase a Troubleshooting de Errores de Entrada y Salida en Adaptadores de Puerto ATM PA-A3 para obtener información adicional.

Solución: Reemplace los adaptadores de puerto ATM de revisión de hardware PA-A3 por los adaptadores de puerto ATM PA-A3 (al menos revisión 2) o PA-A6.

PA-A3 duales en VIP2-50

El PA-A3-OC3SMM, PA-A3-OC3SMI y PA-A3-OC3SML están diseñados para proporcionar el máximo rendimiento de conmutación cuando se instala un único adaptador de puerto en un solo VIP2-50. Un único PA-A3-OC3SMM, PA-A3-OC3SMI o PA-A3-OC3SML en un VIP2-50 proporciona aproximadamente 85.000 paquetes por segundo de capacidad de conmutación en cada dirección mediante paquetes de 64 bytes. Tenga en cuenta que un solo PA-A3-OC3SMM, PA-A3-OC3SMI o PA-A3-OC3SML puede utilizar toda la capacidad de switching de un solo VIP2-50.

Para las aplicaciones que requieren una densidad de puerto máxima o un menor coste del sistema, ahora se admiten configuraciones de adaptador de puerto dual con la versión OC-3/STM-1 del PA-A3 en el mismo VIP2-50. Los dos adaptadores de puerto en el mismo VIP2-50 comparten aproximadamente 95 000 paquetes por segundo de capacidad de conmutación en cada dirección mediante paquetes de 64 bytes.

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

En consecuencia, el rendimiento compartido entre los dos adaptadores de puerto instalados en el mismo VIP2-50 está limitado por la capacidad de switching total (95 kpps) a tamaños de paquetes pequeños y por el ancho de banda agregado (400 mbps) a tamaños de paquete grandes.

Estas advertencias de rendimiento deben tenerse en cuenta cuando se designan redes ATM con PA-A3-OC3SMM, PA-A3-OC3SMI o PA-A3-OC3SML. Según el diseño, el rendimiento de los adaptadores de puerto duales en el mismo VIP2-50 puede ser o no aceptable.

Refiérase a Configuraciones PA-A1 y PA-A3 VIP2 Soportadas para obtener información adicional.

Problemas de LANE

Dominio de difusión LANE

Un número excesivo de sistemas finales en una sola ELAN LANE puede degradar significativamente el rendimiento de todas las estaciones finales. Una ELAN representa un dominio de broadcast. Todas las estaciones de trabajo y los servidores dentro de la ELAN reciben la difusión y posiblemente el tráfico multicast de todos los demás dispositivos en la ELAN. Si el nivel de tráfico de broadcast es alto en relación con la capacidad de procesamiento de la estación de trabajo, el rendimiento de las estaciones de trabajo sufre.

Solución: Restrinja el número de estaciones finales dentro de una sola ELAN a menos de 500. Supervise la red para las tormentas de difusión/multidifusión que pueden afectar negativamente al rendimiento del servidor/estación de trabajo.

Consulte Recomendaciones de diseño LANE para obtener más información.

Cambios excesivos en la topología del árbol de expansión y el tráfico LE-ARP

Otros problemas que pueden conducir a un rendimiento deficiente en una red LANE son la actividad excesiva de LANE ARP (LE-ARP) y los cambios en la topología del árbol de extensión. Estos problemas llevan a LE-ARP no resueltos que conducen al tráfico enviado sobre el bus. Esto también puede conducir a una alta utilización de la CPU en los LEC de la red, lo que también puede causar problemas relacionados con el rendimiento. Puede encontrar más información sobre estos problemas en Troubleshooting Spanning-Tree over LANE.

Configure el Spanning Tree PortFast en los puertos host de los switches Ethernet conectados a LANE para reducir los cambios en la Topología del Spanning Tree. Configure la reverificación LE-ARP local en los switches Catalyst 5000 y 6000 configurados para LANE para reducir el tráfico LE-ARP.

SVC directos de datos VBR-nrt

Con LANE versión 1, los SVC se configuran como categoría de servicio UBR. LANE versión 2 admite la capacidad de establecer SVC de datos directos con el uso de otras categorías de servicio como VBR-nrt. Un proveedor de terceros tiene un error en la implementación de su cliente LANE que puede hacer que los SVC de Data Direct configurados para dispositivos Cisco sean VBR-nrt con un SCR de 4 Kbps. Si su estructura básica ATM consta de links troncales OC-3 (155 Mbps) y OC-12 (622 Mbps) y configura SVC en esos troncales con una Velocidad de celda sostenida de 4 Kbps, su rendimiento se verá afectado. Aunque este problema en particular no es común, señala una necesidad importante cuando se resuelven problemas de rendimiento en circuitos ATM. Debe realizar un seguimiento de la trayectoria que sus SVC atraviesan a través de la red y confirmar que el VC se ha establecido con la categoría de servicio deseada y los parámetros de tráfico.

Los VC de datos directos no están establecidos

Los VC directos de datos LANE son SVC punto a punto bidireccionales que se configuran entre dos clientes de emulación LAN (LEC) y se utilizan para intercambiar datos entre esos clientes. Los clientes LANE envían solicitudes LE-ARP para aprender las direcciones ATM asociadas con una dirección MAC. Luego intentan configurar un VC de datos directos a esa dirección ATM. Antes del establecimiento del VC de Data Direct, los clientes LANE inundan los paquetes unicast desconocidos en el Servidor de difusión y desconocido (BUS). Un cliente LANE puede no establecer un VC de datos directos a otro LEC con el propósito de enviarle datos de unidifusión. Si esto sucede, puede producirse una degradación del rendimiento. El problema es significativo si el dispositivo elegido para realizar los servicios de BUS tiene poca alimentación, es inadecuado o está sobrecargado. Además, algunas plataformas pueden limitar la tasa de unidifusión que se reenvían al BUS. El módulo LANE Catalyst 2900XL es uno de esos cuadros que regula el tráfico de unidifusión enviado al BUS mientras que Catalyst 5000 y Catalyst 6000 no lo hacen.

El SVC directo de datos puede no ser establecido o ser utilizado por cualquiera de estos motivos:

• El LEC no recibe una respuesta a la solicitud LE-ARP.

• El SVC no se puede crear debido a problemas de ruteo o señalización ATM.

• Falla LANE Flush Message Protocol . Una vez que se establece el VC de Data Direct, el LEC envía una solicitud de vaciado en el VC de envío de multidifusión para asegurarse de que todas las tramas de datos que se han enviado a través del BUS hayan llegado a su destino. Cuando el LEC que envió la solicitud de vaciado recibe una respuesta, comienza a enviar datos a través del VC de Data Direct. El mecanismo de vaciado se puede inhabilitar con el comando no lane client flush.

Problemas de IMA

PVC UBR en interfaces IMA

Los VC UBR en interfaces de multiplexación inversa (IMA) se configuran con una PCR de 1,5 Mbps en lugar de la suma de todas las interfaces físicas de encendido/encendido que se configuran en el grupo IMA. Esta condición degrada el rendimiento ya que el VC tiene la forma del tráfico a una velocidad inferior al ancho de banda combinado de todos los links en el grupo IMA.

Originalmente, el ancho de banda de una interfaz de grupo IMA estaba limitado al número mínimo de links IMA activos necesarios para mantener la interfaz IMA activa. El comando para definir este valor es IMA active-links-minimum. Por ejemplo, si cuatro interfaces ATM físicas se configuran como miembros del grupo IMA cero y el valor de IMA active-links-minimum se establece en uno, el ancho de banda es igual a un T1 o 1,5 Mbps, no a 6 Mbps.

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

Los ID de bug de Cisco CSCdt67354 (sólo clientes registrados) y CSCdv67523 (sólo clientes registrados) son solicitudes de mejora posteriores para actualizar el ancho de banda del VC del grupo IMA cuando se agrega o elimina una interfaz del grupo IMA, cierra/no cierra o se rebota debido a una falla de link, cambiar en el extremo remoto. Los cambios implementados en el error de funcionamiento de Cisco IDCSCdr12395 (sólo clientes registrados) configuran el ancho de banda del grupo IMA al ancho de banda total de sus links miembro solamente cuando aparece el grupo IMA. Los cambios en el grupo IMA después del estado inicial activo no se reflejan.

Refiérase a Troubleshooting de Links ATM en el Adaptador de Puerto IMA 7x00 para obtener información adicional.

Información Relacionada

• Selección de ruta de la Interfaz de red privada a red (PNNI)
• TCP Window Scaling
• Resolución de problemas de links ATM en el adaptador del puerto 7x00 IMA
• Configuraciones PA-A1 y PA-A3 VIP2 compatibles
• Detalles de la implementación de TCP/IP de Microsoft Windows 2000
• Resolución de problemas de TCP/IP
• Soporte Técnico - Cisco Systems

Historial de revisiones