Principales diferencias entre Junos OS Evolved y Junos OS

Diferencias del sistema

El concepto de sistema en Junos OS evolucionado es diferente al de Junos OS. Junos OS utiliza un modelo centrado en el motor de enrutamiento, en el que sistema suele hacer referencia a un motor de enrutamiento. Sin embargo, Junos OS Evolved utiliza un modelo basado en nodos, donde sistema hace referencia a todos los nodos, incluidos los motores de enrutamiento, los concentradores de PIC flexibles (FPC) y más. En Junos OS evolucionado, un nodo es cualquier componente que puede ejecutar el kernel de Linux y las aplicaciones de Junos OS evolucionado, y todos los nodos se consideran nodos de proceso.

Impacto operativo

En Junos OS Evolved puede realizar muchas acciones por nodo. Puede utilizar comandos de CLI para ver información y solicitar operaciones en nodos individuales.

Comandos CLI relevantes

• show system nodes — Ver una lista de todos los nodos del sistema.

• show node ( reboot | statistics ) node-name — Ver información sobre un nodo específico.

• show system applications <node node-name> — Muestra la información de resumen de la aplicación para todos los nodos o un nodo específico.

• show system core-dumps <node node-name> — Muestra los archivos principales del sistema para todos los nodos o un nodo específico.

• show system errors active: utilice este comando en lugar del comando para ver la show chassis errors active información de errores del sistema.

• show system processes <node node-name> <detail> — Muestra la información del proceso para todos los nodos o un nodo específico.

• show system storage node ( re0 | re1 | fpc0 | fpc1 | ...) — Ver el espacio libre en disco para un nodo específico.

• show version node ( all | node-name ) — Muestra la información de la versión del software para todos los nodos o para un nodo específico.

• request node ( halt | offline | online | power-off/on | reboot ) node-name — Solicitar una operación en un nodo específico.

• request system reboot — En Junos OS Evolved, este comando reiniciará todos los nodos.

Estructura de software y aplicaciones

Junos OS Evolved funciona como un sistema operativo Linux distribuido con procesos que se ejecutan como aplicaciones autónomas. Cada proceso de Junos OS Evolved se ejecuta como una aplicación. Todas las aplicaciones de Junos OS Evolved se gestionan mediante el proceso mediante unidades de systemd servicio. Las aplicaciones se ejecutan como servicios independientes, lo que proporciona aislamiento de errores porque puede reiniciar una aplicación por separado sin afectar a otras aplicaciones. La mayoría de las aplicaciones publican y consumen el estado, que se almacena en una base de datos central.

Impacto operativo

En Junos OS Evolved, muchas funciones de alta disponibilidad son por aplicación en lugar de por nodo. Algunas aplicaciones ejecutan una copia de seguridad a tiempo completo para una conmutación por error rápida, mientras que otras aplicaciones se reinician en un nuevo nodo en caso de falla.

Comandos CLI relevantes

• show system applications <node node-name> — Muestra la información de resumen de la aplicación para todos los nodos o un nodo específico.

• restart process — En Junos OS, este comando reinicia un proceso específico. En Junos OS Evolved, el mismo comando reinicia una aplicación específica (proceso) en el mismo nodo desde el que se emite el comando.

• request system application restart app application node node — Este comando es específico de Junos OS Evolved y reinicia una aplicación específica en un nodo específico.

Modelo de Estado

Junos OS Evolved utiliza una infraestructura de estado distribuida. Las aplicaciones publican o se suscriben a objetos de estado, que se almacenan en una base de datos de estado denominada almacén de datos distribuido (DDS) que se distribuye entre los nodos. En comparación, los procesos de Junos OS almacenan el estado internamente, intercambiando información de estado y cambios de estado con otros procesos a través del kernel. El modelo de estado evolucionado de Junos OS es asíncrono y, en última instancia, coherente en la capa de transporte con coherencia causal en la capa de aplicación cuando se accede al estado. Esto significa que si un proceso se reinicia en Junos OS evolucionado, la información no se pierde porque puede recuperar información de estado del DDS.

Impacto operativo

