Modo de transferencia asíncrona (ATM) : Emulación LAN (LANE)

Recomendaciones en cuanto al diseño de LANE

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


Contenido


Introducción

Este documento proporciona las pautas de diseño de la red prácticas del LAN Emulation (LANE). Estas guías de consulta le ayudarán al diseño de rendimiento alto, scalable, y de redes LANE de alta disponibilidad. Mientras que este documento se centra en el equipo de Cisco, los mismos conceptos pueden ser aplicados al integrar los productos de terceros.

Antes de comenzar

Convenciones

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

prerrequisitos

Los Quien lea este documento deben estar bien informados de las operaciones básicas y de las configuraciones de las redes LANe.

Componentes Utilizados

Este documento se centra en las configuraciones de 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. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Comprensión de los requisitos del servidor

Presentan los diversos servidores lanes y sus requisitos abajo.

El LAN Emulation Configuration Server (LECS)

El LAN Emulation sobre la especificación de la versión ATM 1.0leavingcisco.com requiere que cada (LEC) del LAN Emulation Client establezca un virtual circuit (VC) al LAN Emulation Configuration Server (LECS) cuando sube. El LEC entonces pide el ATM Address de su LAN Emulation Server correspondiente (LES). Una vez que el LEC tiene su direccionamiento atmósfera LES, el VC entre el LEC y el LECS se quita, y el LEC intenta no más comunicar con el LECS. Cuando el entorno es estable y todos los LEC son ascendentes y operativos, el LECS está ocioso.

Cuando los LEC se unen a LAN emulada (ELAN), él cada contacto el LECS individualmente. Sin embargo, cuando la red LANe experimenta un desastre (por ejemplo, cuando el LECS primario falla), todos los clientes van abajo.

Nota: La excepción a esto es cuando se utiliza el protocolo fast simple server redundancy (FSSRP).

Puesto que van todos los LEC abajo al mismo tiempo, todo el contacto el backup LECS al mismo tiempo. Por lo tanto, para recibir el LECS, usted necesita un dispositivo eso:

  • puede manejar una ráfaga de tráfico súbita dirigida en el nivel de proceso.

  • puede validar casi todas las configuraciones de llamada entrante de los LEC simultáneamente.

  • se sabe para su estabilidad. Si va el LECS abajo, la red completa va abajo (otra vez, a excepción del FSSRP). Por lo tanto, poner el LECS en un dispositivo que funciona con una versión de software experimental no se recomienda.

El LAN Emulation Server (LES)

Cada LEC mantendrá un VC bidireccional al LES del ELAN (puede ser más de un ELAN si se utiliza el FSSRP). En un entorno muy cargado típico, muchas peticiones del protocolo lan emulation address resolution (LE_ARP) serán enviadas al LES. La implementación del LES en los dispositivos de Cisco es muy directa. Todas las tramas entrantes del LE_ARP serán remitidas al control distribuyen Conexión de canal virtual (VCC).

Usted no puede implementar a copia simple de una celda del hardware del control dirigido para controlar distribuye puesto que algunas tramas (tales como las peticiones del unido) tienen que ser analizadas por el proceso LES. Por lo tanto, un dispositivo que puede actuar como buen LES es un dispositivo eso:

  • tiene CPU potente y puede validar muchas configuraciones de la llamada en una pequeña cantidad de hora. Esto es necesario cuando muchos clientes se unen al ELAN al mismo tiempo, pero menos vital que para el LECS, puesto que solamente los LEC en el ELAN tienen que unirse a.

  • tiene soporte del hardware fuerte del Segmentation And Reassembly (SAR). Como todas las celdas entrantes tienen que ser vueltas a montar en las tramas, si mucho únase a las peticiones llegan al mismo tiempo, ellas tendrán que ser vueltas a montar muy rápidamente.

Recuerde que en la implementación de Cisco, el LES y los procesos del broadcast y servidor desconocidos (BUS) están combinados (es decir, usted no puede poner el LES para el ELAN-1 en un dispositivo, y el BUS para el ELAN-1 en otro dispositivo).

