vDay One: Mastering Junos Configuration (Edicion en Espanol)...técnicas de configuración, este lab...

Junos® Learning Sphere

Tanto si eres debutante en Junos

como si quieres perfeccionar tus

técnicas de configuración, este lab

basado en Junosphere impulsará tu

dominio de Junos OS.

por Antonio Sánchez-Monge

vDay One: mastering JUnOs COnfigUratiOn (eDiCión en españOl)

este libro de la colección vDay One trata de Junos y de toda la magia que puedes en-contrar en sus llaves {} de configuración. entra en Junosphere, carga el fichero de topología, mira los vídeos del libro y sencil-lamente copia los comandos de este pDf para ejecutarlos online en las máquinas virtuales de Junosphere. aprende haciendo, no leyendo.

Junosphere® proporciona un entorno económico y flexible en el que puedes crear y hacer funcionar redes en la nube. estas redes tienen prestaciones similares a las de un laboratorio con dispositivos físicos, y permiten realizar todo tipo de tareas, incuy-endo: diseño de redes, modelización, diag-nósticos, pruebas y formación.

Virtual Day One - ¡Aprende Haciendo! n experimenta la Cli de Junos con vídeos y

prácticas reales

n aprende a navegar por las jerarquías de Junos

n maneja técnicas de configuración básicas y

avanzadas

n Descubre los misterios del mecanismo interno

de rollback y commit

n entiende cómo Junos maneja configuraciones

simultáneas

n y mucho más en este lab de 3 horas

preparado para ti.

1 Vm • 3+ horas

¡Atrévete con el Reto del final del Libro!

los servicios en la nube de Juniper networks basados en Junosphere permiten a los profesionales de

redes y seguridad ejecutar planes de pruebas, diseñar, y formarse en un entorno virtual sin riesgos que

utiliza sistemas operativos reales. Junosphere te permite replicar redes físicas con dispositivos Junos Os y

herramientas de ecosistema, todo ello sin el coste, la complejidad y las limitaciones de un laboratorio físico.

para conseguir la mejor experiencia con Junosphere, comprueba que tienes las herramientas y la configuración

adecuadas. Considera estos programas opcionales freeware que facilitarán tu uso de Junosphere.

Configuración

necesaria

n sólo está soportado firefox 19 o superior así como internet explorer 9 o superior

n activa las ventanas emergentes (pop-up) en junosphere.net

n autoriza las descargas desde junosphere.net

n instala el plug-in más reciente de Java

Descargas

recomendadas

n RealVNC - Acceso remoto a servidores CentOS (no se utilizan en esta práctica)

n PuTTY - Cliente SSH/telnet para acceder a los terminales y consolas de los

dispositivos

n Notepad++ - Lector de ficheros de configuración

n FileZilla - Cliente FTP para transferir ficheros desde/hacia los dispositivos

n 7zip - Para crear y descomprimir conjuntos de ficheros de topología

n VMWare player - Para ejecutar el Connector (no se utiliza en esta práctica)

Recomendaciones de Hardware

CpU: procesadores de 1 gHz o más recomendados tanto para Windows como para mac.

memoria: se recomienda un mínimo de 256 mB de memoria ram disponible.

Calidad de Color: para obtener los mejores resultados usa 16-bit (8-bit, 24-bit, y 32-bit también están soportados).

resoluciones de pantalla: se recomienda 1,024 x 768 pixels; se soportan hasta 2,048 x 2,048.

Recomendaciones para PDF

Usa acrobat reader para obtener los mejores resultados al copiar y pegar los comandos y bloques de configuración de este libro en

el terminal Cli.

puedes consultar las actualizaciones más recientes en www.juniper.net/junosphere.

ISBN 978-1936779796

9 781936 779796

5 0 9 0 0

www.juniper.net/junosphere

1h 2h 3h

3

© 2013 por Juniper Networks, Inc. Todos los derechos reservados.

Juniper Networks, el logo de Juniper Networks, Junos, Junosphere, NetScreen, y ScreenOS son marcas registradas de Juniper Networks, Inc. en los Estados Unidos y en otros países. Todas las demás marcas son propiedad de sus propietarios respectivos.

Juniper Networks no asume ninguna responsabilidad por las imprecisiones que pueda contener este documento. Juniper Networks se reserva el derecho de cambiar, modificar, transferir o revisar esta publicación sin previo aviso. Los productos fabricados o vendidos por Juniper Networks así como sus componentes pueden estar cubiertos por una o más de las siguientes patentes que son propiedad y/o licencia de Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, y 6,590,785.

Publicado por Juniper Networks Books: http://www.juniper.net/booksAutor y Editor de Vídeo: Antonio Sánchez-Monge Narración de Vídeo: Antonio Sánchez-Monge Revisión Técnica: Diogo MontagnerEditor Jefe: Patrick AmesRevisión de Edición en Español: Pilar Somohano J-Net Community Manager: Julie WiderISBN: 978-1-936779-79-6 (impreso) Impreso en USA por Vervante Corporation, www.vervante.com

Version History: v1 September 2013 2 3 4 5 6 7 8 9 10

Agradecimientos

El autor quiere agradecer: en primer lugar, a mi mujer Eva y a mis hijos Manuel y Lucas, por su amor y paciencia a pesar de todas las horas extra dedicadas a este proyecto. Patrick Ames por su ilimitada energía positiva y por su creatividad. Aleksey Mints por la integración de vDay One en mi entorno de pruebas favorito con diferencia: Junosphere. Julie Wider por su ayuda en la organización de la fase de beta, y por promover el programa en la comunidad J-Net. Diogo Montagner por la revisión técnica y por su participación en vDay One. Iván Puñal, por compartir su estudio de grabación. Dave Dugal por muchas cosas incluyendo su capacidad de hacerme sonreir. Pilar Somohano y Pablo Mosteiro por su apoyo honesto y su visión global. Levent Ogut por compartir una idea sobre el commit history. Y a mi padre por el esfuerzo que siempre pone en hacer que lo más complejo parezca simple, ¡espero haber aprendido la lección!

Un agradecimiento especial a los beta testers que probaron el material y nos ayudaron a mejorarlo. Para la versión en español, Daniel Toro y Pilar Somohano; y para la versión en inglés varios miembros del equipo Juniper Ambassador: Kevin Barker, Martin Brown, Nick Ryce, Steve Puluka y Victor González. Por último, me gustaría agradecer a todos mis clientes y compañeros de Juniper Networks en España que han promovido el material y han realizado el alpha testing, espe-cialmente: David Soriano (Telefonica), Alfredo Peláez (NSN), José Maroto (Tecnocom), Rubén Díaz (Acuntia), Rocío Benavente, Miguel Angel Rodríguez a.k.a. Miguelón, Iria Varela, José Cid, Manuel Cornejo, Francisco Sánchez, Manuel de Miguel, Oscar Díaz Poveda, Estefanía Rodríguez, Laura Serrano.