El modelo de estado evolucionado de Junos OS conduce a un rendimiento más rápido porque no tiene que esperar a que se actualice el componente más lento. Las aplicaciones leen y escriben en el estado del sistema sin esperar a que cada otro proceso complete primero las actualizaciones. Si se reinicia una aplicación, la nueva instancia conserva el estado y se recupera del DDS, incluso si la aplicación se genera en un nodo diferente.

Administración de software

Cada vez que instale una imagen de software en Junos OS Evolved, la imagen y la configuración de software anteriores se conservarán automáticamente. Junos OS Evolved almacena imágenes de software en el directorio /soft . Cada versión del software se almacena en un área distinta, lo que garantiza que la instalación de un paquete de software no afecte a las otras versiones de software instaladas en el sistema. Mientras que Junos OS admite la instalación de dos versiones de software en el dispositivo, Junos OS Evolved admite el almacenamiento de tantas imágenes de software como el espacio lo permita. Sin embargo, le recomendamos que no mantenga más de cinco versiones de software en el sistema.

Durante una instalación correcta, el paquete de instalación reinstala completamente el software existente. Conserva los archivos de configuración e información similar, como el shell seguro y las claves de host, de la versión anterior. Cuando reinicia el sistema después de instalar un paquete de software, todos los motores de enrutamiento y FPC del sistema ejecutan la nueva versión del software.

Impacto operativo

Junos OS Evolved garantiza que todos los motores de enrutamiento y FPC del sistema ejecuten la misma versión de software. Cuando instala una imagen de software en el motor de enrutamiento principal, el sistema instala la nueva versión del software en ambos motores de enrutamiento, si los motores de enrutamiento están en línea y forman parte del sistema. Si inserta un motor de enrutamiento que tiene una versión de software diferente en el sistema y no ha configurado la system auto-sw-sync enable instrucción, el motor de enrutamiento se mantiene fuera del sistema y el sistema genera una alarma de falta de coincidencia de software.

Cuando instala una nueva imagen de software, el paquete de software anterior se conserva en un área independiente y puede revertir manualmente a ella si es necesario. Junos OS Evolved permite revertir a una imagen alternativa con el archivo de configuración actual o con la instantánea de configuración de la última vez que se ejecutó la imagen alternativa.

Comandos CLI relevantes

• show system software list — En Junos OS Evolved, vea las imágenes instaladas actualmente en cada nodo.

• show system storage— Ver el espacio de almacenamiento disponible. En Junos OS evolucionado, los directorios /soft, /var y /data deben tener menos del 90 % de capacidad para instalar imágenes adicionales.

• request system software delete — Limpiar imágenes antiguas. A partir de Junos OS Evolved versión 20.1R1, utilice este request system storage cleanup comando en lugar del comando para eliminar imágenes ISO del sistema.

• request system snapshot— Tome una instantánea de los archivos que se utilizan actualmente para ejecutar el dispositivo y copie los archivos en la unidad de estado sólido (SSD) alternativa. La instantánea incluye el contenido completo de los directorios /soft, /config y /root, copias de datos de usuario y contenido del directorio /var (excepto los directorios /var/core, /var/external, /var/log y /var/tmp).

• request system software rollback reboot <package-name> <with-old-snapshot-config> — Revertir todos los motores de enrutamiento y FPC a otra versión de software y reiniciar. Incluya la opción de usar la configuración guardada que corresponde a la with-old-snapshot-config imagen de software de reversión.

• request system software sync ( all-versions | current | rollback ) — Sincronice el software y las configuraciones desde el motor de enrutamiento primario a los otros nodos y reinicie los demás nodos.

• set system auto-sw-sync enable — Sincronice automáticamente el software y la configuración desde el motor de enrutamiento primario a un motor de enrutamiento recién agregado y reinicie cuando el motor de enrutamiento recién agregado tenga una versión de software diferente a la del resto del sistema.

Interfaces de administración

En Junos OS Evolved, se cambia el nombre de las interfaces de administración para dar cabida a más de un puerto de administración por nodo del motor de enrutamiento.

Impacto operativo

Las interfaces de administración de Junos OS Evolved no utilizan los mismos nombres que Junos OS (fxp0, em0, me0). En su lugar, el formato de nombre de interfaz de administración de Junos OS Evolved es device-name:type-port. Por ejemplo: re0:mgmt-0, , re0:mgmt-1, re1:mgmt-1re1:mgmt-0.

