EN ESTA PÁGINA
Optimización de la ruta de estructura para la interfaz de estructura abstracta
Elegir entre el modelo de servidor externo y el modelo integrado en el chasis
Descripción general de la interoperabilidad del software multiversión
Servicios de próxima generación en la división de nodos de Junos
Comparación de la división de nodos de Junos con los sistemas lógicos
Descripción de la división de nodos de Junos
Descripción general de la división de nodos de Junos
La división de nodos de Junos permite a los proveedores de servicios y a las grandes empresas crear una infraestructura de red que consolida varias funciones de enrutamiento en un único dispositivo físico. Ayuda a alojar múltiples servicios en una única infraestructura física, a la vez que evita la complejidad operativa involucrada. También mantiene la separación operativa, funcional y administrativa de las funciones alojadas en el dispositivo.
Con la división de nodos de Junos, puede crear varias particiones en un único enrutador físico de la serie MX. Estas particiones se denominan funciones de red de invitados (GNF). Cada GNF se comporta como un enrutador independiente, con su propio plano de control, plano de datos y plano de administración dedicados. Esto le permite ejecutar varios servicios en un único enrutador convergente de la serie MX, sin dejar de mantener el aislamiento operativo entre ellos. Puede aprovechar el mismo dispositivo físico para crear particiones paralelas que no compartan el plano de control ni el plano de reenvío, sino que solo compartan el mismo chasis, espacio y alimentación.
También puede enviar tráfico entre GNF a través de la estructura del conmutador mediante una interfaz de estructura abstracta (af), una pseudointerfaz que se comporta como una interfaz Ethernet de primera clase. Una interfaz de estructura abstracta facilita el control de enrutamiento, los datos y el tráfico de administración entre GNF.
La división de nodos de Junos ofrece dos modelos: un modelo de servidor externo y un modelo integrado en el chasis. En el modelo de servidor externo, los GNF se alojan en un par de servidores x86 estándar de la industria. Para el modelo en chasis, los GNF se alojan en los motores de enrutamiento del enrutador de la serie MX.
La división de nodos de Junos admite la compatibilidad con software multiversión, lo que permite que los GNF se actualicen de forma independiente.
Ventajas de la división de nodos de Junos
Converged network—Con la división de nodos de Junos, los proveedores de servicios pueden consolidar varios servicios de red, como el borde de video y el borde de voz, en un único enrutador físico, sin dejar de mantener la separación operativa entre ellos. Se puede lograr una convergencia horizontal y vertical. La convergencia horizontal consolida las funciones de enrutador de la misma capa en un solo enrutador, mientras que la convergencia vertical colapsa las funciones de enrutador de diferentes capas en un solo enrutador.
Improved scalability—Centrarse en particiones de enrutamiento virtual, en lugar de dispositivos físicos, mejora la programabilidad y escalabilidad de la red, lo que permite a los proveedores de servicios y a las empresas responder a los requisitos de infraestructura sin tener que comprar hardware adicional.
Easy risk management—Aunque varias funciones de red convergen en un solo chasis, todas las funciones se ejecutan de manera independiente, beneficiándose de la separación operativa, funcional y administrativa. La partición de un sistema físico, como la puerta de enlace de red de banda ancha (BNG), en varias instancias lógicas independientes garantiza el aislamiento de los errores. Las particiones no comparten el plano de control ni el plano de reenvío, sino que comparten el mismo chasis, espacio y alimentación. Esto significa que un error en una partición no causa ninguna interrupción generalizada del servicio.
Reduced network costs—La división de nodos de Junos permite la interconexión de GNF a través de estructuras de conmutación internas, lo que aprovecha la interfaz de estructura abstracta (
af), una pseudointerfaz que representa un comportamiento de interfaz Ethernet de primera clase. Conafla interfaz implementada, las empresas ya no necesitan depender de interfaces físicas para conectar GNF, lo que resulta en ahorros significativos.Reduced time-to-market for new services and capabilities—Cada GNF puede funcionar con una versión diferente del software de Junos. Esta ventaja permite a las empresas evolucionar cada GNF a su propio ritmo. Si es necesario implementar un nuevo servicio o una característica en un GNF determinado y requiere una nueva versión de software, solo el GNF involucrado requiere una actualización. Además, con la mayor agilidad, la división de nodos de Junos permite a los proveedores de servicios y a las empresas introducir un modelo de negocio de todo como servicio altamente flexible para responder rápidamente a las condiciones cambiantes del mercado.
Componentes de la división de nodos de Junos
La división de nodos de Junos le permite particionar un único enrutador de la serie MX para que aparezca como varios enrutadores independientes. Cada partición tiene su propio plano de control de Junos OS, que se ejecuta como una máquina virtual (VM), y un conjunto dedicado de tarjetas de línea. Cada partición se denomina función de red de invitados (GNF).
El enrutador de la serie MX funciona como el sistema base (BSYS). El BSYS posee todos los componentes físicos del enrutador, incluidas las tarjetas de línea y la estructura de conmutación. El BSYS asigna tarjetas de línea a los GNF.
El software Administrador de dispositivos (JDM) de Juniper organiza las máquinas virtuales GNF. En JDM, una máquina virtual GNF se conoce como una función de red virtual (VNF). Por lo tanto, un GNF comprende un VNF y un conjunto de tarjetas de línea.
Mediante la configuración en BSYS, puede asignar tarjetas de línea del chasis a diferentes GNF. Además, dependiendo del tipo de tarjeta de línea, incluso puede asignar conjuntos de PFE dentro de una tarjeta de línea a diferentes GNF. Consulte Descripción general de la tarjeta de sublínea para obtener más detalles.
La división de nodos de Junos admite dos modelos:
Modelo de servidor externo
Modelo integrado en el chasis
En el modelo de servidor externo, JDM y VNF se alojan en un par de servidores x86 estándar externos de la industria.
La Figura 1 muestra tres GNF con sus tarjetas de línea dedicadas ejecutándose en un servidor externo.
externo
Consulte Conexión de los servidores y el enrutador para obtener información sobre cómo conectar un enrutador de la serie MX a un par de servidores x86 externos.
En el modelo integrado en el chasis, todos los componentes (JDM, BSYS y GNF) se ejecutan en el motor de enrutamiento del enrutador de la serie MX. Consulte la figura 2.
- Sistema base (BSYS)
- Función de red de invitados (GNF)
- Administrador de dispositivos de Juniper (JDM)
Sistema base (BSYS)
En la división de nodos de Junos, el enrutador de la serie MX funciona como el sistema base (BSYS). El BSYS posee todos los componentes físicos del enrutador, incluidas todas las tarjetas de línea y la estructura. Mediante la configuración de Junos OS en BSYS, puede asignar tarjetas de línea a GNF y definir interfaces de estructura abstracta (af) entre GNF. El software BSYS se ejecuta en un par de motores de enrutamiento redundantes del enrutador de la serie MX.
Función de red de invitados (GNF)
Una función de red de invitados (GNF) posee lógicamente las tarjetas de línea que le asigna el sistema base (BSYS) y mantiene el estado de reenvío de las tarjetas de línea. Puede configurar varios GNF en un enrutador de la serie MX (consulte Configuración de funciones de red de invitados). El plano de control de Junos OS de cada GNF se ejecuta como una máquina virtual (VM). El software Administrador de dispositivos (JDM) de Juniper organiza las máquinas virtuales GNF. En el contexto de JDM, los GNF se denominan funciones de red virtual (VNF).
Un GNF es equivalente a un enrutador independiente. Los GNF se configuran y administran de forma independiente, y están operacionalmente aislados entre sí.
La creación de un GNF requiere dos conjuntos de configuraciones, una que se realizará en BSYS y la otra en JDM.
Un GNF se define mediante un ID. Este ID debe ser el mismo en BSYS y JDM.
La parte BSYS de la configuración GNF consiste en darle una identificación y un conjunto de tarjetas de línea.
La parte JDM de la configuración GNF comprende especificar los siguientes atributos:
Un nombre VNF.
UN GNF ID. Este ID debe ser el mismo que el ID GNF utilizado en el BSYS.
El tipo de plataforma de la serie MX (para el modelo de servidor externo).
Una imagen de Junos OS que se utilizará para el VNF.
La plantilla de recursos del servidor VNF.
La plantilla de recursos del servidor define el número de núcleos de CPU dedicados (físicos) y el tamaño de la DRAM que se asignará a un GNF. Para obtener una lista de las plantillas de recursos de servidor predefinidas disponibles para GNF, consulte la sección Requisitos de recursos de hardware de servidor (por GNF) en Requisitos mínimos de hardware y software para la división de nodos de Junos.
Después de configurar un GNF, puede acceder a él conectándose al puerto de consola virtual del GNF. Con la CLI de Junos OS en el GNF, puede configurar las propiedades del sistema GNF, como el nombre de host y la dirección IP de administración, y posteriormente acceder a él a través de su puerto de administración.
Administrador de dispositivos de Juniper (JDM)
Juniper Device Manager (JDM), un contenedor de Linux virtualizado, permite el aprovisionamiento y la administración de las máquinas virtuales GNF.
JDM admite CLI similar a Junos OS, NETCONF para configuración y administración y SNMP para monitoreo.
En el modelo en chasis, JDM no admite SNMP.
Una instancia de JDM se aloja en cada uno de los servidores x86 del modelo de servidor externo y en cada motor de enrutamiento para el modelo integrado en el chasis. Las instancias de JDM suelen configurarse como pares que sincronizan las configuraciones de GNF: cuando se crea una máquina virtual GNF en un servidor, su máquina virtual de respaldo se crea automáticamente en el otro servidor o motor de enrutamiento.
Es necesario configurar una dirección IP y una cuenta de administrador en el JDM. Una vez configurados, puede iniciar sesión directamente en JDM.
Ver también
Interfaz de estructura abstracta
La interfaz de estructura abstracta (af) es una pseudointerfaz que representa un comportamiento de interfaz Ethernet de primera clase. Una af interfaz facilita el enrutamiento, el control y la administración del tráfico entre las funciones de red de invitados (GNF) a través de la estructura del conmutador. Se crea una af interfaz en un GNF para comunicarse con su GNF par cuando los dos GNF están configurados para conectarse entre sí. Las interfaces de estructura abstractas deben crearse en BSYS. El ancho de banda de las af interfaces cambia dinámicamente en función de la inserción o accesibilidad de la tarjeta de línea/MPC remota. Dado que la estructura es el medio de comunicación entre los GNF, af las interfaces se consideran interfaces WAN equivalentes. Consulte la figura 3.
de estructura abstracta
- Descripción del ancho de banda de la interfaz de estructura abstracta
- Características admitidas en interfaces de estructura abstracta
- Restricciones de la interfaz de estructura abstracta
Descripción del ancho de banda de la interfaz de estructura abstracta
Una interfaz de estructura abstracta (af) conecta dos GNF a través de la estructura y agrega todos los motores de reenvío de paquetes (PFE) que conectan los dos GNF. Una af interfaz puede aprovechar la suma del ancho de banda de cada motor de reenvío de paquetes que pertenece a la af interfaz.
Por ejemplo, si GNF1 tiene un MPC8 (que tiene cuatro motores de reenvío de paquetes con capacidad de 240 Gbps cada uno) y GNF1 está conectado con GNF2 y GNF3 mediante af interfaces (af1 y af2), la capacidad máxima af de la interfaz en GNF1 sería 4x240 Gbps = 960 Gbps.
GNF1—af1——GNF2
GNF1—af2——GNF3
Aquí, af1 y af2 comparten la capacidad de 960 Gbps.
Para obtener información sobre el ancho de banda admitido en cada MPC, consulte la Tabla 1.
Características admitidas en interfaces de estructura abstracta
Las interfaces de estructura abstracta admiten las siguientes características:
Actualización unificada de software en servicio (ISSU)
Configuración del modo Hyper en el nivel BSYS (a partir de Junos OS versión 19.3R2). Esta función es compatible con las tarjetas de línea MPC6E, MPC8E, MPC9E y MPC11E.
Nota:No puede tener diferentes configuraciones de modo hiperactivo para GNF individuales, ya que heredan la configuración de BSYS.
Los enrutadores MX2020 y MX2010 con SFB3 aparecen en modo hiperactivo de forma predeterminada. Si necesita que el modo hiper esté deshabilitado en cualquier GNF, debe configurarlo en BSYS y se aplicará a todos los GNF de ese chasis.
Equilibrio de carga basado en las tarjetas de línea GNF remotas presentes
Soporte de clase de servicio (CoS):
Clasificador y reescritura de precedencia de Inet
Clasificador y reescritura DSCP
Clasificador y reescritura MPLS EXP
Clasificador y reescritura DSCP v6 para tráfico IP v6
Compatibilidad con los protocolos OSPF, IS-IS, BGP, OSPFv3 y L3VPN
Nota:Las no
afinterfaces admiten todos los protocolos que funcionan en Junos OS.-
BFD para BGP, IS-IS y OSPF a partir de Junos OS versión 24.2R1.
Reenvío de multidifusión
Cambio de motor de enrutamiento elegante (GRES)
Aplicaciones MPLS en las que la
afinterfaz actúa como interfaz principal (L3VPN, VPLS, L2VPN, L2CKT, EVPN e IP a través de MPLS)Se admiten las siguientes familias de protocolos:
Reenvío de IPv4
Reenvío de IPv6
MPLS
ISO
CCC
Soporte del sensor de la interfaz de telemetría de Junos (JTI)
A partir de Junos OS versión 19.1R1, las funciones de red para invitados (GNF) admiten VPN Ethernet (EVPN) con encapsulación del protocolo Virtual Extensible LAN (VXLAN). Esta compatibilidad está disponible con la interfaz que no es (
afes decir, física) yafla interfaz como interfaz orientada al núcleo. Este soporte no está disponible para la tarjeta de línea MPC11E.Con la configuración de la interfaz, los
afGNF admitenafMPC con capacidad -capaz. En la Tabla 1 se enumeran lasafMPC con capacidad -, el número de PFE admitidas por MPC y el ancho de banda admitido por MPC.Tabla 1: MPC compatibles con capacidad de estructura abstracta admitidas MPC
Versión inicial
Número de ZFP
Ancho de banda total
MPC7E-MRATE
17.4R1
2
480G (240*2)
MPC7E-10G
17.4R1
2
480G (240*2)
MX2K-MPC8E
17.4R1
4
960G (240*4)
MX2K-MPC9E
17.4R1
4
1.6T (400*4)
MPC2E
19.1R1
2
80 (40*2)
MPC2E NG
17.4R1
1
80G
MPC2E NG Q
17.4R1
1
80G
MPC3E
19.1R1
1
130G
MPC3E NG
17.4R1
1
130G
MPC3E NG Q
17.4R1
1
130G
32x10GE MPC4E
19.1R1
2
260G (130*2)
2x100GE + 8x10GE MPC4E
19.1R1
2
260G (130*2)
MPC5E-40G10G
18.3R1
2
240G (120*2)
MPC5EQ-40G10G
18.3R1
2
240G (120*2)
MPC5E-40G100G
18.3R1
2
240G (120*2)
MPC5EQ-40G100G
18.3R1
2
240G (120*2)
MX2K-MPC6E
18.3R1
4
520G (130*4)
MPC MULTISERVICIOS (MS-MPC)
19.1R1
1
120G
MPC 16x10GE
19.1R1
4
160G (40*4)
MX2K-MPC11E
19,3R2
8
4T (500G*8)
Se recomienda establecer la configuración de MTU en la af interfaz para alinearla con el valor máximo permitido en las interfaces XE/GE. Esto garantiza una fragmentación mínima o nula de los paquetes a través de la af interfaz.
Restricciones de la interfaz de estructura abstracta
A continuación se muestran las restricciones actuales de las interfaces de estructura abstracta:
Las configuraciones, como la interfaz de punto
afde conexión único,afla no coincidencia de asignación de interfaz a GNF o la asignación de variasafinterfaces al mismo GNF remoto no se comprueban durante la confirmación en el BSYS. Asegúrese de que tiene las configuraciones correctas.La asignación de ancho de banda es estática y se basa en el tipo de MPC.
Puede haber caídas mínimas de tráfico (tanto de tránsito como de host) durante el desconexión/reinicio de un MPC alojado en un GNF remoto.
No se admite la interoperabilidad entre las MPC que son
afcompatibles y las MPC que noaflo son.
Ver también
Optimización de la ruta de estructura para la interfaz de estructura abstracta
Puede optimizar el tráfico que fluye a través de las interfaces de estructura abstracta (af) entre dos funciones de red invitadas (GNF) configurando un modo de optimización de ruta de estructura. Esta característica reduce el consumo de ancho de banda de la estructura al impedir cualquier salto adicional de la estructura (conmutación de flujos de tráfico de un motor de reenvío de paquetes a otro) antes de que los paquetes lleguen finalmente al motor de reenvío de paquetes de destino. La optimización de rutas de estructura, compatible con MX2008, MX2010 y MX2020 con MPC9E y MX2K-MPC11E, evita que solo haya un salto de tráfico adicional como resultado del equilibrio de carga de la interfaz de estructura abstracta.
Puede configurar uno de los siguientes modos de optimización de rutas de estructura:
monitor: si configura este modo, el GNF del mismo nivel supervisa el flujo de tráfico y envía información al GNF de origen sobre el motor de reenvío de paquetes al que se reenvía el tráfico actualmente y el motor de reenvío de paquetes deseado que podría proporcionar una ruta de tráfico optimizada. En este modo, el GNF de origen no reenvía el tráfico hacia el motor de reenvío de paquetes deseado.optimize: si configura este modo, el GNF del mismo nivel supervisa el flujo de tráfico y envía información al GNF de origen sobre el motor de reenvío de paquetes al que se reenvía el tráfico actualmente y el motor de reenvío de paquetes deseado que podría proporcionar una ruta de tráfico optimizada. A continuación, el GNF de origen reenvía el tráfico hacia el motor de reenvío de paquetes deseado.
Para configurar un modo de optimización de ruta de estructura, utilice los siguientes comandos de CLI en BSYS.
user@router#set chassis network-slices guest-network-functions gnf id af-name collapsed-forward (monitor | optimize)user@router#commit
Después de configurar la optimización de rutas de estructura, puede usar el comando show interfaces af-interface-name de GNF para ver el número de paquetes que fluyen actualmente en la ruta óptima o no óptima.
Ver también
Elegir entre el modelo de servidor externo y el modelo integrado en el chasis
El modelo de servidor externo le permite configurar más instancias de GNF con mayor escala, ya que puede elegir un servidor de capacidad suficiente para satisfacer los requisitos de GNF. Con el modelo integrado en el chasis, el número de GNF que se pueden configurar depende de los requisitos de escala de los GNF constituyentes y de la capacidad total del motor de enrutamiento.
Los modelos de servidor externo y en chasis de la división de nodos de Junos son mutuamente excluyentes. Un enrutador de la serie MX se puede configurar para que funcione solo en uno de estos modelos a la vez.
Comportamiento del rol primario de BSYS y GNF
En las secciones siguientes se aborda el comportamiento de rol principal de BSYS y GNF en el contexto de la redundancia del motor de enrutamiento.
La figura 4 muestra el comportamiento de rol principal de GNF y BSYS con redundancia de motor de enrutamiento.
Función principal de BSYS
El comportamiento de arbitraje de rol principal del motor de enrutamiento BSYS es idéntico al de los motores de enrutamiento en los enrutadores de la serie MX.
Función principal de GNF
El comportamiento de arbitraje de rol principal de la máquina virtual GNF es similar al de los motores de enrutamiento de la serie MX. Cada GNF se ejecuta como un par de máquinas virtuales con copia de seguridad primaria. Una máquina virtual GNF que se ejecuta en server0 (o re0 para in-chasis) es equivalente a la ranura 0 del motor de enrutamiento de un enrutador de la serie MX, y la máquina virtual GNF que se ejecuta en server1 (o re1 para in-chasis) es equivalente a la ranura 1 del motor de enrutamiento de un enrutador serie MX.
La función principal del GNF es independiente de la función principal de BSYS y de la de otros GNF. El arbitraje de la función principal de GNF se realiza a través de Junos OS. En condiciones de falla de conectividad, el rol principal de GNF se maneja de manera conservadora.
El modelo de rol principal de GNF es el mismo para los modelos de servidor externo y en chasis.
Al igual que con los motores de enrutamiento de la serie MX, debe configurar un cambio correcto de motor de enrutamiento (GRES) en cada GNF. Este es un requisito previo para que la máquina virtual GNF de copia de seguridad asuma automáticamente el rol principal cuando la máquina virtual GNF principal falla o se reinicia.
Roles de administrador de división de nodos de Junos
Las siguientes funciones de administrador le permiten llevar a cabo las tareas de división de nodos:
Administrador de BSYS: responsable del chasis físico, así como del aprovisionamiento de GNF (asignación de tarjetas de línea a GNF). Los comandos de la CLI de Junos OS están disponibles para estas tareas.
Administrador de GNF: responsable de la configuración, el funcionamiento y la administración de Junos OS en el GNF. Todos los comandos normales de la CLI de Junos OS están disponibles para el administrador de GNF para estas tareas.
Administrador de JDM: responsable de la configuración del puerto del servidor JDM (para el modelo de servidor externo) y del aprovisionamiento y la gestión del ciclo de vida de las máquinas virtuales GNF (VNF). Los comandos de la CLI de JDM están disponibles para estas tareas.
Descripción general de la tarjeta de sublínea
En la división de nodos de Junos, cada GNF comprende un conjunto de tarjetas de línea (FPC). De forma predeterminada, la granularidad más fina proporcionada por un GNF se encuentra en el nivel de tarjeta de línea, porque a cada GNF se le asignan tarjetas de línea completas (es decir, el conjunto completo de motores de reenvío de paquetes en cada tarjeta de línea). Con la función de tarjeta de sublínea (SLC), puede definir una granularidad aún más fina del particionamiento asignando subconjuntos de motores de reenvío de paquetes en una sola tarjeta de línea a diferentes GNF.
Estos subconjuntos definidos por el usuario de motores de reenvío de paquetes en una tarjeta de línea se denominan tarjetas de sublínea (SLC). Operativamente, los SLC funcionan como tarjetas de línea independientes.
Cuando se corta una tarjeta de línea, cada SLC de esa tarjeta de línea debe asignarse a un GNF diferente.
Puede asignar SLC desde varias tarjetas de línea al mismo GNF.
En una configuración de división de nodos de Junos con la función SLC, un GNF puede comprender un conjunto de tarjetas de línea completas, así como un conjunto de divisiones (SLC) de tarjetas de línea, lo que proporciona un mayor nivel de flexibilidad.
Cuando se divide una tarjeta de línea, se ejecutan dos tipos de instancias de software en esa tarjeta de línea: una instancia de tarjeta de línea base única (BLC) y varias instancias de SLC (tantas como el número de secciones de esa tarjeta de línea). Actualmente, la capacidad SLC solo está disponible en el MPC11E, que admite dos SLC. La instancia BLC es responsable de administrar el hardware común a todos los SLC de esa tarjeta de línea, mientras que cada instancia SLC es responsable de administrar el conjunto de motores de reenvío de paquetes que se le asignan exclusivamente. La instancia de BLC ejecuta el software Junos de BSYS, mientras que cada instancia de SLC ejecuta el software de Junos de su GNF asociado.
Los SLC admiten la interfaz de estructura abstracta y el reenvío contraído (consulte Optimización de la ruta de estructura para la interfaz de estructura abstracta). Puede usar el show interface af-interface-name comando para ver las estadísticas de equilibrio de carga de los motores de reenvío de paquetes específicos de segmentos FPC remotos. Consulte mostrar interfaces (tejido abstracto) para obtener más información.
La capacidad SLC solo está disponible en el MPC11E (número de modelo: MX2K-MPC11E).
Recursos de tarjetas de línea para SLC
Un SLC o una división de una tarjeta de línea define el conjunto de motores de reenvío de paquetes (de esa tarjeta de línea) que deben funcionar juntos. Los motores de reenvío de paquetes en una tarjeta de línea se identifican mediante identificadores numéricos. Si una tarjeta de línea tiene 'n' motores de reenvío de paquetes, los motores de reenvío de paquetes individuales se numeran del 0 al (n-1). Además, los núcleos de CPU y la DRAM en la tarjeta de control de la tarjeta de línea también deben dividirse y asignarse a la división. Definir un SLC, entonces, es definir los siguientes recursos de tarjeta de línea que se dedicarán a ese SLC:
-
Una gama de motores de reenvío de paquetes
-
El número de núcleos de CPU en la tarjeta de control de la tarjeta de línea
-
El tamaño de la DRAM (en GB) en la tarjeta de control de la tarjeta de línea
Una cierta cantidad de DRAM se reserva automáticamente para la instancia BLC en esa tarjeta de línea, y el resto está disponible para instancias SLC.
Cada SLC se identifica mediante un ID numérico, asignado por el usuario.
Cuando se divide una tarjeta de línea, las particiones de recursos para cada segmento de esa tarjeta de línea deben estar completamente definidas.
Recursos de tarjetas de línea MPC11E para SLC
Una tarjeta de línea MPC11E tiene:
-
8 motores de reenvío de paquetes
-
8 núcleos de CPU en la tarjeta de control
-
32 GB de DRAM en la tarjeta de control
5 GB de DRAM se reservan automáticamente para el uso de BLC, 1 GB de DRAM se asigna al host de la tarjeta de línea y los 26 GB restantes están disponibles para segmentos SLC.
Un MPC11E es capaz de soportar dos SLC.
La Tabla 2 define dos tipos de perfiles de asignación de recursos soportados por un MPC11E para los dos SLC, denominados aquí SLC1 y SLC2.
En el perfil simétrico, los motores de reenvío de paquetes y otros recursos de tarjetas de línea se distribuyen uniformemente entre los segmentos. En el perfil asimétrico, solo se admiten las combinaciones de recursos de tarjeta de línea especificadas que se muestran en la tabla 2 .
Puede configurar los siguientes perfiles de SLC, en función de cómo se dividen los motores de reenvío de paquetes [0-7] entre los dos SLC:
-
Motores de reenvío de paquetes 0-3 para un SLC y 4-7 para el otro SLC (perfil simétrico)
-
Motores de reenvío de paquetes 0-1 para un SLC y 2-7 para el otro SLC (perfil asimétrico)
-
Motores de reenvío de paquetes 0-5 para un SLC y 6-7 para el otro SLC (perfil asimétrico)
En el perfil asimétrico, puede asignar 9 GB o 17 GB de DRAM a un SLC. Dado que todos los recursos de la tarjeta de línea deben asignarse completamente y la DRAM total disponible para SLC es de 26 GB, la asignación de 9 GB de DRAM a una SLC requiere que los 17 GB restantes se asignen al otro SLC.
| Perfil simétrico |
Perfil asimétrico |
|||
|---|---|---|---|---|
| Tipo de recurso |
SLC1 |
SLC2 |
SLC1 |
SLC2 |
| Motor de reenvío de paquetes |
4 |
4 |
2 |
6 |
| DRAM |
13 GB |
13 GB |
17 GB/9 GB |
9 GB/17 GB |
| CPU |
4 |
4 |
4 |
4 |
Consulte también: Configuración de tarjetas de sublínea y asignación de ellas a GNF y administración de tarjetas de sublínea.
Descripción general de la interoperabilidad del software multiversión
A partir de Junos OS versión 17.4R1, la división de nodos de Junos admite la compatibilidad de software multiversión, lo que permite que BSYS interopere con una función de red de invitados (GNF) que ejecuta una versión de Junos OS superior a la versión de software de BSYS. Esta característica admite un rango de hasta dos versiones entre GNF y BSYS. Es decir, el software GNF puede ser dos versiones más alto que el software BSYS. Tanto BSYS como GNF deben cumplir un requisito de versión mínima de Junos OS versión 17.4R1.
Las restricciones en la compatibilidad con varias versiones también se aplican al proceso de actualización de ISSU unificado.
Aunque el control de versiones del software JDM no tiene una restricción similar con respecto a las versiones de software GNF o BSYS, le recomendamos que actualice regularmente el software JDM. Una actualización de JDM no afecta a ninguno de los GNF en ejecución.
Servicios de próxima generación en la división de nodos de Junos
La división de nodos de Junos admite la tarjeta de servicios MX-SPC3, una tarjeta de servicios de seguridad que proporciona potencia de procesamiento adicional para ejecutar los servicios de próxima generación en las plataformas MX. Puede habilitar los servicios de próxima generación en la función de red de invitados (GNF) mediante la CLI request system enable unified-services en GNF. Para admitir un MX-SPC3, un GNF debe tener una tarjeta de línea asociada.
En una configuración de división de nodos de Junos, puede usar MX-SPC3 y MS-MPC en el mismo chasis pero en motores de enrutamiento GNF diferentes. Si ha habilitado los servicios de próxima generación en GNF, mediante request system enable unified-services, el MX-SPC3 se conecta. Si no ha habilitado los servicios de próxima generación, MS-MPC se conecta.
La instalación o actualización de software de una tarjeta MX-SPC3 ocurre cuando instala o actualiza el motor de enrutamiento GNF asociado.
El MX-SPC3 no admite interfaces de estructura abstracta. Por lo tanto, un GNF que tiene una tarjeta MX-SPC3 vinculada a él también debe tener una tarjeta de línea asociada.
Comparación de la división de nodos de Junos con los sistemas lógicos
La división de nodos de Junos es una capa por debajo de los sistemas lógicos de Junos. Ambas tecnologías tienen algunas capacidades superpuestas, pero difieren en otros aspectos. Con la división de nodos de Junos, las tarjetas de línea completas y, por lo tanto, las interfaces físicas, se asignan a un GNF, mientras que con los sistemas lógicos, una sola interfaz física se puede compartir entre diferentes sistemas lógicos, ya que varias interfaces lógicas definidas a través de una interfaz física pueden asignarse a sistemas lógicos separados. Esto significa que los sistemas lógicos permiten una granularidad de uso compartido más fina que la división de nodos de Junos. Pero todos los sistemas lógicos comparten un solo núcleo Junos, por lo que necesariamente se ejecuta la misma versión de Junos, además de tener que compartir el motor de enrutamiento y los recursos físicos de la tarjeta de línea, como la CPU, la memoria y el almacenamiento. Con la división de nodos de Junos, cada GNF obtiene su propio equivalente de un par de motores de enrutamiento, como también tarjetas de línea dedicadas a ese GNF, por lo que los GNF no comparten la mayoría de los recursos físicos, solo comparten el chasis y la estructura del conmutador. Los GNF, a diferencia de los sistemas lógicos, se pueden actualizar y administrar de forma independiente como un enrutador MX independiente.
La división de nodos de Junos es una tecnología que complementa, e incluso aumenta, los sistemas lógicos, ya que un GNF puede tener varios sistemas lógicos dentro de él. Cuando el aislamiento físico, los recursos garantizados y el aislamiento administrativo completo son primordiales, la división de nodos de Junos sería una mejor opción. Y donde la granularidad fina del intercambio, hasta el nivel de interfaz lógica, es primordial, un sistema lógico sería la mejor opción.
Licencias para la división de nodos de Junos
El funcionamiento de la división de nodos de Junos requiere licencias para instalar los GNF y las interfaces de estructura abstracta en BSYS. La ejecución de un GNF sin una licencia instalada en el BSYS dará como resultado el siguiente mensaje syslog y una alarma menor:
CHASSISD_LICENSE_EVENT: License Network-Slices: Failed to get valid license('216') 'gnf-creation'
Minor alarm set, 1 Guest network functions creation for JUNOS requires a license.
Comuníquese con Juniper Networks si tiene consultas relacionadas con las licencias de división de nodos de Junos.