EN ESTA PÁGINA
Optimización de la ruta de la estructura para la interfaz de la estructura abstraída
Elegir entre el modelo de servidor externo y el modelo en 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 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 grandes empresas crear una infraestructura de red que consolida múltiples funciones de enrutamiento en un solo dispositivo físico. Ayuda a alojar múltiples servicios en una única infraestructura física mientras evita la complejidad operativa involucrada. También mantiene la separación operacional, 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 conocen como 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, mientras mantiene el aislamiento operativo entre ellos. Puede aprovechar el mismo dispositivo físico para crear particiones paralelas que no comparten el plano de control ni el plano de reenvío, sino que solo comparten el chasis, el espacio y la alimentación.
También puede enviar tráfico entre GNF a través de la estructura de conmutación mediante el uso de una interfaz de estructura abstraída (af), una pseudointerfaz que se comporta como una interfaz Ethernet de primera clase. Una interfaz de estructura abstraída 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 en 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 propio enrutador de la serie MX.
La división de nodos de Junos admite la compatibilidad de software con varias versiones, lo que permite que los GNF se actualicen independientemente.
Beneficios 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 borde de video y borde de voz, en un único enrutador físico, mientras mantienen la separación operativa entre ellos. Puede lograr convergencia horizontal y vertical. La convergencia horizontal consolida las funciones del enrutador de la misma capa en un solo enrutador, mientras que la convergencia vertical colapsa las funciones del 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 la escalabilidad de la red, lo que permite a los proveedores de servicios y 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; es decir, se benefician de la separación operacional, 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 solo comparten el chasis, el espacio y la alimentación. Esto significa que, si se produce un error en una partición, ese error no afectará a ningún otro 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 abstraída (
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 operar en una versión de software de Junos diferente. Esta ventaja permite a las empresas evolucionar cada GNF a su propio ritmo. Si es necesario desplegar 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 las empresas introducir un modelo empresarial 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 GNF.
El software Juniper Device Manager (JDM) orquesta 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 una VNF y un conjunto de tarjetas de línea.
A través de la configuración en el 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 en chasis
En el modelo de servidor externo, JDM y VNF se alojan en un par de servidores x86 externos estándar 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 acerca de cómo conectar un enrutador de la serie MX a un par de servidores x86 externos.
En el modelo en chasis, todos los componentes (JDM, BSYS y GNF) se ejecutan dentro del motor de enrutamiento del enrutador de la serie MX. Vea la Figura 2.
chasis
- 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. A través de la configuración de Junos OS en el BSYS, puede asignar tarjetas de línea a GNF y definir interfaces de estructura abstraída (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 asignó 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 para invitados). El plano de control de Junos OS de cada GNF se ejecuta como una máquina virtual (VM). El software Juniper Device Manager (JDM) orquesta las máquinas virtuales GNF. En el contexto de JDM, las 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 operativamente aislados entre sí.
La creación de un GNF requiere dos conjuntos de configuraciones, una que se realizará en el BSYS y la otra en el JDM.
Un GNF se define por un ID. Este ID debe ser el mismo en BSYS y JDM.
La parte BSYS de la configuración GNF comprende darle una identificación y un conjunto de tarjetas de línea.
La parte JDM de la configuración de GNF comprende la especificación de los siguientes atributos:
-
Un nombre VNF.
-
UN ID DE GNF. Este ID debe ser el mismo que el ID de 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 la VNF.
-
La plantilla de recursos del servidor VNF.
La plantilla de recursos de servidor define el número de núcleos de CPU dedicados (físicos) y el tamaño de DRAM que se asignará a un GNF. Para obtener una lista de plantillas de recursos de servidor predefinidas disponibles para GNF, consulte la sección Requisitos de recursos de hardware del servidor (por GNF) en Requisitos mínimos de hardware y software para la división de nodos de Junos.
Una vez configurado un GNF, puede acceder a él conectándose al puerto de la 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)
El Administrador de dispositivos de Juniper (JDM), un contenedor 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 en chasis. Las instancias de JDM se configuran normalmente 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.
Se debe 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 abstraída
La interfaz de estructura abstraída (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 invitadas (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 abstraída se deben crear 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 remota/MPC. Dado que la estructura es el medio de comunicación entre GNF, af las interfaces se consideran interfaces WAN equivalentes. Vea la Figura 3.
de estructura abstraída
- Descripción del ancho de banda de interfaz de estructura abstracta
- Funciones admitidas en interfaces de estructura abstraída
- Restricciones de interfaz de estructura abstraída
Descripción del ancho de banda de interfaz de estructura abstracta
Una interfaz de estructura abstraída (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 interfaz en GNF1 sería 4 x 240 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.
Funciones admitidas en interfaces de estructura abstraída
Las interfaces de estructura abstraída admiten las siguientes funciones:
-
Actualización de software en servicio (ISSU)
-
Configuración del modo Hyper a nivel de BSYS (a partir de la versión 19.3R2 de Junos OS). Esta función es compatible con las tarjetas de línea MPC6E, MPC8E, MPC9E y MPC11E.
Nota:-
No puede tener diferentes configuraciones de hipermodo para GNF individuales, ya que heredan la configuración del 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 el 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 de DSCP
-
Clasificador y reescritura de EXP de MPLS
-
Clasificador y reescritura DSCP v6 para tráfico IP v6
-
-
Compatibilidad con protocolos OSPF, SI-SI, BGP, OSPFv3 y L3VPN
Nota:Las no
afinterfaces admiten todos los protocolos que funcionan en Junos OS. -
BFD para BGP, SI-SI y OSPF a partir de la versión 24.2R1 de Junos OS.
-
Reenvío de multidifusión
-
Conmutación del motor de enrutamiento elegante (GRES)
-
Aplicaciones MPLS en las que la
afinterfaz actúa como interfaz principal (L3VPN, VPLS, L2VPN, L2CKT, EVPN e IP sobre MPLS) -
Se admiten las siguientes familias de protocolos:
-
Reenvío IPv4
-
Reenvío de IPv6
-
MPLS
-
ISO
-
CCC
-
-
Soporte del sensor de la interfaz de telemetría de Junos (JTI)
-
A partir de la versión 19.1R1 de Junos OS, las funciones de red de invitados (GNF) admiten VPN Ethernet (EVPN) con encapsulación del protocolo LAN virtual extensible (VXLAN). Esta compatibilidad está disponible con interfaces no (
afes decir, físicas) eafinterfaces como interfaz frontal principal. Esta compatibilidad no está disponible para la tarjeta de línea MPC11E. -
Con la configuración de interfaz
af, los GNF admitenafMPC compatibles. En la tabla 1 se enumeran lasafMPC compatibles, la cantidad de PFE admitidas por MPC y el ancho de banda admitido por MPC.Tabla 1: MPC abstraídos compatibles con capacidad de estructura abstracta MPC
Lanzamiento inicial
Número de PFE
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,6 D (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
260 G (130 * 2)
2x100GE + 8x10GE MPC4E
19.1R1
2
260 G (130 * 2)
MPC5E-40G10G
18.3R1
2
240 G (120 * 2)
MPC5EQ-40G10G
18.3R1
2
240 G (120 * 2)
MPC5E-40G100G
18.3R1
2
240 G (120 * 2)
MPC5EQ-40G100G
18.3R1
2
240 G (120 * 2)
MX2K-MPC6E
18.3R1
4
520G (130*4)
MPC multiservicios (MS-MPC)
19.1R1
1
120G
MPC de 16x10GE
19.1R1
4
160G (40*4)
MX2K-MPC11E
19.3R2
8
4T (500 G*8)
Le recomendamos que establezca la configuración de UMT 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 interfaz de estructura abstraída
A continuación, se muestran las restricciones actuales de las interfaces de estructura abstraída:
-
Las configuraciones, como la interfaz de un solo punto de conexión,
afla falta de coincidencia del mapeo deafinterfaz 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 tener las configuraciones correctas. -
La asignación del ancho de banda es estática, según el tipo de MPC.
-
Puede haber caídas mínimas de tráfico (tanto de tránsito como de host) durante el reinicio o fuera de línea de una MPC alojada en una GNF remota.
-
No se admite la interoperabilidad entre las MPC que son
afcompatibles y las MPC que noafson compatibles.
Ver también
Optimización de la ruta de la estructura para la interfaz de la estructura abstraída
Puede optimizar el tráfico que fluye a través de las interfaces de estructura abstraída (af) entre dos funciones de red invitadas (GNF) configurando un modo de optimización de ruta de estructura. Esta función reduce el consumo de ancho de banda de la estructura al evitar cualquier salto de estructura adicional (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, solo evita un único salto de tráfico adicional que resulte del equilibrio de carga de la interfaz de estructura abstraída.
Puede configurar uno de los siguientes modos de optimización de rutas de estructura:
monitor: si configura este modo, el GNF par 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 par 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 rutas de estructura, utilice los siguientes comandos de la 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 la ruta de la estructura, puede usar el comando show interfaces af-interface-name en GNF para ver la cantidad de paquetes que fluyen actualmente en la ruta óptima / no óptima.
Ver también
Elegir entre el modelo de servidor externo y el modelo en 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 cumplir con los requisitos de GNF. Con el modelo en chasis, la cantidad de GNF que se pueden configurar es una función de los requisitos de escala de los GNF constituyentes y la capacidad general 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 funcionar solo en uno de estos modelos a la vez.
Comportamiento de rol principal de BSYS y GNF
En las siguientes secciones 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 del 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 enrutadores de la serie MX.
Rol principal de GNF
El comportamiento de arbitraje de rol principal de GNF VM es similar al de los motores de enrutamiento de la serie MX. Cada GNF se ejecuta como un par de máquinas virtuales de respaldo principal. Una máquina virtual GNF que se ejecuta en server0 (o re0 para el 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 el chasis) es equivalente a la ranura 1 del motor de enrutamiento de un enrutador de la serie MX.
El rol principal de GNF es independiente del rol principal de BSYS y del de otros GNF. El arbitraje de la función principal de GNF se realiza a través de Junos OS. En condiciones de fallo de conectividad, el rol principal de GNF se maneja de forma 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 una conmutación correcta del motor de enrutamiento (GRES) en cada GNF. Este es un requisito previo para que la máquina virtual GNF de respaldo asuma automáticamente el rol principal cuando se produce un error o se reinicia la máquina virtual GNF principal.
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, operación y administración de Junos OS en el GNF. Todos los comandos regulares 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, ya que 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 de partición, 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, las SLC funcionan como tarjetas de línea independientes.
Cuando 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 sola instancia de tarjeta de línea base (BLC) y varias instancias de SLC (tantas como el número de divisiones de esa tarjeta de línea). Actualmente, la capacidad de SLC solo está disponible en el MPC11E, que admite dos SLC. La instancia de BLC es responsable de administrar el hardware común a todos los SLC de esa tarjeta de línea, mientras que cada instancia de SLC es responsable de administrar el conjunto de motores de reenvío de paquetes que se le asignaron exclusivamente. La instancia de BLC ejecuta el software de Junos del BSYS, mientras que cada instancia de SLC ejecuta el software de Junos de su GNF asociado.
Los SLC admiten la interfaz de estructura abstraída y el reenvío colapsado (consulte Optimización de la ruta de la estructura para la interfaz de estructura abstraída). Puede utilizar 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 de FPC remotos. Consulte show interfaces (estructura abstraída) para obtener más detalles.
La capacidad SLC solo está disponible en el MPC11E (número de modelo: MX2K-MPC11E).
Recursos de tarjeta de línea para SLC
Un SLC o una porció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 ID 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 DRAM en el tablero de control de la tarjeta de línea también deben dividirse y asignarse a la segmentación. Entonces, definir un SLC es definir los siguientes recursos de tarjeta de línea que se dedicarán a ese SLC:
-
Un rango de motor de reenvío de paquetes
-
Número de núcleos de CPU en la tarjeta de control de la tarjeta de línea
-
El tamaño de 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 división de esa tarjeta de línea deben estar completamente definidas.
Recursos de la tarjeta 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 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 de SLC.
Un MPC11E es capaz de admitir dos SLC.
En la tabla 2 se definen dos tipos de perfiles de asignación de recursos admitidos por una MPC11E para las dos SLC, a los que se hace referencia aquí como SLC1 y SLC2.
En el perfil simétrico, los motores de reenvío de paquetes y otros recursos de tarjeta 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 dividan 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 por completo y que el DRAM total disponible para los SLC es de 26 GB, la asignación de 9 GB de DRAM a un 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 GNF y administración de tarjetas de sublínea.
Descripción general de la interoperabilidad del software multiversión
A partir de la versión 17.4R1 de Junos OS, la división de nodos de Junos admite la compatibilidad de software de varias versiones, 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 del BSYS. Esta característica admite un rango de hasta dos versiones entre GNF y BSYS. Es decir, el software GNF puede ser dos versiones superior al software BSYS. Tanto BSYS como GNF deben cumplir con 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 periódicamente 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 diferentes motores de enrutamiento GNF. 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 habilitó los servicios de próxima generación, MS-MPC se conecta.
La instalación o actualización de software de una tarjeta MX-SPC3 se produce cuando se instala o actualiza el motor de enrutamiento GNF asociado.
MX-SPC3 no admite interfaces de estructura abstraídas. Por lo tanto, un GNF que tiene una tarjeta MX-SPC3 vinculada también debe tener una tarjeta de línea asociada.
Comparación de la división de nodos de Junos con sistemas lógicos
La división de nodos de Junos es una capa por debajo de los sistemas lógicos en 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 en una interfaz física se pueden asignar a sistemas lógicos independientes. Esto significa que los sistemas lógicos permiten un uso compartido más detallado que la División de nodos de Junos. Pero todos los sistemas lógicos comparten un único kernel de Junos, por lo que necesariamente ejecutan 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, así como 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. A diferencia de los sistemas lógicos, los GNF 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 múltiples 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 combinación. Y cuando la granularidad fina del intercambio, hasta el nivel de la interfaz lógica, es primordial, un sistema lógico sería la mejor combinación.
Licencias para la división de nodos de Junos
La operación de la división de nodos de Junos requiere licencias para que los GNF y las interfaces de estructura abstraída se instalen en el 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 la División de nodos de Junos.