El show interfaces resultado muestra el estado de todas las interfaces, incluidas las interfaces Ethernet de administración de ambos motores de enrutamiento de un sistema de motor de enrutamiento dual.

Nombres de host del sistema

En Junos OS evolucionado, los nombres de host del sistema se anexan con un número de motor de enrutamiento correspondiente, como -re0 o -re1.

Impacto operativo

En Junos OS evolucionado, cuando se especifica la host-name instrucción, se anexa el nombre actual del motor de enrutamiento al hostname que especifique. Por ejemplo, en el motor de enrutamiento 0, set system host-name my-host establezca el nombre de host en my-host-re0. También puede utilizar el carácter para designar dónde sustituir el %s nombre del motor de enrutamiento. Por ejemplo, en el motor de enrutamiento 1, set system host-name %s_my_host establezca el nombre de host en re1_my-host .

Comandos CLI relevantes

• set system host-name hostname

Filtros de firewall del motor de enrutamiento

En Junos OS, para controlar el flujo de paquetes locales entre las interfaces físicas y el motor de enrutamiento, puede aplicar filtros de firewall sin estado a la entrada o salida de la interfaz de circuito cerrado. La interfaz de circuito cerrado (lo0) es la interfaz del motor de enrutamiento y no lleva paquetes de datos. En Junos OS, los filtros aplicados a la interfaz de circuito cerrado se aplican tanto al tráfico de control de red como al tráfico de administración.

Junos OS Evolved, por otro lado, admite dos filtros diferentes para controlar el flujo de paquetes locales: uno para el tráfico de control de red (tráfico de circuito cerrado) y otro para el tráfico de administración. Por lo tanto, los filtros aplicados a la interfaz de circuito cerrado solo se aplican al tráfico de control de red. También puede aplicar filtros por separado a la interfaz de administración, lo que le permite configurar un filtro más estricto en el tráfico de administración.

Impacto operativo

En Junos OS Evolved, los filtros de firewall aplicados a la interfaz de circuito cerrado solo se aplican al tráfico de control de red. Debe aplicar explícitamente filtros de firewall a la interfaz de administración para filtrar el tráfico de administración. En Junos OS Evolved, el filtrado de administración utiliza filtros del motor de enrutamiento basados en Netfilter, un marco que proporciona el kernel de Linux. Como resultado, solo se admiten ciertas coincidencias y acciones. En la tabla 1 se describe la aplicación de filtro Junos OS Evolved.

Pila de red evolucionada de Junos OS

Junos OS Evolved se ejecuta en Linux nativo. Existen algunas diferencias entre la forma en que Linux muestra la información de topología de red solicitada, como los datos de interfaz y ruta, y la forma en que Junos OS muestra esta información. La CLI de Junos OS Evolved está diseñada para superar estas diferencias. Por lo tanto, se recomienda utilizar comandos de CLI en lugar de comandos de shell para cualquier operación de red, especialmente para operaciones que requieren especificar una instancia de enrutamiento.

Si debe realizar operaciones en el shell de Linux cuando utiliza Junos OS evolucionado, debe conocer las siguientes instancias de enrutamiento, también conocidas como instancias virtuales de enrutamiento y reenvío (VRF):

• default: gestiona tanto la WAN como el tráfico de administración de forma predeterminada, a menos que configure la instancia de mgmt_junos enrutamiento.
• mgmt_junos: cuando configura esta instancia de enrutamiento, coloca el puerto de administración en su propia instancia de enrutamiento, lo que separa el tráfico de administración del tráfico WAN para el motor de enrutamiento.

• iri—Maneja el tráfico del plano de control (comunicación entre entrenudos). En la CLI evolucionada de Junos OS, esto es equivalente a la instancia de __juniper_private1__ enrutamiento.

Impacto operativo

En el shell de Junos OS evolucionado, puede usar la chvrf utilidad (change VRF) para ejecutar un comando en el contexto de una instancia de enrutamiento específica, o VRF. Por ejemplo:

Registro del sistema

