Descripción general de las funciones de la NFX150

La arquitectura de software de la NFX150 está diseñada para proporcionar un plano de control unificado que funciona como un único punto de gestión.

La figura 1 ilustra la arquitectura de la NFX150.

Figura 1: Arquitectura NFX150

Los componentes clave del software del sistema incluyen:

• VNF: una VNF es una oferta consolidada que contiene todos los componentes necesarios para admitir un entorno de red totalmente virtualizado. Puede configurar y usar VNF de terceros en cadenas de servicio.

• Plano de control de Junos (JCP): el JCP es la máquina virtual de Junos que se ejecuta en el sistema operativo host, Wind River Linux. El JCP funciona como el único punto de gestión para todos los componentes. El JCP controla el plano de datos de capa 2, que proporciona los servicios de capa 2, y el plano de datos de capa 3, que proporciona los servicios de capa 3 a capa 7.

  Además de la administración del chasis, JCP permite:

  • Configuración de funciones de seguridad avanzadas.

  • Gestión de funciones de red virtualizadas (VNF) de invitados durante su ciclo de vida.

  • Instalación de VNF de terceros.

  • Creación de cadenas de servicio VNF.

  • Gestión de imágenes VNF invitadas (sus archivos binarios).

  • Gestión del inventario del sistema y uso de recursos.

  • Gestión de la interfaz LTE.

• Administrador de dispositivos de Juniper (JDM): contenedor de aplicaciones que administra VNF y proporciona servicios de infraestructura. El JDM funciona en segundo plano y los usuarios no pueden acceder a JDM directamente.

• Plano de datos L2: plano de datos de capa 2 que administra el tráfico de capa 2. El plano de datos de capa 2 reenvía el tráfico LAN a la placa posterior de NFV, Open vSwitch (OVS). El plano de datos de capa 2 se asigna al FPC0 virtual en el JCP. De forma predeterminada, todos los puertos físicos de 1 Gigabit Ethernet se asignan a las interfaces virtuales en el plano de datos de capa 2.

• Plano de datos L3: plano de datos de capa 3 que proporciona funciones de ruta de datos para los servicios de capa 3 a capa 7. El plano de datos de capa 3 se asigna al FPC1 virtual en el JCP. De forma predeterminada, los dos puertos SFP+ del chasis NFX150 se asignan a las interfaces virtuales del plano de datos de capa 3.

• Linux: el sistema operativo host, WindRiver Linux. En Junos OS versión 18.1R1, la versión de WindRiver Linux es 8.

• Puente Open vSwitch (OVS): el puente OVS es un puente de sistema compatible con VLAN que actúa como la placa posterior de NFV a la que se conectan las VNF y FPC. Además, puede crear puentes OVS personalizados para aislar la conectividad entre diferentes VNF.

• LTE: un controlador en contenedores que proporciona administración de conectividad 4G LTE. El contenedor LTE está enlazado al FPC1 para su administración.

Las interfaces de los dispositivos NFX150 comprenden interfaces físicas, interfaces virtuales y la interfaz LTE.

• Interfaces físicas
• Interfaces virtuales
• Interfaz LTE
• Asignación de interfaz

En la Tabla 5 se enumeran las funciones de Junos compatibles con NFX150.

Para obtener más información sobre las características compatibles, consulte el Explorador de características.

Los dispositivos NFX150 proporcionan los siguientes modos operativos:

• Modo de transferencia de datos: proporciona el máximo de recursos (CPU y memoria) para el software de Junos y los recursos restantes, si los hubiera, para las VNF de terceros.

  Nota:

  No puede crear VNF en modo de rendimiento.

  A partir de Junos OS versión 21.1R1, la asignación de OVS a la interfaz de plano de datos de capa 3 no se admite en el modo de transferencia de datos en dispositivos NFX150-S1 y NFX150-S1E. Si la asignación de OVS está presente en versiones anteriores a Junos OS versión 21.1R1, debe cambiar la asignación antes de actualizar el dispositivo a Junos OS versión 21.1R1 para evitar que se produzca un error de confirmación de configuración.

• Modo híbrido: proporciona una distribución equilibrada de recursos entre el software de Junos y las VNF de terceros.

• Modo de proceso: proporciona recursos mínimos para el software de Junos y recursos máximos para VNF de terceros.