Otra cosa a tener presente es comportamiento con derecho preferente posible. Si se habilita el derecho preferente de compra, el LES/BUS con la prioridad más alta (según la base de datos LANe) asumirá el control siempre el deber del LES/BUS principal. Es decir si el LES/BUS principal falla, todos los LEC del ELAN irán abajo y volverán a conectar al LES/BUS de backup. Si se configura el PRE-emptivity, debe el LES/BUS principal subir otra vez, todos los LEC irán abajo una vez más y volverán a conectar al LES/BUS con la prioridad más alta. En el Software Release 11.3(4) y Posterior del ½ del ¿Â del Software Release 3.2.8 y Posterior, y de Cisco IOSï del módulo LANE, la característica de vaciamiento previó se puede dar vuelta por intervalos. La característica de vaciamiento previó se puede configurar según lo descrito en configurar la documentación del LAN Emulation.

El servidor de difusión y desconocido (BUS)

El trabajo del BUS es muy similar al trabajo del LES. Cada LEC se requiere para hacer que un Multicast envíe al BUS. El LEC le envía todo su Multicast, broadcast o tráfico desconocido. El BUS tiene una punta a de múltiples puntos VCC a todos los LEC en el ELAN. Los capítulos no tienen que ser examinados detalladamente por el BUS. Es decir cada trama entrante en el Multicast envía se puede remitir ciego al Multicast adelante.

Un buen dispositivo del BUS:

  • tiene soporte del hardware para la copia de la trama del Multicast entrante enviado al Multicast saliente adelante. Si usted tiene hardware “elegante”, esta operación de copiado se puede hacer antes del nuevo ensamble. Esto significa que las celdas entrantes en el Multicast envían están remitidas en el Multicast adelante. Esto guarda un Segmentation And Reassembly por la trama.

  • requiere un CPU fuerte si no hay soporte del hardware para el BUS.

  • debe poder procesar muchas configuraciones de la llamada al mismo tiempo, pero con un límite más bajo que el LECS.

Tabla 1: Rendimiento de bus por el dispositivo

