EN ESTA PÁGINA
Modificación de la función principal predeterminada del motor de enrutamiento
Configuración de la conmutación por error automática al motor de enrutamiento de copia de seguridad
Cambio manual de la función principal del motor de enrutamiento
Comprobación del estado de redundancia del motor de enrutamiento
Copiar un archivo de configuración de un motor de enrutamiento a otro
Carga de un paquete de software desde el otro motor de enrutamiento
Configuración de la redundancia del motor de enrutamiento
Siga los pasos y ejemplos que se indican a continuación para configurar la redundancia del motor de enrutamiento.
Para completar las tareas de las secciones siguientes, se deben definir los grupos de configuración re0 y re1 . Para obtener más información acerca de los grupos de configuración, consulte la Guía del usuario de la CLI de Junos OS.
Modificación de la función principal predeterminada del motor de enrutamiento
En el caso de enrutadores con dos motores de enrutamiento, puede configurar qué motor de enrutamiento es el principal y cuál es el de respaldo. De forma predeterminada, el motor de enrutamiento de la ranura 0 es el principal (re0) y el de la ranura 1 es la copia de seguridad (re1).
En sistemas con dos motores de enrutamiento, ambos motores de enrutamiento no se pueden configurar para ser primarios al mismo tiempo. Esta configuración hace que se produzca un error en la comprobación de confirmación.
Para modificar la configuración predeterminada, incluya la routing-engine instrucción en el nivel de [edit chassis redundancy] jerarquía:
[edit chassis redundancy] routing-engine slot-number (master | backup | disabled);
slot-number puede ser 0 o 1. Para configurar el motor de enrutamiento para que sea el principal, especifique la opción maestra . Para configurarla para que sea la copia de seguridad, especifique la opción de copia de seguridad . Para deshabilitar un motor de enrutamiento, especifique la opción deshabilitada .
Para cambiar entre los motores de enrutamiento principal y el de reserva, consulte Cambio manual de la función principal del motor de enrutamiento.
Configuración de la conmutación por error automática al motor de enrutamiento de copia de seguridad
En las secciones siguientes se describe cómo configurar la conmutación por error automática al motor de enrutamiento de reserva cuando se producen ciertos errores en el motor de enrutamiento principal.
- Sin interrupciones en el reenvío de paquetes
- Al detectar un error de disco duro en el motor de enrutamiento principal
- Al detectar una conectividad LCMD rota entre la máquina virtual y RE
- Al detectar una pérdida de señal keepalive del motor de enrutamiento primario
- Al detectar el error de interfaz em0 en el motor de enrutamiento principal
- Cuando un proceso de software falla
Sin interrupciones en el reenvío de paquetes
En el caso de enrutadores con dos motores de enrutamiento, puede configurar un cambio correcto de motor de enrutamiento (GRES). Cuando se configura una conmutación correcta, la reconexión del zócalo se produce sin problemas sin interrupción en el reenvío de paquetes. Para obtener información acerca de cómo configurar un cambio correcto del motor de enrutamiento, consulte Configuración del cambio correcto del motor de enrutamiento.
Al detectar un error de disco duro en el motor de enrutamiento principal
Después de configurar un motor de enrutamiento de copia de seguridad, puede indicarle automáticamente que asuma el rol principal si detecta un error de disco duro desde el motor de enrutamiento principal. Para habilitar esta característica, incluya la on-disk-failure instrucción en el nivel de [edit chassis redundancy failover] jerarquía.
[edit chassis redundancy failover] on-disk-failure;
La on-disk-failure instrucción en el nivel de [edit chassis redundancy] jerarquía no se admite en plataformas PTX que ejecutan Junos Evolved. Estas plataformas utilizan de forma predeterminada un cambio cuando se detecta un fallo de disco.
Al detectar una conectividad LCMD rota entre la máquina virtual y RE
Establezca la siguiente configuración que dará como resultado un cambio automático de RE cuando se interrumpa la conectividad LCMD entre VM y RE. Para habilitar esta característica, incluya la on-loss-of-vm-host-connection instrucción en el nivel de [edit chassis redundancy failover] jerarquía.
[edit chassis redundancy failover] on-loss-of-vm-host-connection;
Si el proceso LCMD se bloquea en el principal, el sistema cambiará después de un minuto, siempre que la conexión LCMD de RE de respaldo sea estable. El sistema no cambiará bajo las siguientes condiciones: si la conexión LCMD de RE de respaldo es inestable o si el primario actual acaba de ganar el rol principal. Cuando el principal acaba de adquirir el rol principal, el cambio ocurre solo después de cuatro minutos.
Al detectar una pérdida de señal keepalive del motor de enrutamiento primario
Después de configurar un motor de enrutamiento de reserva, puede indicarle que asuma la función principal automáticamente si detecta una pérdida de señal keepalive del motor de enrutamiento principal.
Para habilitar la conmutación por error al recibir una pérdida de señal keepalive, incluya la on-loss-of-keepalives instrucción en el nivel de [edit chassis redundancy failover] jerarquía:
[edit chassis redundancy failover] on-loss-of-keepalives;
La on-loss-of-keepalives instrucción en la [edit chassis redundancy] jerarquía no se admite en plataformas PTX que ejecutan Junos Evolved. Estas plataformas utilizan de forma predeterminada un cambio cuando no se detectan mensajes keepalive.
Cuando no se configura un cambio correcto de motor de enrutamiento, de forma predeterminada, la conmutación por error se produce después de 300 segundos (5 minutos). Puede configurar un intervalo de tiempo más corto o más largo.
El período de tiempo de keepalive se restablece a 360 segundos cuando el motor de enrutamiento principal se ha reiniciado o detenido manualmente.
Para cambiar el período de tiempo keepalive, incluya la keepalive-time instrucción en el nivel jerárquico [edit chassis redundancy] :
[edit chassis redundancy] keepalive-time seconds;
El rango para el tiempo de mantenimiento con vida es de 2 a 10,000 segundos.
En el ejemplo siguiente se describe la secuencia de eventos si se configura el motor de enrutamiento de reserva para detectar una pérdida de señal keepalive en el motor de enrutamiento principal:
-
Configure manualmente un tiempo de mantenimiento de 25 segundos.
-
Después de que se pierde la conexión del motor de reenvío de paquetes con el motor de enrutamiento principal y expira el temporizador keepalive, se interrumpe el reenvío de paquetes.
-
Después de 25 segundos de pérdida de keepalive, se registra un mensaje y el motor de enrutamiento de reserva intenta asumir el rol principal. Se genera una alarma cuando el motor de enrutamiento de reserva se activa y la pantalla se actualiza con el estado actual del motor de enrutamiento.
-
Después de que el motor de enrutamiento de respaldo asume la función principal, sigue funcionando como principal.
Cuando se configura un cambio correcto del motor de enrutamiento, la señal keepalive se activa automáticamente y el tiempo de conmutación por error se establece en 2 segundos (4 segundos en enrutadores M20). No puede restablecer manualmente la hora de keepalive.
Cuando detiene o reinicia el motor de enrutamiento principal, Junos OS restablece el tiempo de keepalive a 360 segundos y el motor de enrutamiento de reserva no asume la función principal hasta que expira el período de tiempo keepalive de 360 segundos.
Un antiguo motor de enrutamiento principal se convierte en un motor de enrutamiento de reserva si vuelve al servicio después de una conmutación por error al motor de enrutamiento de reserva. Para restaurar el estado principal al antiguo motor de enrutamiento principal, puede usar el comando de modo operativo de modo operativo de conmutador maestro de motor de enrutamiento de chasis .
Si en algún momento uno de los motores de enrutamiento no está presente, el motor de enrutamiento restante se convierte en primario automáticamente, independientemente de cómo se configure la redundancia.
Al detectar el error de interfaz em0 en el motor de enrutamiento principal
Después de configurar un motor de enrutamiento de reserva, indique que asuma el rol principal automáticamente si se produce un error en la interfaz em0 en el motor de enrutamiento principal. Para habilitar esta característica, incluya la on-re-to-fpc-stale instrucción en el nivel de [edit chassis redundancy failover] jerarquía.
[edit chassis redundancy failover] on-re-to-fpc-stale;
Cuando un proceso de software falla
Para configurar el cambio automático al motor de enrutamiento de reserva si se produce un error en un proceso de software, incluya la failover other-routing-engine instrucción en el nivel de [edit system processes process-name] jerarquía:
[edit system processes process-name] failover other-routing-engine;
process-name es uno de los nombres de proceso válidos. Si esta instrucción está configurada para un proceso y ese proceso falla cuatro veces en 30 segundos, el enrutador se reinicia desde el otro motor de enrutamiento. Otra instrucción disponible en el nivel jerárquico [edit system processes] es failover alternate-media. Para obtener información acerca de la opción de medios alternativos, consulte la Biblioteca de administración de Junos OS para dispositivos de enrutamiento.
Cambio manual de la función principal del motor de enrutamiento
Para cambiar manualmente el rol principal de Motor de enrutamiento, use uno de los siguientes comandos:
-
En el motor de enrutamiento de reserva, solicite que el motor de enrutamiento de reserva asuma la función principal emitiendo el
request chassis routing-engine master acquirecomando. -
En el motor de enrutamiento principal, solicite que el motor de enrutamiento de reserva asuma la función principal mediante el
request chassis routing-engine master releasecomando. -
En cualquiera de los motores de enrutamiento, cambie el rol principal emitiendo el
request chassis routing-engine master switchcomando.
Comprobación del estado de redundancia del motor de enrutamiento
Se proporciona un archivo de registro independiente para el registro de redundancia en /var/log/mastership. Para ver el registro, utilice el file show /var/log/mastership comando. En la tabla 1 se enumeran los códigos y las descripciones de los eventos del registro de funciones principales.
| Código de evento |
Descripción |
|---|---|
| E_NULL = 0 |
El evento es un evento null. |
| E_CFG_M |
El motor de enrutamiento está configurado como principal. |
| E_CFG_B |
El motor de enrutamiento se configura como copia de seguridad. |
| E_CFG_D |
El motor de enrutamiento está configurado como deshabilitado. |
| E_MAXTRY |
Se superó el número máximo de intentos para adquirir o liberar el rol principal. |
| E_REQ_C |
Se envió una solicitud de función principal de reclamación. |
| E_ACK_C |
Se recibió un reconocimiento de la función principal de la reclamación. |
| E_NAK_C |
No se reconoció una solicitud de rol principal de reclamación. |
| E_REQ_Y |
Se solicita confirmación del rol principal. |
| E_ACK_Y |
Se reconoce el rol principal. |
| E_NAK_Y |
No se reconoce el rol principal. |
| E_REQ_G |
Un motor de enrutamiento envió una solicitud de rol principal de liberación. |
| E_ACK_G |
El motor de enrutamiento reconoció la liberación del rol principal. |
| E_CMD_A |
La solicitud de comando de adquisición maestra del motor de enrutamiento del chasis se emitió desde el motor de enrutamiento de reserva. |
| E_CMD_F |
La fuerza de adquisición maestra del motor de enrutamiento del chasis de solicitud de comando se emitió desde el motor de enrutamiento de reserva. |
| E_CMD_R |
La versión maestra del motor de enrutamiento del chasis de solicitud de comando se emitió desde el motor de enrutamiento principal. |
| E_CMD_S |
El conmutador maestro del motor de enrutamiento del chasis de solicitud de comando se emitió desde un motor de enrutamiento. |
| E_NO_ORE |
No se detecta ningún otro motor de enrutamiento. |
| E_TMOUT |
Se agotó el tiempo de espera de una solicitud. |
| E_NO_IPC |
Se perdió la conexión del motor de enrutamiento. |
| E_ORE_M |
Otro estado del motor de enrutamiento se cambió a principal. |
| E_ORE_B |
Otro estado del motor de enrutamiento se cambió a copia de seguridad. |
| E_ORE_D |
Otro estado del motor de enrutamiento se cambió a deshabilitado. |
Compruebe el uso general de CPU y memoria
Propósito
Puede mostrar información exhaustiva del proceso del sistema sobre los procesos de software que se ejecutan en el enrutador y tienen terminales de control. Este comando es equivalente al comando superior de UNIX. Sin embargo, el comando superior de UNIX muestra el uso de memoria en tiempo real, con los valores de memoria cambiando constantemente, mientras que el comando show system processes extensive proporciona una instantánea del uso de memoria en un momento dado.
Acción
Para comprobar el uso general de CPU y memoria, escriba el siguiente comando de interfaz de línea de comandos (CLI) de Junos OS:
user@host> show system processes extensive
Salida de muestra
user@R1> show system processes extensive
last pid: 5251; load averages: 0.00, 0.00, 0.00 up 4+20:22:16 10:44:41
58 processes: 1 running, 57 sleeping
Mem: 57M Active, 54M Inact, 17M Wired, 184K Cache, 35M Buf, 118M Free
Swap: 512M Total, 512M Free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
4480 root 2 0 3728K 1908K select 231:17 2.34% 2.34% chassisd
4500 root 2 0 1896K 952K select 0:36 0.00% 0.00% fud
4505 root 2 0 1380K 736K select 0:35 0.00% 0.00% irsd
4481 root 2 0 1864K 872K select 0:32 0.00% 0.00% alarmd
4488 root 2 0 8464K 4600K kqread 0:28 0.00% 0.00% rpd
4501 root 2 -15 1560K 968K select 0:21 0.00% 0.00% ppmd
4510 root 2 0 1372K 812K select 0:13 0.00% 0.00% bfdd
5 root 18 0 0K 0K syncer 0:09 0.00% 0.00% syncer
4485 root 2 0 3056K 1776K select 0:07 0.00% 0.00% snmpd
4499 root 2 0 3688K 1676K select 0:05 0.00% 0.00% kmd
4486 root 2 0 3760K 1748K select 0:05 0.00% 0.00% mib2d
4493 root 2 0 1872K 928K select 0:03 0.00% 0.00% pfed
4507 root 2 0 1984K 1052K select 0:02 0.00% 0.00% fsad
4518 root 2 0 3780K 2400K select 0:02 0.00% 0.00% dcd
8 root -18 0 0K 0K psleep 0:02 0.00% 0.00% vmuncachedaemo
4 root -18 0 0K 0K psleep 0:02 0.00% 0.00% bufdaemon
4690 root 2 0 0K 0K peer_s 0:01 0.00% 0.00% peer proxy
4504 root 2 0 1836K 968K select 0:01 0.00% 0.00% dfwd
4477 root 2 0 992K 320K select 0:01 0.00% 0.00% watchdog
4354 root 2 0 1116K 604K select 0:01 0.00% 0.00% syslogd
4492 root 10 0 1004K 400K nanslp 0:01 0.00% 0.00% tnp.sntpd
4446 root 10 0 1108K 616K nanslp 0:01 0.00% 0.00% cron
4484 root 2 0 15716K 7468K select 0:01 0.00% 0.00% mgd
4494 root 2 15 2936K 2036K select 0:01 0.00% 0.00% sampled
5245 remote 2 0 8340K 3472K select 0:01 0.00% 0.00% cli
2 root -18 0 0K 0K psleep 0:00 0.00% 0.00% pagedaemon
4512 root 2 0 2840K 1400K select 0:00 0.00% 0.00% l2tpd
1 root 10 0 852K 580K wait 0:00 0.00% 0.00% init
5244 root 2 0 1376K 784K select 0:00 0.00% 0.00% telnetd
4509 root 10 0 1060K 528K nanslp 0:00 0.00% 0.00% eccd
4508 root 2 0 2264K 1108K select 0:00 0.00% 0.00% spd
2339 root 10 0 514M 17260K mfsidl 0:00 0.00% 0.00% newfs
4497 root 2 0 2432K 1152K select 0:00 0.00% 0.00% cosd
4490 root 2 -15 2356K 1020K select 0:00 0.00% 0.00% apsd
4496 root 2 0 2428K 1108K select 0:00 0.00% 0.00% rmopd
4491 root 2 0 2436K 1104K select 0:00 0.00% 0.00% vrrpd
4487 root 2 0 15756K 7648K sbwait 0:00 0.00% 0.00% mgd
5246 root 2 0 15776K 8336K select 0:00 0.00% 0.00% mgd
0 root -18 0 0K 0K sched 0:00 0.00% 0.00% swapper
5251 root 30 0 21732K 840K RUN 0:00 0.00% 0.00% top
4511 root 2 0 1964K 908K select 0:00 0.00% 0.00% pgmd
4502 root 2 0 1960K 956K select 0:00 0.00% 0.00% lmpd
4495 root 2 0 1884K 876K select 0:00 0.00% 0.00% ilmid
4482 root 2 0 1772K 776K select 0:00 0.00% 0.00% craftd
4503 root 10 0 1040K 492K nanslp 0:00 0.00% 0.00% smartd
6 root 28 0 0K 0K sleep 0:00 0.00% 0.00% netdaemon
4498 root 2 0 1736K 932K select 0:00 0.00% 0.00% nasd
4506 root 2 0 1348K 672K select 0:00 0.00% 0.00% rtspd
4489 root 2 0 1160K 668K select 0:00 0.00% 0.00% inetd
4478 root 2 0 1108K 608K select 0:00 0.00% 0.00% tnetd
4483 root 2 0 1296K 540K select 0:00 0.00% 0.00% ntpd
4514 root 3 0 1080K 540K ttyin 0:00 0.00% 0.00% getty
4331 root 2 0 416K 232K select 0:00 0.00% 0.00% pccardd
7 root 2 0 0K 0K pfeacc 0:00 0.00% 0.00% if_pfe_listen
11 root 2 0 0K 0K picacc 0:00 0.00% 0.00% if_pic_listen
3 root 18 0 0K 0K psleep 0:00 0.00% 0.00% vmdaemon
9 root 2 0 0K 0K scs_ho 0:00 0.00% 0.00% scs_housekeepi
10 root 2 0 0K 0K cb-pol 0:00 0.00% 0.00% cb_poll
Significado
La salida de ejemplo muestra la cantidad de memoria virtual utilizada por el motor de enrutamiento y los procesos de software. Por ejemplo, 118 MB de memoria física están libres y 512 MB del archivo de intercambio están libres, lo que indica que al enrutador no le falta memoria. El campo de procesos muestra que la mayoría de los 58 procesos están en el estado de suspensión, con 1 en el estado de ejecución. El proceso o comando que se está ejecutando es el comando superior.
La columna comandos enumera los procesos que se están ejecutando actualmente. Por ejemplo, el proceso de chasis (chassisd) tiene un identificador de proceso (PID) de 4480, con una prioridad actual (PRI) de 2. Un número de prioridad más bajo indica una prioridad más alta.
Los procesos se enumeran según el nivel de actividad, con el proceso más activo en la parte superior de la salida. Por ejemplo, el proceso de chasis (chassisd) consume la mayor cantidad de recursos de CPU con un 2,34 por ciento.
El campo de memoria (Mem) muestra la memoria virtual administrada por el motor de enrutamiento y utilizada por los procesos. El valor del campo de memoria está en KB y MB, y se desglosa de la siguiente manera:
-
Activa: memoria asignada y realmente en uso por los programas.
-
Inact: memoria asignada pero no utilizada recientemente o memoria liberada por programas. La memoria inactiva todavía se asigna en el espacio de direcciones de uno o más procesos y, por lo tanto, cuenta para el tamaño del conjunto residente de esos procesos.
-
Cableada: memoria que no es apta para ser intercambiada y que generalmente se usa para estructuras de memoria del motor de enrutamiento o memoria bloqueada físicamente por un proceso.
-
Caché: memoria que no está asociada a ningún programa y que no necesita ser intercambiada antes de ser reutilizada.
-
Buf: tamaño del búfer de memoria utilizado para contener datos recientemente llamados desde el disco.
-
Libre: memoria que no está asociada a ningún programa. La memoria liberada por un proceso puede volverse Inactiva, Caché o Libre, dependiendo del método utilizado por el proceso para liberar la memoria.
Cuando el sistema está bajo presión de memoria, el proceso de paginación reutiliza la memoria de las páginas libres, en caché, inactivas y, si es necesario, activas.
El campo Swap muestra el espacio total de swap disponible y cuánto no se ha utilizado. En el ejemplo, la salida muestra 512 MB de espacio total de intercambio y 512 MB de espacio de intercambio libre.
Finalmente, se enumera el uso de memoria de cada proceso. El campo SIZE indica el tamaño del espacio de direcciones virtuales y el campo RES indica la cantidad del programa en la memoria física, que también se conoce como RSS o Resident Set Size. En el resultado de ejemplo, el proceso de chasis (chassisd) tiene 3728 KB de espacio de direcciones virtuales y 1908 KB de memoria física.
Ejemplo de configuración inicial del motor de enrutamiento
Puede usar grupos de configuración para asegurarse de que se usan las direcciones IP correctas para cada motor de enrutamiento y para mantener un único archivo de configuración para ambos motores de enrutamiento.
En el ejemplo siguiente se definen los grupos de configuración re0 y re1 con direcciones IP independientes. Estos nombres de grupo de configuración conocidos solo surten efecto en el motor de enrutamiento adecuado.
groups {
re0 {
system {
host-name my-re0;
}
interfaces {
fxp0 {
description "10/100 Management interface";
unit 0 {
family inet {
address 10.255.2.40/24;
}
}
}
}
}
re1 {
system {
host-name my-re1;
}
interfaces {
fxp0 {
description "10/100 Management interface";
unit 0 {
family inet {
address 10.255.2.41/24;
}
}
}
}
}
}
Puede asignar una dirección IP adicional a la interfaz Ethernet de administración (fxp0 en este ejemplo) en ambos motores de enrutamiento. La dirección asignada utiliza la palabra clave solo maestra y es idéntica para ambos motores de enrutamiento, lo que garantiza que se pueda acceder a la dirección IP del motor de enrutamiento principal en cualquier momento. La dirección solo está activa en la interfaz Ethernet de administración del motor de enrutamiento principal. Durante un cambio de motor de enrutamiento, la dirección se mueve al nuevo motor de enrutamiento principal.
Por ejemplo, en re0, la configuración es:
[edit groups re0 interfaces fxp0]
unit 0 {
family inet {
address 10.17.40.131/25 {
master-only;
}
address 10.17.40.132/25;
}
}
En re1, la configuración es:
[edit groups re1 interfaces fxp0]
unit 0 {
family inet {
address 10.17.40.131/25 {
master-only;
}
address 10.17.40.133/25;
}
}
Para obtener más información acerca de la configuración inicial de motores de enrutamiento duales, consulte la Guía de instalación y actualización del software Junos OS. Para obtener más información acerca de cómo asignar una dirección IP adicional a la interfaz Ethernet de administración con la palabra clave solo maestro en ambos motores de enrutamiento, consulte la Guía del usuario de la CLI de Junos OS.
Ver también
Copiar un archivo de configuración de un motor de enrutamiento a otro
Puede utilizar el puerto de consola o el puerto Ethernet de administración para establecer la conectividad entre los dos motores de enrutamiento. A continuación, puede copiar o utilizar FTP para transferir la configuración de la copia de seguridad principal a la copia de seguridad, cargar el archivo y confirmarlo de la forma normal.
Para conectarse al otro motor de enrutamiento mediante el puerto Ethernet de administración, emita el siguiente comando:
user@host> request routing-engine login (other-routing-engine | re0 | re1)
En un enrutador TX Matrix, para establecer conexiones con el otro motor de enrutamiento mediante el puerto Ethernet de administración, emita el siguiente comando:
user@host> request routing-engine login (backup | lcc number | master | other-routing-engine | re0 | re1)
Para obtener más información sobre el request routing-engine login comando, consulte el Explorador de CLI.
Para copiar un archivo de configuración de un motor de enrutamiento al otro, ejecute el file copy comando:
user@host> file copy source destination
En este caso, source es el nombre del archivo de configuración. Estos archivos se almacenan en el directorio /config. La configuración activa es /config/juniper.conf, y las configuraciones anteriores están en /config/juniper.conf {1...9}. El destination es un archivo en el otro motor de enrutamiento.
En el ejemplo siguiente se copia un archivo de configuración del motor de enrutamiento 0 al motor de enrutamiento 1:
user@host> file copy /config/juniper.conf re1:/var/tmp/copied-juniper.conf
En el ejemplo siguiente se copia un archivo de configuración del motor de enrutamiento 0 al motor de enrutamiento 1 en un enrutador TX Matrix:
user@host> file copy /config/juniper.conf scc-re1:/var/tmp/copied-juniper.conf
Para cargar el archivo de configuración, escriba el load replace comando en el nivel de [edit] jerarquía:
user@host> load replace /var/tmp/copied-juniper.conf
Asegúrese de cambiar las direcciones IP especificadas en la configuración de la interfaz Ethernet de administración en el motor de enrutamiento 0 a las direcciones adecuadas para el motor de enrutamiento 1.
Ver también
Carga de un paquete de software desde el otro motor de enrutamiento
Puede cargar un paquete desde el otro motor de enrutamiento en el motor de enrutamiento local mediante el comando existente request system software add package-name :
user@host> request system software add re(0|1):/filename
En la parte re de la dirección URL, especifique el número del otro motor de enrutamiento. En la filename parte de la dirección URL, especifique la ruta de acceso al paquete. Los paquetes suelen estar en el directorio /var/sw/pkg.