EN ESTA PÁGINA
Instalación del paquete RPM de JDM en servidores x86 que ejecutan RHEL (modelo de servidor externo)
Configuración de JDM en los servidores x86 (modelo de servidor externo)
Configuración de usuarios que no son raíz 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 en chasis
Configuración de interfaces de estructura abstraída entre un par de GNF
Optimización de la ruta de la estructura para la interfaz de la estructura abstraída
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 configuración de la 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 para la configuración de la 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 el BSYS tenga configuraciones de interfaz asociadas con las tarjetas de línea instaladas en el sistema. En su lugar, las funciones de red para invitados (GNF) tendrán las configuraciones completas del enrutador.
Instalación del paquete RPM de JDM en servidores x86 que ejecutan RHEL (modelo de servidor externo)
Antes de instalar el paquete RPM JDM para servidores x86, asegúrese de que ha instalado los paquetes adicionales, tal y como se describe en Instalación de paquetes adicionales para JDM.
Descargue e instale el paquete RPM de JDM para servidores x86 que ejecuten 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 del paquete JDM de Ubuntu en servidores x86 que ejecutan Ubuntu 24.04 (modelo de servidor externo)
Antes de instalar el paquete JDM de 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 24.04 de la siguiente manera:
Para instalar el paquete JDM en los servidores x86 que ejecutan Ubuntu 24.04, realice los pasos siguientes en cada uno de los servidores:
Repita los pasos para el segundo servidor.
Configuración de JDM en los servidores x86 (modelo de servidor externo)
Siga estos pasos para configurar JDM en cada uno de los servidores x86.
Configuración de usuarios que no son raíz 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 la versión 18.3R1 de Junos OS. Necesita una cuenta raíz para crear un usuario no root. Los usuarios que no son root pueden iniciar sesión en JDM mediante la consola de JDM o a través de 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 que no son root pueden realizar las siguientes funciones:
Interactúe con JDM.
Orquestar y gestionar las funciones de red de invitados (GNF).
Supervise el estado del JDM, el servidor host y los GNF mediante los 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 que no son root:
Clase de inicio de sesión |
Permisos |
|---|---|
superusuario |
|
operador |
|
solo lectura |
Similar a la clase de operador, con la excepción de que los usuarios no pueden reiniciar daemons dentro de JDM. |
No autorizado |
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 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 alCB0yCB1sobre el enrutador 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 ver 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 la versión 19.2R1 de Junos OS, la división de nodos de Junos admite la asignación de un rango de direcciones MAC único globalmente (proporcionado por Juniper Networks) para GNF. .
Configuración del enrutador de la serie MX para que funcione en modo en chasis
Para configurar la división de nodos de Junos en el chasis, el enrutador de la serie MX debe tener uno de los siguientes tipos de motores de enrutamiento instalados:
-
RE-S-X6-128G (utilizado en enrutadores MX480 y MX960)
-
REMX2K-X8-128G (utilizado en enrutadores MX2010 y MX2020)
-
REMX2008-X8-128G (utilizado en enrutadores MX2008)
-
En el modelo en chasis, el sistema base (BSYS), el administrador de dispositivos de Juniper (JDM) y todas las funciones de red de invitados (GNF) se ejecutan dentro del 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 la máquina virtual después de configurar la set vmhost resize vjunos compact instrucción. Debe guardar los archivos que se encuentran actualmente en /var/log o /var/crash antes de continuar con la configuración del cambio de tamaño del host de la máquina virtual si desea utilizarlos como referencia.
Instalación y configuración de JDM para el modelo de chasis
Los pasos enumerados en este tema solo se aplican a la configuración de la división de nodos de Junos en el chasis.
- Instalación del paquete RPM de JDM en un enrutador de la serie MX (modelo en chasis)
- Configuración de JDM (modelo en chasis)
Instalación del paquete RPM de JDM en un enrutador de la serie MX (modelo en chasis)
Antes de instalar el paquete RPM del Administrador de dispositivos de Juniper (JDM) en un enrutador de la serie MX, debe configurar el enrutador de la serie MX para que funcione en el modo BSYS en el chasis. Para obtener más información, consulte Configuración del enrutador de la serie MX para funcionar en modo en chasis.
El paquete jns-jdm-vmhost RPM está diseñado para el despliegue de la división de nodos de Junos en el chasis, mientras que el paquete jns-jdm RPM se usa para el despliegue de la División de nodos de Junos basada en servidores externos.
Configuración de JDM (modelo en chasis)
Siga estos pasos para configurar JDM en ambos motores de enrutamiento de un enrutador de la serie MX:
En la división de nodos de Junos en el 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 desde el motor de enrutamiento 0 de GNF1 a JDM).
En el modo en chasis, no puede realizar ninguna
scpoperación entre las interfaces de administración de 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 realizar el paso 8 sin completar el paso 7, el sistema mostrará un mensaje de error como se muestra en el siguiente ejemplo:
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 la versión 19.2R1 de Junos OS, la división de nodos de Junos admite la asignación de un rango de direcciones MAC único globalmente (proporcionado por Juniper Networks) para GNF. .
Asignación de direcciones MAC a GNF
A partir de la versión 19.2R1 de Junos OS, la división de nodos de Junos admite la asignación de un rango de direcciones MAC único globalmente (proporcionado por Juniper Networks) para GNF.
Para recibir el rango de dirección MAC único a nivel mundial para los GNF, comuníquese con su representante de Juniper Networks y entregue su SSRN (número de referencia de soporte de software) de licencia de GNF, el cual se le enviará electrónicamente al momento de comprar la licencia de GNF. Para localizar el SSRN en su licencia GNF, consulte el artículo Base de conocimientos de Juniper Networks KB11364.
Por cada licencia de GNF, se le proporcionará un "SSRN aumentado", que incluye el rango de direcciones MAC único a nivel global asignado por Juniper Networks para esa licencia de 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 solo para un ID GNF. En el JDM, las máquinas virtuales GNF se conocen como funciones de red virtual (VNF). El ID de GNF es uno de sus atributos. Los atributos de una VNF se describen con detalle en la sección siguiente Configuración de funciones de red para 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. 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 de Junos en el chasis) antes de configurar el SSRN aumentado.
De manera similar, 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 de Junos en el 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 aplicó el rango de dirección MAC asignado para un GNF, cuando el GNF entre en funcionamiento, use el comando
show chassis mac-addressesCLI de Junos: el resultado coincidirá con una subcadena del SSRN aumentado.
Configuración de funciones de red para invitados
La configuración de una función de red de invitados (GNF) consta de dos tareas, una que debe realizarse 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, use 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 principal:Mismatched MAC address pool between GNF RE0 and GNF RE1. Para ver la alarma, utilice el comando show system alarms. -
Antes de intentar crear un GNF, debe asegurarse de que los servidores (o motores de enrutamiento en el caso del modelo en chasis) tengan suficientes recursos (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 como se muestra en el siguiente ejemplo:
usuario@enrutador# set chassis network-slices guest-network-functions gnf 1 fpcs 4
usuario@enrutador# commit
En el JDM, las máquinas virtuales GNF se conocen como funciones de red virtual (VNF). Una VNF tiene 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.
-
Una imagen de Junos OS 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 Función de división de nodos - red de invitados para descargar una imagen Junos para el GNF.
La plantilla de recursos del servidor VNF.
En el JDM, para configurar una VNF, realice los siguientes pasos:
Utilice el comando
scpdel 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 de la CLI de JDM, 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 siguiente ejemplo:
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 en chasis, no configure el tipo de plataforma (
set virtual-network-functionstest-gnfchassis-type mx2020). Se detectará automáticamente.A partir de la versión 19.2R1 de Junos OS, la división de nodos de Junos admite la asignación de un rango de direcciones MAC único globalmente (proporcionado por Juniper Networks) para GNF.
Para especificar también una configuración de línea base o inicial de Junos OS para un GNF, prepare el archivo de configuración de GNF (ejemplo: /var/jdm-usr/gnf-config/test-gnf.conf) tanto en los servidores (server0 y server1) para el modelo de servidor externo como en los motores de enrutamiento (re0 y re1) para el modelo en chasis, y especifique el filename 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 de 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 que se utiliza 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 la VNF con 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. Le recomendamos que establezca 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 la CLI para el modelo en el chasis es
root@jdm#.Para ver configuraciones de ejemplo, 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 física x86 TC o la interfaz de administración GNF desde el shell de Linux (mediante el comando
ifconfig interface-name down), estos se activarán automáticamente cuando se inicie el GNF.
Configuración de interfaces de estructura abstraída entre un par de GNF
La creación de una interfaz de estructura abstraída (af) entre dos funciones de red invitadas (GNF) implica configuraciones tanto en el sistema base (BSYS) como en el GNF. Las interfaces de estructura abstraída se crean en GNF según la configuración de 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 en la que a cada GNF se le asigna una sola FPC, si los motores de reenvío de paquetes de la FPC asignada al GNF remoto dejan de ser accesibles mediante estructura, la interfaz de estructura abstraída asociada deja de funcionar. Entre los ejemplos de errores que podrían causar este comportamiento se encuentran los errores de accesibilidad de la estructura de PFE y los eventos CMERROR que provocan
pfe disableuna acción (use elshow chassis fpc errorscomando para obtener más detalles). Si un GNF tiene varios FPC asignados, los FPC locales que informan de que todos los motores de reenvío de paquetes par están inactivos se eliminan para determinar el estado de la interfaz de estructura abstraída.
Para configurar af interfaces entre un par de GNF:
-
En el BSYS, aplique la configuración como se muestra en el siguiente ejemplo:
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 de interfaz de estructura abstraída 2 yaf4es la instancia de interfaz de estructura abstraída 4.Nota:Los valores de interfaz permitidos
afvan desdeaf0.af9La interfaz GNF
afestará visible y arriba. Puede configurar unaafinterfaz de la misma manera que configura cualquier otra interfaz. En el GNF, aplique la configuración como se muestra en el siguiente ejemplo:
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 ambos GNF entre los que está configurada laafinterfaz.Para ver configuraciones de ejemplo
af, consulte Configuración de ejemplo para la división de nodos de Junos.
Clase de servicio en interfaces de estructura abstraída
La clasificación de paquetes de clase de servicio (CoS) asigna un paquete entrante a una cola de salida según la clase de reenvío del paquete. Consulte la Guía de configuración de CoS para obtener más detalles.
En las siguientes secciones, se explica la asignación de clase a cola de reenvío, y los clasificadores y reescrituras de agregado de comportamiento (BA) admitidos en las interfaces de estructura (af) abstraídas.
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 aún tendrá que pasar por las dos colas de estructura (la de prioridad baja o alta).
Actualmente, una af interfaz funciona solo en modo de 2 colas. Por lo tanto, todas las funciones basadas en colas, como la programación, la vigilancia y la forma, no están disponibles en una af interfaz.
Los paquetes de la af interfaz heredan la cola de estructura determinada por la prioridad de estructura configurada para la clase de reenvío a la que pertenece ese paquete. Por ejemplo, consulte la siguiente configuración de asignación de clase de reenvío a 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 mostró 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 de 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 de DSCP
Clasificador y reescritura de EXP de MPLS
También puede aplicar reescrituras para paquetes IP que ingresan al túnel MPLS y reescribir los bits de EXP y de tipo de servicio IPv4 (TDS). Este enfoque funcionará como lo hace en otras interfaces normales.
Clasificador y reescritura DSCP v6 para tráfico IP v6
No se admite lo siguiente:
Clasificación y reescritura de IEEE 802.1
Clasificación y reescritura de IEEE 802.1AD (QinQ)
Consulte la Guía de configuración de CoS para obtener más información sobre los clasificadores de BA de CoS.
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
Compatibilidad con capturas SNMP: Configuración del servidor NMS (modelo de servidor externo)
El Administrador de dispositivos de Juniper (JDM) admite las siguientes capturas de SNMP:
Trampas de enlace ascendente y descendente para interfaces JDM.
Se generan trampas SNMP estándar linkUp/linkDown. Se utiliza una cadena
jdmde comunidad predeterminada.Trampas de enlace ascendente y descendente para interfaces de host.
Se generan capturas SNMP estándar
linkUp/linkDown. Se utiliza una cadenahostde comunidad predeterminada.Capturas de pérdida o recuperación de conectividad de JDM a JDM.
Las capturas de pérdida o recuperación de conectividad de JDM a JDM se envían mediante capturas de syslog genéricas (jnxSyslogTrap) a través de la interfaz de administración de hosts.
La trampa
JDM_JDM_LINK_DOWNde conectividad JDM descendente se envía cuando el JDM no puede comunicarse con el JDM par en otro servidor overcb0ocb1links. 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 trampa
JDM_JDM_LINK_UPde conectividad de JDM a JDM se envía cuando aparece elcb0vínculo ocb1y los JDM de ambos servidores pueden comunicarse de nuevo. 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 obtener detalles sobrelibvirtMIBlas notificaciones, consulte esta página web. Consulte también 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 el JDM, consulte el siguiente ejemplo:
[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 de la CLI de configuración SNMP en JDM solo se utiliza para configurar el archivo snmpd.conf de JDM que está presente en el contenedor. Para generar una trampa de vínculo ascendente/descendente, debe incluir manualmente la configuración como se muestra en el siguiente ejemplo 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> con la dirección IP de la estación de administración de red (NMS).
Jerarquía de configuración de chasis en BSYS y GNF
En la división de nodos de Junos, el 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 existe) se debe aplicar en el BSYS o en el GNF de la siguiente manera:
Los parámetros de nivel físico en la
chassisjerarquía de configuración deben aplicarse en el BSYS. Por ejemplo, la configuración para manejar errores físicos en una FPC es un parámetro de nivel físico y, por lo tanto, debe aplicarse en la 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 de la
chassisjerarquía de configuración se deben aplicar en el GNF asociado con la FPC. Por ejemplo, la configuración de la tarjeta de colas máximas por 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
chassisjerarquía de configuració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 la tarjeta de sublínea.
-
Esta función se aplica a la tarjeta de línea MPC11E (número de modelo: MX2K-MPC11E) en los enrutadores MX2010 y MX2020 utilizados en la configuración de la División de nodos de Junos basada en servidores externos.
-
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 una MPC11E más en tarjetas de sublínea (SLC), debe usar la fpc-slice opción CLI en la jerarquía en set chassis network-slices guest-network-functions gnf BSYS.
Antes de confirmar la configuración, debe configurar todas las SLC compatibles con la tarjeta de línea y asignar a las SLC todos los recursos necesarios, como el núcleo, la DRAM y los motores de reenvío de paquetes. 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 MPC11E SLC y MPC9
-
GNF con MPC11E, SLC y MPC11E
-
GNF con MPC11E SLC, MPC9, MPC11E
Para configurar SLC y asignarlas a GNF, siga estos pasos:
-
Debe configurar todas las instrucciones CLI siguientes a la vez para todas las SLC (como se muestra en los pasos a continuación). Cualquier modificación posterior a esta configuración hace que se reinicie toda la tarjeta de línea.
- 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 ejemplos de configuraciones para la división de nodos de Junos.
- Configuración JDM de ejemplo (modelo de servidor externo)
- Ejemplo de configuración de JDM (modelo en chasis)
- Ejemplo de configuración de BSYS con interfaz de estructura abstraída
- Ejemplo de configuración de estructura abstracta en GNF con clase de servicio
- Prueba de salida para el estado de interfaz de la estructura abstraída en un GNF
Configuración 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;
}
}
Ejemplo de configuración de JDM (modelo en 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;
}
}
Ejemplo de configuración de BSYS con interfaz de estructura abstraída
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 ];
}
}
}
Ejemplo de configuración de estructura abstracta en GNF con clase de servicio
Suponga que existe una interfaz de estructura abstracta (af) entre GNF1 y GNF2. En la siguiente configuración de ejemplo, se muestra cómo aplicar reescrituras en la af interfaz en GNF1 y aplicar clasificadores en la interfaz en GNF2, en un escenario en el que el af tráfico procede 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*/
}
}
}
}
}
Prueba de salida para el estado de interfaz de la estructura abstraída 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 ejemplos de configuraciones para tarjetas de sublínea (SLC).
- Configuración de ejemplo para perfil de tarjeta de sublínea simétrica
- Configuración de ejemplo para perfil de tarjeta de sublínea asimétrica
Configuración de ejemplo para perfil de tarjeta de sublínea simétrica
En el perfil simétrico, solo es posible una combinación de recursos.
A continuación, se muestra una configuración de ejemplo para dividir la FPC 1 (MPC11E) en un perfil de tarjeta de sublínea simétrica:
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ía 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 las PFE o los motores de reenvío de paquetes [0-7] entre las 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 a continuación es un ejemplo de división [0-1, 2-7].
En el ejemplo siguiente, las asignaciones de núcleos 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 de 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ía 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-1;
cores 4;
dram 17;
}
}
}
}
gnf 2{
fpc-slice {
fpc 1{
slc 2{
pfe-id-list 2-7;
cores 4;
dram 9;
}
}
}
}