Dispositivo Rendimiento de bus (kpps)
Módulo del Catalyst 6K LANE/MPOA (OC-12) 600
Módulo del Catalyst 5K LANE/MPOA (OC-12) 600
Módulo del Catalyst 5K LANE/MPOA (OC-3) 166
Módulo LANE del Catalyst 5K (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

Información sobre las capacidades de dispositivos de Cisco

Esta sección cubre las capacidades de los dispositivos de Cisco mas comunes usados para funcionar con el LEC, el LECS, el LES, y el BUS. Estos dispositivos son los módulos LANE de Cisco, el LightStream 1010, el Catalyst 8510MSR y los 8540MSR, y los 7500/RSP. Sus capacidades se comparan contra los requisitos enumerados arriba.

Módulos LANE

La arquitectura de todos los módulos LANE para el Catalyst 5000 y 6000 se basa áspero en la vista de alto nivel siguiente:

/image/gif/paws/10459/LANEdesign.gif

El Segmentation And Reassembly es realizado por el hardware. El chip SAR es algo inteligente, y puede remitir directamente las tramas reensambladas al bus de la trama del Catalyst (el backplane de Catalyst). Para las tramas de control, el chip SAR puede remitir las tramas al CPU del módulo LANE. Una trama de control es cualquier trama que tenga que ser analizada (por ejemplo, Interim Local Management Interface (ILMI), señalización, y las tramas destinadas al LES), viniendo al módulo LANE vía un VC especificado.

El chip SAR puede también reorientar las células que vienen en el Multicast envía al Multicast adelante (es decir, Multicast, broadcast, y las células desconocidas que vienen de los LEC). Las células no se vuelven a montar en las tramas. Su facilidad de la implementación da lugar al rendimiento de bus muy bueno.

Una vez que se han creado una “vía directa de datos” y una entrada en la tabla de la memoria de contenido direccionable (CAM), las tramas reensambladas se envían directamente al BUS de la trama y se marcan con etiqueta con el Virtual LAN (VLAN) correcto ID. Un módulo LANE hace un LEC muy bueno porque una vez que se ha establecido la “vía directa de datos”, el CPU está implicado no más.

LightStream 1010 y Catalyst 8510MSR

El LS1010 y el Catalyst 8510MSR no tienen soporte del hardware para el SAR. Por lo tanto, esos dispositivos son malas elecciones para implementar las funciones LES/BUS. Son, sin embargo, convenientes para el LECS (refiera al diseño de ejemplo 2 abajo).

8540MSR

El 8540MSR tiene soporte del hardware para el SAR. También tiene un procesador potente Risc 5000. 8540MSR no se recomienda para soportar el LES/BUS por dos razones:

  • El rendimiento de bus está alrededor de 50Kpps para 64 paquetes de bytes, lejos debajo de cualquier módulo LANE. Esto es porque no hay aceleración por hardware para el BUS.

  • Si el 8540MSR se utiliza con la atmósfera y las placas Ethernet, el CPU se puede utilizar sobre todo para hablar con el linecards de los Ethernetes. En este caso, el 8540MSR's CPU no se debe utilizar como LES.

Plataformas de router

El router más de uso general para la encaminamiento inter-ELAN es la plataforma del Cisco 7500 (el (RSM) del Route Switch Module y el Cisco 7200 son también ampliamente utilizados). El adaptador de puerto contiene el chip del hardware SAR. La ruta/los Procesadores del switch (RSP) por ejemplo el RSP4 tiene bastantes energías en la CPU para procesar las tramas entrantes muy rápidamente; por lo tanto, ella es una buena opción para el LES. El rendimiento de bus, sin embargo, está abajo el de los módulos LANE.

Diseños de ejemplo

El LANE se utiliza principalmente en grande y las redes críticas. Como tal, la Redundancia es obligatoria. El Simple Server Redundancy Protocol (SSRP) es el Redundancy Protocol más ampliamente utilizado. Si el software es reciente, el FSSRP es el Protocolo preferido (refiera a la guía de consulta #11).

Asumámosnos tienen bastante una Red grande, por ejemplo 100 VLA N/ELAN y 100 Catalyst, cada uno con un módulo LANE dual del uplink. Esto significa que en cada módulo LANE, puede ser que necesitemos un LEC por el ELAN, en este caso 10,000 LEC. Además, asumimos que el IP está utilizado, y que el diseño incluye un C de la clase de la caja fuerte (254 direccionamientos del host IP, 254 direcciones MAC) por el VLA N.

Diseño 1: Simple, pero ser evitado…

En este diseño, un módulo LANE se ha elegido para funcionar con los 100 servidores LES/BUS. Al mismo tiempo, el LECS primario está en el mismo módulo LANE. Esto se ilustra en el gráfico abajo:

LANEdesign1.gif

Al crear los LEC en el módulo LANE, todos los LEC suben tan pronto como se configuren. Durante la operación, el proceso LES pudo sobrecargarse, y el módulo LANE se ejecutará de la memoria. El diseño 2 abajo soluciona ambos estos problemas.

La cuestión principal en esta red es cuando ocurre un problema principal. Asuma que el módulo LANE que recibe el LECS, el LES, o el BUS llega a ser inalcanzable. Esto pudo suceder, por ejemplo, si el módulo LANE del Catalyst 1 llega a ser defectuoso. ¡Usted puede ver la Redundancia el ocurrir, pero el tiempo de redundancia (es decir, el tiempo entre el LECS primario, LES, o falla de bus, y el último LEC que llega a ser operativo otra vez) pudo durar hasta dos horas! Un buen diseño pudo derribar este número a algunas docenas de segundos, o de algunos minutos en las Redes grandes.

El problema miente en la señalización implicada con los LEC que se unen al ELAN. Si el LECS se debe entrar en contacto por cada LEC, recibirá 10,000 configuraciones de la llamada (100 módulos LANE con 100 LEC en cada uno) casi simultáneamente. El módulo LANE se diseña para interligar eficientemente entre el bus de la trama y el link de la célula, pero para no manejar muchas configuraciones de la llamada por segundo. El CPU del módulo LANE no es bastante potente manejar este volumen de configuraciones de la llamada. El producto siguiente ilustra el tiempo de redundancia en una red LANe con appproximately 1600 LEC (solamente visualizan a la 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 usted puede ver, el módulo LANE es excesivo excesivamente debido a la actividad de señalización entrante. ¿Qué explica el tiempo de redundancia de dos horas? La respuesta miente en la noción del descanso. Las especificaciones de señalización mencionan claramente que si el dispositivo no recibe un mensaje del “Conectar” después de una determinada cantidad de hora en que se envía una “configuración de la llamada”, debe comenzar encima. Las especificaciones de LANe requieren que el LEC deba volver a su estado inicial, y comienzan de nuevo. ¡Esto significa que si un LEC puede entrar en contacto el LECS y conseguir conectado con él, pudo su configuración de la llamada al LES time-out, y vuelve a su estado inicial de intentar entrar en contacto el LECS! Esto puede también suceder con las conexiones del LES, y desde/hasta el BUS.

Se basan en las explicaciones arriba, aquí algunas recomendaciones del diseño básico:

  • Intente separar el LES/BUS para los diversos ELAN en los diversos dispositivos que pueden implementarlo eficientemente. Idealmente, un LES/BUS principal en cada módulo LANE, con los siguientes sosteniendo los primeros. En la práctica, esto generaría una base de datos LECS muy larga. La experiencia muestra que 10 servidores LES/BUS por el módulo LANE parecen ser un número seguro.

  • Intente no poner el LECS en la misma ubicación que otros servidores importantes LES/BUS. También el intento para poner el LECS en un dispositivo con las suficientes energías en la CPU así que él puede manejar la información de señalización eficientemente. El LECS debe estar en un router (el Cisco 7200 o los 7500 se recomienda, idealmente sin el LES/BUS), o en un switch ATM.

  • El IP presuntuoso y un rango del C de la clase se utiliza para cada VLA N, aproximadamente 250 direcciones MAC son un buen número para el trabajo LES. Para 10 LES en un módulo LANE, esto significa el 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 esto es una caja fuerte y un cálculo conservador. Por otra parte, 200 LES/BUS en un módulo LANE, con cada ELAN conteniendo 1000 estaciones terminales, son seguros mientras la estación siga siendo prácticamente ociosa (refiera a la guía de consulta #3 para más detalles).

Diseño 2: Más complejo, pero más seguro y más eficiente…

En este diseño, pusimos el LECS en el switch ATM. Separamos el LES/BUS en diversos módulos LANE. Los altos valores del proceso CPU no se consideran en ninguna módulos LANE, y la Redundancia es normal.

LANEdesign2.gif

Pautas

Las guías de consulta presentadas abajo son recomendaciones prácticas solamente, sobre la base de las redes LANe del despliegue de producción. Mientras que existen los ejemplos de las redes satisfactorias que exceden las recomendaciones, una perfecta comprensión cómo afectarán de la red se requiere antes de exceder estas guías de consulta.

Guía 1

Si usted planea utilizar el Hot Standby Router Protocol (HSRP) por LANE, aseegurese que usted actualiza a una versión reciente y ha leído implementar el HSRP over LANE.

Pauta Nro. 2

Distribuya el BUS LANE en los dispositivos con la capacidad de rendimiento de bus más alta, y donde tendrá efecto mínimo en otros procesos en el dispositivo.

El BUS LANE es responsable de remitir todo el broadcast, Multicast, y tramas de unidifusión del destino desconocido recibidas de los miembros de un ELAN, a todos los miembros del ELAN. Puesto que el LANE utiliza el capa 5 de adaptación del ATM (AAL5) que no permite la interpolación de las células de diversas unidades de datos de protocolo (PDU), el BUS debe serializar las tramas antes de la expedición. Esto requiere el BUS volver a montar las tramas recibidas, divide cada trama en segmentos uno por uno, y remite las células. El requisito de volver a montar y de dividir cada trama en segmentos limita perceptiblemente el rendimiento de reenvío del BUS, que influencia considerablemente el scalability de un ELAN. La proliferación de las aplicaciones del Multicast IP más futuras intensifica esta tarea. Recuerde que solamente los módulos LANE pueden recibir las células en el Multicast envían y remítalas en el Multicast adelante. Esto se hace sin el nuevo ensamble.

Pauta Nº 3

Distribuya los servicios LANe a través de los módulos múltiples y de los dispositivos.

Expusimos arriba que 10 LES/BUS con cada ELAN correspondiente a una red del IP del C de la clase (aproximadamente 250 usuarios) son seguros y conservadores; sin embargo, las redes LANe acertadas con 10-60 pares LES/BUS por el módulo existen. Esto depende levemente del módulo, pero marcar el diseño implicará siempre el marcar de la utilización de la CPU (usando el comando show processes cpu), y de memoria disponible más baja (usando el comando show memory). Esto se debe, por supuesto, realizar durante la utilización de la red máxima, pues la utilización de la CPU total LES se relaciona directamente con el proceso del LE_ARP.

En un entorno LANe, es común ver los pares LES/BUS situados en un único dispositivo que soporta la red LANe entera. No sólo esto representa un solo punto de falla, pero limita el rendimiento de bus dentro de cada ELAN.

La distribución de los servicios LANe a través de las plataformas múltiples proporciona el mayor scalability en los entornos multi-ELAN, así como una Disponibilidad del sistema más alta y rendimiento de bus total creciente (por ejemplo, el rendimiento de bus total en la red aumenta mientras que más dispositivos y interfaces se configuran para el soporte del BUS). Para el capacidad de bus máximo de una perspectiva del diseño, de los módulos ATM del Catalyst 5000 y 6000 puede ser dedicado al LES y a los servicios de BUS.

Conociendo la capacidad del BUS, y estimando la cantidad de broadcast o de tráfico Multicast esperado en cada ELAN, usted puede calcular el número de pares LES/BUS que se puedan aplicar a una interfaz dada. Usted puede también medir la capacidad del BUS.

El cálculo de la cantidad de broadcast o del tráfico Multicast para cada ELAN es, sin embargo, más desafiador. Un método para estimar la cantidad de broadcast o el tráfico Multicast para cada ELAN es medir este tráfico en la red existente. Dispositivo un analizador de red o de una sonda del Monitoreo remoto (RMON) se puede insertar en el LAN existente para medir la cantidad de broadcast y de tráfico Multicast. Otra manera es preguntar los objetos MIB de los “ifOutMulticastPkts” y de los “ifOutBroadcastPkts”. Marque primero independientemente de si están soportados en su IOS/platform.

Alternativamente, usted puede, calcular hasta cierto punto la cantidad de broadcast o de tráfico Multicast calculando el ancho de banda consumido por los broadcasts del Routing Protocol, por ejemplo. Para el Intercambio de paquetes entre redes (IPX), el Routing Information Protocol (RIP), y el protocolo service advertising (SAP), el consumo de ancho de banda puede ser determinado exactamente si el número de rutas de IPX y las savias se saben. Lo mismo es verdad para el IP y el Routing Protocol particular que es utilizado.

El espacio libre adicional del capacidad de bus debe ser reservado para:

  • Soportar el tráfico de unidifusión mientras que se está estableciendo un VC de la vía directa de datos y hasta que un paquete rasante se reconoce en el LEC de recepción.

  • Las aplicaciones a pedido del Multicast IP que se utilizan en diversas ocasiones del día (éstos se deben considerar en el volumen de multidifusión general).

  • Tráfico adicional de la encaminamiento cuando un protocolo se está ejecutando y en un estado de la convergencia (es decir, anuncios del estado del vínculo (LSA) intercambiados durante un cambio de la topología del Open Shortest Path First (OSPF)).

  • Volúmenes altos de peticiones de Address Resolution Protocol (ARP), específicamente por la mañana en que primer registro de los puestos de trabajo en el LAN y los servidores de red.

Usando cualquier método está disponible, la meta es tener una representación precisa de la cantidad de broadcast y de tráfico Multicast que existirá en cada ELAN. Desafortunadamente, esta información está raramente disponible para el diseñador de red por las diversas razones. Cuando están hechas frente con esta situación, algunas pautas generales conservadoras pueden ser utilizadas. Como recomendación, una red típica con 250 usuarios por elan, ejecutando las más aplicaciones comunes, se debe afectar un aparato por lo menos 10 kpps del capacidad de bus. El cuadro 1 ilustra la cantidad recomendada máxima de pares LES/BUS por la interfaz.

Estos números se deben utilizar conjuntamente con la guía de consulta #4, que limita a 250 el número de LEC mantenidos por todos los pares LES/BUS configurados en una interfaz. También, estos números se deben ajustar según el número real de usuarios en cada ELAN, mientras que prestan la especial atención a cualquier broadcast o aplicación de multidifusión que sean ejecutados en el ELAN.

Pauta Nº 4

Limite el número total de LEC mantenido por los pares LES/BUS a un máximo de 250. Durante la inicialización, y después de un desperfecto de la red, para que los clientes LANE se unan a su ELAN, deben establecer las conexiones múltiples y hacer las peticiones a sus componentes de servicio LANe. Puesto que los dispositivos que soportan los servicios LANe poseen una velocidad finita en la cual puedan procesar las conexiones y las peticiones, se recomienda que los pares LES/BUS configurados en una interfaz mantienen un máximo de 250 clientes LANE. Por ejemplo, una interfaz se puede configurar con 10 pares LES/BUS, cada los 25 LEC de mantenimiento para un total de 250 LEC siendo mantenido por la interfaz. Esto asegurará la inicialización a tiempo y la recuperación de errores.

Pauta Nº 5

Ponga el LES/BUS para un ELAN dado en el muy cerca a cualquier fuente importante de tráfico de broadcast o multicast.

En un entorno LANe, específicamente donde están funcionando las aplicaciones de multidifusión (es decir, IP/TV), es buena práctica del diseño colocar el BUS tan cerca al origen de multidifusión sabido como sea posible. Puesto que el tráfico Multicast se debe primero enviar al BUS, que a su vez adelante el tráfico a todos los clientes, situando el BUS en el muy cerca al origen de multidifusión guarda el tráfico de cruzar la estructura básica de ATM dos veces.

Esto permite que la red LANe escale a una mayor magnitud. Además, el BUS no se debe situar en la misma interfaz que el LEC que soporta el origen de multidifusión, puesto que el tráfico Multicast cruzaría el link del transmitir dos veces.

Ejercite la precaución si usted está considerando el LANE como la tecnología de interconexión de redes soportar un entorno del Multicast. Mientras que el LANE soporta el tráfico Multicast, hace tan bastante ineficazmente. El LANE inunda simplemente el tráfico Multicast a todos los clientes en el ELAN sin importar independientemente de si son parte del grupo de multidifusión. Exceso del tráfico Multicast puede degradar perceptiblemente el rendimiento de las estaciones de trabajo (como se debate en la guía de consulta #6), mientras que la conducta de inundación pierde el ancho de banda de estructura básica.

Pauta Nº 6

Limite el número de sistemas extremos en un ELAN dado a 500 o menos, si la red lleva solamente los paquetes del IP. El cuadro 2 abajo da una cierta recomendación básica basada en la cantidad de broadcast generada por el protocolo. En caso de que usted no esté completamente seguro qué protocolos serán necesarios, tenga una vez más presente la recomendación de 250 estaciones terminales que dimos en el pasado.

Por definición, un ELAN representa un dominio de broadcast. Por lo tanto, dentro de un ELAN, todo el broadcast y paquetes de multidifusión se inundan a todos los miembros del ELAN. Los puestos de trabajo deben procesar cada broadcast y paquete de multidifusión recibidos para determinar si está de interés. El proceso de los paquetes de broadcast “sin interés” pierde los ciclos de la CPU del puesto de trabajo. Cuando el nivel de actividad de broadcast llega a ser alto (en relación con la capacidad de procesamiento de los puestos de trabajo), pueden ser afectados y ser prevenidos seriamente de realizar sus tareas previstas.

El número de sistemas extremos, las aplicaciones, y los protocolos funcionando determinan el nivel de difusión dentro de un ELAN. Las pruebas han ilustrado que, en ausencia de las aplicaciones intensivas del broadcast, el número de sistemas extremos que se pueden configurar con seguridad en un solo ELAN se extiende a partir del 200 a 500 dependiendo de la combinación de protocolos.

Tabla 2: Número máximo de sistemas extremos recomendados por el ELAN basado en la combinación de protocolos

Tipo de protocolo Número de sistemas extremos
IP 500
IPX 300
AppleTalk 200
Mixto 200

Pauta Nº 7

Calcule el uso del VC de la red para asegurarse que está dentro de la capacidad de los dispositivos ATM.

Uso del VC

El Switches ATM y los dispositivos de borde soportan un número limitado de VCs. Al diseñar las redes ATM, es importante asegurarse de que la capacidad del VC del equipo no está excedida. Esto es determinado importante en las redes LANe, puesto que el LANE no se observa para su eficacia del VC. Durante la fase de diseño de red, usted debe calcular el uso anticipado del VC para la estructura básica, así como para cada dispositivo de borde individual. El uso del VC de la estructura básica corresponde al número total de VCs esperó en la red. Esta cantidad se debe comparar al número de VCs soportó por el Switches ATM.

Puesto que no toda la cruz de VCs un Switch dado, este número sirve como límite superior. La topología real de la estructura básica y de los patrones de tráfico se debe considerar, en relación con el número total de VCs, para determinar si la capacidad del VC del Switches ATM es excedida.

Semejantemente, el uso del VC para cada dispositivo de borde debe ser calculado. Esto se relaciona con el número de VCs que terminará en una interfaz dada de un dispositivo de borde. Este número se debe entonces comparar a la capacidad del VC de la interfaz.

Las fórmulas siguientes pueden ser utilizadas en el cálculo del uso del VC de la red. Estas fórmulas asumen el uso de los servicios LANe y de los clientes de Cisco, y se aplican al SSRP y al FSSRP. Cuando se indica el presente, las diferencias en el uso del VC entre los dos protocolos.

Uso del VC de la estructura básica

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

Uso del VC de la interfaz de dispositivo de borde

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 usted ha calculado el uso del VC, compare los resultados a la capacidad del VC de los dispositivos pertinentes usando el cuadro 3.

Tabla 3: Encaminamiento Inter-ELAN - Capacidad del VC para los diversos dispositivos de Cisco

Dispositivo Presupuesto del circuito virtual
Catalyst 8540MSR 256k
Catalyst 8510 MSR/LS1010 Memoria RAM dinámica del 16 MB (DRAM) = 4k
32 MB DRAM = 16k
64 MB DRAM = 32k
Atmósfera del Cisco 7500/7200 de lujo 4k
ATM Lite del Cisco 7500/7200 2k
Catalyst 6K - LANE/MPOA OC-12 4k
Catalyst 5K - LANE/MPOA OC-12 4k
Catalyst 5K - LANE/MPOA OC-3 4k
Catalyst 5K - LANE OC-3 4k
Catalyst 2900 XL - LANE OC-3 1k

Pauta Nº 8

Si usted quiere conectar diversas redes ATM de oficina central a los trayectos virtuales permanentes (PVP), siempre la “ruta” entre los sitios bastante que los ELAN nativos atravesar diversas redes ATM de oficina central.

Pauta Nº 9

Evalúe la capacidad del router necesaria estimando la cantidad de la encaminamiento inter-ELAN requerida.

La cantidad de capacidad de ruteo requerida en una determinada red LANe varía extensamente. Por lo tanto, la cantidad de capacidad de ruteo se debe estimar durante el proceso de diseño de red. Después de determinar la capacidad requerida, el número de Routers y las interfaces del router necesarias se pueden determinar usando la tabla siguiente del rendimiento de reenvío:

Tabla 4: Capacidad de ruteo Inter-ELAN para los diversos dispositivos de Cisco

Dispositivo Cisco Express Forwarding (CEF) distribuido (kpps) Envío del Cisco Express Forwarding (CEF) (kpps)
RSP4/VIP2-50 ATMÓSFERA PA-A3 118 101
RSP4/VIP2-50 ATMÓSFERA PA-A1 91 91
RSP4/VIP2-40 ATMÓSFERA PA-A3 83 60
RSP4/VIP2-40 ATMÓSFERA PA-A1 66 66

Mientras que la configuración del router “de un brazo” es popular en los diseños de LANe, ésta no proporciona típicamente la capacidad de ruteo adecuada. En lugar, requieren las interfaces múltiples y/o a los routeres múltiples. Las velocidades de reenvío CEF enumeradas en la tabla antedicha asumen una configuración del router de un brazo. Para alcanzar estas tarifas, el procesador central del router se avanza a la utilización del casi 100%. Por el contrario, las velocidades de reenvío distribuidas se alcanzan usando el procesador que reside en el procesador de interfaz versátil (VIP), con esencialmente ningún impacto en el procesador del router centralizado. Como consecuencia, las interfaces ATM múltiples se pueden instalar en el router que lleva a un rendimiento total mucho más alto.

Pauta N° 10

Proporcione los dispositivos de borde atmósfera del dual-hogar por lo menos a dos diversos Switches ATM para la Redundancia.

En una red LANe, el switch ATM que soporta los dispositivos de borde puede ser un solo punto de falla para la Conectividad a la estructura básica. Los Catalyst 6K y 5K proporcionan OC-12/OC-3 los módulos del link ascendente dual-físicos del substrato (PHY) para la conectividad redundante al Switches ATM rio abajo. Los módulos LANE dirigidos duales proporcionan un “Fiber Distributed Data Interface (FDDI) - como” la característica del PHY dual. Este módulo del link ascendente del PHY dual proporciona una interfaz ATM primaria y secundaria. Si la interfaz primaria pierde la Conectividad del link al switch ATM, el módulo cambiará automáticamente la conexión a la interfaz secundaria.

Se recomienda altamente que el diseñador de red se aprovecha de las interfaces del PHY dual en los módulos LANE y proporciona el uplinks dirigido dual a dos diversos Switches ATM en la base. Esto protegerá los dispositivos de borde contra el error de un solo switch ATM.

Directiva nº11

Utilice el FSSRP a menos que el presupuesto del VC tenga apremios.

Puesto que los diversos componentes de servicio LANe son solos puntos de falla en una red LANe, las redes de producción se deben diseñar con la Redundancia. Cisco soporta dos planes de redundancia para los servicios LANe: Simple Server Redundancy Protocol (SSRP) y Fast SSRP (FSSRP).

El FSSRP es el plan de redundancia recomendado en la mayoría de los casos. Casi proporciona a la falla por transmisión inmediata sin la pérdida de datos, incluso en las Redes grandes. Por otra parte, el SSRP dará lugar a la pérdida durante una Conmutación por falla, y los tiempos de recuperación pueden ser sustanciales (a veces los minutos) en las Redes grandes.

Existe una situación donde el SSRP se recomienda sobre el FSSRP: cuando VC-se obliga la red. En contraste con el SSRP, el FSSRP LEC mantiene las conexiones de respaldo a los pares redundantes LES/BUS. Hasta tres pares del LES/BUS de backup se pueden configurar compararon a un total de cuatro por el ELAN. El aumento del uso del VC que la red experimentará bajo el FSSRP se puede calcular usando la fórmula siguiente:

4 (#LEC_per_ELAN) (#LES/BUS_per_ELAN - 1) (#ELAN) 

Por lo tanto, si la red alcanza su capacidad del VC, el SSRP se recomienda sobre el FSSRP. Si usted utiliza el FSSRP, después usted debe reducir el número de componentes redundantes LES/BUS. En la mayoría de los casos, un total de dos pares LES/BUS por el ELAN ofrecen un equilibrio aceptable entre el uso del VC y los solos puntos de falla de la eliminación.


Información Relacionada


Document ID: 10459