EN ESTA PÁGINA
Instalación del paquete JDM RPM en servidores x86 que ejecutan RHEL (modelo de servidor externo)
Configuración de JDM en servidores x86 (modelo de servidor externo)
Configuración de usuarios no root en JDM (división de nodos de Junos)
Configuración de interfaces JDM (modelo de servidor externo)
Configuración del enrutador de la serie MX para que funcione en modo integrado en el chasis
Instalación y configuración de JDM para el modelo integrado en el chasis
Configuración de interfaces de estructura abstracta entre un par de GNF
Optimización de la ruta de estructura para la interfaz de estructura abstracta
Compatibilidad con capturas SNMP: Configuración del servidor NMS (modelo de servidor externo)
Configuración de la división de nodos de Junos
Antes de continuar con las tareas de instalación de división de nodos de Junos, si utiliza el modelo de servidor externo, debe haber completado los procedimientos descritos en el capítulo Preparación de la instalación de división de nodos de Junos.
Configuración de un enrutador de la serie MX para que funcione en modo BSYS (modelo de servidor externo)
Asegúrese de que el enrutador de la serie MX esté conectado a los servidores x86, como se describe en Conexión de los servidores y el enrutador.
La división de nodos de Junos requiere que el enrutador de la serie MX funcione como sistema base (BSYS).
Siga estos pasos para configurar un enrutador de la serie MX para que funcione en modo BSYS:
No se espera que un enrutador en modo BSYS ejecute características distintas de las necesarias para ejecutar las funcionalidades básicas de administración en la división de nodos de Junos. Por ejemplo, no se espera que BSYS tenga configuraciones de interfaz asociadas con las tarjetas de línea instaladas en el sistema. En su lugar, las funciones de red de invitados (GNF) tendrán las configuraciones de enrutador completas.
Instalación del paquete JDM RPM en servidores x86 que ejecutan RHEL (modelo de servidor externo)
Antes de instalar el paquete JDM RPM para servidores x86, asegúrese de haber instalado los paquetes adicionales, tal y como se describe en Instalación de paquetes adicionales para JDM.
Descargue e instale el paquete JDM RPM para servidores x86 que ejecutan RHEL de la siguiente manera:
Para instalar el paquete en servidores x86 que ejecutan RHEL, realice los pasos siguientes en cada uno de los servidores:
Repita los pasos para el segundo servidor.
Instalación de JDM Ubuntu Package en servidores x86 que ejecutan Ubuntu 20.04 (modelo de servidor externo)
Antes de instalar el paquete JDM Ubuntu para servidores x86, asegúrese de haber instalado los paquetes adicionales. Para obtener más información, consulte Instalación de paquetes adicionales para JDM.
Descargue e instale el paquete JDM Ubuntu para servidores x86 que ejecutan Ubuntu 20.04 de la siguiente manera:
Para instalar el paquete JDM en los servidores x86 que ejecutan Ubuntu 20.04, realice los pasos siguientes en cada uno de los servidores:
Repita los pasos para el segundo servidor.
Configuración de JDM en servidores x86 (modelo de servidor externo)
Siga estos pasos para configurar JDM en cada uno de los servidores x86.
Configuración de usuarios no root en JDM (división de nodos de Junos)
En el modelo de servidor externo, puede crear usuarios no root en Juniper Device Manager (JDM) para la división de nodos de Junos, a partir de Junos OS versión 18.3R1. Necesita una cuenta raíz para crear un usuario no raíz. Los usuarios no root pueden iniciar sesión en JDM mediante la consola de JDM o mediante SSH. A cada usuario no root se le proporciona un nombre de usuario y se le asigna una clase de inicio de sesión predefinida.
Los usuarios no root pueden realizar las siguientes funciones:
Interactúe con JDM.
Organice y gestione las funciones de red de invitados (GNF).
Supervise el estado de JDM, el servidor host y los GNF mediante comandos de la CLI de JDM.
Las cuentas de usuario no raíz solo funcionan dentro de JDM, no en el servidor host.
Para crear usuarios no root en JDM:
La Tabla 1 contiene las clases de inicio de sesión predefinidas que JDM admite para usuarios no root:
Login Class |
Permisos |
|---|---|
superusuario |
|
operador |
|
de solo lectura |
Similar a la clase de operador, excepto que los usuarios no pueden reiniciar demonios dentro de JDM. |
Desautorizado |
Operaciones de ping y traceroute. |
Configuración de interfaces JDM (modelo de servidor externo)
Si desea modificar las interfaces de servidor configuradas en JDM, realice los pasos siguientes:
En el JDM, debe configurar:
Los dos puertos de servidor de 10 Gbps que están conectados al enrutador de la serie MX.
El puerto del servidor que se utilizará como puerto de administración de JDM.
El puerto del servidor que se utilizará como puerto de administración de GNF.
Por lo tanto, debe identificar lo siguiente en cada servidor antes de iniciar la configuración de los puertos:
Las interfaces de servidor (por ejemplo,
p3p1yp3p2) que están conectadas alCB1CB0enrutador de la serie MX.Las interfaces de servidor (por ejemplo,
em2yem3) que se utilizarán para la gestión de JDM y la gestión de GNF.
Para obtener más información, consulte la figura Conexión de los servidores y el enrutador.
Necesita esta información tanto para como
server0server1para .Estas interfaces solo son visibles en el host Linux.
Para configurar las interfaces de servidor x86 en JDM, realice los pasos siguientes en ambos servidores:
Para obtener ejemplos de configuraciones de JDM, consulte Configuración de ejemplo para la división de nodos de Junos.
Si desea modificar las interfaces de servidor configuradas en JDM, debe eliminar los GNF (si se configuraron), configurar las interfaces como se describió anteriormente, reiniciar JDM desde el shell, reconfigurar y activar los GNF y confirmar los cambios,
A partir de Junos OS versión 19.2R1, la división de nodos de Junos admite la asignación de un rango de direcciones MAC único globalmente (suministrado por Juniper Networks) para GNF. .
Configuración del enrutador de la serie MX para que funcione en modo integrado en el chasis
Para configurar la división de nodos Junos en el chasis, el enrutador de la serie MX debe tener instalado uno de los siguientes tipos de motores de enrutamiento:
-
RE-S-X6-128G (usado en enrutadores MX480 y MX960)
-
REMX2K-X8-128G (usado en enrutadores MX2010 y MX2020)
-
REMX2008-X8-128G (usado en enrutadores MX2008)
-
En el modelo de chasis, el sistema base (BSYS), el Administrador de dispositivos de Juniper (JDM) y todas las funciones de red de invitados (GNF) se ejecutan en el motor de enrutamiento del enrutador de la serie MX. BSYS y GNF se ejecutan en el host como máquinas virtuales (VM). Primero, debe reducir la huella de recursos del enrutador independiente de la serie MX de la siguiente manera:
Todos los archivos de la ubicación /var/ , incluidos los archivos de registro (/var/log) y los archivos principales (/var/crash), se eliminan al reiniciar el host de máquina virtual después de configurar la set vmhost resize vjunos compact instrucción. Debe guardar todos los archivos actualmente en /var/log o /var/crash antes de continuar con la configuración de cambio de tamaño del host de máquina virtual si desea usarlos como referencia.
Instalación y configuración de JDM para el modelo integrado en el chasis
Los pasos enumerados en este tema solo se aplican a la configuración de división de nodos Junos en chasis.
- Instalación del paquete JDM RPM en un enrutador de la serie MX (modelo integrado en el chasis)
- Configuración de JDM (modelo en chasis)
Instalación del paquete JDM RPM en un enrutador de la serie MX (modelo integrado en el chasis)
Antes de instalar el paquete RPM de Juniper Device Manager (JDM) en un enrutador serie MX, debe configurar el enrutador serie MX para que funcione en el modo BSYS en chasis. Para obtener más información, consulte Configuración del enrutador de la serie MX para que funcione en modo in-chassis.
El paquete jns-jdm-vmhost RPM está diseñado para la implementación de división de nodos Junos dentro del chasis, mientras que el paquete jns-jdm RPM se usa para la implementación de división de nodos Junos basada en servidores externos.
Configuración de JDM (modelo en chasis)
Siga estos pasos para configurar JDM en los dos motores de enrutamiento de un enrutador de la serie MX:
En la división de nodos Junos en chasis, no puede hacer ping ni enviar tráfico entre las interfaces de administración del mismo motor de enrutamiento (por ejemplo, desde el motor de enrutamiento 0 de GNF1 al motor de enrutamiento 0 de GNF2 o del motor de enrutamiento 0 de GNF1 a JDM).
En el modo de chasis, no se puede realizar una
scpoperación entre las interfaces de administración BSYS y JDM.Debe haber realizado el intercambio de claves ssh como se describe en el paso 7 antes de intentar el paso 8. Si intenta el paso 8 sin completar el paso 7, el sistema muestra un mensaje de error como se muestra en el ejemplo siguiente:
Failed to fetch JDM software version from server1. If authentication of peer server is not done yet, try running request server authenticate-peer-server.
A partir de Junos OS versión 19.2R1, la división de nodos de Junos admite la asignación de un rango de direcciones MAC único globalmente (suministrado por Juniper Networks) para GNF. .
Asignación de direcciones MAC a GNF
A partir de Junos OS versión 19.2R1, la división de nodos de Junos admite la asignación de un rango de direcciones MAC único globalmente (suministrado por Juniper Networks) para GNF.
Para recibir el rango de direcciones MAC único a nivel mundial para los GNF, comuníquese con su representante de Juniper Networks y proporcione su SSRN (Número de referencia de soporte de software) de licencia GNF, que le habrá sido enviado electrónicamente al comprar la licencia GNF. Para localizar el SSRN en su licencia GNF, consulte el artículo KB11364 de la Base de conocimientos de Juniper Networks.
Para cada licencia GNF, se le proporcionará un "SSRN aumentado", que incluye el rango de direcciones MAC único globalmente asignado por Juniper Networks para esa licencia GNF. A continuación, debe configurar este SSRN aumentado en la CLI de JDM de la siguiente manera:
root@jdm#set system vnf-license-supplement vnf-id gnf-id license-supplement-string augmented-ssrn-stringroot@jdm#commit
Se debe usar un SSRN aumentado para un solo ID GNF. En JDM, las máquinas virtuales GNF se denominan funciones de red virtual (VNF). GNF ID es uno de sus atributos. Los atributos de una VNF se describen en detalle en la siguiente sección Configuración de funciones de red de invitados.
De forma predeterminada, se validará el SSRN aumentado. Si alguna vez necesita omitir esta validación, puede usar el atributo no-validate en la CLI de la siguiente manera: Ejemplo:
set system vnf-license-supplement vnf-id gnf-id license-supplement-string augmented-ssrn-string [no-validate].
Puede configurar el SSRN aumentado para un ID de GNF solo cuando el GNF no esté operativo y aún no se haya aprovisionado también. Primero debe configurar el SSRN aumentado para un ID de GNF antes de configurar el GNF. Si el ID de GNF ya está aprovisionado, primero debe eliminar el GNF para ese ID de GNF en ambos servidores (en el caso del modelo de servidor externo) o en ambos motores de enrutamiento (en el caso del modelo de división de nodos Junos en chasis) antes de configurar el SSRN aumentado.
Del mismo modo, primero debe eliminar el GNF para un ID de GNF determinado en ambos servidores (en el caso del modelo de servidor externo) o en ambos motores de enrutamiento (en el caso del modelo de división de nodos Junos en chasis) antes de eliminar el SSRN aumentado para el ID de GNF.
No puede aplicar un SSRN aumentado a un GNF basado en Junos OS 19.1R1 o anterior.
Para confirmar que se ha aplicado el intervalo de direcciones MAC asignado para un GNF, cuando el GNF entre en funcionamiento, utilice el comando
show chassis mac-addressesJunos CLI: el resultado coincidirá con una subcadena del SSRN aumentado.
Configuración de funciones de red de invitados
La configuración de una función de red de invitados (GNF) consta de dos tareas, una que se realizará en el BSYS y la otra en el JDM.
- Antes de intentar crear un GNF, debe asegurarse de haber configurado la sincronización de confirmación como parte de la configuración de JDM para que los prefijos MAC aleatorios generados por las instancias de JDM estén sincronizados. Para comprobar si los prefijos MAC aleatorios están sincronizados, utilice el comando
show server connectionsCLI oshow system random-mac-prefixen JDM. Si los prefijos MAC aleatorios no están sincronizados, el software activa la siguiente alarma importante:Mismatched MAC address pool between GNF RE0 and GNF RE1. Para ver la alarma, utilice el comando mostrar alarmas del sistema. -
Antes de intentar crear un GNF, debe asegurarse de que los servidores (o motores de enrutamiento en el caso del modelo integrado en chasis) tengan recursos suficientes (CPU, memoria, almacenamiento) para ese GNF.
-
Debe asignar un ID a cada GNF. Este ID debe ser el mismo en BSYS y JDM.
En el BSYS, especifique un GNF asignándole un ID y un conjunto de tarjetas de línea aplicando la configuración que se muestra en el ejemplo siguiente:
user@router# set chassis network-slices guest-network-functions gnf 1 fpcs 4
user@router# commit
En JDM, las máquinas virtuales GNF se denominan funciones de red virtual (VNF). Un VNF tiene 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.
-
Una imagen de Junos OS que se utilizará para el GNF, que se puede descargar desde la página de descargas de Juniper.
En la página Descargas , seleccione Todos los productos > Junos Node Slicing - Guest Network Function para descargar una imagen de Junos para el GNF.
La plantilla de recursos del servidor VNF.
En el JDM, para configurar una VNF, realice los pasos siguientes:
Utilice el comando
scpde shell de JDM para recuperar la imagen de división de nodos de Junos OS para GNF y colóquela en el directorio local de JDM /var/jdm-usr/gnf-images (repita este paso para recuperar el archivo de configuración de GNF).root@jdm:~#
scp source-location-of-the-gnf-image /var/jdm-usr/gnf-imagesroot@jdm:~#scp source-location-of-the-gnf-configuration-file /var/jdm-usr/gnf-configAsigne esta imagen a un GNF mediante el comando JDM CLI, como se muestra en el ejemplo siguiente:
root@test-jdm-server0>
request virtual-network-functions test-gnf add-image /var/jdm-usr/gnf-images/junos-install-ns-mx-x86-64-17.4R1.10.tgz all-serversServer0: Added image: /vm-primary/test-gnf/test-gnf.img Server1: Added image: /vm-primary/test-gnf/test-gnf.img-
Configure la VNF aplicando las instrucciones de configuración como se muestra en el ejemplo siguiente:
root@test-jdm-server0#
set virtual-network-functionstest-gnfid1root@test-jdm-server0#
set virtual-network-functionstest-gnfchassis-type mx2020root@test-jdm-server0#
set virtual-network-functionstest-gnfresource-template2core-16groot@test-jdm-server0#
set system vnf-license-supplement vnf-id 1 license-supplement-string RTU00023003204-01-AABBCCDDEE00-1100-01-411CPara el modelo integrado en el chasis, no configure el tipo de plataforma (
set virtual-network-functionstest-gnfchassis-type mx2020). Se detectará automáticamente.A partir de Junos OS versión 19.2R1, la división de nodos de Junos admite la asignación de un rango de direcciones MAC único globalmente (suministrado por Juniper Networks) para GNF.
Para especificar también una configuración inicial o de línea base de Junos OS para un GNF, prepare el archivo de configuración de GNF (por ejemplo: /var/jdm-usr/gnf-config/test-gnf.conf) en los servidores (servidor0 y servidor1) para el modelo de servidor externo y en los motores de enrutamiento (re0 y re1) para el modelo en chasis, y especifique el nombre de archivo como parámetro en la
base-configinstrucción como se muestra a continuación:root@test-jdm-server0#
set virtual-network-functions test-gnf base-config /var/jdm-usr/gnf-config/test-gnf.confroot@test-jdm-server0#
commit synchronizeNota:Asegúrese de que:
-
Utilice el mismo ID de GNF que el especificado anteriormente en BSYS.
-
El nombre del archivo de configuración de línea base (con la ruta) es el mismo en ambos servidores / motores de enrutamiento.
-
La sintaxis del contenido del archivo de línea base está en el formato de configuración de Junos OS.
-
El nombre GNF utilizado aquí es el mismo que el asignado a la imagen de Junos OS para GNF en el paso 2.
-
Para comprobar que se ha creado la VNF, ejecute el siguiente comando de la CLI de JDM:
root@test-jdm-server0>
show virtual-network-functions test-gnfInicie sesión en la consola de VNF emitiendo el siguiente comando de la CLI de JDM:
root@test-jdm-server0>
request virtual-network-functions test-gnf consoleNota:Recuerde cerrar sesión en la consola de VNF después de haber completado las tareas de configuración. Se recomienda establecer un tiempo de espera de inactividad mediante el comando
set system login idle-timeout minutes. De lo contrario, si un usuario olvida cerrar sesión en la sesión de la consola de VNF, otro usuario puede iniciar sesión sin proporcionar las credenciales de acceso. Para obtener más información, consulte Inicio de sesión del sistema (división de nodos de Junos).Configure la VNF de la misma manera que configura un motor de enrutamiento de la serie MX.
El indicador de CLI para el modelo en el chasis es
root@jdm#.Para obtener ejemplos de configuraciones, consulte Configuración de ejemplo para la división de nodos de Junos.
En el caso del modelo de servidor externo, si previamente había desactivado cualquier interfaz CB x86 física o la interfaz de administración GNF desde el shell de Linux (mediante el comando
ifconfig interface-name down), estos se mostrarán automáticamente cuando se inicie GNF.
Configuración de interfaces de estructura abstracta entre un par de GNF
La creación de una interfaz de estructura abstracta (af) entre dos funciones de red de invitados (GNF) implica configuraciones tanto en el sistema base (BSYS) como en el GNF. Las interfaces de estructura abstractas se crean en GNF basadas en la configuración BSYS, que luego se envía a esos GNF.
-
Solo se puede configurar una
afinterfaz entre un par de GNF. - En una configuración de división de nodos de Junos, donde cada GNF se asigna con una sola FPC, si los motores de reenvío de paquetes de la FPC asignada al GNF remoto se vuelven inaccesibles a través de la estructura, la interfaz de estructura abstracta asociada deja de funcionar. Algunos ejemplos de errores que podrían provocar este comportamiento son los errores de accesibilidad de la estructura pfe y los eventos cmerror que provocan
pfe disableuna acción (use elshow chassis fpc errorscomando para obtener más información). Si un GNF tiene varias FPC asignadas, las FPC locales que notifican que todos los motores de reenvío de paquetes del mismo nivel están inactivos se eliminan de la determinación del estado de la interfaz de estructura abstracta.
Para configurar af interfaces entre un par de GNF:
-
En BSYS, aplique la configuración como se muestra en el ejemplo siguiente:
user@router#
set chassis network-slices guest-network-functions gnf 2 af4 peer-gnf id 4user@router#set chassis network-slices guest-network-functions gnf 2 af4 peer-gnf af2user@router#set chassis network-slices guest-network-functions gnf 4 af2 peer-gnf id 2user@router#set chassis network-slices guest-network-functions gnf 4 af2 peer-gnf af4En este ejemplo,
af2es la instancia 2 de la interfaz de estructura abstracta yaf4es la instancia 4 de la interfaz de estructura abstracta.Nota:Los valores de interfaz permitidos
afvan desdeaf0.af9La interfaz GNF
afserá visible y estará activa. Puede configurar unaafinterfaz de la misma manera que configura cualquier otra interfaz. En el GNF, aplique la configuración como se muestra en el ejemplo siguiente:
user@router-gnf-b#
set interfaces af4 unit 0 family inet address 10.10.10.1/24user@router-gnf-d#set interfaces af2 unit 0 family inet address 10.10.10.2/24
Si desea aplicar configuraciones de familia MPLS en las
afinterfaces, puede aplicar el comandoset interfaces af-name unit logical-unit-number family mplsen los GNF entre los que está configurada laafinterfaz.Para obtener ejemplos
afde configuraciones, consulte Configuración de ejemplo para la división de nodos de Junos.
Clase de servicio en interfaces de estructura abstracta
La clasificación de paquetes de clase de servicio (CoS) asigna un paquete entrante a una cola de salida basada en la clase de reenvío del paquete. Consulte la Guía de configuración de CoS para obtener más detalles.
En las secciones siguientes se explica la asignación de clase de reenvío a cola y los clasificadores y reescrituras de agregado de comportamiento (BA) admitidos en las interfaces de estructura abstracta (af).
Reenvío de asignación de clase a cola
Una af interfaz es una interfaz WAN simulada con la mayoría de las capacidades de cualquier otra interfaz, excepto que el tráfico designado a un motor de reenvío de paquetes remoto todavía tendrá que pasar por las dos colas de estructura (de prioridad baja/alta).
Actualmente, una af interfaz funciona solo en modo de 2 colas. Por lo tanto, todas las características basadas en colas, como la programación, la vigilancia y el moldeado, no están disponibles en una af interfaz.
Los paquetes de la af interfaz heredan la cola de tejido determinada por la prioridad de tejido configurada para la clase de reenvío a la que pertenece ese paquete. Por ejemplo, consulte la siguiente clase de reenvío a la configuración del mapa de cola:
[editar]
user@router# show class-of-service forwarding-classes
class Economy queue-num 0 priority low; /* Low fabric priority */
class Stream queue-num 1;
class Business queue-num 2;
class Voice queue-num 3;
class NetControl queue-num 3;
class Business2 queue-num 4;
class Business3 queue-num 5;
class VoiceSig queue-num 6 priority high; /* High fabric priority */
class VoiceRTP queue-num 7;
Como se muestra en el ejemplo anterior, cuando un paquete se clasifica en la clase VoiceSigde reenvío, el código de la ruta de reenvío examina la prioridad de estructura de esa clase de reenvío y decide qué cola de estructura elegir para este paquete. En este caso, se elige la cola de estructura de alta prioridad.
Clasificadores y reescrituras de BA
El clasificador de agregado de comportamiento (BA) asigna un valor de clase de servicio (CoS) a una clase de reenvío y prioridad de pérdida. La combinación de clase de reenvío y prioridad de pérdida determina el tratamiento CoS dado al paquete en el enrutador. Se admiten los siguientes clasificadores y reescrituras de BA:
Clasificador y reescritura de Inet-Precedence
Clasificador y reescritura DSCP
Clasificador y reescritura MPLS EXP
También puede aplicar reescrituras para los paquetes IP que entren en el túnel MPLS y realizar una reescritura de los bits de tipo de servicio (ToS) EXP e IPv4. Este enfoque funcionará como lo hace en otras interfaces normales.
Clasificador y reescritura DSCP v6 para tráfico IP v6
No se admiten los siguientes elementos:
Clasificación y reescritura IEEE 802.1
Clasificación y reescritura IEEE 802.1AD (QinQ)
Consulte la Guía de configuración de CoS para obtener detalles sobre los clasificadores de BA de CoS.
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
Compatibilidad con capturas SNMP: Configuración del servidor NMS (modelo de servidor externo)
El Administrador de dispositivos de Juniper (JDM) admite las siguientes capturas SNMP:
Capturas LinkUp y linkDown para interfaces JDM.
Se generan capturas SNMP linkUp/linkDown estándar. Se utiliza una cadena
jdmde comunidad predeterminada.Capturas LinkUp/linkDown para interfaces de host.
Se generan capturas SNMP estándar
linkUp/linkDown. Se utiliza una cadenahostde comunidad predeterminada.Trampas de pérdida/recuperación de conectividad de JDM a JDM.
Las capturas de pérdida/recuperación de conectividad de JDM a JDM se envían mediante capturas syslog genéricas (jnxSyslogTrap) a través de la interfaz de administración de host.
La captura
JDM_JDM_LINK_DOWNdescendente de conectividad de JDM se envía cuando el JDM no puede comunicarse con el JDM par en otro servidor a través decb0ocb1vínculos. Vea el siguiente ejemplo:{ SNMPv2c C=host { V2Trap(296) R=1299287309 .1.3.6.1.2.1.1.3.0=42761992 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.2636.4.12.0.1 .1.3.6.1.4.1.2636.3.35.1.1.1.2.1="JDM_JDM_LINK_DOWN" .1.3.6.1.4.1.2636.3.35.1.1.1.3.1="" .1.3.6.1.4.1.2636.3.35.1.1.1.4.1=5 .1.3.6.1.4.1.2636.3.35.1.1.1.5.1=24 .1.3.6.1.4.1.2636.3.35.1.1.1.6.1=0 .1.3.6.1.4.1.2636.3.35.1.1.1.7.1="jdmmon" .1.3.6.1.4.1.2636.3.35.1.1.1.8.1="JDM-HOST" .1.3.6.1.4.1.2636.3.35.1.1.1.9.1="JDM to JDM Connection Lost" .1.3.6.1.6.3.1.1.4.3.0.0=”” } }La captura
JDM_JDM_LINK_UPascendente de conectividad de JDM a JDM se envía cuando aparece elcb0vínculo ocb1y los JDM de ambos servidores pueden comunicarse nuevamente. Vea el siguiente ejemplo:{ SNMPv2c C=host { V2Trap(292) R=998879760 .1.3.6.1.2.1.1.3.0=42762230 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.2636.4.12.0.1 .1.3.6.1.4.1.2636.3.35.1.1.1.2.1="JDM_JDM_LINK_UP" .1.3.6.1.4.1.2636.3.35.1.1.1.3.1="" .1.3.6.1.4.1.2636.3.35.1.1.1.4.1=5 .1.3.6.1.4.1.2636.3.35.1.1.1.5.1=24 .1.3.6.1.4.1.2636.3.35.1.1.1.6.1=0 .1.3.6.1.4.1.2636.3.35.1.1.1.7.1="jdmmon" .1.3.6.1.4.1.2636.3.35.1.1.1.8.1="JDM-HOST" .1.3.6.1.4.1.2636.3.35.1.1.1.9.1="JDM to JDM Connection Up" .1.3.6.1.6.3.1.1.4.3.0.0="" } }VM(GNF) arriba/abajo:
libvirtGuestNotifnotificaciones.Para los eventos de inicio/apagado de GNF, se generan las notificaciones estándar
libvirtGuestNotif. Para obtenerlibvirtMIBdetalles sobre las notificaciones, consulte esta página web. Además, vea el siguiente ejemplo:HOST [UDP: [127.0.0.1]:53568->[127.0.0.1]]: Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (636682) 1:46:06.82, SNMPv2-MIB::snmpTrapOID.0 = OID: LIBVIRT-MIB::libvirtGuestNotif, LIBVIRT-MIB::libvirtGuestName.0 = STRING: "gnf1", LIBVIRT-MIB::libvirtGuestUUID.1 = STRING: 7ad4bc2a-16db-d8c0-1f5a-6cb777e17cd8, LIBVIRT-MIB::libvirtGuestState.2 = INTEGER: running(1), LIBVIRT-MIB::libvirtGuestRowStatus.3 = INTEGER: active(1)
Las capturas SNMP se envían al servidor NMS de destino. Para configurar los detalles del servidor NMS de destino en JDM, consulte el ejemplo siguiente:
[editar]
root@jdm#show snmp | display setroot@jdm#set snmp name nameroot@jdm#set snmp description descriptionroot@jdm#set snmp location locationroot@jdm#set snmp contact user's emailroot@jdm#set snmp trap-group tg-1 targets target ip address1root@jdm#set snmp trap-group tg-1 targets target ip address2
JDM no escribe ninguna configuración en el archivo de configuración snmp del host (/etc/snmp/snmpd.conf). Por lo tanto, la instalación de JDM y la configuración posterior no tienen ningún impacto en el SNMP del host. El comando SNMP configuration CLI en JDM sólo se utiliza para configurar el archivo snmpd.conf del JDM que está presente en el contenedor. Para generar una captura linkUp/Down, debe incluir manualmente la configuración, tal como se muestra en el ejemplo siguiente, en el archivo snmpd.conf del servidor host (/etc/snmp/snmpd.conf):
createUser trapUser iquerySecName trapUser rouser trapUser defaultMonitors yes notificationEvent linkUpTrap linkUp ifIndex ifAdminStatus ifOperStatus ifDescr notificationEvent linkDownTrap linkDown ifIndex ifAdminStatus ifOperStatus ifDescr monitor -r 10 -e linkUpTrap "Generate linkUp" ifOperStatus != 2 monitor -r 10 -e linkDownTrap "Generate linkDown" ifOperStatus == 2 trap2sink <NMS-IP> host
En el ejemplo anterior, reemplace <NMS-IP> por la dirección IP de Network Management Station (NMS).
Jerarquía de configuración del chasis en BSYS y GNF
En la división de nodos de Junos, BSYS posee todos los componentes físicos del enrutador, incluidas las tarjetas de línea y la estructura, mientras que los GNF mantienen el estado de reenvío en sus respectivas tarjetas de línea. De acuerdo con esta responsabilidad dividida, la configuración de la CLI de Junos bajo la chassis jerarquía (si la hubiera) debe aplicarse en el BSYS o en el GNF de la siguiente manera:
Los parámetros de nivel físico bajo la
chassisjerarquía de configuración deben aplicarse en el BSYS. Por ejemplo, la configuración para controlar errores físicos en un FPC es un parámetro de nivel físico y, por lo tanto, debe aplicarse en el BSYS.At BSYS Junos CLI: [edit] user@router#
set chassis fpc fpc slot error major threshold threshold value action alarmLos parámetros lógicos o de nivel de característica bajo la
chassisjerarquía de configuración deben aplicarse al GNF asociado con el FPC. Por ejemplo, la configuración de colas máximas por tarjeta de línea es un parámetro de nivel lógico y, por lo tanto, debe aplicarse en el GNF.At GNF Junos CLI: [edit] user@router#
set chassis fpc fpc slot max-queues valueComo excepciones, se deben aplicar los dos parámetros siguientes en la jerarquía de
chassisconfiguración tanto en BSYS como en GNF:At both BSYS and GNF CLI: [edit] user@router#
set chassis network-services network services modeuser@router#set chassis fpc fpc slot flexible-queueing-mode
Configuración de tarjetas de sublínea y asignación a GNF
Para obtener una descripción general de las tarjetas de sublínea, consulte Descripción general de tarjetas de sublínea.
-
Esta función se aplica a la tarjeta de línea MPC11E (número de modelo: MX2K-MPC11E) de los enrutadores MX2010 y MX2020 utilizados en la configuración de división de nodos Junos basada en servidor externo.
-
Asegúrese de que cada motor de enrutamiento de todos los GNF y BSYS ejecute Junos OS versión 21.2R1 o versiones posteriores.
Para dividir aún más un MPC11E en tarjetas de sublínea (SLC), debe utilizar la opción CLI fpc-slice en la set chassis network-slices guest-network-functions gnf jerarquía de BSYS.
Antes de confirmar la configuración, debe configurar todas las SLC compatibles con la tarjeta de línea y asignar todos los recursos necesarios, como el núcleo, la DRAM y los motores de reenvío de paquetes a las SLC. Una tarjeta de línea MPC11E admite dos SLC.
Los GNF admiten las siguientes combinaciones de tarjetas de línea completa y SLC:
-
GNF con SLC MPC11E
-
GNF con SLC MPC11E y MPC9
-
GNF con SLC MPC11E y MPC11E
-
GNF con SLC MPC11E, MPC9, MPC11E
Para configurar SLC y asignarlos a GNF, siga estos pasos:
-
Debe configurar todas las siguientes instrucciones de CLI a la vez para todas las SLC (como se muestra en los pasos siguientes). Cualquier modificación de esta configuración posterior hace que toda la tarjeta de línea se reinicie.
- Si configura valores incorrectos (por ejemplo, rangos de motor de reenvío de paquetes, núcleos de CPU o valores DRAM no compatibles), se producirá un error en la confirmación de configuración con un mensaje adecuado para indicar el error.
Ver también
Configuración de ejemplo para la división de nodos de Junos
En esta sección se proporcionan configuraciones de ejemplo para la división de nodos de Junos.
- Configuración de JDM de ejemplo (modelo de servidor externo)
- Configuración de JDM de ejemplo (modelo en el chasis)
- Configuración BSYS de ejemplo con interfaz de estructura abstracta
- Configuración de estructura abstracta de ejemplo en GNF con clase de servicio
- Salida de muestra para el estado de interfaz de estructura abstracta en un GNF
Configuración de JDM de ejemplo (modelo de servidor externo)
root@test-jdm-server0> show configuration
groups {
server0 {
system {
host-name test-jdm-server0;
}
server {
interfaces {
cb0 p3p1;
cb1 p3p2;
jdm-management em2;
vnf-management em3;
}
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.112/21;
}
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
server1 {
system {
host-name test-jdm-server1;
}
server {
interfaces {
cb0 p3p1;
cb1 p3p2;
jdm-management em2;
vnf-management em3;
}
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.113/21;
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
}
}
apply-groups [ server0 server1 ];
system {
root-authentication {
encrypted-password "..."; ## SECRET-DATA
}
services {
ssh;
netconf {
ssh;
rfc-compliant;
}
}
}
virtual-network-functions {
test-gnf {
id 1;
chassis-type mx2020;
resource-template 2core-16g;
base-config /var/jdm-usr/gnf-config/test-gnf.conf;
}
}
Configuración de JDM de ejemplo (modelo en el chasis)
root@test-jdm-server0> show configuration
groups {
server0 {
system {
host-name test-jdm-server0;
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.112/21;
}
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
server1 {
system {
host-name test-jdm-server1;
}
interfaces {
jmgmt0 {
unit 0 {
family inet {
address 10.216.105.113/21;
}
}
}
routing-options {
static {
route {
0.0.0.0/0 next-hop 10.216.111.254;
}
}
}
}
}
}
apply-groups [ server0 server1 ];
system {
root-authentication {
encrypted-password "..."; ## SECRET-DATA
}
services {
ssh;
netconf {
ssh;
rfc-compliant;
}
}
}
virtual-network-functions {
test-gnf {
id 1;
resource-template 2core-16g;
base-config /var/jdm-usr/gnf-config/test-gnf.conf;
}
}
Configuración BSYS de ejemplo con interfaz de estructura abstracta
user@router> show configuration chassis
network-slices {
guest-network-functions {
gnf 1 {
af2 {
peer-gnf id 2 af1;
}
af4 {
peer-gnf id 4 af1;
}
description gnf-a;
fpcs [ 0 19];
}
gnf 2 {
af1 {
peer-gnf id 1 af2;
}
af4 {
peer-gnf id 4 af2;
}
description gnf-b;
fpcs [ 1 6 ];
}
gnf 4 {
af1 {
peer-gnf id 1 af4;
}
af2 {
peer-gnf id 2 af4;
}
description gnf-d;
fpcs [ 3 4 ];
}
}
}
Configuración de estructura abstracta de ejemplo en GNF con clase de servicio
Supongamos que existe una interfaz abstracta de estructura (af) entre GNF1 y GNF2. La siguiente configuración de ejemplo ilustra cómo aplicar reescrituras en la af interfaz en GNF1 y aplicar clasificadores en la interfaz en GNF2, en un escenario donde el af tráfico proviene de GNF1 a GNF2:
GNF1 Configuration
interfaces {
xe-4/0/0 {
unit 0 {
family inet {
address 22.1.2.2/24;
}
}
}
af2 {
unit 0 {
family inet {
address 32.1.2.1/24;
}
}
}
}
class-of-service {
classifiers {
dscp testdscp {
forwarding-class assured-forwarding {
loss-priority low code-points [ 001001 000000 ];
}
}
}
interfaces {
xe-4/0/0 {
unit 0 {
classifiers {
dscp testdscp;
}
}
classifiers {
dscp testdscp;
}
}
af1 {
unit 0 {
rewrite-rules {
dscp testdscp; /*Rewrite rule applied on egress AF interface on GNF1.*/
}
}
}
}
rewrite-rules {
dscp testdscp {
forwarding-class assured-forwarding {
loss-priority low code-point 001001;
}
}
}
}
GNF2 Configuration
interfaces {
xe-3/0/0:0 {
unit 0 {
family inet {
address 42.1.2.1/24;
}
}
}
af1 {
unit 0 {
family inet {
address 32.1.2.2/24;
}
}
}
}
class-of-service {
classifiers {
dscp testdscp {
forwarding-class network-control {
loss-priority low code-points 001001;
}
}
}
interfaces {
af1 {
unit 0 {
classifiers {
dscp testdscp; /*Classifier applied on AF at ingress of GNF2*/
}
}
}
}
}
Salida de muestra para el estado de interfaz de estructura abstracta en un GNF
user@router-gnf-b> show interfaces af9
Physical interface: af9, Enabled, Physical link is Up
Interface index: 209, SNMP ifIndex: 527
Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Speed: 370000mbps
Device flags : Present Running
Interface flags: Internal: 0x4000
Link type : Full-Duplex
Link flags : None
Current address: 00:90:69:2b:00:4c, Hardware address: 00:90:69:2b:00:4c
Last flapped : 2018-09-12 01:44:01 PDT (00:01:02 ago)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
Bandwidth : 370 Gbps
Peer GNF id : 9
Peer GNF Forwarding element(FE) view :
FPC slot:FE num FE Bandwidth(Gbps) Status Transmit Packets Transmit Bytes
6:0 130 Up 0 0
12:0 120 Up 0 0
12:1 120 Up 0 0
Residual Transmit Statistics :
Packets : 0 Bytes : 0
Fabric Queue Statistics :
FPC slot:FE num High priority(pkts) Low priority(pkts)
6:0 0 0
12:0 0 0
12:1 0 0
FPC slot:FE num High priority(bytes) Low priority(bytes)
6:0 0 0
12:0 0 0
12:1 0 0
Residual Queue Statistics :
High priority(pkts) Low priority(pkts)
0 0
High priority(bytes) Low priority(bytes)
0 0
Logical interface af9.0 (Index 332) (SNMP ifIndex 528)
Flags: Up SNMP-Traps 0x4004000 Encapsulation: ENET2
Input packets : 0
Output packets: 13
Protocol inet, MTU: 1500
Configuración de ejemplo para tarjetas de sublínea
En esta sección se proporcionan configuraciones de ejemplo para tarjetas de sublínea (SLC).
- Configuración de ejemplo para el perfil simétrico de tarjeta de sublínea
- Configuración de ejemplo para perfil de tarjeta de sublínea asimétrica
Configuración de ejemplo para el perfil simétrico de tarjeta de sublínea
En el perfil simétrico, sólo es posible una combinación de recursos.
A continuación se muestra un ejemplo de configuración para dividir la FPC 1 (MPC11E) en un perfil de tarjeta de sublínea simétrico:
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 pfe-id-list 0-3set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 cores 4set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 dram 13set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 pfe-id-list 4-7set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 cores 4set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 dram 13
Esta configuración aparecerá como se muestra a continuación:
root@bsys> show chassis network-slices guest-network-functions
gnf 1{
fpc-slice {
fpc 1{
slc 1{
pfe-id-list 0-3;
cores 4;
dram 13;
}
}
}
}
gnf 2{
fpc-slice {
fpc 1{
slc 2{
pfe-id-list 4-7;
cores 4;
dram 13;
}
}
}
}
Configuración de ejemplo para perfil de tarjeta de sublínea asimétrica
En el perfil asimétrico, son posibles dos configuraciones, dependiendo de cómo se dividan los PFE o los motores de reenvío de paquetes [0-7] entre los dos SLC. En una configuración de ejemplo, los dos primeros motores de reenvío de paquetes [0-1] se asignan a un SLC y los motores de reenvío de paquetes restantes [2-7] al otro SLC. En la otra configuración de ejemplo, los dos últimos motores de reenvío de paquetes [6-7] se asignan a un SLC y los motores de reenvío de paquetes restantes [0-5] al otro SLC.
La configuración de ejemplo siguiente es un ejemplo de división [0-1 2-7].
En el ejemplo siguiente, las asignaciones de núcleo de CPU y DRAM para los SLC coinciden con una de las columnas de la combinación de recursos 'Perfil asimétrico', como se muestra en la tabla Perfiles SLC compatibles con MPC11E en la página Descripción general de la tarjeta de sublínea .
set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 pfe-id-list 0-1set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 cores 4set chassis network-slices guest-network-functions gnf 1 fpc-slice fpc 1 slc 1 dram 17set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 pfe-id-list 2-7set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 cores 4set chassis network-slices guest-network-functions gnf 2 fpc-slice fpc 1 slc 2 dram 9
Esta configuración aparecerá como sigue:
root@bsys> show chassis network-slices guest-network-functions
gnf 1{
fpc-slice {
fpc 1{
slc 1{
pfe-id-list 0-1;
cores 4;
dram 17;
}
}
}
}
gnf 2{
fpc-slice {
fpc 1{
slc 2{
pfe-id-list 2-7;
cores 4;
dram 9;
}
}
}
}