• Modo personalizado: proporciona una opción para asignar recursos a los componentes del sistema:

  • Plano de datos de capa 2, plano de datos de capa 3 y plano posterior NFV para modelos NFX150-S1 y NFX150-S1E

  • Plano de datos de capa 2 y plano de datos de capa 3 para los modelos NFX150-C-S1, NFX150-C-S1-AE/AA y NFX150-C-S1E-AE/AA

  Nota:

  Los modos de proceso, híbrido y de transferencia de datos se admiten en Junos OS versión 19.1R1 o posterior. El modo personalizado se admite a partir de Junos OS versión 22.1R1.

  El modo predeterminado es el rendimiento en las versiones de Junos OS anteriores a 21.4R1. A partir de Junos OS versión 21.4R1, el modo predeterminado es computación.

En los modos híbrido y de cómputo, puede asignar interfaces de plano de datos de capa 3 a SR-IOV u OVS. En el modo de transferencia de datos, puede asignar interfaces de plano de datos de capa 3 solo a SR-IOV.

Por ejemplo:

• Asigne interfaces de plano de datos de capa 3 a SR-IOV:

  user@host# set vmhost virtualization-options interfaces ge-1/0/1 mapping interface heth-0-1

• Asigne interfaces de plano de datos de capa 3 a OVS:

  user@host# set vmhost virtualization-options interfaces ge-1/0/1

En el modo híbrido o informático, puede crear VNF con las CPU disponibles en cada modo. Puede comprobar la disponibilidad de la CPU mediante el show vmhost mode comando. Cada VNF admite un máximo de 10 interfaces (eth0 a eth9), incluidas las dos interfaces de administración eth0 y eth1.

Para cambiar el modo actual, ejecute el request vmhost mode mode-name comando. El request vmhost mode ? comando enumera solo los modos predefinidos, como los modos híbrido, de proceso y de rendimiento.

Antes de cambiar a un modo, emita los show system visibility cpu comandos y show vmhost mode para comprobar la disponibilidad de las CPU. Cuando cambie entre modos operativos, asegúrese de que no se produzcan conflictos de recursos y configuración. Por ejemplo, si pasa del modo de proceso que admite VNF al modo de rendimiento que no admite VNF, se producen conflictos:

Si el plano de datos de capa 3 no está asignado a SR-IOV, se produce un error al cambio del modo híbrido o de cómputo al modo de procesamiento.

Si ancla una CPU virtual a CPU físicas para una VNF, asegúrese de que las CPU físicas no se superpongan con las CPU que se utilizan para los componentes del sistema Juniper, incluida la CPU física 0.

Las CPU físicas utilizadas para anclar un emulador pueden superponerse con las CPU que se usan para los componentes del sistema Juniper, excepto la CPU física 0. Esta superposición puede afectar el rendimiento de uno o más componentes del sistema Juniper y VNF.

• Cómo definir una plantilla de modo personalizado
• Mapeo de núcleo a CPU en NFX150

Para las características o los niveles de escala que requieren una licencia, debe instalar y configurarla correctamente para que cumpla los requisitos para usar la característica licenciable o el nivel de escala. El dispositivo le permite confirmar una configuración que especifica una característica o escala licenciable sin licencia durante un período de gracia de 30 días. El período de gracia es una concesión a corto plazo que le permite comenzar a usar las funciones del paquete o escalar hasta los límites del sistema (independientemente del límite de la clave de licencia) sin una clave de licencia instalada. El período de gracia comienza cuando el dispositivo usa realmente la característica licenciable o el nivel de escalado (no cuando se confirma por primera vez). En otras palabras, puede confirmar características licenciables o límites de escalado a la configuración del dispositivo, pero el período de gracia no comienza hasta que el dispositivo usa la característica licenciable o supera un nivel de escalado licenciable.

Para obtener más información sobre cómo comprar licencias de software, comuníquese con su representante de ventas de Juniper Networks. El software Junos OS implementa una estructura de licencias basada en honores y le ofrece un período de gracia de 30 días para usar la función sin una clave de licencia instalada. El período de gracia comienza cuando configura la función y el dispositivo utiliza la función con licencia por primera vez, pero no necesariamente cuando instala la licencia. Después de que expira el período de gracia, el sistema genera mensajes de registro del sistema que indican que la función requiere una licencia. Para borrar el mensaje de error y utilizar correctamente la característica con licencia, debe instalar y comprobar la licencia necesaria.

El dispositivo informa de cualquier infracción de licencia como un mensaje de registro de advertencia cada vez que se confirma una configuración que contiene una característica o un uso de límite de escala que requiere una licencia. Después del período de gracia de 30 días, el dispositivo informa periódicamente de la infracción a mensajes syslog hasta que se instala una licencia y se configura correctamente en el dispositivo para resolverla.