-- Antonio Sánchez-Monge, September 2013

q

vDayOne:MasteringJunosConfiguration(EdiciónenEspañol) 4

1h 2h 3h

Bienvenido a vDay One

Este libro vDay One proporciona un workshop práctico y virtual cuyos componentes son:

�� Vídeos: La mayoría de los capítulos contienen un enlace a un vídeo de YouTube que explica la metodología y los conceptos relevantes en detalle.

�� Un dispositivo Junos OS Real: La topología (de un único dispositivo) que se utiliza en este workshop está lista para arrancar en la Public Library de Junosphere. El término dispositivo se refiere a un router, un switch, o un firewall, etc. En este caso, el dispositivo es un VJX, pero los principios de configuración Junos OS que aprendes aquí se pueden aplicar a todas las plataformas físicas o virtuales que corran Junos OS.

�� Este Libro: Para mantener el foco en las tareas prácti-cas, este libro simplemente contiene un procedimiento para ejecutar en el laboratorio paso a paso, así como los enlaces a los vídeos que describen cada una de las prácticas.

Este libro vDay One cubre los aspectos más importantes de la configuración en Junos. Está dirigido a lectores que o bien son principiantes en Junos OS, o quieren perfeccionar su manejo de la configuración. Las técnicas descritas van desde la configura-ción básica a aspectos relativamente avanzados. Con las herramientas de este libro, serás un maestro de la base de datos de configuración de Junos OS.

Pre-requisitos

Las 3h00m de tiempo neto necesario para recorrer todo el material es sólo una estimación. Es recomendable que reserves más horas para poder hacer pausas, o para explorar algunos comandos o funcionalidades; o, si eres principiante en Junos OS

o en Junosphere, puedes necesitar más tiempo para asimilar el contenido. El modelo actual de reservas en Junosphere funciona por días, así que es flexible en este sentido.

Los pre-requisitos para este workshop virtual son:

