Escrito por The Evangelist el 19 de Agosto de 2008 y etiquetado como: Cisco, IOS, Networking
Una de las cosas que echaba en falta en el IOS al venir del JunOS es el backup de configuraciones (aunque tanto en JunOS como IOS uso Rancid) pero desde la versión 12.3 hay disponible un comando de IOS que permite hacer copia de seguridad de las configuraciones. El comando en cuestión es archive y aunque tiene varias opciones aquí solo voy a exponer algunas con varios ejemplos.
El único requerimiento mínimo es el camino donde se van a guardar las copiar de la configuración, que puede ser en el mismo router (flash) o fuera del mismo (usando HTTP, FTP, RCP, o TFTP), por supuesto la recomendación es guardar las configuraciones fuera del router por si falla la flash o el propio router en sí.
Para configurar sus opciones debemos entrar en el modo global de configuración en donde tenemos las siguientes opciones:
Router(config-archive)#?
Archive configuration commands:
default Set a command to its defaults
exit Exit from archive configuration mode
log Logging commands
maximum maximum number of backup copies
no Negate a command or set its defaults
path path for backups
rollback Rollback parameters
time-period Period of time in minutes to automatically archive the
running-config
write-memory Enable automatic backup generation during write memory
A destacar especialmente en entornos donde varias personas hacen modificaciones es la opción “write-memory” que genera una copia cada vez que se guarda la configuración con lo cual siempre que se haga cambios tendremos una copia aunque puede generar muchas copias si se producen muchos cambios constantemente, además también destacar “time-period” que hace una copia cada cierto tiempo (aunque para esto prefiero más Rancid) y “maximum” que limita el número de copias a realizar, aunque es recomendable realizar el control de borrado externamente o incluso borrar a mano cuando haya muchas copias, hoy en día un disco duro es muy barato y nunca se sabe cuando nos puede hacer falta una copia de hace tiempo.
Un pequeño ejemplo:
R0#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R0(config)#archive
R0(config-archive)#path disk0:R0
R0(config-archive)#wri
R0(config-archive)#write-memory
R0(config-archive)#end
Con esto conseguimos que cada vez que se guarde la configuración haga una copia en “disk0” con el nombre del propio router “R0” al cual añadirá “-número” (-1, -2, -3, etc) por cada copia que haga.
R0#dir disk0:
Directory of disk0:/
1 -rw- 839 Aug 17 2008 22:27:08 +00:00 R0-1
Si lo que queremos es guardar una copia en un servidor TFTP remoto podemos hacer lo siguiente:
R0(config-archive)#path tftp://10.10.10.10/R0/copia
con lo que irá guardando copias (copia-1, -2, -3, etc) en el servidor con IP 10.10.10.10 dentro del directorio llamado “R0″ (el mismo nombre que el router para una localización posterior rápida).
Dos parámetros no mostrados en la ayuda por defecto dentro de PATH son “$h” que indica el nombre del router y “$t” que indica la fecha y hora del router, con lo cual podemos hacer una mini plantilla para todos los routers usando esas variables, así el anterior ejemplo podría convertirse en:
R0(config-archive)#path tftp://10.10.10.10/$h/$t
Para ver las copias que hay además ver la unidad donde se guardan (dir disk0 en el caso anterior) podemos usar:
R0#show archive
There are currently 3 archive configurations saved.
The next archive file will be named disk0:R0-3
Archive # Name
0
1 disk0:R0-1
2 disk0:R0-2 <- Most Recent
3
4
5
6
7
8
9
10
11
12
13
14
También nos puede interesar ver que diferencias hay entre una copia y otra para saber que se ha modificado o que hay de diferente (especialmente útil en entornos donde varias personas modifican) y podemos ver las diferencias de 2 formas:
differences muestra las diferencias entre las dos configuraciones, ya sea una copia y la actual o entre 2 copias.
incremental-diffs muestra las líneas del fichero de configuración que se añadirán a la running-config.
R0#show archive config differences disk0:/R0-1 disk0:/R0-3
Contextual Config Diffs:
interface FastEthernet0/0
-description prueba
Indica que “description prueba” en R0-1 no está y en R0-3 si, en caso contrarío en vez de un digno “-” sería un signo “+”. Si se omite “disk0:/R0-3″ se compara “disk0:/R0-1″ con la configuración actual (que en este caso es la misma que disk0:/R0-3 porque se acaba de generar).
Escrito por The Evangelist el 12 de Agosto de 2008 y etiquetado como: Cisco, Dynamips, gns3, Networking
Hacía ya mucho que no probaba la utilidad de Cisco para hacer laboratorios llamada Packet Tracer pero han anunciado hace pocos días la nueva versión 5.0 y me he decidido a probarla. La verdad es que la versión 4.0 y 4.1 no me dejaron un bien sabor de boca y la verdad es que ignoré por completo esta utilidad sobre todo desde que conocí dynamips. He de reconocer que esta versión me está dejando muy buen sabor de boca especialmente ahora que estoy mirando la curricula de CCNA 4.0 y que viene repleta de actividades muy interesantes y muy prácticas relacionadas y para hacer con el Packet Tracer (y que en posteriores artículos iré comentando).
Iré ampliando este artículo e incluso iré escribiendo otros según vaya conociendo mejor esta utilidad, pero si quiero comentar una de las posibilidades y enlaces con la curricula CCNA que he probado hoy. En la curricula CCNA 4.0 exploration vienen unos ficheros para el Packet Tracer que son actividades para configurar routers y switches y según vamos avanzando nos va indicando el progreso en tanto por ciento y al final de la actividad podemos ver si está correcto o no y en que hemos fallado con lo cual podemos seguir las actividades y quedarnos tranquilos de si lo hemos hecho bien o no (ver captura 1).
Captura 1: 
Como se puede ver en la captura 2 podemos hacer laboratorios bastante decentes aunque la disponibilidad de switches (2950-24, 2950T, 2960, genérico) y routers (1841, 2620, 2621, 2811, genérico) es limitada y no podemos elegir la versión de IOS (cosa que si se puede en dynamips).
Captura 2: 
Si pinchamos en un dispositivo (ya sea router, switch, etc) no sale un ventana con tres pestañas, Physical, Config y CLI, la cuales nos permiten configurar el dispositivo como si fuera uno físico. El CLI es realmente un CLI real, funciona el autocomplementar (usando el tabulador) e incluso funciona la ayuda (tecleando ?).
En las capturas 3 y 4 podemos ver la ventana del dispositivo (al hacer click sobre él) donde la captura 3 es la parte física del dispositivo en la cual podemos hacer zoom a la imagen del mismo y nos da información de los módulos y conexiones que tiene. En la captura 2 tenemos el CLI que es lo mismo que si nos conectamos a la consola.
Captura 3: 
Captura 4: 
En definitiva creo que hay que darle una oportunidad a esta utilidad de Cisco orientada con fines educativos, especialmente mirando a las certificaciones de Cisco. La única pega es que no está disponible de forma libre, es decir que si no estás en un curso de cisco no tienes acceso a ella, la verdad es que desconozco los requisitos para utilizar la herramienta, pero sé que está disponible en la web cisco.netacad.net una vez que te autenticas y entras en un curso o currícula.
Los que tengáis acceso a la web de Cisco podéis descargar el Packet Tracer desde este enlace en sus versiones para Windows o Linux, esperemos que Cisco se dé cuenta de los muchos ingenieros de red que usamos OSX y saque una versión para OSX, ya no solo de esta utilidad si no de otras muchas.
Escrito por The Evangelist el 9 de Agosto de 2008 y etiquetado como: Juniper, JunOS, Networking
Siguiendo con los magníficos artículos de Jeff Doyle sobre el Juniper y JunOS aquí tenéis la traducción de otro artículo más (original aquí).
Una de mis quejas durante mucho tiempo acerca de IOS es que si se escribe un nuevo comando en el CLI y pulse Enter, el comando de inmediato se convierte en activo en el router. Para alguien propenso a error, como yo (Jeff), este es un gran riesgo. Y dado que la mayoría de problemas de red se deben a un error humano en lugar de fallos de hardware y software, es un riesgo para todos.
Esto también puede ser un problema cuando se está haciendo cambios de configuración. Al tener estos cambios surtan efecto un comando cada vez, puede introducir todo tipo de condiciones transitorias.
La configuración candidata y aplicación de la configuración explicitamente
Esto lleva, por el contrario, a uno de mis características favoritas de JunOS: Cuando se hace un cambio de configuración, el cambio no surtirá efecto de inmediato. En lugar de ello, va a un archivo de configuración candidata. Se puede añadir, borrar y/o cambiar cuanto desee en la configuración, y ninguno de ellos serán activos en el router hasta que se confirme (commit). Este comando (commit) hace que la configuración candidata se convierta en la configuración activa.
La configuración candidata y la confirmación explícita (de la configuración) ayuda enormemente a reducir el número de simples errores humanos que afectan día a día a las operaciones de red. Se pueden hacer todos los cambios, comprobar como tantas veces como desee durante el proceso de configuración, y sólo se aplican cuando esté listo y estemos seguros de los cambios de configuración se ven correctos.
Rollback (marcha atrás)
Por supuesto, aún existe la posibilidad de que después de aplicar la configuración candidata el resultado no es lo que esperaba, y que desea volver a una configuración anterior. Se puede hacer eso en JUNOS ya que cuando se hace una confirmación y la configuración candidata se convierte en la configuración activa, la anterior configuración se guarda en el disco duro en el router.
Así que si quiere volver a una configuración anterior, puede introducir el comando rollback 1 y la más configuración reciente guardada se convierte en la configuración candidata. A continuación, se puede hacer que la configuración anterior sea activa de nuevo mediante la introducción del comando commit.
JUNOS guarda los últimos 49 archivos de configuración. Cuando se confirma (commit) una nueva configuración, la configuración activa anterior se guarda como juniper.conf.1. Lo que fuera juniper.conf.1 se convierte en juniper.conf.2, lo que fuera juniper.conf.2 se convierte en juniper.conf.3, y así sucesivamente. Así que si quiere volver a alguno configuración más antigua que la guardada más reciente, puede hacerlo. Por ejemplo, si introduce rollback 3, juniper.conf.3 - la configuración que estaba activa antes de las tres últimas confirmaciones (commit) - se carga como la nueva configuración candidata.
Aplicar la configuración confirmando (commit confirmed)
Supongamos que, a pesar de todos los esfuerzos para asegurar que la nueva configuración es correcta antes de aplicarla, algo se pasa por alto y cuando se aplica, que se queda el router bloqueado.
En lugar de aplicar (commit), se puede hacer la configuración candidata activa con este comando commit confirmed. Con este comando, el router espera 10 minutos para una segunda confirmación. Si no recibe confirmación dentro de los 10 minutos, el router automáticamente hace un rollback y se aplica, de manera que la configuración anterior se activa de nuevo.
El comando commit confirmed puede ser un salvavidas, recomiendo que se tenga el hábito de utilizarlo en vez de commit en todos los casos.
Puede cambiar el valor de tiempo por defecto que JUNOS espera para aplicar una confirmación entre 1 y 65535 minutos. Si, por ejemplo, se desea que el router espere tan solo 3 minutos para una confirmación, se puede introducir commit confirmed 3.
Guardar y cargar (save y load)
La configuración candidata es también una gran característica para hacer las ventanas de mantenimiento vayan más rápidas. Imaginamos que necesitamos hacer cambios a 10 routers con un mantenimiento programado a las 2 de la madrugada. Podemos hacer los cambios antes de lo previsto en el archivo de configuración candidata y, a continuación, guardar el archivo bajo cualquier nombre que se desee, ya sea en el router el disco duro o en un servidor externo.
Cuando llegue la hora de llevar a cabo el mantenimiento, puede cargar el archivo de configuración de vuelta al fichero de configuración candidata y confirmar.
Por ejemplo, si se realiza un cambio de la configuración pre-mantenimiento y se desea guardar como Juniper3_10August_Change, se introduce el comando save Juniper3_10August_Change.
Después de salvar, es una buena idea hacer un rollback 0. Esto causa una copia de la configuración actualmente activa (juniper.conf.0) para ser la configuración candidata, evitando así una situación en la que alguien más podría entrar en el router y aplicar estos cambios antes de la hora.
Ten en cuenta que si nos encontramos en la parte superior de la jerarquía de configuración, indicado por [edit], se guarda toda la configuración. Si se está en algún nivel inferior al salvar, sólo se guarda la parte de la configuración a ese nivel. Por ejemplo, si se está en [edit protocols bgp], sólo se guarda la configuración de BGP.
Cuando se esté listo para hacer los cambios en la configuración permanente, se carga la configuración guardada a la configuración candidata con el comando load. Este comando tiene varias opciones, dependiendo de cómo se desea utilizar el archivo que se carga:
- load override sustituye completamente la configuración actual candidata con el archivo que está cargando. Por lo tanto, si ha guardado una configuración completa, esta es la opción de usar.
- load merge añade el archivo guardado a la configuración candidata actual. Esto es útil si va a añadir nuevas secciones de configuración, por ejemplo, si añade una configuración BGP a [edit protocolo], donde no había ninguna configuración antes de BGP.
- load update se compara la configuración candidato y el archivo que se carga, y sólo cambia la parte de la configuración candidata que sean diferentes de la nueva configuración. Se podría utilizar esto, por ejemplo, si existe una configuración de BGP y el archivo que va a cargar hace cambios de alguna manera.
- load replace busca las etiquetas que se han añadido al fichero que se carga, y sustituye las partes de la configuración candidata con todo lo que se especifica después de la etiqueta. Esto es útil cuando se desea más control sobre exactamente qué se está cambiado.
Después de la operación de carga, se puede comprobar la configuración candidata nueva para asegurarse que muestra los cambios que se desean y, a continuación se aplican (commit).
Hay un enfoque alternativo a la operación que se acaba de describir. Se puede hacer cambios a la configuración candidato y luego usar el comando commit, especificando la hora y el minuto más tarde el mismo día, o especificar una fecha posterior, hora y minuto. Por ejemplo, se podría aplicar commit 2008-09-21 02:30:00 y no se aplicaría hasta las 2:30 AM del 21 de septiembre de 2008 (suponiendo que el tiempo es en el futuro, de acuerdo con la fecha y hora del router).
Personalmente no me gusta este comando, ya que deja demasiado a la automatización. Prefiero grabar y cargar (save y load), lo que da un mayor control de la operación
Escrito por The Evangelist el 23 de Mayo de 2007 y etiquetado como: Consola, Hardware, Networking
Escrito por The Evangelist el 8 de Enero de 2008 y etiquetado como: Juniper, JunOS, Networking
Tener una copia de seguridad de la configuración del Junos es muy importante pero es aún más importante tenerla en un servidor remoto. El JunOS hace varias copia de seguridad en el propio sistema, para ser exactos 50 copias, la actual y las tres siguientes (1 a 3) en la Compact Flash (para tenerlas a mano rápidamente) y el resto (de la 4 a la 49) en el disco duro (para ahorrar espacio en la Compact Flash.
La actual y las tres siguientes las podemos ver:
user@router> file list /config [detail]
/config:
juniper.conf.1.gz
juniper.conf.2.gz
juniper.conf.3.gz
juniper.conf.gz
rescue.conf.gz
el resto:
user@rrouter> file list /var/db/config/ [detail]
/var/db/config/:
juniper.conf.10.gz
juniper.conf.11.gz
...
juniper.conf.48.gz
juniper.conf.49.gz
juniper.conf.5.gz
juniper.conf.6.gz
juniper.conf.7.gz
juniper.conf.8.gz
juniper.conf.9.gz
En ambos casos podemos usar el parámetro “detail”para ver en más detalle los atributos de los fichero, al más puro estilo unix.
Otra forma de obtener una copia de la configuración, esta vez fuera del router en un servidor remoto, es usando la siguiente instrucción desde el modo operacional:
file copy <fichero> <destination URL>
file copy /config/juniper.conf.gz server:nombre_fichero_configuración
file copy /config/juniper.conf.gz ftp://user:pass@server:nombre_fichero_configuración
El primero copia vía ssh y el segundo vía ftp.
Desde el modo configuración podemos guardar la configuración completa o una parte, según estemos en la raíz [edit] o en alguna sección concreta con lo cual SOLO guardará dicha sección completa.
Para guardar la configuración completa en modo configuración:
[edit]
user@router# save server:nombre_fichero_configuración
user@router# save ftp://user:pas@server:nombre_fichero_configuración
o Si solo queremos guardar por ejemplo la configuración de BGP:
[edit protocols bgp]
user@router# save server:nombre_fichero_configuración
user@router# save ftp://user:pas@server:nombre_fichero_configuración
Todos estos métodos son manuales , pero si queremos hacerlo de forma automáticamente tenemos 2 posibilidades. La primera es hacer una copia de la configuración cada vez que hagamos un “commit” (del tipo que sea) con lo cual siempre tendremos una copia en un servidor remoto con cada cambio realizado:
[edit]
user@router# set system archival configuration transfer-on-commit
user@router# set system archival configurationarchive-site ftp://user:pass@server:/directorio_donde_dejar_las_copias
El otro método es similar pero hace la copia cada un intervalo de tiempo especificado, ya se hayan hecho modificaciones o no, con lo cual podemos tener varias copias idénticas de la configuración por lo que se recomienda poner algún tipo de cron que rote las configuraciones o borre antiguas a menos que tengamos bastante espacio (aunque los ficheros no ocupan demasiado):
[edit]
user@router# set system archival configuration transfer-interva intervalo
user@router# set system archival configurationarchive-site ftp://user:pass@server:/directorio_donde_dejar_las_copias
intervalo puede ser desde 15 minutos hasta 2.880 minutos (48 horas) y se debe especificar en minutos.
NOTA: una gran desventaja de estos dos últimos métodos es que se debe usar el método de transferencia de FTP y por lo tanto la clave queda en la configuración sin cifrar por lo que es visible a simple vista.
Como método alternativo y ajeno a la configuración del JunOS es utilizar la heramienta libre de código abierto llamada RANCID muy utilizada para copias de seguridad de dispositivos de red de diersas marcas.
Escrito por The Evangelist el 8 de Junio de 2008 y etiquetado como: Aplicaciones, Networking, OSX
Estupendo programa para hacer diagramas de red tipo Visio (aunque no llega al nivel del Visio, una pena que no haya Visio para OSX). No es una aplicación barata así que muchos no podrán trabajar con ella a nivel personal. Aunque importa diagramas de Visio, deben estar en XML por lo que en Visio es necesario exportar a XML extensión VDX, lo cual es un poco engorro y algún fichero gordo puede dar problemas de importación.
Entre sus características están:
- Bibliotecas de formas muy detallada.
- Esnanea la LAN de forma automática y hace un diagrama.
- Estima la longitud de cable.
- Calculadora de máscara de subred
- Múltiples capas para separar las diferentes áreas de visibilidad.
- Exportación a formatos gráficos, PDF, Power Point, Flash, HTML y con hipervínculos.
- Custom propiedades para almacenar información detallada sobre los equipos de red.
- Hay versiones tanto Win como MAC OSX
La página oficial: http://www.conceptdraw.com/en/products/netdiagrammer/main.php
Capturas:
Escrito por The Evangelist el 22 de Junio de 2008 y etiquetado como: Cisco, IOS, Networking
Muchas veces de las que hacemos un “show running-config” o lo que es más a menudo “sh run” no queremos ver todo si no un parte de la configuración, para ello hay algunos atajos muy útiles que no siempre se recuerdan:
-
show run interface:
router# sh run int fa0/0
Building configuration…
Current configuration : 93 bytes
!
interface FastEthernet0/0
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto
end
-
show run | section:
router#sh run | section interface
interface FastEthernet0/0
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto
interface FastEthernet1/0
ip address 192.168.4.1 255.255.255.0
duplex auto
speed auto
-
show run | begin :
router#sh run | begin interface
interface FastEthernet0/0
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 192.168.4.1 255.255.255.0
duplex auto
speed auto
!
ip http server
no ip http secure-server
ip classless
!
control-plane
!
!
–More–
-
show run | include:
router# sh run interface f0/0 | include ip
ip address 10.1.1.1 255.255.255.0
-
show ip interface brief:
router#sh ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 10.1.1.1 YES manual up up
FastEthernet1/0 192.168.1.1 YES manual up up
-
Mientras se está haciendo un “sh run” se puede usar el carácter / para hacer una búsqueda específica:
router#sh run
Building configuration…
Current configuration : 663 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname blog_demo
!
boot-start-marker
boot-end-marker
!
!
memory-size iomem 5
no aaa new-model
ip subnet-zero
!
!
!
!
ip cef
ip ips po max-events 100
/192.168
filtering…
ip address 192.168.4.1 255.255.255.0
duplex auto
speed auto
!
ip http server
NOTA: Extraído de “http://www.globalconfig.net/brandons_blog/2008/06/shortucts.html“
Escrito por The Evangelist el 21 de Febrero de 2008 y etiquetado como: Networking, Ripe
Como consultar la base de datos de ripe
Podemos hacerlo desde la web http://www.ripe.net/fcgi-bin/whois o desde la shell con la orden whois.
Las consultas que se hacen vía web en la shell se deben poner entre comillas y ejecutarlas de la siguiente manera:
whois -h whois.ripe.net — “CONSULTA”
Consultas últiles:
Listar TODOS los objetos que sean del nick-handle ABC-RIPE
whois -h whois.ripe.net -- "-B -r -i admin-c,tech-c,zone-c ABC-RIPE"
Listar TODOS los objetos mantenidos por el maintainer XYZ-MNT
whois -h whois.ripe.net -- '-B -i mnt-by XYZ-MNT'
Escrito por The Evangelist el 9 de Enero de 2008 y etiquetado como: Debian, Linux, Networking
Por defecto el paquete de netatalk de Debian (al menso en Etch) no viene con soporte de encriptación debido a las políticas de Debian, por lo que si usamos por ejemplo Leopard nos daremos cuanta que nuestro server de APF no funciona ya que Leopard obliga a las contraseñas vayan cifradas no en textos plano como en Tiger. Así que vamos a compilar nuestro propio paquete DEB de Netatlak con soporte de encriptación.
Primero nos vamos a un directorio temporal donde vamos a trabajar (luego se puede borrar a que solo es necesario para compilar):
mkdir /usr/src/netatalk
cd /usr/src/netatalk
Y procedemos a bajar los ficheros necesarios para compilar, primero comprobamos que tenemos las librerías y paquetes necesarios (puede que ya tengamos estos paquetes instalados, si es así seguimos):
apt-get install openssl cracklib2 libpam-cracklib cracklib2-dev wspanish
Nos bajamos el source de Netatalk (y sus ficheros complementarios .diff y .dsc):
apt-get source netatalk
Comprobamos que tenemos los paquetes requeridos para compilar el paquete Netatalk:
apt-get build-dep netatalk
Ya tenemos todo lo necesario para compilar, por lo que procedemos a modificar la configuración para indicarle que queremos soporte de encriptación:
cd netatalk-2.0.3/
vi debian/rules
Y añadimos la línea siguiente justo antes del comentario que dice ## FIXME:
DEB_BUILD_OPTIONS=ssl debuild
y solo nos queda compilar y que todo vaya bien:
dpkg-buildpackage
Si todo ha ido bien (seguro que si) en el directorio superior a donde estamos se habrá creado el paquete Debian del Netatalk con soporte de encriptación, así que lo instalamos:
dpkg -i netatalk_2.0.3-4_i386.deb
Escrito por The Evangelist el 7 de Diciembre de 2007 y etiquetado como: Juniper, JunOS, Networking
Procedimiento para borrar o cambiar la cable de root del JunOS de un Juniper. Probado en la Serie M.
- Conectado el router Juniper vía consola, arrancar o reiniciar y una vez que aparezca el trexto:
Hit [Enter] to boot immediately, or any other key for command
Booting [kernel] in 9 seconds...
Pulsar la barra espaciadora para que aparezca el promtp.
- Arranca en modo single-user:
Type '?' for a list of commands, 'help' for more detailed help.
ok boot -s
- El router juniper arranca y al final aparecerá el texto siguiente donde pulsaremos ENTER:
Enter full pathname of shell or RETURN for /bin/sh:
- Ahora debemos montar los sistemas de ficheros virtuales (para JUNOS 5.4 y superior, no es necesarios montar elpaquete jbase sin embargo los otros paquete aún son necesarios montarlos):
NOTE: to go to multi-user operation, exit the single-user shell (with ^D)
# cd /packages
# ./mount.jbase
Mounted jbase package on /dev/vn1...
# ./mount.jkernel
Mounted jkernel package on /dev/vn2...
# ./mount.jroute
Mounted jroute package on /dev/vn3...
- Después entramos en modo de recuperación:
# /usr/libexec/ui/recovery-mode
- Una vez aparezca el prompt del CLI entramos en el modo de configuración y podemos hacer dos cosas o borrar o modificar la clave de autenticación de rooti (en el ejemplo se borra la clave):
root> configure
Entering configuration mode
[edit]
root# delete system root-authentication
- Pocedemos a aplicar los cambios para que surtan efecto y salimos del modo de configuración:
[edit]
root # commit
commit complete
[edit]
root@router# exit
Exiting configuration mode
- Salimos del router donde nos pedirá que reiniciemos el router:
root@router> exit
- Exit recovery mode and enter “y” when prompted to reboot the system:
Reboot the system? [y/n] y
Terminated
El sistema reinicia y la clave de root ya no está (o si la cambiamos es la que es válida).
Extraido de “http://juniper.cluepon.net/index.php/Password_recovery“, traducido libremente por The Evangelist.
