Descripción general de ISSU unificado en interfaces LSQ en línea
A partir de la versión 15.1 de Junos OS, se admite la actualización unificada de software en servicio (ISSU) en las interfaces de servicios de conexión en línea de cola inteligente (LSQ) en enrutadores serie MX. Unified ISSU permite una actualización entre dos versiones de Junos OS sin interrupciones en el plano de control y con una interrupción mínima del tráfico. Multilink PPP (MLPPP), Multilink Frame Relay (FRF.16) y Multilink Frame Relay de extremo a extremo (FRF.15) para las interfaces WAN de multiplexación por división de tiempo (TDM) proporcionan servicios de agrupación a través del motor de reenvío de paquetes sin necesidad de pic o concentrador de puerto denso (DPC). La interfaz lógica LSQ en línea (lsq-slot/pic/0) es una interfaz lógica de servicio virtual que reside en el motor de reenvío de paquetes para proporcionar servicios de agrupación para paquetes de capa 2 que no necesitan una PIC de servicios.
La compatibilidad unified ISSU para interfaces LSQ en línea ofrece retrocompatibilidad con versiones de Junos OS en las que este soporte no está disponible. Puede realizar un proceso ISSU unificado entre una versión de Junos OS que admita ISSU unificada para interfaces LSQ en línea y una versión de Junos OS en la que no esté disponible la compatibilidad con ISSU unificada para interfaces LSQ en línea. Esta retrocompatibilidad no se aplica a la situación en la que parte del software (como el software del kernel) se actualiza mientras que otra parte (como el software del motor de reenvío de paquetes) no se actualiza. La infraestructura ISSU unificada ofrece API para almacenar datos persistentes, realizar arranque frío (sin restablecer la energía) y administrar la conectividad y sincronización posteriores al reinicio de ISSU con el núcleo del motor de enrutamiento y otros procesos. El ISSU unificado también es compatible con interfaces LSQ (rlsq-) redundantes configuradas en modo de espera en caliente y en modo de espera caliente.
Las siguientes tarjetas de línea en enrutadores serie MX admiten ISSU unificado para interfaces LSQ en línea:
MIC DS3/E3 canalizado de 8 puertos (MIC-3D-8CHDS3-E3-B)
MIC canalizado SONET/SDH OC3/STM1 (Multi-Rate) de 8 puertos con SFP (MIC-3D-8CHOC3-4CHOC12)
MIC canalizado SONET/SDH OC3/STM1 (multi-velocidad) de 4 puertos con SFP1 (MIC-3D-4CHOC3-2CHOC12)
MPC tipo 1 3D Q (MX-MPC1-3D-Q)
MPC tipo 2 3D Q (MX-MPC2-3D-Q)
Las interfaces LSQ admiten los siguientes tres tipos de tráfico de datos multivínculo:
Paquetes multilink completos (para los que se configuran el ancho de banda y la encapsulación): estos paquetes no requieren la memoria de reensamblamiento.
Paquetes multivínculo fragmentados: estos paquetes requieren memoria de reensamblamiento para formar paquetes completos hasta que lleguen todos los fragmentos de todos los paquetes.
Paquetes de interleaving de fragmentos de vínculo (LFI): estos paquetes no tienen ningún encabezado multivínculo.
Hay dos intervalos de tiempo o duraciones llamados ventanas oscuras durante el proceso ISSU unificado. Estas ventanas oscuras indican la breve interrupción y interrupción del tráfico en el manejo de paquetes que pueden ocurrir cuando los motores de reenvío de paquetes se reinician debido a que se instala el software actualizado en ellos. La duración de estas desconexiones de tráfico varía según varios factores, como la plataforma y la versión de Junos OS que se está actualizando. Se observan las siguientes dos ventanas oscuras:
La primera ventana oscura se encuentra durante la fase de arranque ISSU unificada. Durante este período de tiempo, los paquetes enlazados a host se ven afectados porque se está inicializando la nueva imagen de microkernel y no se ha descubierto aún la ruta al host. Los cálculos de antigüedad para el reensamblaje y la fragmentación se detienen, lo que provoca que los tipos de tráfico fragmentado se caigan. Sin embargo, los paquetes LFI y los paquetes multilink completos no se interrumpen.
La segunda ventana oscura se produce durante la fase de sincronización del hardware. Durante este período de tiempo, el hardware aprende todos los estados nuevos del software. Los ASIC se reinician con las nuevas configuraciones. Durante este período, todo tipo de caídas de tráfico son permisibles. La duración de esta ventana oscura es de aproximadamente 4 a 5 segundos. Durante la segunda ventana oscura, dado que los paquetes se pierden en el lado de fragmentación, se produce una discordancia de número de recepción-ml-seq en el otro extremo de la conexión (lado del reensamblamiento o del receptor). Este comportamiento puede causar caídas de paquetes adicionales.
Durante un ISSU unificado, no se produce un cambio de la interfaz LSQ principal a la interfaz lsq secundaria y el paquete permanece activo. El impacto en los paquetes fragmentados (que se volverán a ensamblar) sigue siendo el mismo que en los paquetes en interfaces LSQ. Los paquetes LFI y no fragmentados se recorren hasta que comienza la segunda ventana oscura. La duración de la ventana oscura de las interfaces rlsq- es la misma que la de las interfaces LSQ. Ningún atributo en particular se mantiene solo en el hardware de MPC local. Todas las funcionalidades de QoS se comportan de la misma manera que la fase ISSU preun unificada.
Durante el proceso ISSU unificado, no se actualiza ninguno de los contadores de varios vínculos (excepto el número de secuencia de varios vínculos). Los contadores se restablecen e incrementan desde cero después de completar ISSU unificado. Los contadores de recepción-ml-seq y de envío de ml-seq deben actualizarse para que el reensamblaje se lleve a cabo correctamente, pero la actualización de estos contadores no se exporta a la microkernel del motor de reenvío de paquetes ni al motor de enrutamiento.
Se da por sentado que los vínculos de agrupación no flap durante la ventana ISSU unificada. Las siguientes operaciones se producen en los extremos de fragmentación y reensamblación durante un proceso ISSU unificado:
Cuando se completa ISSU unificado, el número de la secuencia de multivínculo de envío (send-ml-seq) comienza desde cero y provoca que el número de multilink de recepción (receive-ml-seq) no se coincida en el otro extremo de la conexión, lo que da lugar a caídas adicionales de paquetes. Considere el caso en el que los paquetes y vínculos de LSQ se pueden alojar en diferentes motores de reenvío de paquetes en una configuración de motor de reenvío de paquetes dual. En este caso, es posible que estos dos motores de reenvío de paquetes se encuentren en diferentes estados del proceso ISSU, donde las ventanas oscuras para ambos podrían seguir diferentes líneas de tiempo. Esta condición se suma a más caídas.
En el lado del reensamblado:
El reensamblace se detiene en la fase unificada de preparación o inicialización ISSU, lo que puede causar una ventana oscura más larga para los paquetes fragmentados. En el momento de LA EMISIÓN unificada, la memoria de reensamblamiento se utiliza para el procesamiento de ISSU unificado y no está disponible, desde la fase de preparación de ISSU unificada hasta la etapa de sincronización unificada del hardware ISSU.
Las dos actividades de cálculos de carga de vínculo y antigüedad de fragmentos podrían afectar el recorrido de paquetes durante ISSU unificado.
En el lado de la fragmentación:
. El contador de números ml-seq, necesario para que funcione la fragmentación de varios vínculos, no forma parte de los contadores ISSU unificados.
Los paquetes generados por host (que son paquetes de reescritura de capa 2) se transfieren como parte del encabezado de estructura y se guardan como objetos binarios de gran tamaño (BLOB).
Para el tráfico LFI, el cálculo de hash debe funcionar correctamente para que los vínculos estén equilibrados de carga. Si el estado del vínculo de medios cambia durante ISSU unificado, el estado del paquete también se puede ver afectado.