En Junos OS evolucionado, cada nodo tiene la herramienta estándar journalctl , que es una interfaz para recuperar y filtrar el diario del sistema. Los mensajes de registro del sistema se analizan desde el diario del sistema. El relay-eventd proceso se ejecuta en todos los nodos y recupera eventos (basados en la configuración syslog) del diario del sistema, así como mensajes de error de las diferentes aplicaciones y los reenvía al master-eventd proceso. El master-eventd proceso se ejecuta en el motor de enrutamiento principal y escribe los mensajes de registro y los errores en el disco.

Utilice la aplicación System Log Explorer para ver o comparar mensajes de registro del sistema en diferentes versiones.

Impacto operativo

En Junos OS Evolved no hay ningún messages archivo en el motor de enrutamiento de reserva. Todos los registros del motor de enrutamiento de copia de seguridad se encuentran en el messages archivo del nodo principal Motor de enrutamiento.

Formato de mensaje de registro del sistema

De forma predeterminada, Junos OS Evolved anexa el nombre de nodo al nombre de host en los mensajes de registro del sistema; Junos OS no. Esta acción mantiene los mensajes de registro del sistema Junos OS Evolved en conformidad con RFC5424. Sin embargo, es posible que algunos sistemas de supervisión no identifiquen correctamente un nombre de host de Junos OS Evolved, ya que la combinación nombre-nodo no coincide con ningún nombre de host del inventario de nombres de host.

Impacto operativo

Si el sistema de supervisión no identifica correctamente los nombres de host de Junos OS Evolved, debe emitir el comando de modo de set system syslog alternate-format configuración. Este comando cambia el formato de los mensajes de registro del sistema de Junos OS Evolved. El nombre del nodo se antepone al nombre del proceso en el mensaje en lugar de anexarse al nombre de host, lo que permite que el sistema de supervisión identifique el nombre de host correctamente.

Arquitectura de seguimiento

Junos OS Evolved utiliza una nueva arquitectura de seguimiento. Todas las aplicaciones en ejecución crean información de seguimiento, con varias instancias de la misma aplicación con su propia información de seguimiento. Junos OS Evolved trace-relay y trace-writer las aplicaciones coordinan la información de seguimiento. La trace-relay aplicación se ejecuta en nodos locales y comparte un búfer de memoria con cada aplicación. Cuando una aplicación de Junos OS Evolved escribe en memoria, la trace-relay aplicación lee los datos directamente desde la memoria y los envía a las trace-writer aplicaciones. Una trace-writer aplicación se ejecuta en cada nodo del motor de enrutamiento. Recibe la información de seguimiento enviada desde las trace-relay aplicaciones y la escribe en el archivo apropiado en formato de seguimiento común (CTF).

Impacto operativo

En Junos OS, las operaciones de seguimiento se habilitan configurando la traceoptions instrucción en el nivel de jerarquía específico del que se desea realizar el seguimiento. Junos OS Evolved, por otro lado, utiliza un modelo basado en aplicaciones y, por lo tanto, los mensajes de seguimiento se registran, ven y configuran por aplicación. Como resultado, Junos OS Evolved no admite la traceoptions instrucción en muchos de los niveles de jerarquía que admite Junos OS. Sin embargo, algunos niveles de jerarquía, como los de [edit protocols], todavía requieren configurar la instrucción para habilitar los traceoptions mensajes de seguimiento.

Aunque Junos OS deshabilita las operaciones de seguimiento global para muchos niveles de jerarquía de forma predeterminada, algunos procesos registran mensajes de seguimiento de forma predeterminada para eventos importantes. Por el contrario, todas las aplicaciones que se ejecutan en Junos OS Evolved crean información de seguimiento en el nivel de info forma predeterminada.

En Junos OS Evolved, no se ven los archivos de seguimiento directamente y nunca se deben agregar, editar ni eliminar archivos de seguimiento en el directorio / var/log/traces , ya que esto puede dañar los seguimientos. En su lugar, utilice el show trace application application-name node node-name comando para leer y descodificar mensajes de seguimiento almacenados en los archivos de seguimiento.

Comandos CLI relevantes

• show trace application application-name node node-name — Leer y decodificar archivos de rastreo.

• clear trace — Limpie manualmente los archivos de rastreo.

• set system trace application — Modifique las configuraciones de los mensajes de rastreo a nivel de aplicación.