Este documento proporciona directrices prácticas de diseño de red de emulación de LAN (LANE). Estas directrices le ayudarán en el diseño de redes LANE de alto rendimiento, escalables y de alta disponibilidad. Aunque este documento se centra en el equipo de Cisco, se pueden aplicar los mismos conceptos al integrar productos de terceros.
Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.
Los lectores de este documento deben conocer las operaciones básicas y las configuraciones de las redes LANE.
Este documento se centra en las configuraciones LANE Ethernet.
La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.
A continuación se presentan los diversos servidores LANE y sus requisitos.
La especificación LAN Emulation Over ATM Version 1.0 requiere que cada LAN Emulation Client (LEC) establezca un circuito virtual (VC) al LAN Emulation Configuration Server (LECS) cuando se activa. A continuación, el LEC solicita la dirección ATM de su servidor de emulación de LAN (LES) correspondiente. Una vez que el LEC tiene su dirección LES ATM, se elimina el VC entre el LEC y el LECS, y el LEC ya no intenta comunicarse con el LECS. Cuando el entorno es estable y todos los LEC están activos y operativos, el LECS está inactivo.
Cuando los LEC se unen a la LAN emulada (ELAN), cada uno se pone en contacto con el LECS individualmente. Sin embargo, cuando la red LANE sufre un desastre (por ejemplo, cuando falla el LECS principal), todos los clientes se desactivan.
Nota: La excepción es cuando se utiliza el protocolo simple rápido de redundancia de servidor (FSSRP).
Dado que todos los LEC se desactivan al mismo tiempo, todos se pondrán en contacto con el LECS de respaldo al mismo tiempo. Por lo tanto, para alojar el LECS, necesita un dispositivo que:
puede manejar una ráfaga repentina de tráfico dirigida al nivel del proceso.
puede aceptar casi todas las configuraciones de llamadas entrantes de los LEC simultáneamente.
es conocido por su estabilidad. Si el LECS se desactiva, toda la red se desactiva (de nuevo, con la excepción de FSSRP). Por lo tanto, no se recomienda colocar el LECS en un dispositivo que ejecute una versión de software experimental.
Cada LEC mantendrá un VC bidireccional al LES de la ELAN (puede ser más de una ELAN si se utiliza FSSRP). En un entorno muy cargado típico, se enviarán a LES muchas solicitudes de protocolo de resolución de direcciones de emulación de LAN (LE_ARP). La implementación del LES en los dispositivos Cisco es bastante sencilla. Todas las tramas LE_ARP entrantes se reenviarán al control distribute virtual channel connection (VCC).
No puede implementar una simple replicación de celdas de hardware desde control directo a control distribuida, ya que algunas tramas (como las solicitudes de unión) deben ser analizadas por el proceso LES. Por lo tanto, un dispositivo que puede actuar como un LES bueno es un dispositivo que:
cuenta con una potente CPU y puede aceptar muchas configuraciones de llamadas en un breve período de tiempo. Esto es necesario cuando muchos clientes se unen a la ELAN al mismo tiempo, pero menos importante que para la LECS, ya que sólo los LEC en la ELAN tienen que unirse.
cuenta con compatibilidad de hardware de segmentación y reensamblado (SAR) sólida. Como todas las celdas entrantes deben reensamblarse en tramas, si muchas solicitudes de unión llegan al mismo tiempo, tendrán que ser reensambladas muy rápidamente.
Recuerde que en la implementación de Cisco, los procesos LES y Broadcast and Unknown Server (BUS) se combinan (es decir, no puede colocar el LES para ELAN-1 en un dispositivo y el BUS para ELAN-1 en otro dispositivo).
Otra cosa a tener en cuenta es el posible comportamiento preventivo. Si se habilita la función de prevención, los LES/BUS con la prioridad más alta (según la base de datos LANE) siempre se harán cargo de la función LES/BUS principal. En otras palabras, si falla el LES/BUS primario, todos los LEC de la ELAN se desactivarán y se reconectarán al LES/BUS de respaldo. Si se configura la capacidad preventiva, si el LES/BUS primario vuelve a subir, todos los LEC se desactivarán una vez más y se reconectarán al LES/BUS con la prioridad más alta. En LANE Module Software versión 3.2.8 y posteriores, y Cisco IOS® Software versión 11.3(4) y posteriores, la función de prevención se puede activar y desactivar. La función de pre-vacío se puede configurar como se describe en la documentación Configuración de LAN Emulation.
El trabajo del BUS es bastante similar al del LES. Se requiere que cada LEC tenga un envío multicast al BUS. El LEC le envía todo su tráfico multicast, broadcast o desconocido. El BUS tiene una VCC punto a multipunto para todos los LEC en la ELAN. Las tramas no tienen que ser examinadas en detalle por el BUS. En otras palabras, cada trama entrante en el envío multicast puede ser reenviada ciegamente al reenvío multicast.
Un buen dispositivo BUS:
tiene soporte de hardware para la copia de trama de la multidifusión entrante enviada al reenvío multidifusión saliente. Si tiene hardware "inteligente", esta operación de copia se puede realizar antes del reensamblado. Esto significa que las celdas entrantes en el envío multicast se reenvían en el reenvío multicast. Esto guarda una segmentación y un reensamblado por trama.
requiere una CPU fuerte si no hay soporte de hardware para el BUS.
debe poder procesar muchas configuraciones de llamadas al mismo tiempo, pero con un límite inferior al LECS.
Dispositivo | Rendimiento Del BUS (Kpps) |
---|---|
Módulo Catalyst 6K LANE/MPOA (OC-12) | 600 |
Módulo Catalyst 5K LANE/MPOA (OC-12) | 600 |
Módulo Catalyst 5K LANE/MPOA (OC-3) | 166 |
Módulo Catalyst 5K LANE (OC-3) | 122 |
RSP4 - VIP-2-50+PA-A1 | 92 |
RSP4 - VIP-2-500+PA-A3 | 84 |
RSP4 - VIP-2-40+PA-A3 | 78 |
RSP4 - VIP-2-40+PA-A1 | 77 |
4700 | 40 |
LS1010 | 30 |
Esta sección trata sobre las capacidades de los dispositivos de Cisco más comunes utilizados para ejecutar LEC, LECS, LES y BUS. Estos dispositivos son los módulos LANE de Cisco, el Lightstream 1010, el Catalyst 8510MSR y 8540MSR y el 7500/RSP. Sus capacidades se comparan con los requisitos enumerados anteriormente.
La arquitectura de todos los módulos LANE para Catalyst 5000 y 6000 se basa aproximadamente en la siguiente visión de alto nivel:
La segmentación y el reensamblado la realiza el hardware. El chip SAR es algo inteligente y puede reenviar directamente las tramas reensambladas al bus de tramas del catalizador (la placa de interconexiones del catalizador). Para las tramas de control, el chip SAR puede reenviar las tramas a la CPU del módulo LANE. Una trama de control es cualquier trama que debe analizarse (por ejemplo, la Interfaz de administración local provisional (ILMI), la señalización y las tramas destinadas al LES), que llega al módulo LANE a través de un VC especificado.
El chip SAR también puede redirigir las células que vienen en el envío multidifusión al reenvío multidifusión (es decir, multidifusión, difusión y células desconocidas que vienen de los LEC). Las celdas no se vuelven a montar en tramas. Su facilidad de implementación da como resultado un muy buen rendimiento del BUS.
Una vez que se ha creado una "dirección de datos" y una entrada en la tabla de memoria de contenido direccionable (CAM), las tramas reensambladas se envían directamente al BUS de tramas y se etiquetan con la ID de LAN virtual (VLAN) correcta. Un módulo LANE hace un LEC muy bueno porque una vez que se ha establecido la "dirección de datos", la CPU ya no está involucrada.
El LS1010 y el Catalyst 8510MSR no tienen soporte de hardware para SAR. En consecuencia, estos dispositivos son opciones deficientes para implementar las funcionalidades LES/BUS. Sin embargo, son adecuadas para el LECS (consulte el diseño de muestra 2 a continuación).
El 8540MSR no admite hardware para SAR. También cuenta con un potente procesador Risc 5000. No se recomienda 8540MSR para soportar LES/BUS por dos razones:
El rendimiento del BUS es de aproximadamente 50 Kpps para paquetes de 64 bytes, muy por debajo de cualquier módulo LANE. Esto se debe a que no hay aceleración de hardware para el BUS.
Si el 8540MSR se utiliza con tarjetas ATM y Ethernet, la CPU se puede utilizar principalmente para hablar con tarjetas de línea Ethernet. En este caso, la CPU del 8540MSR no debe utilizarse como LES.
El router más utilizado para el ruteo entre ELAN es la plataforma Cisco 7500 (el Route Switch Module (RSM) y Cisco 7200 también se utilizan ampliamente). El adaptador de puerto contiene el chip de hardware SAR. Los procesadores de routing/switch (RSP) como el RSP4 tienen suficiente potencia de CPU para procesar las tramas entrantes muy rápidamente; por lo tanto, son una buena elección para el LES. Sin embargo, el rendimiento del BUS está por debajo del de los módulos LANE.
LANE se utiliza principalmente en redes grandes y críticas. Como tal, la redundancia es obligatoria. El protocolo simple de redundancia de servidor (SSRP) es el protocolo de redundancia más utilizado. Si el software es reciente, el FSSRP es el protocolo preferido (consulte la Directriz #11).
Supongamos que tenemos una red bastante grande, por ejemplo 100 VLAN/ELAN y 100 catalizadores, cada uno con un módulo LANE de enlace ascendente dual. Esto significa que en cada módulo LANE podríamos necesitar un LEC por ELAN, en este caso 10.000 LEC. Además, asumimos que se utiliza IP y que el diseño incluye una clase C segura (254 direcciones IP de host, 254 direcciones MAC) por VLAN.
En este diseño, se ha elegido un módulo LANE para ejecutar los 100 servidores LES/BUS. Al mismo tiempo, el LECS primario se encuentra en el mismo módulo LANE. Esto se ilustra en el siguiente dibujo:
Cuando se crean los LEC en el módulo LANE, todos los LEC se activan tan pronto como se configuran. Durante la operación, el proceso LES podría sobrecargarse y el módulo LANE se quedaría sin memoria. El diseño 2 a continuación resuelve ambos problemas.
El problema principal en esta red es cuando ocurre un problema importante. Suponga que el módulo LANE que aloja el LECS, LES o BUS se vuelve inalcanzable. Esto podría ocurrir, por ejemplo, si el módulo LANE del catalyst 1 falla. Puede ver que se produce redundancia, pero el tiempo de redundancia (es decir, el tiempo entre la falla principal de LECS, LES o BUS y el último LEC que vuelve a funcionar) puede durar hasta dos horas. Un buen diseño podría reducir este número a docenas de segundos, o a unos minutos en redes grandes.
El problema radica en la señalización que implica que los LEC se unan a la ELAN. Si cada LEC debe ponerse en contacto con el LECS, recibirá 10.000 configuraciones de llamadas (100 módulos LANE con 100 LEC cada uno) casi simultáneamente. El módulo LANE está diseñado para establecer un puente eficiente entre el bus de tramas y el link de celda, pero no para manejar muchas configuraciones de llamadas por segundo. La CPU del módulo LANE no es lo suficientemente potente como para manejar este volumen de configuraciones de llamadas. El siguiente resultado ilustra el tiempo de redundancia en una red LANE con aproximadamente 1600 LEC (sólo se muestra parte del comando show processes cpu):
ATM#show processes cpu CPU utilization for five seconds: 99%/0%; one minute: 98%; five minutes: 69% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process <snip> 7 13396 207 64714 16.55% 10.85% 3.77% 0 ATM ILMI Input 8 13600 188 72340 13.45% 10.54% 3.72% 0 ILMI Process <snip> 35 107892 553 195103 68.94% 55.34% 26.72% 0 ATMSIG Input 36 34408 1125 30584 12.29% 9.45% 6.63% 0 ATMSIG Output <snip>
Como puede ver, el módulo LANE está sobreutilizado debido a la actividad de señalización entrante. ¿Qué significa el tiempo de redundancia de dos horas? La respuesta reside en la noción de tiempo de espera. Las especificaciones de señalización mencionan claramente que si el dispositivo no recibe un mensaje de "conexión" después de una cantidad de tiempo especificada cuando se envía una "configuración de llamada", debe empezar de nuevo. Las especificaciones LANE requieren que el LEC vuelva a su estado inicial y comience de nuevo. Esto significa que si un LEC es capaz de contactarse con el LECS y de conectarse a él, su configuración de llamada al LES podría agotar el tiempo de espera, y regresa a su estado inicial de tratar de contactarse con el LECS! Esto también puede ocurrir con las conexiones desde el LES y desde/hacia el BUS.
Sobre la base de las explicaciones anteriores, aquí hay algunas recomendaciones básicas de diseño:
Intente difundir el LES/BUS para las diferentes ELAN en los diversos dispositivos que pueden implementarlo eficientemente. Idealmente, un LES/BUS primario en cada módulo LANE, con los siguientes respaldando el primero. En la práctica, esto generaría una base de datos LECS muy larga. La experiencia muestra que 10 servidores LES/BUS por módulo LANE parecen ser un número seguro.
Intente no colocar el LECS en la misma ubicación que otros servidores LES/BUS importantes. También intente colocar el LECS en un dispositivo con suficiente potencia de CPU para que pueda manejar la información de señalización de manera eficiente. El LECS debe estar en un router (se recomienda el Cisco 7200 o 7500, idealmente sin LES/BUS), o en un switch ATM.
Suponiendo que se utilice un rango de clase C y IP para cada VLAN, aproximadamente 250 direcciones MAC son un buen número para el trabajo LES. Para 10 LES en un módulo LANE, esto significa la CPU de un módulo LANE para un máximo de 2500 direcciones MAC. Tenga en cuenta que no hay números fijos y oficiales, pero esta es una estimación segura y conservadora. Por otra parte, 200 LES/BUS en un módulo LANE, con cada ELAN que contenga 1000 estaciones finales, son seguros mientras la estación permanezca prácticamente inactiva (consulte la directriz #3 para más detalles).
En este diseño, ponemos el LECS en el switch ATM. Difundimos el LES/BUS en diferentes módulos LANE. Los valores de CPU de procesos altos no se ven en ningún módulo LANE y la redundancia es normal.
Las directrices que se presentan a continuación son sólo recomendaciones prácticas, basadas en el despliegue de redes de producción LANE. Aunque existen ejemplos de redes exitosas que exceden las recomendaciones, se requiere un entendimiento exhaustivo de cómo afectarán a la red antes de exceder estas pautas.
Si planea utilizar el protocolo de router en espera en caliente (HSRP) sobre LANE, asegúrese de actualizar a una versión reciente y de leer Implementación de HSRP sobre LANE.
Distribuya el BUS LANE en dispositivos con la mayor capacidad de rendimiento de BUS y donde tendrá un impacto mínimo en otros procesos del dispositivo.
El BUS LANE es responsable de reenviar todas las tramas de difusión, multidifusión y unidifusión de destino desconocido recibidas de los miembros de una ELAN a todos los miembros de la ELAN. Dado que LANE utiliza la capa 5 de adaptación ATM (AAL5) que no permite el entrelazado de celdas de diferentes unidades de datos de protocolo (PDU), el BUS debe serializar las tramas antes del reenvío. Esto requiere que el BUS reensamble las tramas recibidas, divida cada trama una por una y reenvíe las celdas. El requisito de reensamblar y segmentar cada trama limita significativamente el rendimiento de reenvío del BUS, lo que influye considerablemente en la escalabilidad de una ELAN. La proliferación de aplicaciones de multidifusión IP intensifica aún más esta tarea. Recuerde que sólo los módulos LANE pueden recibir las celdas en multicast send y forward en multicast forward. Esto se hace sin reensamblado.
Distribuya los servicios LANE a través de varios módulos y dispositivos.
Anteriormente se indicó que 10 LES/BUS con cada ELAN correspondiente a una red IP de Clase C (aproximadamente 250 usuarios) son seguros y conservadores; sin embargo, existen redes LANE exitosas con 10-60 pares LES/BUS por módulo. Esto depende ligeramente del módulo, pero verificar el diseño siempre implicará verificar la utilización de la CPU (usando el comando show processes cpu) y la memoria disponible más baja (usando el comando show memory). Esto, por supuesto, se debe llevar a cabo durante el uso pico de la red, ya que el uso general de la CPU de LES está directamente relacionado con el proceso LE_ARP.
En un entorno LANE, es común ver los pares LES/BUS ubicados en un único dispositivo que soporta toda la red LANE. Esto no solo representa un único punto de falla, sino que limita el rendimiento de BUS dentro de cada ELAN.
La distribución de los servicios LANE en varias plataformas proporciona una mayor escalabilidad en entornos multiELAN, así como una mayor disponibilidad del sistema y un mayor rendimiento total de BUS (por ejemplo, el rendimiento total de BUS en la red aumenta a medida que se configuran más dispositivos e interfaces para el soporte BUS). Para obtener la máxima capacidad de BUS desde una perspectiva de diseño, los módulos ATM Catalyst 5000 y 6000 pueden estar dedicados a servicios LES y BUS.
Al conocer la capacidad del BUS y estimar la cantidad de tráfico de difusión o multidifusión esperada en cada ELAN, puede calcular el número de pares LES/BUS que se pueden aplicar a una interfaz dada. También puede medir la capacidad del BUS.
Sin embargo, calcular la cantidad de tráfico de difusión o multidifusión para cada ELAN es más complicado. Un método para estimar la cantidad de tráfico de difusión o multidifusión para cada ELAN es medir este tráfico en la red existente. Se puede insertar un dispositivo de sonda RMON (analizador de red o supervisión remota) en la LAN existente para medir la cantidad de tráfico de difusión y multidifusión. Otra forma es consultar los objetos mib "ifOutMulticastPkts" y "ifOutBroadcastPkts". Verifique primero si son compatibles con su IOS/plataforma.
Alternativamente, puede, hasta cierto punto, calcular la cantidad de tráfico de difusión o multidifusión calculando el ancho de banda consumido por las difusiones de protocolo de ruteo, por ejemplo. Para Internetwork Packet Exchange (IPX), Routing Information Protocol (RIP) y Service Advertising Protocol (SAP), el consumo de ancho de banda se puede determinar con precisión si se conoce el número de rutas IPX y SAP. Lo mismo es válido para IP y el protocolo de ruteo particular que se utiliza.
La capacidad adicional del BUS debe reservarse para:
Compatibilidad con el tráfico de unidifusión mientras se establece un VC de datos directos y hasta que se reconoce un paquete de vaciado en el LEC receptor.
Aplicaciones de multidifusión IP a demanda que se utilizan en varias horas del día (deben tenerse en cuenta en el volumen de multidifusión general).
Tráfico de routing adicional cuando se ejecuta un protocolo y en estado de convergencia (es decir, anuncios de estado de link (LSA) intercambiados durante un cambio de topología Open Shortest Path First (OSPF)).
Grandes volúmenes de solicitudes de protocolo de resolución de direcciones (ARP), específicamente en la mañana en que las estaciones de trabajo inician sesión por primera vez en los servidores LAN y de red.
Utilizando cualquier método disponible, el objetivo es tener una representación precisa de la cantidad de tráfico de difusión y multidifusión que existirá en cada ELAN. Desafortunadamente, esta información rara vez está disponible para el diseñador de la red por diversos motivos. Cuando se enfrenta a esta situación, se pueden usar algunas pautas generales conservadoras. Como recomendación, una red típica con 250 usuarios por ELAN, que ejecute las aplicaciones más comunes, debería asignarse al menos 10 Kpps de capacidad BUS. La tabla 1 ilustra el número máximo recomendado de pares LES/BUS por interfaz.
Estos números se deben utilizar junto con la directriz n.º 4, que limita a 250 el número de LEC atendidas por todos los pares LES/BUS configurados en una interfaz. Además, estos números deben ajustarse según el número real de usuarios en cada ELAN, mientras se presta especial atención a cualquier aplicación de difusión o multidifusión que se ejecute en la ELAN.
Limite el número total de LEC atendidas por el par LES/BUS a un máximo de 250. Durante la inicialización, y después de una falla de red, para que los clientes LANE se unan a su ELAN, deben establecer varias conexiones y hacer solicitudes a sus componentes de servicio LANE. Dado que los dispositivos que admiten los servicios LANE poseen una velocidad finita a la que pueden procesar las conexiones y solicitudes, se recomienda que los pares LES/BUS configurados en un servicio de interfaz tengan un máximo de 250 clientes LANE. Por ejemplo, una interfaz se puede configurar con 10 pares LES/BUS, cada uno de los cuales da servicio a 25 LEC para un total de 250 LECs atendidos por la interfaz. Esto garantizará la inicialización oportuna y la recuperación de fallos.
Sitúe el LES/BUS para una ELAN dada cerca de cualquier origen de tráfico de difusión o multidifusión principal.
En un entorno LANE, específicamente cuando se utilizan aplicaciones de multidifusión (es decir, IP/TV), es una buena práctica de diseño colocar el BUS lo más cerca posible de la fuente de multidifusión conocida. Dado que el tráfico multicast debe enviarse primero al BUS, que a su vez reenvía el tráfico a todos los clientes, situar el BUS cerca del origen multicast evita que el tráfico cruce la estructura básica ATM dos veces.
Esto permite que la red LANE se amplíe a una mayor magnitud. Además, el BUS no debería estar ubicado en la misma interfaz que el LEC que soporta el origen multicast, ya que el tráfico multicast cruzaría el link de transmisión dos veces.
Tenga cuidado si considera LANE como la tecnología de red para admitir un entorno de multidifusión. Aunque LANE sí admite tráfico multidifusión, lo hace de forma bastante ineficiente. LANE simplemente inunda el tráfico multicast a todos los clientes en la ELAN independientemente de si forman parte o no del grupo multicast. El exceso de tráfico multidifusión puede degradar significativamente el rendimiento de las estaciones de trabajo (como se describe en la Directriz nº 6), mientras que el comportamiento de inundación desperdicia el ancho de banda de la estructura básica.
Limite el número de sistemas finales en una ELAN dada a 500 o menos, si la red lleva solamente paquetes IP. En el cuadro 2 que figura a continuación se ofrece una recomendación básica basada en la cantidad de difusión generada por el protocolo. Una vez más, en caso de que no esté completamente seguro de qué protocolos serán necesarios, tenga en cuenta la recomendación de 250 estaciones finales que hicimos en el pasado.
Por definición, una ELAN representa un dominio de difusión. Por lo tanto, dentro de una ELAN, todos los paquetes de difusión y multidifusión se inundan a todos los miembros de la ELAN. Las estaciones de trabajo deben procesar cada paquete de difusión y multidifusión recibido para determinar si es de interés. El procesamiento de paquetes de broadcast "no interesantes" desperdicia los ciclos de CPU de las estaciones de trabajo. Cuando el nivel de actividad de difusión se eleva (en relación con la capacidad de procesamiento de las estaciones de trabajo), puede verse gravemente afectado e impedido de realizar las tareas previstas.
El número de sistemas finales, aplicaciones y los protocolos en uso determinan el nivel de transmisión dentro de una ELAN. Las pruebas han ilustrado que, en ausencia de aplicaciones de difusión intensiva, el número de sistemas finales que se pueden configurar de forma segura en una única ELAN varía de 200 a 500, según la combinación de protocolos.
Tabla 2: Número máximo de sistemas finales recomendados por ELAN basado en la combinación de protocolosTipo de protocolo | Número de sistemas finales |
---|---|
IP | 500 |
IPX | 300 |
AppleTalk | 200 |
Mixto | 200 |
Calcule el uso del VC de red para asegurarse de que se encuentra dentro de la capacidad de los dispositivos ATM.
Los switches ATM y los dispositivos de borde admiten un número limitado de VC. Al diseñar las redes ATM, es importante asegurarse de que no se exceda la capacidad VC del equipo. Esto es particularmente importante en las redes LANE, ya que LANE no se destaca por su eficiencia de VC. Durante la fase de diseño de red, debe calcular el uso de VC esperado para la estructura básica, así como para cada dispositivo de borde individual. El uso de VC de la estructura básica corresponde al número total de VC esperados en la red. Esta cantidad debe compararse con el número de VC soportados por los switches ATM.
Dado que no todos los VC cruzan un switch determinado, este número sirve como límite superior. Se debe considerar la topología real de la estructura básica y los patrones de tráfico, en relación con el número total de VC, para determinar si se excederá la capacidad de VC de los switches ATM.
Del mismo modo, se debe calcular el uso del VC para cada dispositivo de borde. Esto se relaciona con el número de VC que terminarán en una interfaz dada de un dispositivo de borde. Este número debe compararse entonces con la capacidad de VC de la interfaz.
Se pueden utilizar las siguientes fórmulas para calcular el uso del VC de la red. Estas fórmulas asumen el uso de clientes y servicios LANE de Cisco, y se aplican a SSRP y FSSRP. Cuando está presente, se indican las diferencias en el uso de VC entre los dos protocolos.
a. LEC-LANE Service VCs: SSRP: 4 (#LEC_per_ELAN)(#ELAN) FSSRP: 4 (#LEC_per_ELAN)(#LES/BUS_per_ELAN)(#ELAN) b. LECS-LES Control VCs: (#LES/BUS_per_ELAN)(#ELAN) c. LECS-LECS Control VCs: (#LECS)(#LECS - 1) / 2 d. LEC-LEC Data Direct VCs: If mesh_factor < 1.0: (#LEC_per_ELAN) [(#LEC_per_ELAN)(mesh_factor)/2](#ELAN) If mesh_factor = 1.0: (recommended in most designs) (#LEC_per_ELAN) [((#LEC_per_ELAN) - 1)/2](#ELAN) where: mesh_factor = fraction of LECs within an ELAN communicating a given time. (When determining the fraction of LECs within an ELAN communicating at a given time, the data direct timeout period must be considered. Even a brief conversation between two LECs will cause a data direct connection to be maintained for the timeout period. Therefore, unless the traffic patterns are very clearly understood, a mesh_factor = 1.0 is highly recommended). Backbone VC Usage = a + b + c + d
a. LEC-LANE Service VCs: SSRP: (#active_LES/BUS_on_interface) (2 * #LEC_per_ELAN + 2) FSSRP: (#LES/BUS_on_interface) (2 * #LEC_per_ELAN + 2) b. LECS-LES Control VC's: (#LES/BUS_on_interface) c. LECS-LECS Control VCs (#LECS - 1) d. LEC-LEC Data Direct VCs: (#LEC)[(#LEC_per_ELAN)(#LEC_per_ELAN)(mesh_factor)/2] Interface VC usage = a + b + c + d
Una vez que haya calculado el uso del VC, compare los resultados con la capacidad del VC de los dispositivos relevantes usando la tabla 3.
Tabla 3: Ruteo Inter-ELAN - Capacidad de VC para diversos dispositivos de CiscoDispositivo | Presupuesto del circuito virtual |
---|---|
Catalyst 8540 MSR | 256 000 |
Catalyst 8510 MSR/LS1010 | 16 MB de memoria dinámica de acceso aleatorio (DRAM) = 4000 |
32 MB de DRAM = 16 000 | |
64 MB de DRAM = 32 000 | |
Cisco 7500/7200 ATM Deluxe | 4000 |
Cisco 7500/7200 ATM Lite | 2000 |
Catalyst 6K - LANE/MPOA OC-12 | 4000 |
Catalyst 5K - LANE/MPOA OC-12 | 4000 |
Catalyst 5K - LANE/MPOA OC-3 | 4000 |
Catalyst 5K - LANE OC-3 | 4000 |
Catalyst 2900 XL - LANE OC-3 | 1k |
Si desea vincular diferentes redes ATM de campus con rutas virtuales permanentes (PVP), siempre "enrute" entre los sitios en lugar de permitir que las ELAN nativas abarquen diferentes redes ATM de campus.
Evalúe la capacidad del router necesaria mediante la estimación de la cantidad de ruteo inter-ELAN necesaria.
La cantidad de capacidad de ruteo requerida en una red LANE dada varía ampliamente. Por lo tanto, la cantidad de capacidad de ruteo debe ser estimada durante el proceso de diseño de la red. Después de determinar la capacidad requerida, el número de routers e interfaces de router necesarios se puede determinar mediante la siguiente tabla de rendimiento de reenvío:
Tabla 4: Capacidad de ruteo entre ELAN para diversos dispositivos de CiscoDispositivo | Cisco Express Forwarding (CEF) Distributed (Kpps) | Cisco Express Forwarding (CEF) Forwarding (Kpps) |
---|---|---|
RSP4/VIP2-50 ATM PA-A3 | 118 | 101 |
RSP4/VIP2-50 ATM PA-A1 | 91 | 91 |
RSP4/VIP2-40 ATM PA-A3 | 83 | 60 |
RSP4/VIP2-40 ATM PA-A1 | 66 | 66 |
Aunque la configuración de router "de un solo brazo" es popular en los diseños LANE, normalmente esto no proporciona una capacidad de ruteo adecuada. En su lugar, se requieren varias interfaces y/o varios routers. Las velocidades de reenvío de CEF enumeradas en la tabla anterior asumen una configuración de router con un solo brazo. Para alcanzar estas velocidades, el procesador central del router se impulsa a una utilización de casi el 100%. Por el contrario, las velocidades de reenvío distribuidas se logran utilizando el procesador que reside en el Procesador de interfaz versátil (VIP), sin que, básicamente, tenga ningún impacto en el procesador del router centralizado. Como resultado, se pueden instalar varias interfaces ATM en el router, lo que conduce a un rendimiento agregado mucho mayor.
Proporcione dispositivos de borde ATM de doble inicio a al menos dos switches ATM diferentes para obtener redundancia.
En una red LANE, el switch ATM que soporta los dispositivos de borde puede ser un único punto de falla para la conectividad a la estructura básica. Los Catalyst 6K y 5K proporcionan módulos de enlace ascendente de subcapa física dual (PHY) OC-12/OC-3 para una conectividad redundante con switches ATM de flujo descendente. Los módulos LANE doblemente conectados proporcionan una función dual-PHY "similar a la interfaz de datos distribuidos por fibra (FDDI)". Este módulo de link ascendente PHY dual proporciona una interfaz ATM primaria y secundaria. Si la interfaz primaria pierde la conectividad de link con el switch ATM, el módulo conmutará automáticamente la conexión a la interfaz secundaria.
Se recomienda encarecidamente que el diseñador de redes aproveche las interfaces PHY duales en los módulos LANE y proporcione enlaces ascendentes de doble reposición a dos switches ATM diferentes en el núcleo. Esto protegerá a los dispositivos de borde de la falla de un solo switch ATM.
Utilice FSSRP a menos que el presupuesto VC tenga restricciones.
Dado que los diversos componentes del servicio LANE son puntos únicos de falla en una red LANE, las redes de producción deben diseñarse con redundancia. Cisco admite dos esquemas de redundancia para los servicios LANE: Simple Server Redundancy Protocol (SSRP) y Fast SSRP (FSSRP).
FSSRP es el esquema de redundancia recomendado en la mayoría de los casos. Proporciona conmutación por fallo casi inmediata sin pérdida de datos, incluso en redes grandes. Por otra parte, el SSRP provocará pérdidas durante una conmutación por fallo, y los tiempos de recuperación pueden ser sustanciales (a veces minutos) en las redes grandes.
Existe una situación en la que se recomienda el SSRP sobre el FSSRP: cuando la red está limitada por VC. A diferencia de SSRP, los LEC FSSRP mantienen conexiones de respaldo a los pares LES/BUS redundantes. Se pueden configurar hasta tres pares LES/BUS de respaldo comparado con un total de cuatro por ELAN. El aumento de uso de VC que experimentará la red bajo FSSRP se puede calcular usando la siguiente fórmula:
4 (#LEC_per_ELAN) (#LES/BUS_per_ELAN - 1) (#ELAN)
Por lo tanto, si la red alcanza su capacidad de VC, se recomienda SSRP sobre FSSRP. Si utiliza FSSRP, debe reducir el número de componentes LES/BUS redundantes. En la mayoría de las circunstancias, un total de dos pares LES/BUS por ELAN ofrece un equilibrio aceptable entre el uso de VC y la eliminación de puntos únicos de falla.