�� Una cuenta Junosphere válida (http://www.junosphere.net). Para comprar Junosphere con un descuento especial, ve a https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5735 y utiliza el código promocional jun3928 , válido sólo para Junosphere CLASSROOM (no para LAB).

�� Necesitas tener permisos de administración en tu terminal para instalar el programa Network Connect, que se descarga en la primera conexión a Junosphere. Aunque normalmente la instalación funciona bien al primer intento, algunos usuarios han tenido que reintentarlo una o dos veces, para que finalmente funcione.

�� No es posible ejecutar dos instancias simultáneas de Network Connect, así que si ya tienes una instancia de Network Connect corriendo para dar acceso a una VPN corporativa, la debes parar primero.

�� Network Connect funciona mejor sin proxies web, aunque también soporta configuración de proxy estática. Sin embargo, no funciona si el navegador está configurado con un fichero PAC (Proxy Auto-Configu-ration).

��IMPORTANTE�� Al principio de este documento puedes encontrar las recomendaciones de navegador web, sistema y aplicaciones para Junosphere.

PISTA Si vas a copiar y pegar bloques de comandos o de configuración directamente desde el PDF al terminal, la experi-encia pasada muestra que Acrobat Reader funciona mejor que otros lectores de PDF - éstos últimos pueden juntar varias líneas en una sola.

q

https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5735


1h 2h 3h

1. Iniciando el Escenario de Pruebas

Inicia tu dispositivo Junos OS siguiendo las instrucciones del Vídeo 1, y comprueba que el fichero topology.vmm correspon-de a la Figura 1.

Figura�1� Topología�Física�de�la�VM�(Virtual�Machine)

Aunque el Vídeo 1 muestra cómo arrancar una topología de 7 VMs de otro libro vDay One, el proceso para iniciar la to-pología de 1 VM de este libro es muy similar. Asegúrate de que cargas la topología de 1 VM llamada vDay One: Mastering Junos Configuration. La puedes encontrar en la Public Library llamada Day One Books en Junosphere.

El Vídeo 1 también muestra cómo descargar un fichero llama-do Mastering_Junos_Configuration.zip, que puedes examinar si eres curioso y quieres entender algo de la magia que hay detrás de Junosphere. Este fichero .zip contiene a su vez los siguientes ficheros:

�� topology.vmm , que especifica la manera en la que el dispositivo Junos OS - o Virtual Machine - está físicamente conectado.

�� myJunos.conf es una configuración sencilla de Junos OS que cargarás más adelante en la Sección 2.

�� ge-mtu.slax es un Commit Script de muestra, que usarás en la Sección 10.

��CONSEJO�� ¿LAB o CLASSROOM? Hay dos tipos de sandbox: LAB y CLASSROOM. Las topologías de vDay One están disponibles para ambos. Asegúrate de que eliges la topología apropiada para tu sandbox. Ten en cuenta que el código promocional sólo está disponible para CLASSROOM.

Video�1� Iniciando�la�VM�(¡haz�click�en�la�imagen!)

��IMPORTANTE�� El método de acceso varía a lo largo del libro. En la Secciones 2 y 3, y al principio de la Sección 4, necesitas conectarte a la consola del dispositivo Junos OS. En las secciones restantes, te conectarás mediante telnet a la IP de gestión.

TRUCO Si pierdes la conectividad a tu topología de Junosphere, ¡no te preocupes! Mientras tu reserva esté activa, la topología sigue corriendo, y sólo necesitas reconectarte.

¿MÁS?�� Para familiarizarte mejor con los conceptos de Junosphere y su GUI, mira los vídeos de la página https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5735.

q

https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=5735

http://youtu.be/GabMlQGCWUs


1h 2h 3h

2. Navegando por la Configuración de Junos OS

Vamos a empezar cargando una configuración Junos OS muy sencilla. A continuación la examinarás (sin modificarla) usando diferentes modos de línea de comandos (CLI).

Primero, conéctate a la consola del dispositivo, usando un cliente telnet:

telnet <IP> <port>

La dirección <IP> y el <puerto> están indicados en la columna Console, dentro de la pestaña Virtual Machines de la GUI de Junosphere. El usuario es root y la contraseña Clouds. ¿Por qué la consola, y por qué el usuario root? Porque vas a borrar en breve la mayor parte de la configuración, dejando a root como único usuario válido, y la consola como único método de acceso. El objetivo es conseguir una configuración muy breve y simple, que facilitará tu proceso de aprendizaje.

Cuando te conectas como root, el prompt es %, que correspon-de a la shell freeBSD. Este no es un modo soportado oficial-mente, así que necesitas iniciar una sesión de Junos OS CLI, lo que cambia el prompt a >.

% cli

>

En una máquina virtual VJX de Junosphere, la configuración inicial se puede especificar en el fichero topology.vmm de la siguiente manera:

install "ENV(HOME)/active/configset/<hostname>.conf" "/root/olive.conf";

Esta línea no está presente en tu fichero topology.vmm, y por esa razón el dispositivo arrancó inicialmente con la configura-ción de fábrica por defecto. Vamos a echar un vistazo a la configuración (en realidad, todavía no necesitas entenderla):

> show configuration

TRUCO Dale a la tecla tab (tabulador) a menudo. ¡Con respecto a otros sistemas operativos, permite autocompletar más palabras incluso que la barra espaciadora! Y, por supues-to, el signo de interrogación (?) te guiará en el camino.

¿MÁS? Si te apetece una introducción a la CLI de Junos OS en general, echa un vistazo a Day One: Exploring the Junos CLI. Lo puedes encontrar en la página principal de Day One (http:// www.juniper.net/dayone).

Estás a punto de reemplazar la configuración que está activa en este momento, por otra mucho más sencilla. Este comando muestra los contenidos de un fichero:

> file show /var/tmp/myJunos.conf

Más adelante en este libro, verás los comandos configure, load, save y commit explicados en detalle. El procedimiento siguiente guarda una copia de seguridad de la configuración en un fichero llamado original.conf, y a a continuación activa otra configuración completamente nueva y basada en el contenido de myJunos.conf:

> configure

# save /var/tmp/original.conf# load override /var/tmp/myJunos.conf# commit and-quit

ATENCIÓN A día de hoy, Junosphere no tiene ningún método para reiniciar (o resetear) conexiones de consola. Si por alguna razón perdieras conectividad con la consola antes de la mitad de la Sección 4, y no consiguieras reconectarte, necesitar-ías reiniciar la topología.

��IMPORTANTE�� Vamos a ver el vídeo 2. Pero es importante que lo veas en su totalidad antes de hacer la tarea práctica. Si ejecutas comandos antes de que acabe el vídeo (pausando y reanudándolo), la experiencia será mucho menos útil, por no mencionar las diferencias que puede haber entre el vídeo y la tarea práctica. Este consejo también es válido para los vídeos de los capítulos posteriores.

q


1h 2h 3h

Video�2� Navegando�por�la�Configuración�de�Junos�OS

Mira la configuración activa en modo operacional (prompt >):

> show configuration

> show configuration interfaces

> show configuration interfaces ge-0/0/1

> show configuration interfaces ge-0/0/1 unit 1

> show configuration interfaces ge-0/0/1 unit 1 vlan-id

¿Cómo se aplica esta configuración exactamente? Vamos a verlo:

> show interfaces terse lo0.0

> show interfaces terse ge-0/0/1

> show interfaces terse ge-0/0/1 routing-instance default

> show interfaces ge-0/0/1.1 | match vlan

¿MÁS?�� Puedes ignorar la interfaz ge-0/0/1.32767, que se crea automáticamente para la comunicación interna entre componentes del plano de control a través de la routing-in-stance __juniper_pri- vate1__, que es interna. Estos components están normalmente en tarjetas físicas diferentes. Pero no esta vez, ya que estamos en un entorno virtual.

��NOTA��Puede ser que aún veas una dirección IP asignada a ge-0/0/0, a pesar de no estar configurada. Puedes considerarla como parte de la infraestructura de Junosphere, y avanzar al siguiente paso.

Ahora vas a entrar en modo de configuración (prompt #). En este modo puedes modificar la configuración, pero de momento sólo la vas a ver:

> configure

# show

# show interfaces

# run show interfaces terse ge-0/0/1.1

PREGUNTA�#1 ¿Para qué sirve el comando run?

Ahora, sigue los pasos que aún no has ejecutado del Vídeo 2:

# show interfaces ge-0/0/1 unit 1

# show interfaces ge-0/0/1.1

# edit interfaces ge-0/0/1

# show

# show unit 1 vlan-id

# top

# edit interfaces lo0 unit 0

# show

# up

# show

# top show system

# top edit interfaces ge-0/0/1 unit 1

# edit vlan-id

Es normal ver un error en el último comando, ya que edit está diseñado para entrar en ramas, no en hojas. Dos comandos más y estarás listo para la siguiente Sección:

# up 2

# top

¡PRUÉBALO!��Puedes salir del modo de configuración con exit o quit. Estos comandos hacen lo mismo si los ejecutas desde la raíz del árbol. Pero no si lo haces desde una rama.

q

http://youtu.be/jsggfpo3gG0


1h 2h 3h

3. Editando la Configuración Candidata

Ya conoces los comandos: show, edit, up, top y run. Ahora vas a familiarizarte con otros comandos más potentes: set, delete, copy, rename, replace y insert. Como sus nombres sugieren, estos comandos se utilizan para modificar la configuración, si bien no actúan directamente sobre la configuración activa. En su lugar, realizan cambios sobre un borrador que suele llamarse configuración candidata o base de datos candidata. Por ejemplo, puedes añadir una nueva interfaz lógica con el comando set, pero esta nueva interfaz no se crea en el disposi-tivo mientras no confirmes (en inglés, commit) los cambios en la configuración activa. Esta Sección se centra en los comandos básicos que puedes utilizar para editar un borrador de configu-ración, mientras que los detalles del commit se dejan para la Sección 4.

Ahora veamos el Vídeo 3.

Video�3� Editando�la�Configuración�Candidata

Vamos a tomar contacto con set y delete. Ejecuta la secuencia siguiente, que no tiene como resultado ningún cambio neto de la configuración candidata, ya que el comando delete neutraliza los cambios iniciales:

# show interfaces ge-0/0/1

# set interfaces ge-0/0/1 unit 2 vlan-id 2


# edit interfaces ge-0/0/1

# show

# set unit 2 vlan-id 102

# show

# set unit 2 family inet address 10.2.2.1/30

# show

# set unit 2 family inet address 10.102.2.1/30

# show

# run show configuration interfaces ge-0/0/1

# delete unit 2

# show

PREGUNTA�#2 ¿Cuál es la diferencia entre el comando show en modo configuración, y el comando show configuration en modo operacional?

Como puedes comprobar, la secuencia de comandos siguientes - que introducen copy y rename - tampoco provoca ningún cambio neto en la configuración candidata: los estados inicial y final son idénticos.

# top

# copy interfaces ge-0/0/1 to ge-0/0/2

# show interfaces

# delete interfaces ge-0/0/1

# show interfaces

# rename interfaces ge-0/0/2 to ge-0/0/1

# show interfaces

Ahora ejecuta el bloque siguiente, que esta vez sí que tiene como resultado un cambio neto en la base de datos candidata. La clave aquí es que una interfaz lógica soporta varias direcciones IPv4:

# top


# show

# set family inet address 10.200.1.1/32

# show

q

http://youtu.be/Iw0EA44t6TI


1h 2h 3h

# delete family inet address 10.100.1.1/32

# show

# run show interfaces lo0.0 terse

PREGUNTA�#3 ¿Coincide la información proporcio-nada por los dos últimos comandos? ¿Por qué? Llamemos a estos dos comandos #1 (# show) y #2 (# run show interfaces lo0.0 terse), respectivamente.

Ahora sal del modo de configuración, y verifica que aún no ha habido ningún cambio en la configuración activa:

# exit

The configuration has been changed but not committed

Exit with uncommitted changes? [yes,no] (yes) yes

> show configuration interfaces lo0

Ninguno de los cambios realizados hasta ahora ha tenido como resultado un cambio en la configuración activa. De todos modos, vamos a volver al modo de configuración para deshacer los cambios realizados en la configuración candidata:

> configure


# rename family inet address 10.200.1.1/32 to address 10.100.1.1/32

# show

Ahora vamos a ver los riesgos del potente comando replace. La secuencia siguiente no provoca ningún cambio neto en la configuración candidata:

# top

# edit interfaces

# show

# replace pattern 1 with 2

# show


# show

# show | compare

# replace pattern 10.100.1.1/31 with 10.100.1.1/32

# show

# show | compare

PREGUNTA�#4��¿Qué hace el comando “show | compare”? Es normal que aún no sepas la respuesta, pero está bien que empieces a acostumbrarte a este comando.

Por último, usa el comando insert. Cambiar el orden relativo de direcciones IPv4 no es la aplicación más habitual de insert, comparado con reordenar términos dentro de un firewall filter o de una política de routing. Aun así, este ejemplo nos sirve para ilustrar el funcionamiento de insert:

# top


# show

# set family inet address 10.200.1.1/32

# show

# insert family inet address 10.200.1.1/32 before address 10.100.1.1/32

# show

RECUERDA ¡El tabulador te puede hacer la vida más sencilla!

¡PRUÉBALO! El comando edit también existe en modo operacional. Es similar a configure, y además te puede llevar a la rama que tú quieras.

q


1h 2h 3h

4. Confirmando los Cambios de Configuración

Ha llegado el momento de ver en detalle dos de los comandos más importantes y diferenciadores en la configuración de Junos OS: rollback y commit. Estos términos se usan en las bases de datos relacionales, y representan conceptos opuestos. Con rollback, descartas los cambios de configuración pendien-tes. La base de datos candidata pasa a ser idéntica a la configu-ración activa, que a su vez no experimenta ningún cambio. Con commit, activas los cambios de configuración copiando la base de datos candidata a la configuración activa.

Hasta ahora, has estado usando la conexión de consola. Ahora vas a hacer algunos cambios prácticos a la configuración, para que se pueda acceder al equipo mediante el tradicional telnet IPv4. Puedes empezar descartando todos los cambios de configuración pendientes:

# top

# rollback

# show | compare

# exit

El último “show | compare” debería estar vacío. Ahora, apunta la dirección IPv4 de la interfaz de gestión ge-0/0/0 (pero no intentes configurarla ya que está reservada a Junosphere):

> file show /var/tmp/original.conf | match address

> file show /config/mgmt.ipaddress

Y configura tu dispositivo para recibir conexiones telnet. En Junos OS, el usuario root puede acceder por SSH pero no por telnet. Por esta razón, necesitas configurar también un usuario adicional. Este es el procedimiento completo:

> configure

# set system services telnet

# set system login user vdayone class super-user authentication plain-text-password

New password: Clouds

Retype new password: Clouds# show | compare# commit and-quit

Ahora, desde otro terminal, prueba a hacer telnet al dispositivo usando la dirección que has anotado, así como el usuario y la contraseña que acabas de configurar:

telnet <address>

Username: vdayone

Password: Clouds

Echa un vistazo al Vídeo 4 para ver el proceso de commit en acción.

Video�4� Confirmando�Cambios�de�Configuración

Ahora vas a ver el commit en acción:

# set system host-name EVEREST# show | compare# commit

¡El prompt ha cambiado a EVEREST!

¿Qué ocurre exactamente durante una operación de commit? La secuencia en un dispositivo sin redundancia de plano de control (es decir, con 1 sola Routing Engine) es:

�� Primero, el demonio de gestión o management daemon (mgd) responsable de la sesión CLI donde se está realizando el commit, llama a todos los demonios o procesos de background que puedan estar afectados por el cambio de configuración. Así, mgd puede

q

http://youtu.be/5k_xBNCBWfg


1h 2h 3h

solicitar a los demonios de routing (rpd), firewall (dfwd), clase de servicio (cosd), interfaces (dcd), etc., que lean la configuración y la validen.

NOTA�� Un demonio es el nombre común de cualquier proceso de background en FreeBSD y en otros sistemas operativos basados en UNIX.

�� Cada uno de los demonios involucrados crea un proceso hijo mediante la llamada de sistema fork(). Estos procesos hijo se encargan de la tarea de vali-dación, mientras su proceso padre respectivo puede seguir realizando su tarea habitual. Cada demonio hijo inspecciona la parte de la configuración que considera relevante, y comprueba su consistencia - por ejemplo, una interfaz no puede tener un filtro aplicado si el filtro no está definido globalmente. Los procesos hijo devuelven el resultado de la validación a mgd, y desaparecen.

�� La validación sólo tiene éxito si todos los demonios hijo devuelven un resultado satisfactorio de su vali-dación a mgd. Si el comando commit se ejecuta con la opción check, sólo proporciona los resultados de la validación y finaliza sin confirmar ningún cambio. Del mismo modo, un commit normal (sin la opción check) no activaría ningún cambio si alguno de los demonios reportara un error de validación.

�� En este punto, si la validación se completa con éxito y la opción check no se está usando, mgd activa la configuración candidata, rota los ficheros de configu-ración como se detalla en la próxima sección, envía una señal SIGHUP a todos los procesos de background relevantes, y devuelve el prompt.

Los procesos de background relevantes (por sí mismos, no sus hijos) leen los cambios de configuración y ejecutan rutinas de reconfiguración. Estas rutinas pueden necesitar un tiempo significativo en dispositivos con un alto nivel de provisión. Por ejemplo, puedes ver el estado de la reconfiguración de rpd ejecutando el comando show task jobs después del commit, y buscando tareas de tipo reconfig.

5. La Historia de Commits en Junos OS

Junos OS es un sistema operativo avanzado. Junos OS guarda las últimas 50 configuraciones confirmadas, con la numeración #0 a #49, donde #0 es la configuración activa en el momento actual, y #49 es la que se confirmó hace 49 commits. Esta sección te muestra cómo sacar partido de dicha funcionalidad. Mira el vídeo 5 para aprender la teoría antes de pasar a la práctica.

Video�5� La�Historia�de�Commits�en�Junos�OS

Vamos a empezar descartando todos los cambios potenciales que pueda haber en la base de datos candidata, que a su vez pasa a ser idéntica a la configuración activa:

# rollback

# show | compare /* Debería estar vacío */

# show

Llegó el momento de ver la historia de commits en acción:

# show | compare

# show | compare rollback 1

# set system host-name K2

# show | compare

# commit

q

http://youtu.be/omuUP6g_M6g


1h 2h 3h

# set system host-name MAKALU

# show | compare

# commit

# set system host-name ANNAPURNA

# show | compare

# commit

# set system host-name CHO-OYU

# show | compare

# rollback

# show | compare

# set system host-name CHO-OYU

# commit comment "I like mountains"

# exit

> show system commit

> show system rollback 0

> show system rollback 1

> show configuration | compare rollback 1

> show system rollback 0 compare 1







> configure

# rollback 1

# show | compare

# commit

# rollback 1

# show | compare

# commit

# rollback ?




PREGUNTA�#5� ¿Cómo puedes volver a la configuración que contenía el host-name Everest, sin configurar el host-name explícitamente?

PREGUNTA�#6 ¿Cuál sería el resultado de ejecutar la secuencia: rollback 1 + commit, 999 veces? ¿Y 1000 veces?

El comando commit tiene varias opciones útiles. Por ejemplo, ya has probado la opción comment. Vamos a ver otras dos opciones muy útiles:

# set system host-name NANGA-PARBAT

# show | compare

# commit check

PREGUNTA�#7�� ¿Qué hace la opción check?# show | compare

# commit confirmed 1

Espera un par de minutos. ¿Qué ha pasado?

La opción confirmed es esencial cuando se van a realizar cambios arriesgados en la configuración, y se desea añadir una capa adicional de seguridad. Prácticamente cualquier ingeniero con experiencia directa en equipos de red ha visto cómo una sesión de CLI deja de responder de repente tras un cambio de configuración. La causa puede ser obvia (por ejemplo, si se apaga o deshabilita el puerto de gestión) o más sofisticada. En cualquier caso, si estás a punto de aplicar un cambio de configuración que pueda afectar tu sesión de alguna manera, la opción confirmed es tu aliada. Los cambios sólo se activan durante el tiempo especificado en minutos (10 por defecto), y si durante ese tiempo no ha habido más commits, el dispositivo vuelve automáticamente a la último configuración activa, con lo que la sesión CLI volvería a la vida en caso de haberse visto afectada.

ATENCIÓN� En dispositivos con redundancia de plano de control (más de una Routing Engine), la opción commit synchro-nize es clave, ya que permite tener los dos planos sincronizados por si hubiera una conmutación de plano de control. Puedes configurar set system commit synchronize para que esta opción se añada automáticamente en cada commit

q


1h 2h 3h

Por último, sube el host-name al pico más al alto de la Tierra:

# set system host-name EVEREST

# commit and-quit

Ejecuta estos dos comandos para encontrar la localización de la historia de commits en los sistemas de ficheros:

> file list /config/juniper* detail

> file list /var/db/config/ detail

Usa el comando file show para mostrar el contenido, ya descomprimido, de alguno de los ficheros listados arriba. Echa un vistazo también al fichero /var/db/commits, cuya primera columna representa las horas de commit en formato UTC.

¡PRUÉBALO!�� Lista el directorio /var/run/db y localiza dos ficheros binarios llamados juniper.data y juniper.db. Estas son las verdaderas bases de datos de configuración. No intentes mostrar su contenido, ya que están en formato binario. Sin embargo, si juegas con los comandos de configuración y observas las fechas de modificación de estos dos ficheros, serás capaz de decir cuál de ellos es la base de datos de configuración candidata, y cuál la activa.

¿MÁS?�� Los commits agrupados o en batch permiten encolar las operaciones de commit y agruparlas en una única oper-ación. Esto puede ser útil en dispositivos con un alto nivel de provisión. Para aprender más de esta funcionalidad, puedes mirar la documentación en Juniper Techpubs, www.juniper.net/techpubs.

¿MÁS?� En dispositivos con redundancia de plano de control, o con arquitectura multi-chasis, una optimización interesante es fast-synchronize.

6. Otras Vistas de la Configuración de Junos OS

La vista clásica de la configuración de Junos OS, con todas sus llaves {} mágicas, es práctica de visualizar y leer. Sin embargo, hay otros formatos más convenientes para determinados usos. En el Vídeo 6 puedes ver uno de los formatos más utilizados:

Video�6� Visualizando�la�configuración�en�formato�set

Ahora pruébalo tú:

> configure

# show interfaces lo0 | display set

# exit

> show configuration interfaces lo0 | display set

PREGUNTA�#8 ¿Es equivalente mostrar la configuración de loopback en modo operacional y de configuración?

Otra aplicación interesante del formato set es el siguiente:

> configure

# show interfaces | match address

# show | display set | match address

# show | match address | display set

q

http://youtu.be/Hvn1O4l1F4M


1h 2h 3h

Por último, aunque el formato XML no es el más sencillo de leer, es un formato abierto y estándar. Funciona con todas las librerías XML de la industria, y es esencial para todas las funcionalidades de Junos Automation, incluyendo los Commit, Event y Op Scripts:

# show interfaces | display xml

¿MÁS?��Lee el Day One: Navigating The Junos XML Hierar-chy en www.juniper.net/dayone.

¡Pausa para el Café!

Te has ganado un descanso. Tómate un café, agua, o estira tus piernas mientras piensas en las llaves {} mágicas.

7. Guardando y Cargando Bloques de Configuración y Parches

Muchas veces necesitarás manejar bloques de configuración de manera eficiente. Por ejemplo, si tienes la configuración completa o parcial de un dispositivo, y quieres aplicarla (tras adaptarla en un editor de texto) a otro equipo. O si necesitas deshacer o rehacer un cambio de configuración que hiciste en el commit #33. Y, por supuesto, para hacer copias de seguridad y restaurar configuraciones antiguas. Junos OS es muy potente y flexible en este sentido: ¡configurar grandes redes no es un gran reto con Junos OS!

En el Vídeo 7 puedes ver una muestra de las diferentes aplica-ciones:

Video�7� Manejando�Bloques�de�Configuración�y�Parches

En el primer ejemplo, vas a guardar toda la configuración activa en un fichero local que opcionalmente puedes transferir por FTP/SCP a un servidor externo. Después borrarás toda la configuración candidata para volver a cargarla, pero esta vez sin utilizar el comando rollback:

q¡Pausa para el Café!

http://youtu.be/Djz9oUHbb5Q


1h 2h 3h

# exit

> show configuration | save myFile1

> file show myFile1

> configure

# delete

This will delete the entire configuration

Delete everything under this level? [yes,no] (no) yes

# show

# show | compare myFile1

# load override myFile1

# show

# show | compare myFile1

La salida del último comando debería estar vacía, ya que no hay diferencias entre la configuración candidata y myFile1.

NOTA� Hasta ahora sólo hemos actuado sobre la base de datos candidata, ya que no hemos confirmado ningún cambio.

Ahora vamos a jugar con una parte concreta de la configuración. Esta vez vas a usar la opción merge en lugar de override, ya que la idea es añadir configuración sin destruir la existente. Al final del procedimiento siguiente deshaces los cambios iniciales, por lo que el resultado final coincide con la configuración original:

# show interfaces lo0

# show interfaces lo0 | save myFile2

# run file show myFile2

# delete interfaces lo0

# load merge myFile2

/* Es esperable ver un error aquí */


# edit interfaces lo0

# load merge myFile2

/* Es esperable ver un error aquí */

# show

# load merge myFile2 relative

# show

# top

Copia la salida del comando siguiente en un documento de texto (usa cualquier editor de texto externo), y mantén el documento abierto:

q


Ahora, borra la configuración de la interfaz lo0 y aplícala en formato de llaves:


# edit interfaces lo0

# show

# load merge terminal relative

Pega el contenido (original o ligeramente modificado) del docu-mento de texto en el terminal, y ejecuta ctrl-D. La configura-ción de lo0 debería estar de nuevo en sitio:

# show

NOTA Todas las opciones del comando load comentadas en este libro permiten la entrada de datos tanto por terminal como por fichero.

Una variante más:

# top

# show interfaces lo0 | display set | save myFile2-bis



# load set myFile2-bis


Y, por último, la opción más potente de todas (patch). Aunque pueda parecer extraño al principio, esta opción es de lejos la más útil cuando se trata de configurar o hacer evolucionar una red de manera incremental e interactiva con la CLI.


# replace pattern 10.100.1.1 with 10.200.1.1


# show | compare

# show | compare | save myFile3

# run file show myFile3

# rollback


# load patch myFile3


# show | compare

# rollback

# exit


1h 2h 3h

8. Configuraciones Simultáneas

Hasta ahora, sólo ha habido un usuario configurando el equipo: tú. En la vida real del laboratorio y de las redes de producción, es muy frecuente que haya varias personas, o incluso la misma persona (o sistema de provisión) en distintas sesiones, accediendo a la configuración a la vez. Garantizar la consistencia se convierte en un reto, y hay varias estrategias para afrontarlo. Mira el vídeo 8 y prepárate para la sesión práctica.

Video�8��Acceso�Simultáneo�de�Lectura�y�Escritura�a�las�Bases�de�Datos�de��Configuración

Conecta otra sesión CLI al dispositivo:

telnet <address>

Username: vdayone

Password: Clouds

TRUCO�� Puedes usar el comando operacional show interfaces terse ge-0/0/0 si no recuerdas la dirección IPv4 de gestión

Ahora tienes dos sesiones CLI (#1 y #2) conectadas al mismo equipo. Ambas sesiones estarán en modo de configuración a la vez.

IMPORTANTE Por defecto, el comando configure propor-ciona acceso directo de lectura y escritura a la base de datos candidata.

La base de datos candidata está compartida por toda las sesio-nes que acceden a ella. Con las instrucciones siguientes podrás comprobar el funcionamiento de este acceso compartido. Considera la línea vertical como el eje temporal. Sólo debes progresar a la línea siguiente si ambas sesiones ya han ejecutado la línea actual. Recuerda que estás simulando dos usuarios que están activos a la vez, así que con mucha frecuencia deberás cambiar de una sesión a otra durante esta práctica:

SESSION#1

@EVEREST> configure

@EVEREST# show system host-name

@EVEREST# set system host-name LHOTSE


@EVEREST# exit

The configuration has been changed but

not committed

Exit with uncommitted changes? yes

@EVEREST> configure


@EVEREST#


@EVEREST# show | compare

@EVEREST#

@K2# exit

@K2>

TRUCO Si ejecutas una secuencia set + delete cuyo resultado final es nulo, es decir, sin cambios pendientes por confirmar, la base de datos candidata puede quedarse con el flag de modificación puesto, incluso aunque la salida de “show | compare” esté vacía. En este caso, simplemente haz “rollback” y ya puedes salir limpiamente con “exit”.

Como viste en el vídeo, las sesiones en modo privado no tienen acceso directo a la base de datos de configuración compartida. ¡Compruébalo!

q

SESSION#2

@EVEREST> configure


@EVEREST#


@EVEREST# exit

The configuration has been changed

but not committed

Exit with uncommitted changes? yes

@EVEREST> configure


@EVEREST# set system host-name K2


@EVEREST# show | compare

@EVEREST# commit

@K2# exit

@K2>

http://youtu.be/nPZPiC5kDzE


1h 2h 3h

SESSION#1

@K2> configure private

@K2# show system host-name

@K2# set system host-name ANNAPURNA


@K2# exit

The configuration has been changed

but not committed

Discard uncommitted changes? yes



@K2# set system host-name ANNAPURNA


@K2# show | compare

@K2# commit

@ANNAPURNA#

@ANNAPURNA#

@ANNAPURNA# show system host-name

@ANNAPURNA#

@ANNAPURNA#

@ANNAPURNA#

@ANNAPURNA#

@ANNAPURNA#

@ANNAPURNA#

@ANNAPURNA#


@ANNAPURNA#

@ANNAPURNA#

@MAKALU# show system host-name

@MAKALU# exit

Ahora puedes experimentar con el modo exclusivo:

SESSION#1

@MAKALU> configure

@MAKALU# set system host-name ANNAPURNA

error: configuration database locked

@MAKALU# exit

Y, por último, veamos la interacción entre una sesión en el modo de configuración por defecto (con acceso a la base de datos de configuración compartida) y otra sesión en modo privado:

SESSION#1

@MAKALU> configure private

@MAKALU# set system host-name ANNAPURNA

@MAKALU#

@MAKALU# exit

�PISTA Si entras en el modo de configuración y ejecutas commit sin que haya ningún cambio pendiente de confirmar, pueden ocurrir dos cosas. En el modo de configuración por defecto, se lanza el procedimiento completo de commit (con la particulari-dad de que el número de demonios que se señalizan es mínimo), y tiene lugar una rotación de ficheros de configuración. Por otro lado, en el modo privado no ocurre nada y la sesión devuelve el prompt inmediatamente.

q

SESSION#2



@K2#


@K2#

@K2#


@K2#


@K2# show | compare

@K2#


@ANNAPURNA# set system host-name MAKALU


@ANNAPURNA# show | compare

@ANNAPURNA# commit

[edit system host-name]

‘host-name ANNAPURNA’

statement does not match patch:

’ANNAPURNA’ != ’K2’


@ANNAPURNA# show | compare

@ANNAPURNA# commit

@MAKALU# show system host-name

@MAKALU# exit

SESSION#2

@MAKALU> configure exclusive

@MAKALU# exit

SESSION#2

@MAKALU> configure

@MAKALU#

@MAKALU# set system host-name CHO-OYU

error: private edits in use. Try

‘configure private’ or ‘configure

exclusive’.

@MAKALU# exit


1h 2h 3h

9. Jerarquía en Acción

La configuración de Junos OS está muy lejos de ser un fichero de texto monolítico. En realidad, hay dos vistas llamadas pre-herencia y post-herencia. Cuando muestras la configura-ción, típicamente obtienes la vista pre-herencia. Pero cuando haces un commit, Junos construye la vista post-herencia. Diferentes vistas pre-herencia pueden resultar en la misma vista post-herencia. ¿De qué trata la herencia en este contex-to? Imagina que quieres borrar una interfaz de la configura-ción sólo de manera temporal. Si la borras con el comando delete, la interfaz desaparece completamente de la configura-ción. Pero también puedes desactivarla con el comando deactivate, y dejarla en la configuración con el flag de inactiva. Los dos comandos delete y deactivate sólo se diferencian en la vista pre-herencia. Una vez calculada la vista post-herencia, la interfaz desaparece de la vista. También tienes la posibilidad de definir ciertas estructuras llamadas grupos, que pueden aplicarse de manera jerárquica a varias partes de la configuración a la vez. En este sentido, las fases pre-herencia y post-herencia de la configuración se corresponden con el antes y el después de la aplicación de los grupos.

Mira el Vídeo 9 para ver estos conceptos en acción:

Video�9� El�Rol�de�la�Herencia�en�la�Configuración�de�Junos�OS

Uno de los comandos más útiles en Junos OS es deactivate. Este comando te permite suprimir una parte de la configuración desde el punto de vista operacional/funcional, pero sin borrarla. Para volver a activarla, el comando es simplemente activate. Com-pruébalo:

> configure


# show interfaces ge-0/0/1 | display inheritance

# deactivate interfaces ge-0/0/1



# run show interfaces ge-0/0/1 terse

# commit


# activate interfaces ge-0/0/1




# commit


Los grupos de configuración son otra técnica muy utilizada. Puedes verlos en acción aquí:

# set groups myMTU interfaces <ge-*> unit <*> family inet mtu 1600

Si quieres ver el comando anterior entero, cambia las propie-dades de la sesión ejecutando:

# run set cli screen-width 200

Ahora aplica a la jerarquía de interfaces el grupo que acabas de crear:

# show interfaces | display inheritance

# set interfaces apply-groups myMTU

# show interfaces

# show interfaces | display inheritance

# show interfaces | display inheritance no-comments

# show interfaces | display inheritance | display set

# show | compare

# commit check

q

http://youtu.be/smUgbqYGr2U


1h 2h 3h

El proceso de validación de la configuración ha detectado un error. La MTU (Maximum Transmission Unit) de la interfaz lógica en ningún caso puede sobrepasar la MTU de la interfaz física. Vamos a corregir la condición de error:


# commit check

Al final de la Sección 4, viste una lista de los pasos internos asociados a la operación de commit. En realidad, la herencia tiene lugar antes del paso 1. En otras palabras, mgd comienza el proceso de validación una vez que la configuración candidata ha sido procesada con display inheritance.

Durante el proceso de arranque de Junos OS se realiza un commit para activar el fichero de configuración /config/juniper.conf. La lógica de validación puede cambiar de una versión de Junos OS a otra. Así, es posible que una configuración dada pase la validación en la versión A con éxito, pero no en la versión B. En ese caso, una migración de A a B dejaría el dispositivo (al arrancar en la versión B) en un modo llamado Amnesiac, es decir, con la configuración activa vacía (factory defaults).

¿Cómo puedes sacar un dispositivo del modo Amnesiac? Solucionando la inconsistencia en la base de datos candidata y ejecutando commit. Sin embargo, esta operación es manual.

¿Cómo puedes evitar que un dispositivo entre en modo Amne-siac? El comando request system software add tiene la opción validate activada por defecto. Con esta opción, la configuración activa en ese momento pasa a ser validada por las rutinas de validación de la versión objetivo, comprobando si el commit tendría exito después de la migración.

ATENCIÓN� Si las versiones de Junos OS A y B están muy lejos entre sí desde el punto de vista del calendario de versiones, la validación no está garantizada. En concreto, la opción validate puede dar un error genérico aunque la configuración sea perfectamente válida para A y B. En este caso, necesitas saltarte la validación con la opción no-validate. Si es un equipo

de producción, intenta cargar antes la configuración activa en un equipo de laboratorio que esté corriendo la versión B, y comprueba que pasa el commit check.

¿MÁS?� Explora algunas aplicaciones del comando apply-path. Las puedes encontrar en Juniper Techpubs, www.juniper.net/techpubs.

10. Reglas de Ingeniería Personalizadas – Commit Scripts

YEn la Sección anterior viste cómo una inconsistencia en la configuración se detecta típicamente durante el proceso de validación (commit check). Sin embargo, el hecho de que una configuración sea completamente consistente y sintácticamente correcta desde el punto de vista de Junos OS, no te da ninguna garantía de que vaya a cumplir los requisitos del servicio concreto que estás desplegando. Por ejemplo, Junos OS permite que una interfaz esté configurada en ISIS aunque no lo esté en MPLS. Pero en tu red, podría ser obligatorio desde un punto de vista de diseño, activar MPLS en todas las interfaces que tengan IS-IS habilitado. Este tipo de reglas de ingeniería personalizadas se pueden definir y aplicar utilizando un elemento clave del conjunto de funcionalidades llamado Junos Automation: los commit scripts. Como administrador o arquitecto de red, decides qué condiciones tiene que cumplir una configuración candidata antes de someterla a la validación estándar de Junos OS.

Vamos a ver un ejemplo simple. Desde el punto de vista de Junos OS, poner la interfaz ge-0/0/1 con una MTU de 1400 es perfectamente válido, ya que la MTU lógica aplicada a ge-0/0/1.1 con los grupos de configuración es menor (1300):

# set interfaces ge-0/0/1 mtu 1400

# commit check

q

http://www.juniper.net/techpubs


1h 2h 3h

Sin embargo, decides aplicar una regla de ingeniería personal-izada que impide que la MTU física tenga un valor por debajo de 1500 bytes:

# run file show /var/db/scripts/commit/ge-mtu.slax

# set system scripts commit file ge-mtu.slax

# commit check

# rollback

# exit

Aunque la configuración es sintácticamente correcta desde el punto de vista de Junos OS, falla el proceso de validación porque no se cumple una regla de ingeniería personalizada que has definido.

Volviendo a la lista del final de la Sección 4, los commit scripts procesan la vista post-inheritance, antes del paso 1 de la lista. Es más, un commit script puede incluso modificar la configura-ción candidata altes de que comience el proceso de validación estándar de Junos OS (paso 1 de la lista).

¿MÁS?�� Los Commit Scripts en particular, y Junos Automa-tion en general, son un amplio conjunto de funcionalidades. Echa un vistazo a la colección de Day One Junos Automation en www.juniper.net/dayone.

Respuestas a Preguntas

ANSWER�#1�� El comando run permite ejecutar comandos operacionales sin salir del modo de configuración.

ANSWER�#2� El comando show en modo configuración muestra la configuración candidata, mientras que el comando show configuration en modo operacional muestra la configura-ción activa.

ANSWER�#3�� No, no coinciden. El comando #1 muestra la configuración candidata, mientras que el comando #2 muestra el resultado de aplicar la configuración activa.

ANSWER�#4� El comando show | compare compara la configu-ración candidata con la activa. Básicamente te dice qué cambi-aría en el dispositivo si ejecutaras commit.

ANSWER�#5 Con la secuencia de comandos siguiente:> configure

# rollback 6

# show | compare

# commit

ANSWER�#6� Ejecutar varias veces: rollback 1 + commit, hace que la configuración activa alterne entre la actual y la última activa. Así que 999 veces es equivalente a 1 vez. Y 1000 veces es equivalente a 0 veces. Todo esto, suponiendo que ningún otro usuario o sesión realice ningún cambio de configuración o commit entre tanto.

ANSWER�#7 Con commit check sólo compruebas que la configuración es sintácticamente válida, pero no activas (commit) los cambios. Si ves errores con el commit check, entonces un commit “real” fallaría y no continuaría aplicando los cambios.

ANSWER�#8�� No, en el modo de configuración estás mirando a la base de datos candidata, mientras que en el modo operacio-nal inspeccionas la configuración activa.

q


1h 2h 3h

Y AHORA... ¡UN RETO!

Bienvenidos al vDay One End-of-Book Challenge

Ahora que ya has finalizado el libro "vDay One: Mastering Junos Configuration", ha llegado el momento de que pongas a prueba tu habilidad con Junos y Junosphere. Para ello te proponemos la siguiente prueba.

El escenario consiste en una máquina virtual que corre Junos, en Junosphere. Sólo necesitas parar (stop) tu topología actual, e iniciar otra topología llamada vDay One – Challenge 1, que también está disponible en la Public Library de Junosphere. Una vez que te unas (join) a esta topología de una única VM, intenta adivinar la respuesta al siguiente acertijo.

EL ACERTIJO

Alguien ha borrado de la configuración las unidades 2, 4, 6 y 8 del interfaz ge-0/0/1. Tu tarea es proponer un procedimiento para recuperar dicha configuración borrada. El procedimiento no debe producir ningún otro cambio en la configuración.

Durante la fase de investigación, debes buscar el procedimiento correcto. En esta fase sólo está permitida una acción: ejecutar comandos show, tantos como quieras, pero no uses el símbolo pipa ( | ) en esta fase. Tu investigación debe concluir con la propuesta de un procedimiento que cumpla las condiciones siguientes:

�� Sólo debes usar tu terminal telnet/ssh. No está per-mitido el uso de otras conexiones ni de aplicaciones externas como editores de texto. En cambio, puedes copiar-pegar desde el terminal telnet/ssh al propio terminal si lo deseas.

�� El usuario que aplique este procedimiento debe pulsar el teclado un máximo de 100 veces. No está permitido auto-completar con el tabulador o con la barra espacia-dora. Una operación de copiar-pegar cuenta como 20 pulsaciones de teclado.

�� El procedimiento debe contener como máximo 4 comandos y tener este aspecto:

user@device> [comando #1]user@device> [comando #2]user@device# [comando #3]user@device# commit

IMPORTANTE� Hay al menos dos procedimientos (muy similares, pero diferentes) que cumplen los requisitos. El reto es proponer ambos.

Diviértete intentándolo. Comprueba en la última versión de este libro vDay One si ya está el enlace a la solución (en inglés). Si la solución no está aún publicada, envía tu respuesta a vday-one-demo@ juniper.net y, si es correcta, te regalaremos tiempo adicional en tu cuenta de Junosphere.

NOTA� �No te preocupes si algunos rollbacks no están dis-ponibles. El resto de la historia de commits está en correcto estado.

¿MÁS?��Además, en el momento en que se publique este libro comienza un concurso. La primera persona que resuelva el acertijo de arriba será premiada de manera especial y reconocida en J-Net como ganador(a) del concurso.

ATENCIÓN� Este no es un concurso de hacking. ¡Sólo debes ejecutar comandos válidos y documentados de la CLI de Junos!

Y AHORA... ¡UN RETO!

vDay One: Mastering Junos Configuration (Edicion en Espanol)...técnicas de configuración, este lab...

Documents

Transcript of vDay One: Mastering Junos Configuration (Edicion en Espanol)...técnicas de configuración, este lab...