Memoria GNS3

TRABAJO FIN DE MSTER
Mster Universitario en Ingeniera de Telecomunicacin
Estudio e implementacin de la herramienta de

simulacin de redes GNS3
Autor:
Julio Jornet Monteverde
Directores:
Carolina Pascual Villalobos
Adolfo Albaladejo Blzquez
Septiembre, 2013
Mster Universitario en Ingeniera de Telecomunicacin - UA
Pgina en blanco intencionadamente
Estudio e implementacin de la herramienta de simulacin de redes GNS3
UA - Mster Universitario en Ingeniera de Telecomunicacin
NDICE
1. PREMBULO ................................................................................. 9
1.1.
Introduccin ............................................................................................ 9
1.2.
Objetivos ................................................................................................ 11
2.
GNS3 GRAPHICAL NETWORK SIMULATOR ...................... 13
2.1.
Introduccin .......................................................................................... 13
2.2.
Historia de GNS3 ................................................................................... 15
2.3.
Arquitectura del emulador .................................................................... 16
2.3.1. Dynamips .................................................................................................................... 16

2.3.2. Dynagen ...................................................................................................................... 18
2.3.3. Network File................................................................................................................ 18
2.4.
Herramientas para GNS3 ...................................................................... 19
2.4.1. VirtualBox.................................................................................................................... 19
2.4.2. QEMU .......................................................................................................................... 21
2.4.3. Wireshark .................................................................................................................... 22
2.4.4. Simulacin de PCs .................................................................................................... 22
2.5.
2.4.4.1.
Virtual PC ................................................................................................22
2.4.4.2.
Routers actuando como PC ....................................................................23
2.4.4.3.
Virtualizar un PC con VirtualBox .............................................................23
Emulacin de Routers .......................................................................... 24
2.5.1. Router de cdigo abierto: XORP............................................................................. 24

2.5.2. Sistema Vyatta ........................................................................................................... 26
2.6.
3.
Anlisis de rendimiento: QEMU vs VirtualBox ................................... 27
INSTALACIN DE OLIVAS ..................................................... 31
3.1.
Introduccin .......................................................................................... 31
3.2.
Requisitos mnimos .............................................................................. 32
3.3.
Instalacin de una Oliva ....................................................................... 32
3.3.1. Instalando FreeBSD .................................................................................................. 33


3.3.2. Configuracin Post-Instalacin ................................................................................ 39
3.3.3. Configuracin Virtual Serial Port Emulator ............................................................ 40
3.3.4. Instalacin IOS Junos 9.6 ........................................................................................ 42
3.3.5. Instalacin JWeb Junos 9.6 ..................................................................................... 47
3.4.
Configurando la Oliva en GNS3 ..................................................................... 50
3.5.
Comprobacin de la Oliva JWeb Junos 9.6 .............................................. 53
3.6.
Instalacin IOS Junos 10.4R1.9...................................................................... 58
3.6.1.
Instalacin FreeBSD ...............................................................................58
3.6.2.
Instalacin Junos 10.4R1.9 .....................................................................60
3.6.3.
Instalacin JWeb Junos10.4 ...................................................................65
3.7.
4.
Comprobacin de la Oliva JWeb Junos 10.4 ......................................68
LAB 1: FUNDAMENTOS DE ROUTING ................................... 71

Parte 1: Configuracin y Monitorizacin de Interfaces .................................................... 72
Parte 2: Configuracin y Monitorizacin de Rutas Estticas .......................................... 78
Parte 3: Configuracin y Monitorizacin OSPF ................................................................ 84
Parte 4: Guardar configuraciones ....................................................................................... 89
5.
LAB 2: POLTICAS DE ROUTING ........................................... 97

Parte 1: Preparacin del Sistema y Verificacin ............................................................... 98
Parte 2: Configurar y Monitorizar Polticas de Enrutamiento ........................................ 102
Parte 3: Configurar servidor TFTP de copias de configuracin ................................... 116
6.
LAB 3: FILTROS FIREWALLS ............................................... 123

Parte 1: Preparacin del Sistema y Verificacin ............................................................. 124
Parte 2: Configurando y Monitorizando Filtros Firewall ................................................. 131
Parte 3: Configurar servidor TFTP de copias de configuracin ................................... 148
7.
LAB 4: CLASES DE SERVICIOS (COS) ................................ 161

Parte 1: Preparacin del Sistema y Verificacin ............................................................. 163
Parte 2: Configurando Colas y Mapas de Planificacin ................................................ 171
Parte 3: Configurando Clasificacin Multicampo ............................................................ 175
8.
LAB 5: IPV6 ............................................................................ 179

Parte 1: Configurar y Monitorizar Interfaces .................................................................... 180
Parte 2: Configurando y Monitorizando Rutas Estticas ............................................... 186
Parte 3: Configurando y Monitorizando OSPF ................................................................ 190
Parte 4: Tunneling IPv6 sobre IPv4 utilizando Encapsulacin GRE ........................... 193
9.
TROUBLESHOOTING JUNOS............................................... 201

9.1.
Problema 1: Fallo enrutamiento OSPF ................................................................ 201
9.1.2.
Conclusiones - 1 Parte.........................................................................209
9.1.4.
Conclusiones Finales ............................................................................221
9.2.
Problema 2: Fallo Filtros Firewall en versin R9.6 ............................................. 222
9.2.2.
Conclusiones Finales ............................................................................229
10. CONCLUSIONES Y RECOMENDACIONES .......................... 231

11. LNEAS FUTURAS ................................................................. 235
12. BIBLIOGRAFA ...................................................................... 237
Listado de Figuras
Figura 1: Bloques software de la herramienta GNS3 .......................................................13
Figura 2: Ventana principal de VirtualBox incluyendo mquinas virtuales. .......................20
Figura 3: Escenario utilizado para anlisis de rendimiento. ..............................................28
Figura 4: Tabla de tiempos y carga del sistema anfitrin. ................................................28
Figura 5: Tiempo medio que tardan en arrancar las Olivas segn el sistema operativo y el
sistema de virtualizacin. .................................................................................29
Figura 6: a) Carga de memoria segn SO. b) Carga de la CPU segn SO. .....................30
Figura 7: Pantallas para la creacin de una mquina virtual con el VirtualBox. ................34
Figura 8: Propiedades de configuracin de una MV. ........................................................34
Figura 9: Pantalla de arranque inicial de la MV con FreeBSD. .........................................35
Figura 10: Men de configuracin del kernel FreeBSD. ...................................................35
Figura 11: Pantalla principal de instalacin FreeBSD.......................................................36
Figura 12: Editor de particiones FDISK. ...........................................................................36
Figura 13: Men del gestor de arranque. .........................................................................37
Figura 14: Editor de filesistems de FreeBSD. ..................................................................37
Figura 15: Men de distribuciones FreeBSD. ...................................................................38
Figura 16: Men de origen de instalacin FreeBSD. ........................................................38
Figura 17: Men configuracin de red. .............................................................................39
Figura 18: Men principal SysInstall FreeBSD. ................................................................40
Figura 19: Configuracin puerto serie de la MV ...............................................................41
Figura 20: Ventana principal VSPE. .................................................................................41
Figura 21: a) Definicin tipo de conexin. b) Definicin puerto virtual. .............................42
Figura 22: Ventana principal con el estado del puerto serie virtual...................................42
Figura 23: Mensajes iniciales de la instalacin del paquete Junos. ..................................44
Figura 24: Mensaje de error de instalacin paquete Junos. .............................................45
Figura 25: Reinicio previo al comienzo de la instalacin paquete Junos. .........................45
Figura 26: Captura del inicio de la instalacin Junos con el programa Putty y a travs del
puerto serie virtual. ........................................................................................46
Figura 27: Arranque inicial de la Oliva con versin Junos 9.6R1.13. ................................46
Figura 28: Captura de los paquetes instalados en la Oliva (comando show version). ......47
Figura 29: Mensajes iniciales instalacin paquete JWEB. ................................................49
Figura 30: Ventana Preferences de GNS3: comprobacin comunicacin con VirtualBox.51
Figura 31: Ventana Preferences de GNS3: definicin de las MV. ....................................52
Figura 32: Administracin de smbolos en GNS3. ............................................................53
6

Figura 33: Listado de MV disponibles para los escenarios. ..............................................53
Figura 34: Ventana principal GNS3 con un escenario cargado. .......................................54
Figura 35: Configuracin de nodo: asignacin de interfaces. ...........................................54
Figura 36: Acceso a la Oliva con GNS3. ..........................................................................55
Figura 37: Pantalla de bienvenida al acceso va Web. .....................................................56
Figura 38: Pantalla de configuracin del router con el JWEB. ..........................................57
Figura 39: Definicin del tamao del disco duro para una MV en VirtualBox. ..................58
Figura 40: Propiedades de configuracin de la MV para Junos 10.4................................59
Figura 41: Tabla de particiones de FreeBSD para Junos 10.4. ........................................60
Figura 42: Distribucin del filesystem para Junos 10.4. ...................................................60
Figura 43: Modificacin archivo +INSTALL. .....................................................................62
Figura 44: Mensajes iniciales instalacin paquete Junos 10.4. ........................................64
Figura 45: Proceso de instalacin Junos 10.4. .................................................................64
Figura 46: Proceso de instalacin paquete JWEB 10.4....................................................66
Figura 47: Listado definiciones de MV en GNS3. .............................................................68
Figura 48: Configuracin de la Oliva 10.4 en un escenario. .............................................69
Figura 49: Pantalla de bienvenida JWEB 10.4. ................................................................70
Figura 50: Pantalla configuracin via Web Junos 10.4. ....................................................70
Figura 51: Escenario del laboratorio Fundamentos de Routing. .......................................71
Figura 52: Integracin nodo de interconexin al escenario. .............................................92
Figura 53: Ventana configuracin nodo de interconexin. ................................................93
Figura 54: Ventana principal de Cisco TFTP Server. .......................................................94
Figura 55: Logs de recepcin de ficheros en el servidor TFTP. .......................................95
Figura 56: Escenario del laboratorio Politicas de Routing. ...............................................97
Figura 57: Escenario del laboratorio Filtros Firewalls. ....................................................123
Figura 58: Escenario original del laboratorio Clases de Servicios. .................................161
Figura 59: Escenario adaptado del laboratorio Clases de Servicios. ..............................162
Figura 60: Escenario del laboratorio IPv6. .....................................................................179
Figura 61: Escenario para la configuracin de OSPFv3. ................................................190
Figura 62: Escenario para la configuracin del tnel GRE. ............................................193
Figura 63: Escenario utilizado en el laboratorio 3: Filtros Firewalls. ...............................201
Figura 64: Escenario de prueba con slo dos routers. ...................................................203
Figura 65: Escenario de pruebas con las lneas intercambiadas. ...................................208
Figura 66: Escenario utilizado en el laboratorio 5.3: IPv6, OSPFv3. ..............................210
Figura 67: Configuracin direccin MAC en una MV de VirtualBox. ...............................217
1.
Prembulo
1.1. Introduccin
El mantenimiento y optimizacin de una red, as como su respuesta ante posibles

fallos o sobrecargas es una tarea peligrosa porque cualquier modificacin en su
configuracin conlleva un impacto sobre el trfico real y por lo tanto sobre el
cliente final ya que estas redes se encuentran en produccin. Esta situacin hace
que las empresas y operadores se planteen alternativas para el estudio y
optimizacin de sus redes, tales como implementar maquetas o realizar
simulaciones con programas especficos. La primera de las opciones, creacin de
maquetas, puede resultar muy costosa ya que conlleva la adquisicin de
equipamiento real y en escenarios grandes puede resultar inviable. Tambin a la
hora de adquirir formacin en determinados productos, para los estudiantes es
inviable comprarse un conjunto de equipamiento real para obtener las
correspondientes certificaciones.
Por todas estas razones, cada vez es ms comn que empresas y estudiantes se
decanten por programas de emulacin/simulacin, tales como OPNET o GNS3,
para probar nuevos protocolos o aprender conceptos que ms adelante los
aplicarn en redes.
Un emulador es un software que permite ejecutar instrucciones originarias de una

plataforma en otra totalmente diferente y que de por s no entiende dicho conjunto
de instrucciones. Se trata de modelar de forma precisa el dispositivo de manera
que este funcione como si estuviese siendo usado en el aparato original. En la
actualidad, existen numerosos emuladores que permiten imitan el comportamiento
de sistemas e incluso toman la forma de dispositivos hardware reales. Algunos
ejemplos seran VMware VirtualBox que emulan sistemas operativos GNS3
que emula dispositivos de red a partir de imgenes reales de IOS CISCO.
Un simulador trata de reproducir el comportamiento del programa o sistema,

permitiendo representar ciertas caractersticas o comportamientos claves
(modelo) del sistema fsico o abstracto que se quiere simular, y por lo tanto el
sistema resultante ser ms limitado. Un ejemplo de un simulador de routers sera
BOSON o Juniper Simulator, diseados con fines acadmicos para soportar las
funcionalidades requeridas para la obtencin de certificaciones CISCO o
JUNIPER, como seran JNCIA o JNCIS.
A la hora de elegir un emulador o un simulador, sin duda es ms real la opcin de

los emuladores. En este trabajo vamos a trabajar con el programa GNS3 y vamos
a tratar de demostrar que se puede adaptar al entorno Juniper y crear laboratorios
para la prueba y aprendizaje de sus equipos.
GNS3 es un emulador con licencia opensource, que posee una GUI muy
amigable, fcil de instalar y manejar. En un principio fue creado para la emulacin
de dispositivos CISCO y para ello utiliza la IOS original de CISCO la cual es
propietaria y requiere de permisos para su obtencin. Esto de por s ya es una
limitacin y hace que el paquete no sea tan libre. Una alternativa a esta
limitacin sera utilizar XORP o Vyatta.
XORP son las siglas de eXtensible Open Router Platform, y es una plataforma de
enrutamiento opensource. Proporciona una plataforma con todas las funciones
que implementan los protocolos de enrutamiento IPv4 e IPv6 y la capacidad de
poder configurarlos. Es la nica plataforma de cdigo abierto con capacidad de
ofrecer multicast integrado. Posee una arquitectura modular que permite una
rpida introduccin de nuevos protocolos, caractersticas y funcionalidades.
10
Vyatta es un sistema operativo opensource que puede instalarse en cualquier

ordenador x86. Funciona sobre un kernel Linux y tiene unos requisitos muy bajos
para poder funcionar, lo cual lo hace muy indicado para ser virtualizado. Posee
una CLI (Comand Line Interface) propietaria muy parecida a la implementada por
JUNIPER en sus equipos, tanto es as que el modo de configuracin y el fichero
de configuracin son iguales. Este sistema operativo se encuentra disponible de
forma gratuita en Internet en su versin ms limitada, si se desea obtener
funcionalidades ms complejas este software deja de ser gratuito.
1.2. Objetivos
El objetivo principal que se persigue en este trabajo es realizar una gua completa
para la creacin, configuracin y consecucin de los laboratorios existentes en la
certificacin JNCIA de Juniper utilizando la herramienta GNS3, junto con un
sistema de virtualizacin para emular los routers Juniper, que permita a los
estudiantes un aprendizaje accesible.
El presente PFC tiene los siguientes objetivos concretos:

a. Conseguir implementar con la IOS de Juniper una mquina virtual,
llamadas Olivas, en varios sistemas de virtualizacin, QEMU y VirtualBox.
b. Estimar los requerimientos hardware que son necesarios para la creacin
de las Olivas.
c. Comprobar y estudiar las capacidades que ofrece el entorno GNS3 para la
simulacin de redes con dispositivos Juniper emulados.
d. Detallar el uso de las caractersticas del entorno GNS3 para los
dispositivos Juniper.
e. Determinar qu sistema de virtualizacin utilizado por GNS3 es el ms
ptimo.
f. Adaptar los escenarios de los laboratorios del JNCIA para el entorno
GNS3.
11
g. Probar la consecucin completa de cada uno de los laboratorios del JNCIA

creados por Juniper.
h. Probar el correcto funcionamiento y configuracin de los protocolos de
enrutamiento IPv6 en el entorno GNS3.
12
2. GNS3 Graphical Network Simulator

2.1. Introduccin
GNS3 son las siglas de Graphical Network Simulator. Esta aplicacin est
enfocada a la simulacin de redes complejas para su estudio. Este entorno visual
usa como motor de ejecucin la plataforma Dynamips/Dynagen, creada
originalmente para ejecutar y emular el firmware de los routers y dispositivos de
Cisco Systems (IOS) y Juniper (JunOS), adems de establecer topologas
(escenarios)
para
conectarlos.
Dichas
topologas
pueden,
su
vez,
interconectarse con otras ejecutndose en diferentes instancias de GNS3, lo que

se denomina red virtual, bien en el mismo o en diferentes PCs (haciendo uso de
los elementos de red disponibles en las mquinas).
GNS3 se ha desarrollado en Python y usa las libreras de Dynagen para crear una
interfaz grfica (GUI). Sus principales funciones son editar el archivo de texto .net
y realizar las operaciones del CLI hechas por Dynagen y Dynamips.
Adicionalmente incorpora la capacidad de simular PCs.
La unin de Dynamips-Dynagen-GNS3, como se observa en la siguiente figura,

crea una plataforma que permite el fcil diseo de topologas de red complejas ya
que se realizan tan slo arrastrando los componentes y dibujando lneas entre
routers de forma intuitiva. Por lo tanto, GNS3 es idneo para el entrenamiento de
estudiantes que desean familiarizarse con dispositivos de red.
Figura 1: Bloques software de la herramienta GNS3

13
Las capacidades ms destacables que podemos obtener de GNS3 y por las

cuales nos hemos decantado para su utilizacin en este trabajo son las
siguientes:
Se encuentra disponible de forma gratuita en la red.
Es fcil de instalar ya que todos los programas que necesita para funcionar
se encuentran en un solo paquete de instalacin.
Est en constante actualizacin y peridicamente se puede encontrar

versiones de la aplicacin ms robustas y con nuevas funcionalidades.
Permite la conexin Telnet a la consola de un router virtual, de forma fcil

directamente desde la interfaz grfica.
Alternativamente tambin permite trabajar directamente desde consola de

gestin de Dynagen.
Permite la comunicacin entre redes virtuales con redes del mundo real.
Es apropiado para simular redes de grandes tamaos ya que permite que

un cliente GNS3 pueda correr en una mquina diferente a la que contiene
al emulador Dynamips, repartiendo el procesamiento entre diferentes PCs.
Puede capturar los paquetes que pasan por enlaces virtuales y escribir los
resultados de la captura en archivos que pueden ser interpretados por
aplicaciones como Wireshark o tcpdumps.
Los foros de Internet evidencian que es una aplicacin ampliamente

utilizada.
GNS3 no es la nica aplicacin que brinda una GUI a Dynamips, existe otra con el
nombre de Dynagui que realiza la misma tarea pero que se encuentra
actualmente en fase de desarrollo y que no llega a implementar todas las
funcionalidades que posee GNS3.
14
2.2. Historia de GNS3
Sobre el 2005 slo exista Dynamips, un emulador de routers Cisco que fue
escrito por Chistophe Fillot. ste emulaba las plataformas hardware 1700, 2600,
3700 y 7200, y ejecutaba las imgenes IOS propias de los routers Cisco. Se
podra ejecutar Dynamips desde la lnea de comandos y tener un router Cisco
emulado ejecutndose en un PC. Pero no es muy til ya que existe software que
convierte un PC en un router. Para conseguir una red en funcionamiento, habra
que iniciar dos instancias del programa con un montn de opciones de lnea de
comandos cuidadosamente construidos. Por lo que hara que su CPU estuviera
trabajando al 100% y por lo tanto no sera operativo.
En el 2006, se lanz la versin 0.2.5 que hizo posible ejecutar Dynamips en modo
Hipervisor, el cual permite simular varios routers en una simple instancia y aadir
la opcin Idle-PC, que te permite ajustar la utilizacin de la CPU del PC y por lo
tanto no saturarlo. Pero es ms importante la caracterstica Hipervisor que
permiti a Greg Anuzelli poner un front-end a todas aquellas opciones de la lnea
de comandos con su programa llamado Dynagen. Aqu fue donde se cre el
formato del fichero .net, y que GNS3 utiliza junto con las libreras de Dynagen. De
hecho, el panel inferior de GNS3 es una consola de Dynagen adaptado.
En ese momento, Dynagen era bueno, pero tena un problema: el mantenimiento

del fichero .net era una pesadilla, un solo error en la definicin de un objeto o
conexin y el Hipervisor no arrancaba.
En Septiembre de 2007 sali la primera versin de GNS3 (versin 0.3). Se

aadieron nuevos colaboradores como Jeremy Grossmann y Xavier Alt al grupo
de desarrollo. En esta versin ya se podan arrastrar y soltar los iconos en el
panel central y automticamente GNS3 creaba dichas conexiones en el fichero
.net para que posteriormente Dynagen hiciera magia con Dynamips para controlar
15
los routers. Tambin se aadieron varias configuraciones extras al fichero .net

(ahora llamado topology.net por defecto) para que se pudiera recordar dnde se
haban colocado exactamente los objetos en el panel y as volver a dibujar el
escenario tal y como se dise.
Paralelamente a todo esto, en el 2007 y en otra parte del mundo, Mirnshi

desarroll una pequea aplicacin llamada VPCS que nos permiti simular PCs y
asociarlos fcilmente a nuestras redes virtuales GNS3. Desde entonces, cada
nueva versin ha ido aportando nuevas funcionalidades con respecto a las
versiones anteriores aumentando la comunidad de usuarios, pero todava muchos
de estos usuarios tienen problemas a la hora de instalar y mantener GNS3,
especialmente en entornos Windows.
2.3. Arquitectura del emulador

2.3.1. Dynamips
Dynamips es el motor de emulacin que permite emular diferentes plataformas

hardware usando imgenes de sistemas operativos de CISCO en un mismo host.
Entre dichas plataformas se encuentran los Routers 1700, 2600, 3600, 3700 y
7200. Por otro lado, puede emular switches Ethernet, Frame-Relay y ATM con
funcionalidades bsicas.
En cuando a la emulacin de switches, Dynamips no es capaz de emular

switches, ni de la familia Cisco Catalyst ni Juniper EX, sino que provee una
versin limitada de un switch virtual, cuyas limitaciones pueden ser resueltas
usando mtodos alternativos como la emulacin de NM-16ESW que el emulador
s soporta. Por otro lado, Dynamips tampoco es capaz de emular Firewalls PIX,
para ello se usa el emulador PEMU a travs de Dynagen.
16
Como ya hemos comentado, inicialmente Dynamips consume grandes cantidades

de CPU del PC anfitrin, esto se debe principalmente a que realiza la emulacin
de los routers instruccin por instruccin y a que no puede saber cundo un router
virtual est inactivo, de modo que ejecuta instrucciones como si la imagen del IOS
estuviera realizando algn trabajo til. Para resolver el problema del excesivo uso
de CPU se crea un proceso llamado IDLE-PC. Este parmetro se debe ajustar
para la familia de dispositivos CISCO, pero para Juniper no es el caso ya que
estos dispositivos se emulan virtualmente a travs de herramientas de
virtualizacin, tales como VirtualBox y no se utiliza Dynamips.
Por otro lado, Dynamips tambin consume memoria RAM del PC emulador, ya
que, en teora cada router virtual debe tener a su disposicin, como mnimo, toda
la cantidad de memoria RAM que necesita para poder trabajar, por lo tanto, esta
cantidad se hace imprctica si se requieren emular redes con varios routers. Para
resolver el problema del excesivo uso de memoria del PC emulador se usan
herramientas que permiten compartir la memoria del mismo entre varios routers
emulados con la misma IOS, y herramientas que usan el disco en vez de la
memoria del emulador.
Algo parecido ocurre con los routers Juniper y la herramienta de virtualizacin, por
ejemplo VirtualBox. Cada router que se incorpore a un escenario consumir una
serie de recursos en la mquina anfitriona sin la posibilidad de poder compartir
memoria entre instancias de routers ya que stos se controlan desde VirtualBox,
un programa ajeno a GNS3. Por este motivo debemos ser cautos a la hora de
crear las mquinas virtuales y asignarles la memoria y CPU, ya que de esos
parmetros depender el nmero total de routers que podamos insertar en
nuestros escenarios.
17
2.3.2. Dynagen
Dynagen es una interfaz escrita en Python que provee la gestin, mediante lnea
de comando (CLI), de las plataformas emuladas por Dynamips haciendo ms fcil
su uso. Usa el modo Hypervisor para comunicarse con Dynamips y ambas
pueden correr en la misma o en diferente PC. Tambin simplifica la gestin de las
redes virtuales ya que implementa comandos para listar, iniciar, parar, reiniciar,
suspender, reanudar los diferentes dispositivos emulados, adems determina los
valores de IDLEPC y realiza capturas de paquetes.
A partir de sus ltimas versiones, Dynagen es capaz de trabajar con el emulador

de firewalls PEMU, el cual viene integrado en GNS3 dotando al emulador de
capacidad de aadir Firewalls CISCO en las topologas. Adems es capaz de
conectar de forma transparente a Dynamips los diferentes dispositivos virtuales
como switches Ethernet, Frame-Relay y ATM soportados por Dynamips. Dynagen
usa un archivo de texto de fcil interpretacin llamado Network File, con
extensin .net, para conocer todas las caractersticas de hardware de los
dispositivos de red a emular y realizar las interconexiones entre ellos.
2.3.3. Network File
Se trata de un archivo, escrito usando sintaxis INI (INI file syntax), que almacena
la configuracin de todos los dispositivos de red de la topologa virtual a simular,
como son los routers, switches, las interconexiones entre ellos y las posiciones de
los objetos en el diagrama, incluso las etiquetas. Este archivo puede especificar
valores tan concretos como los descriptores de los adaptadores de red (NIO) que
se encargan de la conexin con equipos reales o los puertos en los que trabajan
dichos adaptadores de red de red, etc.
18
2.4. Herramientas para GNS3

2.4.1. VirtualBox
VirtualBox es una solucin open source de virtualizacin desarrollada inicialmente

por la empresa alemana Innotek, que fue posteriormente adquirida por Sun
Microsystems, y que a su vez sta ltima fue adquirida en el 2010 por la empresa
ORACLE, la cual lleva actualmente su desarrollo.
VirtualBox no utiliza para-virtualizacin, lo cual penaliza su rendimiento

comparado con otros sistemas de virtualizacin como Xen, pero maximiza su
compatibilidad dado que puede ejecutar cualquier mquina husped que funcione
en una mquina x86 (32 o 64 bits).
Durante los ltimos aos VirtualBox se ha convertido en una de las herramientas

de virtualizacin ms usada, debido a su Interfaz amigable y a que tiene versiones
instalable en multitud de Sistemas Operativos incluyendo Windows, Linux y Mac,
adems de que su desarrollo se ha acelerado enormemente en los ltimos
tiempos incluyendo novedades a un ritmo vertiginoso.
Actualmente la plataforma VirtualBox se compone de un servicio que maneja las

mquinas llamado VboxManage y luego varios entornos grficos o terminales
para acceder a las mquinas. Incluso incorpora un mdulo PHP para crear un
servidor web donde se muestra la misma interface de aplicacin y las mquinas
virtuales.
19
Figura 2: Ventana principal de VirtualBox incluyendo mquinas virtuales.
Las mquinas virtuales pueden ser creadas y gestionadas desde el entorno

grfico o directamente desde la lnea de comandos mediante VboxManage. Por
ejemplo, para arrancar una mquina virtual desde la linea de comandos
escribiremos lo siguiente:
VBoxManage startvm "Junos Olive R12"
Una vez arrancadas las mquinas se puede acceder a ellas mediante RDP. RDP
son las siglas de Remote Desktop Protocol, y es un protocolo para acceder a
escritorios remotos, que nos permite acceder a la mquina sin interferir en el
sistema husped.
20
De esta manera es como GNS3 interacta con las mquinas virtuales de

VirtualBox.
2.4.2. QEMU
GNS3 tiene la capacidad de poder interactuar con el emulador QEMU que no es

ms que un programa de virtualizacin de cdigo libre. GNS3 lo utiliza para
ejecutar IOS de Cisco ASA, PIX e IDS, y en l tambin se puede implementar
JUNOS con QEMU.
QEMU emula un sistema informtico completo, incluyendo procesador y varios
perifricos. Este puede ser usado para proveer hosting virtual a varios
ordenadores virtuales en un nico ordenador. QEMU puede arrancar varios
sistemas operativos, incluyendo entre otros Linux, Microsoft Windows, DOS, y
BSD. Admite adems la emulacin de varias plataformas de hardware, incluyendo
x86, AMD64, Alpha, Mips, y Sparc.
La mayora del programa est bajo licencia LGPL, y el modo de emulacin de
usuario tiene licencia GPL.
Existe un mdulo para el kernel Linux (se han hecho adaptaciones preliminares
para FreeBSD y Windows), denominados kqemu o acelerador QEMU. Esto
acelera la emulacin de i386 en plataformas i386 hasta un nivel ligeramente
inferior a la ejecucin en modo nativo. Se alcanza lo dicho ejecutando el modo de
usuario y virtual en modo de cdigo 8086 directamente sobre la CPU del
computador. Adems, slo se usa la emulacin del procesador y de los perifricos
en modo kernel y en modo de cdigo real. Esto es similar a lo que hacen Vmware
Workstation y Virtual PC. Como resultado, si se usa sobre ella MS-DOS en modo
real, no incrementar demasiado el rendimiento, mientras que Windows 2000 se
ejecutar con una velocidad cercana a la nativa.
En este trabajo se ha utilizado QEMU para crear una mquina virtual con Junos
9.6 y realizar comparativas de rendimiento junto con VirtualBox. Ms adelante se
expondrn los resultados.
21
2.4.3. Wireshark
El paquete de instalacin GNS3 lleva consigo la instalacin de la herramienta de

captura Wireshark. GNS3 integra la capacidad de capturar los paquetes que
pasan por interfaces Ethernet o Serie y almacenarlos en archivos con formato
libpcap para que puedan ser interpretados por aplicaciones como Wireshark,
tcpdump, etc.
Esta capacidad se ha probado y no funciona en enlaces establecidos con

mquinas virtuales y por lo tanto no se ha podido conseguir la captura de
paquetes. GNS3 muestra un error indicando que esta caracterstica solo est
disponible para Hipervisors locales.
2.4.4. Simulacin de PCs
GNS3 permite, adems de los equipos de red, la incorporacin de PCs en las

topologas creadas, lo que facilita la comprobacin y el estudio de las redes
simuladas. Las formas existentes de simulacin de PCs en GNS3 son las
siguientes:
2.4.4.1.
Virtual PC
Esta primera forma de simulacin de PCs se realiza utilizando un programa

llamado Virtual Pc Simulator o VPC que usa puertos UDP para la comunicacin
entre el simulador y cada uno de los PCs simulados. VPC se puede descargar
desde Internet de forma gratuita y se distribuye tanto para Windows como para
Linux.
El propio programa nos proporciona hasta un total de 9 PCs virtuales, los cuales
llamara sesiones porque no son realmente PCs sino como terminales que
22
implementan las herramientas necesarias para realizar comprobaciones en la red.

Es muy similar a las sesiones TTY de Linux.
Las ventajas de usar VPC es que su uso es simple y que no usa grandes
cantidades de memoria ni ciclos de CPU para su funcionamiento; por otro lado,
tiene la desventaja de que tiene funcionalidad limitada, ya que solo permite el uso
de comandos como ping y traceroute, y como ya hemos comentado soporta un
mximo de nueve (09) PCs simulados simultneamente.
2.4.4.2.
Routers actuando como PC
En este mtodo, la incorporacin de un PC a la topologa es la ms simple, ya

que solo se trata de aadir un router para que se puedan ejecutar comandos para
comprobaciones, la desventaja de este mtodo es que utiliza demasiados
recursos de memoria y procesamiento.
Los comandos que debemos usar para configurar cada router son bsicamente
para configurar una direccin IP y un Gateway a la interfaz de conexin, y adems
se deshabilitarn las funciones de enrutamiento del dispositivo.
2.4.4.3.
Virtualizar un PC con VirtualBox
Este mtodo es el ms real ya que implementamos un PC por completo, con

todas sus caractersticas y programas, e incluso con la posibilidad de activar
servicios y as poder asumir el roll de Servidor en nuestros escenarios.
La carga que aade a nuestros escenarios depender de cmo se haya creado la

mquina virtual, y del SO que se haya implementado. No ser lo mismo una MV
23
con Windows XP que una MV con Linux Microcore. Tampoco se implementar

una MV WXP simplemente para realizar comprobaciones de red, en este caso se
utilizarn MV con Linux Microcore. Todo depender de la funcionalidad que
queramos obtener. Es muy recomendable tener una MV con Linux Microcore, una
MV con WXP y por ltimo una MV con Linux, Ubuntu o FreeBSD, para que acte
como servidor HTTP, MAIL, etc.
2.5. Emulacin de Routers
Como ya se ha comentado, en un principio GNS3 se emple para la emulacin de

routers Cisco, y posteriormente a travs de plataformas de emulacin, los routers
Juniper. Aunque GNS3 es de licencia libre, la utilizacin de las IOS conlleva
disponer de una licencia para su utilizacin, y esto es un inconveniente.
Existen otras plataformas de enrutamiento que son libres de licencia y que es

posible implementar con GNS3.
2.5.1. Router de cdigo abierto: XORP
XORP son las siglas de eXtensible Open Router Platform, un trabajo GNU para la
creacin de una plataforma de cdigo abierto que permite la creacin de
dispositivos de interconexin software multiplataforma. XORP tiene una
arquitectura modular y flexible, que permite implementar distintos protocolos de
encaminamiento, los cuales se cargarn y ejecutarn cuando sea requerido por el
administrador del dispositivo.
La versin 1.6 incluye los siguientes mdulos de protocolos y tecnologas de red:

RIP (Routing Information Protocol), OSPF (Open Short-Path First), BGP (Border
24
Gateway Protocol), multicast, IGMP (Internet Group Management Protocol), MLD

(Multicast Listener Discovery), SNMP (Simple Network Management Protocol) y
cortafuegos.
XORP se distribuye de manera gratuita desde su pgina web a travs de live CD

o como fuentes para Windows y Unix/Linux. De nuevo, y siguiendo nuestra
propuesta, XORP podra ser virtualizado sobre el ordenador anfitrin que est
ejecutando GNS3. Para ello, se puede recurrir a la plataforma de virtualizacin
VirtualBox, que segn estudios consume menos recursos al ejecutar XORP que
un emulador Dynamips/Dynagen ejecutando, por ejemplo, una IOS de Cisco. Para
crear estas redes virtuales con XORP se deben utilizar interfaces de kernel tipo
TAP, que son reconocidas por VirtualBox.
No existen apenas diferencias entre la configuracin de un router tipo Cisco y uno

XORP, la consola de configuracin es similar (CLI o command-line interpreter). La
nica diferencia reseable, es que en XORP los protocolos se configuran para
cada interfaz, al contrario que en los routers de Cisco donde en el protocolo se
indica para qu interfaces estar activo.
Segn estudios y pruebas realizadas por grupos de investigacin, como en la

Universidad de Mlaga, las pruebas con XORP han sido muy satisfactorias, y el
consumo de recursos en el PC anfitrin se reduce considerablemente al usar
routers XORP, por lo que las topologas pueden contener ms elementos y
realizar tareas de encaminamiento ms complejas. XORP no tiene todas las
capacidades de un router comercial, pero los protocolos de que dispone son ms
que suficientes para su utilizacin con fines educativos.
25
2.5.2. Sistema Vyatta
Vyatta es un sistema open source de Routing que intenta posicionarse como una
alternativa eficaz y econmica a los sistemas de Cisco. Vyatta funciona en
plataformas standard x86, podemos utilizarlo en cualquier sistema compatible.
Funciona sobre un kernel Linux y tiene unos requisitos muy bajos para poder
funcionar, lo cual lo hace muy indicado para ser virtualizado, debido a que
podemos instalar muchos routers virtuales en una misma mquina fsica sin que
afecte en exceso al rendimiento.
Las capacidades de Vyatta son muy amplias, router, firewall, IDS, IPS,
balanceador de carga, Proxy web, VPN, Filtro de URL, alta disponibilidad y todo
en una suite de software Open Source basado en Debian que permite integrar un
econmico appliance de red de clase empresarial, comparable a cualquier
solucin propietaria, en todo entorno de produccin.
En resumen, Vyatta puede utilizarse para:
Escalar amplias implementaciones BGP de forma asequible.
Mantener tu red segura con su stateful firewall.
Proporcionar conexiones seguras a oficinas remotas con VPN.
Escalar de DSL a 10 Gbps con un paquete de software.
Evitar costes en actualizaciones propietarias.
Correr entornos de red virtualizados en Xen y VMware.
Aadir networking y seguridad a los servidores blade de tu centro de datos.
Ofrecer servicios de seguridad gestionada basados en red.
Dotar de redundancia de red con independencia de los fabricantes de

hardware.
Aunque Vyatta se puede instalar en cualquier sistema, la empresa que desarrolla

el software tambin vende soluciones completas integrales de hardware y
26
software. Existen tres ediciones de Vyatta: Vyatta Core, Vyatta Subscription

Edition y Vyatta Plus. Se puede ver un breve resumen del catlogo de Vyatta en:
http://www.vyatta.com/downloads/datasheets/vyatta_solutions_guide.pdf
Vyatta, al igual que las soluciones de Cisco, tambin incluye una interfaz de
manejo por lnea de comandos, as como una interfaz web muy completa. El
sistema viene como un LiveCD. La lnea de comandos y su configuracin es muy
similar a los routers Juniper.
2.6. Anlisis de rendimiento: QEMU vs VirtualBox
Para emular un dispositivo Juniper con el software JUNOS y poder trabajar con l
en el GNS3 se tienen dos opciones: crear y ejecutar una Oliva con QEMU o
crearla y ejecutarla con VirtualBox. A priori estos dos programas de virtualizacin
nos pueden servir pero para ver qu opcin es la ms apropiada se ha realizado
un estudio comparativo y as poder determinar cul se comporta mejor, tanto en
rendimiento como en utilizacin de recursos.
El estudio ha consistido en la creacin del siguiente escenario con un total de 5

routers Juniper.
3 routers con VirtualBox: srxA1, srxA2, INTERNET.
2 routers con QEMU: vr101, vr102.
4 Hosts con QEMU.
27
Figura 3: Escenario utilizado para anlisis de rendimiento.
Se ha implementado y ejecutado dicho escenario en una mquina anfitriona Intel

x4 i5 M450 a 2.4 GHz tanto en sistema operativo Ubuntu 12.0 como en Windows
7 64 bits. Se han realizado 8 muestras y se han tomado los tiempos de arranque
(hasta que aparece el login) de todos los dispositivos y los recursos utilizados. En
base a estas muestras se han calculado los tiempos medios de arranque y
recursos utilizados para ambas plataformas, W7 y Ubuntu.
Los resultados finales son los siguientes:

UBUNTU
W7 64b
TMA VB (seg)
105,42
120,42
TMA QEMU (seg)
420,50
878,38
Load MEM (GB)
1,92475
1,75
% CPU
13,25%
25,75%
Figura 4: Tabla de tiempos y carga del sistema anfitrin.
Como podemos observar en la tabla resumen, la diferencia entre utilizar mquinas

virtuales con VirtualBox y con QEMU es bastante significativa. Mientras que
28
QEMU se comporta mucho mejor en plataformas Linux, en plataformas Windows

el tiempo de arranque se duplica. Pero aun as, los mejores tiempos de arranque
se obtienen con VirtualBox y en ambas plataformas, siendo muy notable la
diferencia en plataformas Windows. Por lo tanto, podemos concluir que la
mquinas virtuales funcionan mucho mejor con el sistema de virtualizacin
VirtualBox que con QEMU. Y como era de esperar, el escenario en su conjunto, y
una vez puesto en marcha, utiliza menos recursos en plataformas Linux que en
Windows.
Tiempo Medio de Arranque (Seg.)

1000,00
800,00
TMA VB
600,00
TMA QEMU
400,00
200,00
0,00
UBUNTU
W7 64b
Figura 5: Tiempo medio que tardan en arrancar las Olivas segn el

sistema operativo y el sistema de virtualizacin.
En la grfica superior podemos observar la comparativa de los tiempos medios de

arranque, desde que se inician las MV hasta que aparece el Login. Las unidades
de tiempo estn en segundos. La mejor configuracin para utilizar Olivas, en
cuanto a tiempo y mximo nmero de MV en un escenario, es utilizar un
ordenador anfitrin con un sistema operativo Linux Ubuntu 12.0, GNS3 y
VirtualBox para Linux. En esta configuracin, a GNS3 no hay que ajustarle ningn
parmetro tal como IDLE-PC, ya que ste slo es til para IOS de CISCO y no
para MV.
29
Load MEM
% CPU
30,00%
1,5
20,00%
1
10,00%
0,5
0,00%
0
UBUNTU
W7 64b
UBUNTU
W7 64b
Figura 6: a) Carga de memoria segn SO. b) Carga de la CPU segn SO.
En un ordenador estndar, que utilice Windows, la diferencia de utilizar VirtualBox

a QEMU es bastante importante: de tardar apenas unos 2 minutos con VirtualBox
a tardar ms de 14,5 minutos con QEMU.
Si queremos simular escenarios grandes para ver cmo se comportan protocolos

tales como OSPF o BGP, en donde hayan una gran cantidad de routers Juniper,
la mejor opcin ser utilizar la plataforma Ubuntu 12.0 y VirtualBox.
30
3.
Instalacin de Olivas
3.1. Introduccin
Una Oliva es el apodo utilizado para referirse al software JUNOS, que se ejecuta
en los dispositivos Juniper, pero ejecutndose en un PC normal. Podramos
pensar que este software es una versin especial o distribuida exclusivamente
para su ejecucin en PC normales, pero en realidad se trata del mismo software
convencional que se carga en los equipos Juniper.
El fabricante Juniper desarroll la funcionalidad Oliva como una plataforma de

desarrollo software, incluso antes de tener desarrollado el hardware especfico.
No se trata de un simulador de router, ni tampoco un equipo que es capaz de
llevar trfico real y por lo tanto ponerlo en produccin. Estas mquinas
normalmente se utilizan para fines educativos, ya que es la nica forma
econmica de tener acceso al equipamiento Juniper y as poder practicar para las
certificaciones. Tambin suelen utilizarse en laboratorios para pruebas con fines
de investigacin.
Hay que tener presente que la posicin oficial del fabricante Juniper es que las
Olivas no existen. Estas plataformas de por s no disponen de licencia ni
autorizacin por parte del fabricante y por lo tanto son plataformas ilegales, sin
ningn tipo de soporte o apoyo, y menos para uso comercial. Por eso, no se debe
abusar de ellas, ni solicitar soporte oficial ya que el fabricante Juniper fcilmente
podra implementar controles adicionales al software para impedir que funcione.
En este captulo vamos a explicar cmo crear una mquina virtual que
implemente el IOS JUNOS versin 9.6 y versin 10.4.
31
3.2. Requisitos mnimos
Para la versin Junos 9.6, que es con la que se van a implementar los dos
primeros laboratorios, los requisitos mnimos en cuanto al Hardware son:
PC genrico con al menos una tarjeta de red Intel EtherExpress

PRO/100MB.
Disco duro IDE de 10GB. Se recomienda con formato NTFS para Windows.
Memoria RAM de 512MB.
En cuanto al software, se necesitar lo siguiente:
El paquete de instalacin FreeBSD 4.11 mini-iso i386, que se puede

descargar gratuitamente de la direccin:
ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/ISOIMAGES/4.11/4.11-RELEASE-i386-miniinst.iso
Una copia del paquete junos jinstall-9.6R1.13-export-signed.tgz.
El programa Virtual Serial Port Emulator para el entorno Windows.
3.3. Instalacin de una Oliva
Para crear la mquina virtual en un sistema Windows se necesitar tener

instalado la versin de VirtualBox 4.2.16 para host Windows. Tambin se
requerir tener instalado el programa Virtual Serial Port Emulator, en la versin
0.938 que est disponible con licencia libre, para poder acceder al puerto serie de
la Oliva.
Se recomienda crear la Oliva en una plataforma Windows 7 o Linux. En el entorno

Windows XP es posible que d problemas de espacio en disco, tal y como hemos
sufrido, a la hora de lanzar la instalacin del paquete IOS Junos modificado.
32
3.3.1. Instalando FreeBSD
Los requerimientos iniciales para poder crear una maquina VirtualBox son:
1 CPU.
Inicialmente 512 MB de RAM. Una vez acabada la instalacin se podr

reducir a 128MB.
Unidad de CD/DVD.
Adaptador de Red e1000. Este adaptador hace que VB instale el driver

para el chipset de Intel y por lo tanto JUNOS sea capaz de utilizarlo.
10GB de espacio de disco.
Los pasos a seguir en las ventanas de configuracin son los siguientes:

3.3.1.1.
Creacin nueva instancia en VirtualBox.
33
Figura 7: Pantallas para la creacin de una mquina virtual con el VirtualBox.
3.3.1.2.
Una vez creada la instancia de nuestra nueva mquina virtual,

editamos la configuracin y le indicamos dnde tenemos la imagen
ISO del sistema FreeBSD. Tambin es importante configurar el
Puerto Serie de nuestra mquina que lo haremos ms adelante.
Figura 8: Propiedades de configuracin de una MV.
3.3.1.3.
Iniciamos nuestra MV que iniciar el proceso de instalacin del SO

FreeBSD y en el Menu de Configuracin del Kernel escogemos la
primera opcin: Skip kernel configuration and continue with
installation.
34
Figura 9: Pantalla de arranque inicial de la MV con FreeBSD.
Figura 10: Men de configuracin del kernel FreeBSD.
3.3.1.4.
En el men principal de instalacin escogemos la instalacin

Standard.
35
Figura 11: Pantalla principal de instalacin FreeBSD.
3.3.1.5.
En la pantalla de las particiones seleccionamos A (Use Entire disk) y

luego Q para salir.
Figura 12: Editor de particiones FDISK.
3.3.1.6.
En el men de instalacin del Boot Manager escogemos la primera

opcin: BootMgr, Install the FreeBSD Boot Manager.
36
Figura 13: Men del gestor de arranque.
3.3.1.7.
Nos aparecer el editor de particiones donde iremos creando con la

tecla C cada una de las particiones que se muestran a continuacin.
Para finalizar teclear Q.
Figura 14: Editor de filesistems de FreeBSD.
3.3.1.8.
En el men de distribucin elegir el tipo Minimal, y no instalar Ports

Collection. Para salir y continuar elegir Exit.
37
Figura 15: Men de distribuciones FreeBSD.
3.3.1.9.
En el siguiente men elegimos el medio donde est nuestra distribucin, CD/DVD. Nos preguntar si estamos seguros de realizar la
instalacin, elegimos YES. En este momento comenzar la
instalacin de FreeBSD.
Figura 16: Men de origen de instalacin FreeBSD.
38
3.3.2. Configuracin Post-Instalacin
3.3.2.1.
Configuramos la interface Ethernet. Seleccionamos el tipo em0,

Intel PRO/1000 ethernet card. NO configuracin IPv6. SI DHCP.
Figura 17: Men configuracin de red.
3.3.2.2.
No Network Gateway.
3.3.2.3.
NO inetd.
3.3.2.4.
NO Anonymous FTP.
3.3.2.5.
NO NFS Client y Server.
3.3.2.6.
NO Select Default Security Porfile.
3.3.2.7.
NO Customize System Console.
3.3.2.8.
Configurar Set Time Zone. NO UTC. Elegir la zona de Europa,

Espaa.
3.3.2.9.
NO Enable Linux Binary Compatibility.
3.3.2.10. NO USB Mouse.

3.3.2.11. NO Browse Package Collection.
3.3.2.12. NO Add Counts.
3.3.2.13. Definir un password para el usuario root.
3.3.2.14. NO General Configuration Menu.
39
3.3.2.15. En el men principal elegimos salir de la instalacin. Finalizamos

definitivamente la instalacin y automticamente reiniciara la MV.
Figura 18: Men principal SysInstall FreeBSD.
3.3.2.16. En este momento apagamos la MV para poder configurar el VSPE

y quitar la imagen de instalacin FreeBSD.
3.3.3. Configuracin Virtual Serial Port Emulator
A continuacin vamos a configurar una conexin serial virtual entre la MV y un

programa de conexin terminal como Putty. Se trata de hacer como si fuera un
tnel entre el puerto serie COM1 de la MV y un puerto serie de nuestra mquina
anfitriona.
3.3.3.1.
Vamos a las propiedades de la MV y en la pestaa de Puertos

Serie lo configuramos de la siguiente manera.
40
Figura 19: Configuracin puerto serie de la MV
3.3.3.2.
Ahora ejecutamos el programa Virtual Serial Port Emulator y

apretamos el botn de Create new device.
Figura 20: Ventana principal VSPE.
3.3.3.3.
En la ventana de configuracin de la nueva conexin elegiremos el

tipo de conexin Connector, y el COM3 como Virtual Serial Port.
41
Figura 21: a) Definicin tipo de conexin. b) Definicin puerto virtual.
3.3.3.4.
Una vez finalizada la configuracin de la conexin virtual,

tendremos ya listo y preparado el tnel serie.
Figura 22: Ventana principal con el estado del puerto serie virtual.
3.3.4. Instalacin IOS Junos 9.6
A continuacin vamos a instalar el IOS Junos 9.6 en nuestra MV y para ello

debemos copiar en ella los siguientes archivos:
42
jinstall-9.6R1.13-export-signed.tgz
jweb-9.6R1.13-signed.tgz
Podemos hacerlo de varias formas, a travs de un servidor FTP en nuestra

mquina anfitriona y luego simplemente descargando los ficheros, o creando un
archivo ISO y montndolo en la MV. En el ejemplo vamos a utilizar ste ltimo
mtodo.
3.3.4.1.
Accedemos a las propiedades de la MV y en la pestaa de

Almacenamiento asociamos nuestra imagen ISO , fichero JUNOS
R9.6.ISO, en el CD/DVD. Arrancamos la MV y accedemos como
root con la contrasea que definimos en la instalacin.
3.3.4.2.
Lo siguiente ser copiar los ficheros en el directorio /var/tmp/, y

extraeremos el contenido del fichero jinstall-export-signed.
Olive# cd /var/tmp/
Olive# mount /cdrom
Olive# cp /cdrom/* .
Olive# mkdir signed
Olive# cd signed/
Olive# tar zxvf ../jinstall-9.6R1.13-export-signed.tgz
Olive# mkdir jinst
Olive# cd jinst
Olive# tar zxvf ../jinstall-9.6R1.13-export.tgz
3.3.4.3.
A partir de la versin JUNOS 7.4, Juniper implant una proteccin

por medio de un fichero binario llamado checkpic que deberemos
sustituirlo por el archivo ubicado en /usr/bin/true.
Olive# mkdir pkgtools

Olive# cd pkgtools
Olive# tar zxvf ../pkgtools.tgz
Olive# cd bin
Olive# cp /usr/bin/true ./checkpic
Olive# cd ..
Olive# tar zcvf ../pkgtools.tgz *
Olive# cd ..
Olive# rm -rf pkgtools
Olive# tar zcfv /var/tmp/jinstall-9.6R1.13-export-olive.tgz *
Olive# cd /var/tmp
43
Olive# rm r signed/
3.3.4.4.
Ahora ya tenemos listo el paquete de instalacin y procederemos a

su instalacin. Es muy importante que antes de iniciar la
instalacin tengamos abierta una sesin con el terminal Putty ya
que en el momento que reinicie la MV empezar a redirigir toda su
salida hacia el puerto serie y debemos comprobar si nos aparece
algn error.
Olive# pkg_add /var/tmp/jinstall-9.6R1-13-export-olive.tgz
3.3.4.5.
Nos aparecer un mensaje informndonos que se iniciar la

instalacin despus de reiniciar.
Figura 23: Mensajes iniciales de la instalacin del paquete Junos.
3.3.4.6.
Si nos apareciese el siguiente error, es muy probable que sea del

propio SO Windows. Recomendamos realizar la creacin de la
Oliva con en Linux o Windows 7.
44
Figura 24: Mensaje de error de instalacin paquete Junos.
3.3.4.7.
Una vez iniciada la instalacin nos pedir realizar un reboot. A

partir de este momento todos los mensajes aparecern en la
sesin Putty.
Figura 25: Reinicio previo al comienzo de la instalacin paquete Junos.
3.3.4.8.
Es ms que probable que se produzcan varios reinicios. En la

sesin Putty empezar a aparecernos lo siguiente.
45
Figura 26: Captura del inicio de la instalacin Junos con el programa Putty y a
travs del puerto serie virtual.
3.3.4.9.
Una vez finalizada la instalacin nos aparecer el inicio de sesin y

ya habremos concluido la creacin de la Oliva.
Figura 27: Arranque inicial de la Oliva con versin Junos 9.6R1.13.
46
3.3.5. Instalacin JWeb Junos 9.6
Para completar nuestra Oliva, vamos a instalar el entorno WEB. Para ello
necesitamos tener en el disco duro de nuestra Oliva el siguiente paquete:
Si recuerdan, este paquete ya se copi al directorio /var/tmp/. A continuacin

describimos los pasos para la instalacin:
3.3.5.1.
Arrancamos la MV y esperaremos a que nos aparezca el login.

Recordar que no aparecern los mensajes de informacin de
arranque ya que stos estn dirigidos hacia el puerto serie. Si
abrimos una sesin terminal al puerto serie virtual veremos la traza
de arranque. Accedemos como root e interrogamos al router para
saber qu versiones y paquetes se han instalado.
Figura 28: Captura de los paquetes instalados en la Oliva (comando show

version).
47
3.3.5.2.
Accedemos al modo de configuracin y asignamos una password

al usuario root. Luego crearemos un nuevo usuario para poder
acceder al entorno web ya que el sistema no permite el acceso a
root.
Amnesiac (ttyd0)
login: root
Last login: Sat Aug 3 00:40:43 on ttyv0
--- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC
root@% cli
root> configure
Entering configuration mode
[edit]
root# set system host-name oliva
[edit]
root# set system root-authentication plain-text-password
New password:
Retype new password:
[edit]
root# set system login user webadmin class super-user authentication plaintext-password
New password:
[edit]
root# commit and-quit
commit complete
Exiting configuration mode
3.3.5.3.
Ejecutamos el comando para iniciar la instalacin del paquete web.
root@oliva> request system software add /var/tmp/jweb-9.6R1.13-signed.tgz
3.3.5.4.
Nos aparecern los mensajes de la instalacin del paquete y nos

pedir reiniciar el entorno de comandos cli.
48
Figura 29: Mensajes iniciales instalacin paquete JWEB.
3.3.5.5.
Volvemos a acceder al router y ejecutamos otra vez el comando
show versin. Como podemos observar, ahora nos aparece

instalado el paquete Web.
root@oliva> show version
Hostname: oliva
Model: olive
JUNOS Base OS boot [9.6R1.13]
JUNOS Base OS Software Suite [9.6R1.13]
JUNOS Kernel Software Suite [9.6R1.13]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.6R1.13]
JUNOS Packet Forwarding Engine Support (M20/M40) [9.6R1.13]
JUNOS Online Documentation [9.6R1.13]
JUNOS Voice Services Container package [9.6R1.13]
JUNOS Border Gateway Function package [9.6R1.13]
JUNOS Services AACL Container package [9.6R1.13]
JUNOS Services LL-PDF Container package [9.6R1.13]
JUNOS Services Stateful Firewall [9.6R1.13]
JUNOS AppId Services [9.6R1.13]
JUNOS IDP Services [9.6R1.13]
JUNOS Routing Software Suite [9.6R1.13]
JUNOS Web Management [9.6R1.13]
3.3.5.6.
Accedemos al modo de configuracin y activamos el servicio

HTTP.
49
root@oliva> configure
[edit]
root@oliva# set system services web-management http interface em0.0
[edit]
root@oliva# commit and-quit
commit complete
root@oliva>
3.4.
Configurando la Oliva en GNS3
A continuacin vamos a configurar el GNS3 para que se pueda utilizar la Oliva

creada.
3.4.1. Abrimos el programa GNS3 y nos vamos a men Editar/Preferencias.

En dicha ventana nos vamos al apartado VirtualBox y comprobamos si
el GNS3 tiene acceso a la API de Virtualbox apretando el botn Test
Settings. Si la prueba NO ha sido satisfactoria, desinstalar el Virtualbox
y volverlo a instalar con la versin ms reciente.
50
Figura 30: Ventana Preferences de GNS3: comprobacin comunicacin con

VirtualBox.
3.4.2. Una vez comprobada la configuracin con VirtualBox, nos situamos en

la pestaa VirtualBox Guest. Definimos una nueva mquina virtual tal y
como mostramos a continuacin. Recordar actualizar el listado de MV
del VirtualBox por medio del botn Refresh VM List. Guardamos nuestra
nueva mquina.
51
Figura 31: Ventana Preferences de GNS3: definicin de las MV.
3.4.3. Ahora nos situamos en el men, Editar/Symbol Manager. Se nos abrir

una ventana donde crearemos un nuevo smbolo para nuestros
dispositivos Junos. Crearemos un nuevo smbolo tal y como mostramos
a continuacin.
52
Figura 32: Administracin de smbolos en GNS3.
3.5.
Comprobacin de la Oliva JWeb Junos 9.6
Una vez hemos configurado el entorno del GNS3, nos quedara comprobar que
tenemos acceso al cli de nuestro nuevo dispositivo Junos y que tenemos en
ejecucin el entorno de configuracin WEB Junos.
3.5.1. Creamos un nuevo escenario, seleccionamos nuestro nuevo smbolo en

el panel Node Types y lo arrastramos al panel central. Nos preguntar
qu MV queremos insertar y elegimos la que acabamos de crear, Olive
9.6 WEB.
Figura 33: Listado de MV disponibles para los escenarios.
53
3.5.2. Insertamos un objeto Nube para poder interconectar el router con

nuestra mquina anfitriona y un Switch Ethernet.
Figura 34: Ventana principal GNS3 con un escenario cargado.
3.5.3. Accedemos a las propiedades de la Nube y agregamos la conexin

Conexin de rea local.
Figura 35: Configuracin de nodo: asignacin de interfaces.

54
3.5.4. Apretamos el botn de agregar vnculos en el panel de iconos y

creamos los enlaces tal y como se muestra en el punto 5.2. Arrancamos
nuestro escenario y abrimos la consola de la Oliva comprobando que
tenemos acceso al dispositivo.
Figura 36: Acceso a la Oliva con GNS3.
3.5.5. Por ltimo slo nos queda comprobar que podemos acceder al entorno
WEB de nuestro router. Configuramos la interface em0 del router con la
IP 192.168.1.200/24 y la interface VirtualBox de nuestra mquina
anfitriona con la IP 192.168.1.20/24.
[edit]
root@oliva# set interfaces em0 unit 0 family inet address 192.168.1.200/24
[edit]
commit complete
root@oliva> show interfaces terse
Interface
Admin Link Proto Local
dsc
up up
em0
up up
Remote
55
em0.0
em1
em2
em3
gre
ipip
lo0
lo0.16384
lo0.16385
lsi
mtun
pimd
pime
tap
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up inet
down
down
down
up
up
up
up inet
up inet
up
up
up
up
up
10.10.10.1/24
127.0.0.1
--> 0/0
root@oliva>
3.5.6. Abrimos un navegador web, ponemos la IP de nuestro router y se nos
mostrar la pantalla de bienvenida y login.
Figura 37: Pantalla de bienvenida al acceso va Web.
3.5.7. Accedemos al router con el usuario webadmin y nos aparecer el

entorno web.
56
Figura 38: Pantalla de configuracin del router con el JWEB.
Una vez se ha finalizado por completo la creacin de la mquina virtual con la

versin Junos 9.6R1.13 y con el paquete Web, se constata que el conjunto total
de la MV nos ocupa un total de 2,32GB.
Ahora podemos editar las propiedades de la MV y disminuir la RAM a 256MB para

no sobrecargar tanto el sistema anfitrin cuando tengamos en marcha varias MV
en ejecucin. Antes no se puede disminuir porque si no la instalacin del software
Junos nos hubiera dado un error por falta de memoria. Otro comportamiento
anmalo que se ha detectado y por ello nos obliga a ajustar el tamao de la
memoria RAM es que si consumimos muchos recursos RAM en el sistema
anfitrin (varias Olivas en ejecucin), dejando poca memoria para el SO anfitrin,
entonces es muy probable que alguna MV Oliva no nos arranque bien y se quede
bloqueada al inicio de su arranque.
57
3.6.
Instalacin IOS Junos 10.4R1.9
En este apartado vamos a explicar los pasos para crear una Oliva con la versin
Junos 10.4R1.9 que es muy estable y la cual nos servir para todos los laboratorios que se han preparado.
Muchos de los pasos para esta versin son idnticos que en la versin Junos 9.6,
por lo que se omitir su explicacin y desarrollo.
3.6.1. Instalacin FreeBSD
Realizaremos los mismos pasos que en la versin anterior pero modificando los
siguientes parmetros:
3.6.1.1.
El tamao del disco duro en VirtualBox ser de 8GB.
Figura 39: Definicin del tamao del disco duro para una MV en
VirtualBox.
58
3.6.1.2.
Utilizaremos la misma distribucin FreeBSD.
Figura 40: Propiedades de configuracin de la MV para Junos 10.4.
3.6.1.3.
El tamao de memoria RAM ser de 512MB.
3.6.1.4.
Las particiones a crear tendrn el siguiente tamao:

-
1GB para directorio raz /.
1GB para el swap.
512MB para el directorio /config.
El resto para el directorio /var.
59
Figura 41: Tabla de particiones de FreeBSD para Junos 10.4.
Figura 42: Distribucin del filesystem para Junos 10.4.
El resto de pasos ser el mismo que en la versin 9.6.
3.6.2. Instalacin Junos 10.4R1.9
Para la instalacin del IOS Junos 10.4R1.9 crearemos un archivo ISO con los
siguientes ficheros:
60
jinstall-10.4R1.9-domestic-signed.tgz
Por lo dems, se seguirn las mismas indicaciones que en la versin Junos 9.6
excepto un nuevo paso:
3.6.2.1.
Montar la unidad CD/DVD con el fichero ISO que contiene los

paquetes. Copiar los ficheros IOS en el directorio /var/tmp/.
Olive# cd /var/tmp/
Olive# mount /cdrom
Olive# cp /cdrom/* .
3.6.2.2. Descomprimir los ficheros jinstall,
Olive# mkdir signed
Olive# cd signed/
Olive# tar zxvf ../jinstall-10.4R1.9-domestic-signed.tgz
Olive# mkdir jinst
Olive# cd jinst
Olive# tar zxvf ../jinstall-10.4R1.9-domestic.tgz
3.6.2.3.
En este nuevo paso vamos a editar los ficheros +INSTALL y +

REQUIRE, que se han extrado del ltimo fichero jinstall-
10.4R1.9-domestic.tgz, y sustituiremos una lnea de cdigo.

Empezaremos por el fichero +INSTALL y buscamos la siguiente
parte del cdigo que se encuentra en la lnea 2110:
Olive# edit ./+INSTALL
Nos desplazamos hasta la lnea 2110 y dejamos la funcin tal y como

indicamos.
61
check_arch_compatibility()
{
#rename="`/sbin/sysctl -n hw.re.name 2>/dev/null`
re_name="olive"
if [ -z "$re_name" ]; then
Error "hw.re.name sysctl not supported."
fi
Para insertar el carcter # apretar shift+3.Para salir del editor apretar la
tecla ESC, leave editor y luego save changes.
Figura 43: Modificacin archivo +INSTALL.
3.6.2.4.
Ahora realizamos la misma operacin en el fichero +REQUIRE.
Olive# edit ./+REQUIRE
Nos desplazamos hasta la lnea 2110 y dejamos la funcin tal y como

indicamos.
62
check_arch_compatibility()
{
#rename="`/sbin/sysctl -n hw.re.name 2>/dev/null`
re_name="olive"
if [ -z "$re_name" ]; then
Error "hw.re.name sysctl not supported."
fi
Para insertar el carcter # apretar shift+3. Para salir del editor apretar la
tecla ESC, leave editor y luego save changes.
3.6.2.5.
Copiamos el archivo true.
Olive# mkdir pkgtools

Olive# cd pkgtools
Olive# tar zxvf ../pkgtools.tgz
Olive# cd bin
Olive# cp /usr/bin/true ./checkpic
3.6.2.6.
Volvemos a empaquetar los ficheros pkgtools.tgz y jinstallolive.tgz.
Olive# cd ..
Olive# tar zcvf ../pkgtools.tgz *
Olive# cd ..
Olive# rm -rf pkgtools
Olive# tar zcfv /var/tmp/jinstall-10.4R1.9-domestic-olive.tgz *
Olive# cd /var/tmp
Olive# rm r signed/
3.6.2.7.
Por ltimo, instalamos el paquete modificado.
Olive# pkg_add jinstall-10.4R1.9-domestic-olive.tgz
63
Figura 44: Mensajes iniciales instalacin paquete Junos 10.4.
3.6.2.8.
Una vez hayamos reiniciado la MV, empezar la instalacin y

veremos la traza en el terminal Putty.
Figura 45: Proceso de instalacin Junos 10.4.
3.6.2.9.
Al cabo de unos instantes nos aparecer el prompt.
Amnesiac (ttyd0)
login: root
64
--- JUNOS 10.4R1.9 built 2010-12-04 09:20:43 UTC

root@% cli
root> show version
Model: olive
JUNOS Crypto Software Suite [10.4R1.9]
JUNOS Services PTSP Container package [10.4R1.9]
JUNOS Services NAT [10.4R1.9]
JUNOS Services Application Level Gateways [10.4R1.9]
JUNOS Services Captive Portal and Content Delivery Container package
[10.4R1.9]
JUNOS Services RPM [10.4R1.9]
JUNOS Runtime Software Suite [10.4R1.9]
3.6.3. Instalacin JWeb Junos10.4
Para la instalacin del paquete JWEB 10.4R1.9 realizaremos los mismos pasos
que para la versin 9.6.
3.6.3.1.
Accedemos al router y ejecutamos los siguientes comandos.
login: root
Last login: Sat Aug 3 00:40:43 on ttyv0
--- JUNOS 10.4R1.9 built 2010-12-04 09:20:43 UTC
root@% cli
root> configure
[edit]
65
root# set system host-name oliva

[edit]
root# set system root-authentication plain-text-password
New password:
[edit]
root# set system login user adminweb class super-user authentication plaintext-password
New password:
[edit]
root# commit and-quit
commit complete
3.6.3.2.
Ejecutamos el comando para iniciar la instalacin del paquete web.
root@oliva> request system software add /var/tmp/jweb-10.4R1.9signed.tgz
3.6.3.3.
Nos aparecern los mensajes de la instalacin del paquete y nos

pedir reiniciar el entorno de comandos cli.
Figura 46: Proceso de instalacin paquete JWEB 10.4.

66
3.6.3.4.
Volvemos a acceder al router y ejecutamos otra vez el comando
show versin. Como podemos observar, ahora nos aparece

instalado el paquete Web.
root@olive> show version
Hostname: olive
Model: olive
JUNOS Crypto Software Suite [10.4R1.9]
JUNOS Services PTSP Container package [10.4R1.9]
JUNOS Services NAT [10.4R1.9]
JUNOS Services Application Level Gateways [10.4R1.9]
JUNOS Services Captive Portal and Content Delivery Container package
[10.4R1.9]
JUNOS Services RPM [10.4R1.9]
JUNOS Runtime Software Suite [10.4R1.9]
JUNOS Web Management [10.4R1.9]
3.6.3.5.
Accedemos al modo de configuracin y activamos el servicio

HTTP.
[edit]
root@oliva# set system services web-management http interface em0.0
[edit]
67
commit complete
3.7.
Comprobacin de la Oliva JWeb Junos 10.4
Para comprobar que el entorno web est activo y es accesible desde GNS3,
vamos a configurar el anterior escenario creado para la versin 9.6 y aadir un
nuevo dispositivo con Junos 10.4.
3.7.1. Accedemos al GNS3, Editar/Preferencias, y aadimos una nueva MV

en las preferencias de VirtualBox.
Figura 47: Listado definiciones de MV en GNS3.
3.7.2. Luego seleccionamos del panel Node Types un router Juniper y lo

arrastramos hasta nuestro escenario. Escogemos del listado de MV
disponibles la que acabamos de crear, Olive 10.4 WEB.
68
Figura 48: Configuracin de la Oliva 10.4 en un escenario.
3.7.3. Iniciamos nuestro nuevo dispositivo y configuramos la IP 192.168.1.210

en la interface em0.
[edit]
root@oliva# set interfaces em0 unit 0 family inet address 192.168.1.210/24
[edit]
commit complete
3.7.4. Ahora comprobamos con un navegador que tenemos acceso al entorno

Web.
69
Figura 49: Pantalla de bienvenida JWEB 10.4.
3.7.5. Accedemos al sistema con el usuario creado anteriormente y verificamos el acceso.
Figura 50: Pantalla configuracin via Web Junos 10.4.
70
4.
Lab 1: Fundamentos de Routing
Este laboratorio demuestra la configuracin y monitorizacin del nivel 3 de routing

en dispositivos que ejecutan el sistema operativo JUNOS bajo el emulador GNS3.
En esta prctica se utilizar la lnea de comandos (CLI) para configurar y
monitorizar interfaces, rutas estticas y OSPF. Durante todas estas tareas de
configuracin, conseguiremos familiarizarnos con la descripcin de los contenidos
de las tablas de routing y forwarding.
Figura 51: Escenario del laboratorio Fundamentos de Routing.
Para implementar el escenario del laboratorio se necesitarn los siguientes

elementos:
5 Maquinas Virtual Box (MVB) con el SO JUNOS.
4 MVB con el SO Linux.
71
Los requerimientos mnimos en cuanto al Hardware/Software de la mquina

anfitriona para poder emular las mquinas virtuales sern:
Intel/AMD con cuatro ncleos a 2.4 GHz.
3GB de memoria RAM.
Windows XP, preferiblemente Ubuntu 12.x.
Para completar este laboratorio se realizarn las siguientes tareas:
Configurar y verificar el correcto funcionamiento de las interfaces de red.
Configurar y monitorizar las rutas estticas.
Configurar y monitorizar OSPF.
Parte 1: Configuracin y Monitorizacin de Interfaces
En esta parte se configurarn las interfaces de red del equipo asignado. Se

verificar que las interfaces estn funcionando correctamente y que el sistema
aade las correspondientes entradas en la tabla de enrutamiento.
1.1.
Una vez se hayan asignado los equipos, consultar el diagrama de red para
determinar el direccionamiento que poseen las interfaces del router.
Cuestin: Cul es la direccin de gestin asignada a tu PC?

Como ejemplo, si tenemos asignado el equipo srxA1, la direccin IP de la
interface de salida hacia el PC de gestin ser 10.210.14.131/27
perteneciendo a la subred 10.210.14.128/27. Por lo tanto, la IP de nuestro
PC de gestin se escoger entre el rango comprendido entre 129-158.
LinuxMNT> ifconfig eth0 10.210.14.129 netmask 255.255.255.224
lab@srxA1> set interfaces em0 unit 0 family inet address 10.210.14.131/27
1.2.
Ejecuta el comando show route para mostrar el contenido de la tabla de

enrutamiento.
72
lab@srxA1> show route

inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.210.14.128/27 *[Direct/0] 23:39:24 > via em0.0
10.210.14.131/32 *[Local/0] 23:39:31 Local via em0.0
Cuestin: Qu tabla de enrutamiento es la que se muestra con este

comando?
La salida debera mostrar la tabla inet.0 que es la tabla de enrutamiento
primaria IPv4. Se pueden mostrar todas la tablas de enrutamiento y su
contenido utilizando el comando show route all tal y como se muestra a
continuacin:
lab@srxA1> show route all
10.210.14.128/27
*[Direct/0] 1w4d 21:15:32 > via em0.0
10.210.14.131/32
*[Local/0] 1w4d 21:15:37 Local via em0.0
__juniper_private1__.inet.0: 4 destinations, 4 routes (2 active, 0 holddown, 2
hidden)
10.0.0.1/32
*[Direct/0] 1w4d 21:18:48 > via lo0.16385
10.0.0.16/32
*[Direct/0] 1w4d 21:18:48 > via lo0.16385
128.0.0.1/32
[Direct/0] 1w4d 21:18:48 > via lo0.16385
128.0.1.16/32
[Direct/0] 1w4d 21:18:48 > via lo0.16385
__juniper_private2__.inet.0: 1 destinations, 1 routes (0 active, 0 holddown, 1
hidden)
127.0.0.1/32
[Direct/0] 1w4d 21:18:48 > via lo0.16384
__juniper_private1__.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0
hidden)
fe80::221:59ff:fe27:fec0/128 *[Direct/0] 1w4d 21:18:48 > via lo0.16385
Cuestin: Qu entradas de rutas estn presentes en la tabla inet.0?

En la tabla debe aparecer una nica entrada DIRECT y otra LOCAL.
Ambas rutas estn asociadas a la interface em0. La ruta DIRECT coincide
73
con la direccin IP asignada a la interface em0 mientras que la ruta LOCAL

coincide con la red de gestin.
1.3.
Accede al modo configuracin y situarse en el nivel [edit interfaces].

lab@srxA1> configure
[edit]
lab@srxA1# edit interfaces
[edit interfaces]
lab@srxA1#
1.4.
Segn el diagrama de red, configura las interfaces de tu equipo asignado.

Utiliza la VLAN-ID segn el equipo asignado, 101 102. Utiliza la unidad 0
para el resto de interfaces. No olvidar configurar la interface loopback.
[edit interfaces]
lab@srxA1# set lo0 unit 0 family inet address 192.168.x.1/32
[edit interfaces]
lab@srxA1# set em3 unit 0 family inet address 172.18.x.2/30
[edit interfaces]
lab@srxA1# set em2 unit 0 family inet address 172.20.66.x/30
[edit interfaces]
lab@srxA1# set em1 unit 0 family inet address 172.20.77.x/30
[edit interfaces]
lab@srxA1# set em4 vlan-tagging
[edit interfaces]
lab@srxA1# set em4 unit 10v vlan-id 10v
[edit interfaces]
lab@srxA1# set em4 unit 10v family inet address 172.20.10v.1/24
Nota: Se ha observado que en las interfaces en las que se les configura la

etiquetacin VLAN, funcionan exclusivamente hasta que se reinicia el ruter.
74
Una vez se haya reiniciado un ruter, las VLANs se quedan en el estado

administrativo DOWN siendo la nica manera de activarlas el realizar un
borrado y una nueva configuracin.
1.5.
Mostrar la configuracin de las interfaces y asegurarse de que coinciden

con el diagrama de red de este laboratorio. Una vez estemos seguros de
que dicha configuracin es la correcta, ejecutar el comando commit-andquit para activar la configuracin y volver al modo operacional.
[edit interfaces]
lab@srxA1# show
em0 {
description "MGMT Interface - DO NOT DELETE";
unit 0 {
family inet {
address 10.210.14.131/27;
}
}
}
em1 {
unit 0 {
family inet {
address 172.20.77.1/30;
}
}
}
em2 {
unit 0 {
family inet {
address 172.20.66.1/30;
}
}
}
em3 {
unit 0 {
family inet {
address 172.18.1.2/30;
}
}
}
em4 {
vlan-tagging;
unit 101 {
vlan-id 101;
75
family inet {
address 172.20.101.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
[edit interfaces]
lab@srxA1# commit and-quit
commit complete
lab@srxA1>
1.6.
Ejecutar el comando show interfaces terse para verificar el estado actual

de las interfaces configuradas anteriormente.
lab@srxA1> show interfaces terse
Interface
Admin Link
dsc
up up
em0
up up
em0.0
up up
em1
up up
em1.0
up up
em2
up up
em2.0
up up
em3
up up
em3.0
up up
em4
up up
em4.101
up up
em4.32767
up up
gre
up up
ipip
up up
lo0
up up
lo0.0
up up
lo0.16384
up up
lo0.16385
up up
lsi
up up
mtun
up up
pimd
up up
pime
up up
tap
up up
76
Proto Local
inet
10.210.14.131/27
inet
172.20.77.1/30
inet
172.20.66.1/30
inet
172.18.1.2/30
inet
172.20.101.1/24
inet
inet
inet
192.168.1.1
127.0.0.1
Remote
--> 0/0
--> 0/0
Cuestin: Qu significan los estados ADMIN y LINK en las interfaces

recientemente configuradas?
El estado ADMIN se corresponde al estado lgico que tiene actualmente la
interface pudiendo actuar sobre l activndolo o deshabilitndolo.
El estado LINK se corresponde al estado fsico de la interface.
SI todo ha ido bien, los dos estados de cada interface configurada deben
estar en UP.
1.7.
Ejecuta el comando show route para ver las nuevas rutas aadidas.
lab@srxA1> show route
10.210.14.128/27
10.210.14.131/32
172.18.1.0/30
172.18.1.2/32
172.20.66.0/30
172.20.66.1/32
172.20.77.0/30
172.20.77.1/32
172.20.101.0/24
172.20.101.1/32
192.168.1.1/32
*[Direct/0] 02:17:46 > via em0.0

*[Local/0] 02:17:50 Local via em-0.0
*[Direct/0] 00:02:03 > via em-3.0
*[Direct/0] 00:02:03 > via em-2.0
*[Direct/0] 00:02:03 > via em-1.0
*[Direct/0] 00:02:03 > via em-4.101
*[Direct/0] 00:02:03 > via lo0.0
Cuestin: La tabla de enrutamiento muestra una entrada para cada una

de las interfaces y redes conectadas directamente?
La respuesta debera de ser s.
Cuestin: Cul es la preferencia de ruta para las rutas con LOCAL y

DIRECT?
La preferencia para ambas es de 0 tal y como se muestra en la salida.
Cuestin: Existen rutas ocultas?

No existen rutas ocultas. Al inicio del comando se muestra un breve
resumen en el cual nos indica 0 rutas ocultas)
77
1.8.
Utilizar la utilidad ping para verificar la accesibilidad a los dispositivos

vecinos conectados a nuestro router. La siguiente captura muestra el ping
desde el equipo srxA1 al Gateway Internet, srxA2 y vr101, que estn
conectados directamente:
lab@srxA1> ping 172.18.x.1 rapid count 25
PING 172.18.1.1 (172.18.1.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 172.18.1.1 ping statistics --25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.560/5.276/26.080/4.364 ms
lab@srxA1> ping 172.20.66.x rapid count 25
PING 172.20.66.2 (172.20.66.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
lab@srxA1> ping 172.20.77.x rapid count 25
PING 172.20.77.2 (172.20.77.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
lab@srxA1> ping 172.20.10v.10 rapid count 25
PING 172.20.101.10 (172.20.101.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
Cuestin: Son correctos los ping?
Si no son correctos comprobar la configuracin.
Parte 2: Configuracin y Monitorizacin de Rutas Estticas
2.1.
Intenta acceder mediante ping al host de Internet referenciado en el

diagrama.
78
lab@srxA1> ping 172.31.15.1

PING 172.31.15.1 (172.31.15.1): 56 data bytes
ping: sendto: No route to host
^C
Cuestin: Qu indica el resultado del ping?
Nos indica que no existe ninguna ruta al host referenciado.
Cuestin: Basndose en el diagrama, Qu direccin IP debera utilizar

nuestro dispositivo como next-hop para alcanzar el host Internet?
La respuesta depender del dispositivo en que nos encontremos:
srxA1 -> 172.18.1.1
srxA2 -> 172.18.2.1
2.2.
Entrar en modo configuracin y definir una ruta esttica. Utilizar la IP del

paso anterior como el next-hop para la ruta esttica por defecto.
[edit]
lab@srxA1# edit routing-options
[edit routing-options]
lab@srxA1# set static route 0/0 next-hop 172.18.x.1
lab@srxA1#
2.3.
Activar la nueva ruta esttica aadida y ejecutar el comando run show

route 172.31.15.1.
lab@srxA1# commit
commit complete
79
lab@srxA1# run show route 172.31.15.1
0.0.0.0/0
*[Static/5] 00:00:23 > to 172.18.1.1 via em3.0
Cuestin: Se muestra ahora una ruta valida hacia la IP del host Internet?
Si, en este punto la ruta esttica por defecto debera estar activa y todos
los destinos que no tengan una ruta ms especfica utilizarn la ruta por
defecto.
Cuestin: Cul es la preferencia de la ruta esttica por defecto?

Utiliza un valor de preferencia de 5.
2.4.
Ejecutar el comando run ping 172.31.15.1 para comprobar el ping con el

host Internet.
lab@srxA1# run ping 172.31.15.1
PING 172.31.15.1 (172.31.15.1): 56 data bytes
64 bytes from 172.31.15.1: icmp_seq=0 ttl=64 time=5.446 ms
^C
Cuestin: Ha funcionado el ping esta vez?
S.
2.5.
Aadir una ruta esttica para la direccin de loopback del ruter vr10X.
lab@srxA1# set static route 192.168.x.2/32 next-hop 172.20.10v.10
80
2.6.
Definir las correspondientes rutas estticas para permitir una conectividad

total hacia las subredes remotas y direcciones de loopback dentro de tu
rea asignada. Utilizar la direccin IP asignada al ruter opuesto utilizando
la subred 172.20.66.0/30 como el next-hop en las rutas estticas a
configurar.
lab@srxA1# set static route 192.168.x.1/32 next-hop 172.20.66.x
lab@srxA1# set static route 192.168.x.2/32 next-hop 172.20.66.x
lab@srxA1# set static route 172.20.10v.0/24 next-hop 172.20.66.x
2.7.
Utilizar la direccin IP asignada al ruter opuesto en la subred

172.20.77.0/30 como qualified-next-hop para las rutas estticas aadidas
recientemente para las subredes y direcciones loopback. Utilizar un valor 6
de preferencia de ruta para estas definiciones.
lab@srxA1# set static route 192.168.x.1/32 qualified-next-hop 172.20.77.x
preference 6
lab@srxA1# set static route 192.168.x.2/32 qualified-next-hop 172.20.77.x
preference 6
lab@srxA1# set static route 172.20.10v.0/24 qualified-next-hop 172.20.77.x
preference 6
2.8.
Mostrar la configuracin para revisar las rutas definidas. Una vez

comprobadas activar la configuracin y volver al modo operacional.
lab@srxA1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
route 192.168.1.2/32 next-hop 172.20.101.10;
route 192.168.2.1/32 {
81
next-hop 172.20.66.2;
qualified-next-hop 172.20.77.2 {
preference 6;
}
}
route 192.168.2.2/32 {
next-hop 172.20.66.2;
preference 6;
}
}
route 172.20.102.0/24 {
next-hop 172.20.66.2;
preference 6;
}
}
}
commit complete
lab@srxA1>
2.9.
Ejecutar el comando show route protocol static para ver las rutas
estticas actuales en la tabla de enrutamiento de nuestro dispositivo.
lab@srxA1> show route protocol static
0.0.0.0/0
*[Static/5] 00:11:06 > to 172.18.1.1 via em3.0
172.20.102.0/24
*[Static/5] 00:00:44 > to 172.20.66.2 via em2.0
[Static/6] 00:00:44 > to 172.20.77.2 via em1.0
192.168.1.2/32
*[Static/5] 00:00:44 > to 172.20.101.10 via em4.101
192.168.2.1/32
*[Static/5] 00:00:44 > to 172.20.66.2 via em2.0

[Static/6] 00:00:44 > to 172.20.77.2 via em1.0
192.168.2.2/32
*[Static/5] 00:00:44 > to 172.20.66.2 via em2.0

[Static/6] 00:00:44 > to 172.20.77.2 via em1.0
Cuestin: Cuntas rutas estticas se muestran?

82
Se deberan mostrar cinco rutas estticas.
Cuestin: Se muestran varios next-hops en cada subred remota o

loopbacks? Qu next-hop est activo? Por qu?
Se deberan mostrar varios next-hops asociados con subredes remotas o
loopbacks. Las rutas que utilizan el next-hop asociado con la subred
172.20.66.0/30 deberan estar activas debido a que el valor de preferencia
de ruta es menor, siendo 5.
2.10. Realizar un ping a las direcciones de loopback para todos los dispositivos
para verificar la accesibilidad.
PING 192.168.2.1 (192.168.2.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
lab@srxA1> ping 192.168.1.2 rapid count 25
PING 192.168.1.2 (192.168.1.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 192.168.2.2 (192.168.2.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
Cuestin: Se realizaron correctamente los pings?

Debera ser afirmativo, si no repasar la configuracin.
83
Parte 3: Configuracin y Monitorizacin OSPF
En esta parte se configurar y monitorizar el protocolo de enrutamiento OSPF.

Se configurar una simple rea OSPF basada en el diagrama de este laboratorio.
Finalmente se realizarn algunas tareas de comprobacin para asegurar que
OSPF funciona correctamente.
3.1.
Acceder al modo de configuracin y navegar hasta el nivel [edit protocols
ospf].
[edit]
lab@srxA1# edit protocols ospf
[edit protocols ospf]
lab@srxA1#
3.1.
Definir el Area 0 OSPF e incluir todas la interfaces internas que conectan al

router opuesto y al router vr10X. No olvidarse de incluir las interfaces lo0.
Realizar el comando show para ver la configuracin resultante.
Nota: Recuerda especificar la unidad lgica apropiada. Si no se especifica,

Junos OS asumir por defecto la unidad lgica 0.
lab@srxA1# set area 0 interface em1.0
lab@srxA1# set area 0 interface em2.0
lab@srxA1# set area 0 interface em4.10v
lab@srxA1# set area 0 interface lo0.0
lab@srxA1# show
84
area 0.0.0.0 {
interface em1.0;
interface em2.0;
interface em4.101;
interface lo0.0;
}
Cuestin: Con la configuracin OSPF introducida, Cuntas adyacencias

OSPF se deberan formar entre vecinos?
Aunque tengamos cuatro interfaces presentes en la configuracin, slo tres
de estas interfaces sern capaces de crear adyacencias OSPF entre
vecinos. La interface loopback lo0 no puede crear ninguna adyacencia.
3.2.
Activar la configuracin utilizando el comando commit. Ejecutar el

comando run show ospf neighbor para verificar la tabla de adyacencias
OSPF entre vecinos.
Nota: Para que se pueda generar una adyacencia entre dos vecinos,
dichas interfaces deben tener configurado y activado el protocolo OSPF.
lab@srxA1# commit
commit complete
lab@srxA1# run show ospf neighbor
Address
Interface
State
172.20.77.2
em1.0
Full
172.20.66.2
em2.0
Full
172.20.101.10
em4.101
Full
ID
192.168.2.1
192.168.2.1
192.168.1.2
Pri
128
128
128
Dead
37
37
39
Cuestin: Qu estado muestran las adyacencias entre vecinos OSPF?

El estado de los tres vecinos OSPF debera ser FULL.
3.3.
Ejecuta el comando run show route protocol ospf para ver las rutas
activas OSPF en la tabla de enrutamiento de tu dispositivo.
85

lab@srxA1# run show route protocol ospf
172.20.102.0/24
192.168.1.2/32
192.168.2.1/32
192.168.2.2/32
224.0.0.5/32
[OSPF/10] 00:01:33, metric 2

to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
[OSPF/10] 00:02:14, metric 1
> to 172.20.101.10 via em4.101
[OSPF/10] 00:01:33, metric 1
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
[OSPF/10] 00:01:33, metric 2
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[OSPF/10] 00:02:24, metric 1 MultiRecv
Cuestin: Estn activas todas las rutas OSPF para cada subred destino o
loopback?
No, todas las rutas OSPF para las subredes destino y loopback no estn
activas (no tienen el * al inicio de la lnea). Esto es debido a que la
preferencia para OSPF tiene un valor de 10 mientras si recordamos, las
rutas estticas tienen un valor de preferencia de 5 y por lo tanto las hacen
ms preferibles que las rutas OSPF.
3.4.
Borrar todas las rutas estticas utilizadas en el diagrama, excepto las rutas
estticas por defecto utilizadas para el trfico hacia Internet.
lab@srxA1# top edit routing-options
lab@srxA1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
route 192.168.1.2/32 next-hop 172.20.101.10;
route 192.168.2.1/32 {
next-hop 172.20.66.2;
86
preference 6;
}
}
route 192.168.2.2/32 {
next-hop 172.20.66.2;
preference 6;
}
}
route 172.22.102.0/24 {
next-hop 172.20.66.2;
preference 6;
}
}
}
lab@srxA1# delete static route 192.168.1.2/32
lab@srxA1# delete static route 192.168.x.1/32
lab@srxA1# delete static route 192.168.2.2/32
lab@srxA1# delete static route 172.20.10v.0/24
lab@srxA1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
}
3.5.
Activar la configuracin y volver al modo operacin. Ejecutar el comando

show route protocol ospf para verificar que las rutas OSPF estn activas.
commit complete
lab@srxA1> show route protocol ospf
87

172.20.102.0/24
192.168.1.2/32
192.168.2.1/32
192.168.2.2/32
224.0.0.5/32
*[OSPF/10] 00:07:13, metric 2

to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[OSPF/10] 00:07:54, metric 1
> to 172.20.101.10 via em4.101
*[OSPF/10] 00:07:13, metric 1
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[OSPF/10] 00:07:13, metric 2
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[OSPF/10] 00:08:04, metric 1 MultiRecv
lab@srxA1>
Cuestin: Estn ahora activas todas las rutas OSPF que hay para cada
una de las subredes y loopback?
Si, como se puede ver en la salida anterior, todas la rutas OSPF estn
activas ya que tienen el *.
3.6.
Realizar ping a las direcciones loopback de todos los routers del diagrama
y verificar la accesibilidad.
PING 192.168.1.2 (192.168.1.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 192.168.2.1 (192.168.2.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 192.168.2.2 (192.168.2.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
88
lab@srxA1>
Parte 4: Guardar configuraciones
Si queremos conservar las configuraciones de los routers, tenemos dos maneras

de realizarlo. La ms sencilla es la siguiente:
A. Salimos del entorno CLI con el comando exit. Observar que el prompt ha
cambiado y ahora es %. A continuacin nos vamos al directorio /config.
lab@srxA1> exit
lab@srxA1% pwd
/root
lab@srxA1% cd /config/
lab@srxA1% pwd
/config
lab@srxA1%
En este directorio se guarda toda la configuracin del router. Cada vez que
realizamos un commit, se guarda la configuracin en el archivo
juniper.conf.gz guardando las ltimas 9 configuraciones ms recientes. Los
ficheros estn comprimidos en el formato gz por lo que tendremos que
utilizar la herramienta gunzip para extraer el fichero de configuracin
juniper.conf.
lab@srxA1% ls -l
total 24
drwxrwxr-x 2 root wheel
512
-rw-r----1 root wheel
1505
547
558
523
------S--1 root wheel
32
root@srxA1% gunzip juniper.conf.gz
root@srxA1% ls -l
total 24
May 2 17:20 .snap

Jun 17 12:18 juniper.conf.gz
Jun 17 12:18 juniper.conf.1.gz
Jun 13 17:15 juniper.conf.md5
89
drwxrwxr-x 2 root
-rw-r----1 root
-rw-r----1 root
-rw-r----1 root
-rw-r----1 root
------S--1 root
root@srxA1%
wheel
wheel
wheel
wheel
wheel
wheel
512
1505
547
558
523
32
May 2 17:20 .snap

Jun 17 12:18 juniper.conf
Jun 13 17:15 juniper.conf.md5
La manera ms fcil de extraer la configuracin es realizando un

copy/paste del archivo de configuracin juniper.conf utilizando el comando
cat.
lab@srxA1% cat juniper.conf
## Last changed: 2013-06-17 12:18:54 UTC
version 9.6R1.13;
system {
host-name srxA1;
root-authentication {
encrypted-password "$1$khYtQ9ir$hSlWVunnZ05Vp87s/4was1";
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
file interactive-commands {
interactive-commands any;
}
}
}
interfaces {
em0 {
unit 0 {
family inet {
address 10.210.14.131/27;
}
}
}
em1 {
unit 0 {
family inet {
address 172.20.77.1/30;
90
}
}
}
em2 {
unit 0 {
family inet {
address 172.20.66.1/30;
}
}
}
em3 {
unit 0 {
family inet {
address 172.18.1.2/30;
}
}
}
em4 {
vlan-tagging;
unit 101 {
vlan-id 101;
family inet {
address 172.20.101.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
}
}
protocols {
ospf {
area 0.0.0.0 {
interface em1.0;
interface em2.0;
interface em4.101;
interface lo0.0;
}
91
}
}
root@srxA1%
Guardamos dicha configuracin en un fichero de texto y repetimos esta

operacin para cada uno de los routers de nuestro diagrama.
La otra opcin para guardar las configuraciones es ms compleja.

B. Se trata de aadir una nueva conexin entre uno de los routers que
tenemos en el diagrama y nuestro equipo anfitrin. Esto se puede realizar
con el objeto NUBE de GNS3 y posteriormente definiendo en este objeto la
interface de nuestro equipo anfitrin que ser la que se utilizar para la
comunicacin. Con esta configuracin lo que haremos ser conectar
nuestro equipo fsico con las MV de nuestro diagrama de red
Como ejemplo vamos a aadir una Nube en el router srxA1 y configurar la

interface.
Figura 52: Integracin nodo de interconexin al escenario.
Hacemos doble click en la nube y accedemos a la configuracin de este

objeto. Seleccionamos en el listado Generic Interfaces NIO la interface que
92
queremos utilizar (normalmente la conexin local Ethernet RJ45) y la

aadimos quedndonos tal y como se muestra a continuacin.
Figura 53: Ventana configuracin nodo de interconexin.
GNS3 no nos permite conectar directamente una interface de un router a

una interface NIO como la que hemos definido antes. Tenemos que
realizarlo a travs de un Switch Ethernet para poder interconectar los
objetos.
Lo siguiente que tenemos que realizar es configurar la IP en la nueva

interface del router vr101 y en nuestra interface local. Luego, configuramos
un servidor TFTP en nuestra mquina anfitriona.
93
Figura 54: Ventana principal de Cisco TFTP Server.
Desde el router que queremos guardar el fichero de configuracin, salimos

del modo CLI y nos situamos en el directorio /config. Ahora nos
conectaremos al servidor TFTP que tenemos corriendo en nuestra mquina
anfitriona y enviaremos el fichero juniper.conf.
lab@srxA1% pwd
/root
root@srxA1% cd /config/
root@srxA1% ls
.snap
juniper.conf.1
juniper.conf.3.gz
juniper.conf
juniper.conf.2.gz
juniper.conf.md5
root@srxA1% tftp 10.210.14.129
tftp> status
Connected to 10.210.14.129.
Mode: netascii Verbose: off Tracing: off
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
tftp> put juniper.conf
Sent 1586 bytes in 0.0 seconds
tftp>
Si todo ha ido bien, nos aparecer un mensaje en el Server TFTP de que

se ha recibido un fichero.
94
Figura 55: Logs de recepcin de ficheros en el servidor TFTP.
En este momento ya habremos conseguido el fichero de configuracin de

nuestro dispositivo en nuestra mquina anfitriona. Ahora lo que hay que
hacer es ir a cada uno de nuestros routers e ir conectndonos va TFTP e ir
enviando los ficheros de configuracin. Acordarse de renombra los ficheros
para no sobrescribirlos.
95
96
5.
Lab 2: Polticas de Routing
Este laboratorio demuestra la configuracin y monitorizacin de las Polticas de

Enrutamiento en dispositivos que ejecutan el sistema operativo JUNOS bajo el
emulador GNS3. En esta prctica se utilizar la lnea de comandos (CLI) para
definir, aplicar y monitorizar las Polticas de Enrutamiento. Durante todas estas
tareas de configuracin, conseguiremos familiarizarnos con la descripcin de los
contenidos dichas polticas.
Se ha implementado una modificacin del escenario original: se ha sustituido la
MV Linux que estaba asociada al router srxA1 por una interconexin directa a la
mquina anfitriona para facilitar el backup de los archivos de configuracin de
todos los dispositivos. El objeto Nube tiene configurada la interface local generada
por Virtual Box y ello nos permite la comunicacin entre el escenario de
simulacin y la mquina anfitriona local. Cuando necesitemos realizar alguna
verificacin de comunicacin con ping simplemente tendremos que ejecutar la
lnea de comandos Windows (CMD) o Linux y ejecutar el ping.
Figura 56: Escenario del laboratorio Politicas de Routing.
97
Para poder adaptar el anterior escenario del Lab1 al actual hay que eliminar los
objetos que emulan los PCs Linux. GNS3 tiene problemas a la hora de eliminar
objetos y la nica forma de hacerlo es editando el fichero topology.net con un
editor de textos sencillo y eliminar las etiquetas de los objetos. Por ejemplo, si
queremos eliminar el PC Linux_1, eliminaremos todo el contenido de la
subetiqueta [[VBOX Linux_1]] y la lnea que define la conexin del em0 del router
[[VBOX srxA1]].

elementos:
5 Maquinas Virtual Box (MVB) con el SO JUNOS.
1 Nodo de Interconexin a la mquina anfitriona.

3GB de memoria RAM.
Configurar y monitorizar las Polticas de enrutamiento.
Configurar el acceso al Servidor TFTP desde todos los dispositivos.
Parte 1: Preparacin del Sistema y Verificacin
En esta parte se realizarn modificaciones a la configuracin existente y se

verificar el funcionamiento. En esta parte del laboratorio, nos referiremos al
diagrama de red del Laboratorio 2.
98
1.1.
Acceder al modo de configuracin y situarse en el nivel [edit protocols
ospf].
[edit]
lab@srxA1# edit protocols ospf
lab@srxA1#
1.2.
Borrar la interface perteneciente a la VLAN de la configuracin OSPF y

activar los cambios.
lab@srxA1# show
area 0.0.0.0 {
interface em1.0;
interface em2.0;
interface em4.101;
interface lo0.0;
}
lab@srxA-1# delete area 0 interface em4.10v
lab@srxA-1# commit
commit complete
1.3.
Configurar las tres subredes en el router vr10X utilizando la interface em1 y

asignndole tres IPs.
[edit]
lab@ vr101# set interfaces em1 unit 0 family inet address 172.21.0.1/24
[edit]
[edit]
[edit]
lab@srxA-1# commit
99
commit complete
[edit]
lab@vr101# run show interfaces terse
Interface
Admin Link
Proto Local
dsc
up up
em0
up up
em0.101
up up
inet 172.20.101.10/24
em0.32767
up up
em1
up up
em1.0
up up
inet 172.21.0.1/24
172.21.1.1/24
172.21.2.1/24
em2
up down
em3
up down
gre
up up
ipip
up up
lo0
up up
lo0.0
up up
inet 192.168.1.2
lo0.16384
up up
inet 127.0.0.1
lo0.16385
up up
inet
lsi
up up
mtun
up up
pimd
up up
pime
up up
tap
up up
1.4.
Remote
--> 0/0
--> 0/0
Situarse en el nivel jerrquico [edit routing-options]. Definir una ruta

esttica par cada una de las tres subredes conectadas al router vr10X.
lab@srxA1# top edit routing-options
lab@srxA1# set static route 172.2x.0.0/24 next-hop 172.20.10v.10
lab@srxA1#
100
1.5.
Ejecutar el comando show para mostrar los resultados de la configuracin.

Una vez verificado, activar los cambios y volver al modo operacin
utilizando el comando commit and-quit.
lab@srxA1# show
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
route 172.21.0.0/24 next-hop 172.20.101.10;
route 172.21.1.0/24 next-hop 172.20.101.10;
route 172.21.2.0/24 next-hop 172.20.101.10;
}
commit complete
lab@srxA1>
1.6.
Ejecutar el comando show route protocol static para mostrar las rutas
estticas actuales. Acordarse de que las VLAN no se activan por s solas
cuando reiniciamos los routers y por lo tanto habr que desconfigurarlas y
volverlas a crear.
lab@srxA1>
show route protocol static
0.0.0.0/0
172.21.0.0/24
172.21.1.0/24
172.21.2.0/24
*[Static/5] 01:30:15 > to 172.18.1.1 via em3.0

*[Static/5] 00:00:21 > to 172.20.101.10 via em4.101
*[Static/5] 00:00:21 > to 172.20.101.10 via em4.101
*[Static/5] 00:00:21 > to 172.20.101.10 via em4.101
Cuestin: Estn todas las rutas estticas activas?

Deberan estarlo. Como se muestra en la salida, la ruta por defecto y las
tres rutas definidas deberan aparecer como activas.
1.7.
Utilizar la utilidad ping para verificar la accesibilidad a las subredes

conectadas al router vr10X.
lab@srxA1> ping 172.2x.0.1 rapid count 25
101
PING 172.21.0.1 (172.21.0.1): 56 data bytes

!!!!!!!!!!!!!!!!!!!!!!!!!
PING 172.21.1.1 (172.21.1.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 172.21.2.1 (172.21.2.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
Cuestin: Los ping han sido correctos?
Deberan de responder a los pings.
1.8.
Ejecutar el comando show ospf neighbor para mostrar las adyacencias

actuales entre vecinos OSPF.
lab@srxA1> show ospf neighbor
Address
Interface
172.20.77.2
em1.0
172.20.66.2
em2.0
State ID
Full
192.168.2.1
Full
192.168.2.1
Pri
128
128
Dead
39
32
Cuestin: Cuntas adyacencias de vecinos OSPF hay ahora?

Existirn dos adyacencias, una proveniente de la interface em1.0 y la
segunda por la interface em2.0.Si no fuese as, repasar la configuracin o
el estado de las interfaces.
Parte 2: Configurar y Monitorizar Polticas de Enrutamiento
En los siguientes apartados configuraremos y monitorizaremos las polticas de

enrutamiento. Primero crearemos una poltica de enrutamiento diseada para
102
publicar rutas en OSPF. Lo siguiente ser aplicar la poltica como una poltica
exportable situndonos en el nivel jerrquico [edit protocols ospf] para
configurarla. Luego verificaremos que la poltica est trabajando correctamente.
Veremos que las polticas de enrutamiento de Junos son extremadamente

flexibles. Debido a esta flexibilidad, por lo general se puede conseguir el mismo
objetivo de varias maneras. Las configuraciones de ejemplo mostradas en esta
parte ilustran una forma de realizar las tareas. La configuracin es posible que
vare con respecto a lo mostrado.
2.1.
Ejecutar el comando show route 0/0 exact para mostrar las entradas
existentes en la ruta por defecto. En este punto encontraremos que slo
existe una entrada.
lab@srxA1> show route 0/0 exact
0.0.0.0/0
2.2.
*[Static/5] 01:35:53
> to 172.18.1.1 via em3.0
Acceder al modo de configuracin y situarse en el nivel [edit policyoptions].

[edit]
lab@srxA1# edit policy-options
[edit policy-options]
lab@srxA1#
2.2.
Crear una nueva poltica llamada default-route que compruebe y acepte la

ruta esttica por defecto existente. Utiliza la nomenclatura match-defaultstatic-route.
lab@srxA1# edit policy-statement default-route
103
[edit policy-options policy-statement default-route]

lab@srxA1# set term match-default-static-route from protocol static
lab@srxA1# set term match-default-static-route from route-filter 0/0 exact
lab@srxA1# set term match-default-static-route then accept
lab@srxA1#
2.3.
Situarse en el nivel [edit protocols ospf] y aplicar la poltica definida como

una poltica OSPF exportable. Activar los cambios en la configuracin.
lab@srxA1# top edit protocols ospf
lab@srxA1# set export default-route
lab@srxA1# commit
commit complete
lab@srxA1#
2.4.
En este paso se requiere coordinacin entre los grupos de prcticas que

comparten este diagrama de red. Asegurarse de que el grupo remoto
finaliza el paso anterior antes de continuar.
Ejecutar el comando para verificar que el dispositivo ahora muestra una

ruta OSPF por defecto en la tabla de enrutamiento. Comprobar con el
grupo remoto que tambin observan la ruta OSPF por defecto en su
dispositivo.
lab@srxA1# run show route 0/0 exact
104

0.0.0.0/0
*[Static/5] 00:35:18
> to 172.18.1.1 via em3.0
[OSPF/150] 00:22:53, metric 0, tag 0
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
Cuestin: Tu router muestra una ruta por defecto OSPF en su tabla?

En este punto, ambos grupos deberan observar una ruta por defecto
OSPF. SI no es as, comprobar con el grupo remoto que se ha definido
correctamente la poltica.
Cuestin: Est activa la ruta por defecto OSPF? Por qu?

No est activa porque su valor de preferencia es mayor que la actual. La
poltica configurada inserta una ruta OSPF en la tabla pero se la considera
una ruta OSPF externa. Por esta razn la preferencia asignada es de 150
que pertenece a las rutas OSPF externas, para las rutas OSPF internas el
valor es de 10.
Cuestin: Basndonos en la entrada actual de ruta por defecto, Qu

pasara si la conexin fsica de nuestro dispositivo hacia Internet fallara?
La actual configuracin proporciona redundancia para este fallo. Si la
conexin fsica entre el router srxA1 e Internet falla, el router marcar como
activa la ruta por defecto OSPF y empezar a enrutar trfico.
2.5.
Ejecutar el comando run show route protocol ospf para mostra las rutas
actuales de OSPF.
0.0.0.0/0
192.168.2.1/32
[OSPF/150] 00:07:39, metric 0, tag 0

to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[OSPF/10] 01:52:37, metric 1
> to 172.20.77.2 via em1.0
105
to 172.20.66.2 via em2.0

*[OSPF/10] 01:53:34, metric 1
MultiRecv
224.0.0.5/32
2.6.
Volver al nivel de configuracin [edit policy-options].

lab@srxA1# top edit policy-options
lab@srxA1#
2.7.
Definir una nueva poltica llamada interface-routes que compruebe y

acepte las rutas asociadas con las interfaces de tu dispositivo que
conectan a Internet y al router vr10X. Nmbrala como match-interfaceroutes.
lab@srxA1# edit policy-statement interface-routes
[edit policy-options policy-statement interface-routes]
lab@srxA1# set term match-interface-routes from route-filter 172.18.x.0/30
exact
lab@srxA1# set term match-interface-routes from route-filter 172.20.10v.0/24
exact
lab@srxA1# set term match-interface-routes then accept
lab@srxA1#
2.8.
Situarse en el nivel [edit protocols ospf] y aplicar la poltica interface-
routes como una poltica OSPF exportable. Activar los cambios en la

configuracin.
106
lab@srxA1# set export interface-routes

lab@srxA1# commit
commit complete
2.9.
Ejecutar el comando run show route protocol ospf. Comprobar que el

router srxA1 muestra las rutas OSPF externas asociadas a las interfaces
del router opuesto. Comprobar en el dispositivo remoto que se muestran
las rutas OSPF apropiadas en su tabla de enrutamiento.
0.0.0.0/0
172.18.2.0/30
172.20.102.0/24
192.168.2.1/32
224.0.0.5/32
[OSPF/150] 00:08:09, metric 0, tag 0

to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:01:04, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:01:04, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 00:38:29, metric 1
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 00:39:20, metric 1
MultiRecv
Cuestin: Se muestran las rutas OSPF esperadas en la tabla de

enrutamiento del vuestro router?
En este punto, en ambos routers se debera de mostrar las rutas OSPF
esperadas. Si no es as, comprobar en ambos routers la configuracin de
las polticas.
2.10. Situarse en el nivel [edit policy-options].
107

lab@srxA1#
2.11. Definir una tercera poltica llamada other-static-routes que compruebe y
acepte las tres rutas estticas definidas recientemente hacia las subredes
conectadas al router vr10X. Defnela como match-other-static-routes.
lab@srxA1# edit policy-statement other-static-routes
[edit policy-options policy-statement other-static-routes]
lab@srxA1# set term match-other-static-routes from protocol static
lab@srxA1# set term match-other-static-routes from route-filter 172.2x.0.0/24
exact
exact
exact
lab@srxA1# set term match-other-static-routes then accept
lab@srxA1#
2.12. Situarse en el nivel [edit protocols ospf] y aplicar la poltica other-static-
routes como una poltica OSPF exportable. Activar los cambios en la

configuracin.
lab@srxA1# set export other-static-routes
108

lab@srxA1# commit
commit complete
lab@srxA1#
2.13. Ejecutar el comando run show route protocol ospf. Comprobar que el
router srxA1 muestra las rutas OSPF externas asociadas a las interfaces
del router opuesto. Comprobar en el dispositivo remoto que se muestran
las rutas OSPF apropiadas en su tabla de enrutamiento.
0.0.0.0/0
172.18.2.0/30
172.20.102.0/24
172.22.0.0/24
172.22.1.0/24
172.22.2.0/24
192.168.2.1/32
224.0.0.5/32
[OSPF/150] 01:13:36, metric 0, tag 0

to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 01:06:31, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 01:06:31, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:00:48, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:00:48, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:00:48, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 01:43:56, metric 1
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 01:44:47, metric 1
MultiRecv
109
Cuestin: El router muestra las rutas OSPF esperadas en la tabla de

enrutamiento?
En este punto, en ambos routers se debera de mostrar las rutas OSPF
esperadas. Si no es as, comprobar en ambos routers la configuracin de
las polticas.
2.14. Situarse en el nivel [edit policy-options] y mostrar las polticas
configuradas.
lab@srxA1# show
policy-statement default-route {
term match-default-static-route {
from {
protocol static;
route-filter 0.0.0.0/0 exact;
}
then accept;
}
}
policy-statement interface-routes {
term match-interface-routes {
from {
}
then accept;
}
}
policy-statement other-static-routes {
term match-other-static-routes {
from {
protocol static;
}
then accept;
}
}
110
lab@srxA1#
2.15. Utilizar las polticas existentes como una gua. Crear una nueva poltica
llamada ospf-export con tres trminos distintos: match-default-route,
match-interface-routes, y match-other-static-routes. Comprobar que la
nueva poltica logra los mismos objetivos que las tres polticas existentes.
lab@srxA1# edit policy-statement ospf-export
[edit policy-options policy-statement ospf-export]
lab@srxA1# set term match-default-static-route from protocol static
lab@srxA1# set term match-default-static-route from route-filter 0/0 exact
lab@srxA1# set term match-default-static-route then accept
lab@srxA1# set term match-interface-routes from route-filter 172.18.x.0/30
exact
lab@srxA1# set term match-interface-routes from route-filter 172.20.10v.0/24
exact
lab@srxA1# set term match-interface-routes then accept
lab@srxA1# set term match-other-static-routes from protocol static
exact
exact
111

exact
lab@srxA1# set term match-other-static-routes then accept
lab@srxA1#
2.16. Situarse en el nivel [edit protocols ospf] y borrar las polticas exportadas
aplicadas.
lab@srxA1# delete export
lab@srxA1#
2.17. Configurar la poltica como una poltica OSPF exportable y aplicar los
cambios.
lab@srxA1# set export ospf-export
lab@srxA1# commit
commit complete
2.18. Ejecutar el comando .Verificar que el dispositivo muestra las rutas OSPF
externas esperadas que se han exportado del dispositivo remoto.
0.0.0.0/0
172.18.2.0/30
112
[OSPF/150] 01:21:15, metric 0, tag 0

to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 01:14:10, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
172.20.102.0/24
172.22.0.0/24
172.22.1.0/24
172.22.2.0/24
192.168.2.1/32
224.0.0.5/32
*[OSPF/150] 01:14:10, metric 0, tag 0

> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:08:27, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:08:27, metric 0, tag 0
> to 172.20.77.2 via ge-0/0/1.0
to 172.20.66.2 via ge-0/0/2.0
*[OSPF/150] 00:08:27, metric 0, tag 0
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 01:51:35, metric 1
to 172.20.77.2 via ge-0/0/1.0
> to 172.20.66.2 via ge-0/0/2.0
*[OSPF/10] 01:52:26, metric 1
MultiRecv
Cuestin: El router muestra las rutas OSPF esperadas en la tabla de

enrutamiento?
Se deberan mostrar las rutas OSPF configuradas. Comprobar en el equipo
remoto que aparecen las rutas OSPF definidas en las polticas.
2.19. Mostrar la configuracin actual de las polticas configuradas hasta el

momento y de las que se estn exportando.
lab@srxA1# show
policy-statement default-route {
from {
protocol static;
}
then accept;
}
}
policy-statement interface-routes {
from {
}
then accept;
113
}
}
policy-statement ospf-export {
from {
protocol static;
}
then accept;
}
from {
}
then accept;
}
from {
protocol static;
}
then accept;
}
}
policy-statement other-static-routes {
from {
protocol static;
}
then accept;
}
}
lab@srxA1# show
export ospf-export;
area 0.0.0.0 {
interface em1.0;
114
interface em2.0;
interface lo0.0;
}
lab@srxA1#
2.20. Volver al nivel y borrar las polticas de enrutamiento no utilizadas. Activar

los cambios y volver al modo de operacin.
lab@srxA1# delete policy-statement default-route
lab@srxA1# delete policy-statement interface-routes
lab@srxA1# delete policy-statement other-static-routes
commit complete
lab@srxA1>
2.21. Mostrar cmo ha quedado la configuracin actual de las polticas.

lab@srxA1# show
from {
protocol static;
}
then accept;
}
from {
115

}
then accept;
}
from {
protocol static;
}
then accept;
}
}
lab@srxA1#
Parte 3: Configurar servidor TFTP de copias de configuracin
A continuacin vamos a configurar el escenario del Lab 2 para que el Servidor

TFTP ubicado en nuestra mquina anfitriona, a travs de la interconexin de
Nube, pueda ser accesible por todos los dispositivos del escenario y enviar la
configuracin de cada dispositivo.
3.1.
Realizar ping a la mquina anfitriona con la IP 10.210.14.129 desde el

router srxA2.
lab@srxA2> ping 10.210.14.129
PING 10.210.14.129 (10.210.14.129): 56 data bytes
36 bytes from 172.18.2.1: Destination Host Unreachable
Vr HL TOS Len
ID Flg off TTL Pro cks Src
Dst
4 5 00 0054 8670 0 0000 40 01 2cd2 172.18.2.2 10.210.14.129
Vr HL TOS Len
Dst
4 5 00 0054 8671 0 0000 40 01 2cd2 172.18.2.2 10.210.14.129
Vr HL TOS Len
Dst
4 5 00 0054 8672 0 0000 40 01 2cd2 172.18.2.2 10.210.14.129
116

Vr HL TOS Len
Dst
4 5 00 0054 8673 0 0000 40 01 2cd2 172.18.2.2 10.210.14.129
^C
Cuestin: Por qu no contesta el ping la mquina anfitriona?

El router srxA2 no tiene ninguna ruta hacia la subred 10.210.14.128/27
en su tabla de enrutamiento y esto se debe a que el router srxA1 no
est propagando esta ruta a travs de OSPF al no estar configurada en
la poltica de enrutamiento.
3.2.
Aadir un nuevo trmino a la poltica OSPF del router srxA1 para que
se pueda exportar y aceptar con commit.
lab@srxA1# set term match-interface-routes from route-filter
10.210.14.128/27 exact
lab@srxA1# commit
3.3.
Comprobar en el router srxA2 que ahora s que nos aparece una ruta
hacia la subred del servidor TFTP. Ejecutar el comando show route
protocol ospf.
lab@srxA2> show route protocol ospf
0.0.0.0/0
10.210.14.128/27
172.18.1.0/30
[OSPF/150] 01:09:24, metric 0, tag 0

> to 172.20.77.1 via em1.0
to 172.20.66.1 via em2.0
*[OSPF/150] 00:02:51, metric 0, tag 0
> to 172.20.77.1 via em1.0
to 172.20.66.1 via em2.0
*[OSPF/150] 01:09:24, metric 0, tag 0
> to 172.20.77.1 via em1.0
117
172.20.101.0/24
172.21.0.0/24
172.21.1.0/24
172.21.2.0/24
192.168.1.1/32
224.0.0.5/32
to 172.20.66.1 via em2.0

*[OSPF/150] 01:08:19, metric 0, tag 0
> to 172.20.77.1 via em1.0
to 172.20.66.1 via em2.0
*[OSPF/150] 01:08:19, metric 0, tag 0
> to 172.20.77.1 via em1.0
to 172.20.66.1 via em2.0
*[OSPF/150] 01:08:19, metric 0, tag 0
to 172.20.77.1 via em1.0
> to 172.20.66.1 via em2.0
*[OSPF/150] 01:08:19, metric 0, tag 0
> to 172.20.77.1 via em1.0
to 172.20.66.1 via em2.0
*[OSPF/10] 01:09:24, metric 1
to 172.20.77.1 via em1.0
> to 172.20.66.1 via em2.0
*[OSPF/10] 01:09:42, metric 1
MultiRecv
Cuestin: Si realizamos un ping a la IP del servidor TFTP 10.210.14.129

desde srxA2, son satisfactorios?
Deberan de ser satisfactorios. Si no responde, comprobar que la
interface de la mquina anfitriona tiene configurada la puerta de enlace.
PING 10.210.14.129 (10.210.14.129): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
3.4.
Ahora ya tenemos acceso al servidor y podemos enviar el archivo de

configuracin del router srxA2. Desde el modo de operacin podemos
realizar un listado de los archivos tal y como se muestra a continuacin.
Nos salimos del entorno cli y accedemos al sistema Linux. Luego
ejecutamos el comando que nos permite enviar el archivo de
configuracin al servidor TFTP.
lab@srxA2> file list /config
/config:
.snap/
118
juniper.conf.1.gz
juniper.conf.2.gz
juniper.conf.3.gz
juniper.conf.gz
lab@srxA2% pwd
/root
lab@srxA2% cd /config/
lab@srxA2% ls
.snap
juniper.conf.2.gz
juniper.conf.1.gz
juniper.conf.3.gz
juniper.conf.gz
juniper.conf.md5
lab@srxA2% gunzip juniper.conf.gz

lab@srxA2% ls
.snap
juniper.conf.1.gz
juniper.conf
juniper.conf.2.gz
juniper.conf.3.gz
juniper.conf.md5
lab@srxA2% ls -l
total 28
drwxrwxr-x
-rw-r-----rw-r-----rw-r-----rw-r----------S---
2 root
1 root
1 root
1 root
1 root
1 root
wheel
wheel
wheel
wheel
wheel
wheel
512
2460
647
658
647
32
May
Jul
Jul
Jul
Jul
Jun
2 17:20
2 13:23
2 13:17
2 13:01
2 12:17
13 17:15
.snap
juniper.conf
juniper.conf.1.gz
juniper.conf.2.gz
juniper.conf.3.gz
juniper.conf.md5
lab@srxA2% tftp 10.210.14.129

tftp> status
Mode: netascii Verbose: off Tracing: off
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
tftp> q
lab@srxA2%
3.5.
Aunque no se ha tocado nada la configuracin de los routers vr101 y

vr102, vamos a configurarlos para que puedan acceder al Servidor
TFTP. Realizamos un ping al servidor TFTP desde vr101.
lab@vr101> ping 10.210.14.129
PING 10.210.14.129 (10.210.14.129): 56 data bytes
119

^C
Cuestin: Por qu no contesta el ping la mquina anfitriona?

El router vr101 no tiene ninguna ruta hacia la subred 10.210.14.128/27
en su tabla de enrutamiento y esto se debe a que el router srxA1 no
est publicando rutas OSPF.
3.6.
Comprobar las interfaces configuradas con OSPF en el router srxA1

con el comando show ospf interface.
lab@srxA1> show ospf interface
Interface
State Area
em1.0
DR 0.0.0.0
em2.0
DR 0.0.0.0
lo0.0
DR 0.0.0.0
DR ID
192.168.1.1
192.168.1.1
192.168.1.1
BDR ID
192.168.2.1
192.168.2.1
0.0.0.0
Nbrs
1
1
0
Como se puede observar, la interface em4.101 no se encuentra

configurada con OSPF y por este motivo no est recibiendo
actualizaciones OSPF.
3.7.
Vamos a configurar una ruta esttica en el router vr101 para poder

acceder al servidor.
lab@vr101> configure
[edit]
lab@vr101# edit routing-options
lab@vr101# show
static {
route 192.168.2.2/32 next-hop 172.20.101.1;
route 192.168.2.1/32 next-hop 172.20.101.1;
route 172.20.102.0/24 next-hop 172.20.101.1;
}
120
lab@vr101# set static route 10.210.14.128/27 next-hop 172.20.101.1
lab@vr101# commit
commit complete
lab@vr101# show
static {
route 192.168.2.2/32 next-hop 172.20.101.1;
route 192.168.2.1/32 next-hop 172.20.101.1;
route 172.20.102.0/24 next-hop 172.20.101.1;
route 10.210.14.128/27 next-hop 172.20.101.1;
}
lab@vr101# run ping 10.210.14.129 rapid count 25
PING 10.210.14.129 (10.210.14.129): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
root@vr101#
3.8.
Una vez tenemos conectividad con el servidor TFTP, simplemente

tenemos que enviar el archivo juniper.conf de la misma manera que en
el punto 3.4
3.9.
Para
configurar
el
router
vr102
implementaremos
la
misma
configuracin que para el vr101. Se configurar una nueva ruta esttica

hacia el router srxA2.
lab@vr102> ping 10.210.14.129
PING 10.210.14.129 (10.210.14.129): 56 data bytes
^C
121
lab@vr102> configure
[edit]
lab@vr102# edit routing-options
lab@vr102# show
static {
route 192.168.1.2/32 next-hop 172.20.102.1;
route 192.168.1.1/32 next-hop 172.20.102.1;
route 172.20.101.0/24 next-hop 172.20.102.1;
}
lab@vr102# set static route 10.210.14.128/27 next-hop 172.20.102.1
lab@vr102# commit
commit complete
lab@vr102# show
static {
route 192.168.1.2/32 next-hop 172.20.102.1;
route 192.168.1.1/32 next-hop 172.20.102.1;
route 172.20.101.0/24 next-hop 172.20.102.1;
route 10.210.14.128/27 next-hop 172.20.102.1;
}
lab@vr102# run ping 10.210.14.129 rapid count 25
PING 10.210.14.129 (10.210.14.129): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
lab@vr102#
3.10. Una vez tenemos conectividad con el servidor TFTP, simplemente
tenemos que enviar el archivo juniper.conf de la misma manera que en
el punto 3.4.
122
6.
Lab 3: Filtros Firewalls
Este laboratorio demuestra la configuracin y monitorizacin de Filtros Firewall en

dispositivos que ejecutan el sistema operativo JUNOS bajo el emulador GNS3. En
esta prctica se utilizar la lnea de comandos (CLI) para definir, aplicar y
monitorizar los Filtros Firewall.
En este laboratorio, el software JUNOS de las mquinas virtuales se ha migrado a

la versin R10.1, el cual implementa el servicio SSH y adems los filtros
funcionan perfectamente, cosa que no ocurre en la versin R9.6.
Hay que tener especial cuidado cuando interconectamos dos routers utilizando la
misma interface en ellos: como ya se ha descrito en el captulo Troubleshooting
Junos, debemos asegurarnos que se han cambiado la direcciones MAC de las
interfaces a utilizar en la interconexin debido a la clonacin de las MV, sino
provocar que no funcionen las lneas de interconexin ni los pings.
Figura 57: Escenario del laboratorio Filtros Firewalls.

123
Una vez hayamos arrancado las dos MV de los routers srxA1 y srxA2,
comprobaremos que la comunicacin entre ellos funciona correctamente a travs
de las dos lneas realizando varios pings entre ellos.

elementos:
5 Maquinas Virtual Box (MVB) con el SO JUNOS (mnimo R10.1).

3GB de memoria RAM.
Configurar y monitorizar Filtros Firewall.
Configurar el acceso al Servidor TFTP desde todos los dispositivos.

1.1.
Acceder por consola al router srxAX, acceder al modo de configuracin y

situarse en el nivel [edit system services]. Se nos mostrarn los servicios
actualmente activados.
root @srxA1> configure
124

[edit]
root @srxA1# edit system services
[edit system services]
root @srxA1# show
root @srxA1#
Cuestin: Qu servicios hay actualmente habilitados?

Tal y como se observa, no existe ningn servicio al no mostrarse nada.
1.9.
Habilitar el servicio ftp, telnet, ssh
y activar la configuracin con el
comando commit.
lab root srxA1# set ftp
root @srxA1# set telnet
root @srxA1# set ssh
root @srxA1# commit
commit complete
root @srxA1# show
ftp;
ssh;
telnet;
root @srxA1#
1.10. Creamos una cuenta de usuario para poder acceder a los servicios
activados.
[edit system]
root@srxA1# set login user lab authentication plain-text-password
125
New password:
[edit system]
root@srxA1# set login user lab class read-only
[edit system]
root@srxA1# commit
commit complete
[edit system]
root@srxA1#
1.11. Comprobar que est activado OSPF y que existen adyacencias

establecidas. Ejecutar el comando show ospf neighbor.
root @srxA1> show ospf neighbor
Address
Interface
172.20.77.2
em1.0
172.20.66.2
em2.0
State
Full
Full
ID
192.168.2.1
192.168.2.1
Pri Dead
128 38
128 37
root@srxA1>
Cuestin: El router srxAX muestra las adyacencias OSPF con sus vecinos
en el estado Full?
Si, se muestran dos adyacencias en el estado Full.
1.12. Desde el router vr10X, utiliza el ping para comprobar la comunicacin con
las IP de loopback del resto de dispositivos.
root@vr101> ping 192.168.1.1 rapid count 25
PING 192.168.1.1 (192.168.1.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 192.168.2.1 (192.168.2.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
126

PING 172.31.15.1 (172.31.15.1): 56 data bytes
.........................
Cuestin: Por qu ha fallado el ping al Host de Internet?
Si realizamos un traceroute vemos lo siguiente:
root@vr101> traceroute 172.31.15.1
traceroute to 172.31.15.1 (172.31.15.1), 30 hops max, 40 byte packets
1 172.20.101.1 (172.20.101.1) 1.320 ms 1.384 ms 1.025 ms
2 ***
3 ***
4 *^C
Esta situacin es debida a que el router INTERNET no tiene ninguna ruta
para que las respuestas del ping puedan llegar al que las origina,
192.168.1.2.
1.13. Acceder al router INTERNET y ver su tabla de enrutamiento con el

comando show route.
root@INTERNET> show route
172.18.1.0/30
172.18.1.1/32
172.18.2.0/30
172.18.2.1/32
172.31.0.0/16
172.31.1.1/32
192.168.3.1/32
*[Direct/0] 00:51:03
> via em0.0
*[Local/0] 00:51:03
Local via em0.0
*[Direct/0] 00:51:00
> via em1.0
*[Local/0] 00:51:00
Local via em1.0
*[Direct/0] 00:50:59
> via em2.0
*[Local/0] 00:50:59
Local via em2.0
*[Direct/0] 00:51:03
> via lo0.0
root@INTERNET>
127
1.14. Acceder al modo de configuracin y crear una ruta por defecto hacia el
router srxA1.
root@INTERNET> configure
[edit]
root@INTERNET# edit routing-options
root@INTERNET# set static route 0/0 next-hop 172.18.1.2
root@INTERNET# commit and-quit
commit complete
root@INTERNET>
1.15. Volver a comprobar la conectividad con un ping desde el router vr10X.

PING 172.31.15.1 (172.31.15.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
root@vr101>
1.16. Desde el router vr10X, intenta establecer una sesin FTP con tu dispositivo
asignado. Utiliza la direccin de configurada en el router como la IP del
servidor FTP. Accede con el usuario lab para comprobar el servicio.
root@vr101> ftp 192.168.1.1
220 srxA1 FTP server (Version 6.00LS) ready.
Name (192.168.1.1:root): lab
331 Password required for lab.
Password:
230 User lab logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
128
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for '/bin/ls'.
total 4
drwxr-xr-x 2 lab staff 512 Jul 15 20:42 .ssh
226 Transfer complete.
ftp> bye
221 Goodbye.
root@vr101>
Cuestin: Se ha establecido la sesin FTP?
Tal y como se muestra, la conexin con el servidor FTP se ha establecido
correctamente.
1.17. Desde el router vr10X, intenta establecer una sesin SSH con tu dispositivo
asignado. Utiliza la direccin de configurada en el router como la IP del
servidor SSH. Accede con el usuario lab para comprobar el servicio.
root@vr101> ssh lab@192.168.1.1
lab@192.168.1.1's password:
--- JUNOS 10.1R1.8 built 2010-02-12 17:15:05 UTC
lab@srxA1> quit
Connection to 192.168.1.1 closed.
1.18. Desde el router vr10X, intenta establecer una sesin TELNET con tu
dispositivo asignado. Utiliza la direccin de configurada en el router como
la IP del servidor TELNET. Accede con el usuario lab para comprobar el
servicio.
root@vr101> telnet 192.168.1.1
Trying 192.168.1.1...
Escape character is '^]'.
srxA1 (ttyp0)
login: lab
Password:******
--- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC
129
lab@srxA1> exit
Connection closed by foreign host.
root@vr101>
Cuestin: Se ha establecido la sesin TELNET?

Tal y como se muestra, la conexin con el servidor TELNET se ha
establecido correctamente.
1.19. Ver la tabla de enrutamiento y comprobar que se muestran todas las

subredes del escenario. Ejecutar el comando show route.
root@srxA1> show route

0.0.0.0/0
10.210.14.128/27
10.210.14.131/32
172.18.1.0/30
172.18.1.2/32
172.18.2.0/30
172.20.66.0/30
172.20.66.1/32
172.20.77.0/30
172.20.77.1/32
130
*[Static/5] 02:48:05
> to 172.18.1.1 via em3.0
[OSPF/150] 02:46:50, metric 0, tag 0
> to 172.20.77.2 via em1.0
to 172.20.66.2 via em2.0
*[Direct/0] 02:48:07
> via em0.0
*[Local/0] 02:48:07
Local via em0.0
*[Direct/0] 02:48:05
> via em3.0
*[Local/0] 02:48:05
Local via em3.0
*[OSPF/150] 02:46:50, metric 0, tag 0
> to 172.20.77.2 via em1.0
to 172.20.66.2 via em2.0
*[Direct/0] 02:48:06
> via em2.0
*[Local/0] 02:48:06
Local via em2.0
*[Direct/0] 02:48:07
> via em1.0
*[Local/0] 02:48:07
Local via em1.0
172.20.101.0/24
172.20.101.1/32
172.20.102.0/24
172.21.0.0/24
172.21.1.0/24
172.21.2.0/24
172.22.0.0/24
172.22.1.0/24
172.22.2.0/24
192.168.1.1/32
192.168.1.2/32
192.168.2.1/32
224.0.0.5/32
*[Direct/0] 00:04:37
> via em4.101
*[Local/0] 00:04:37
Local via em4.101
*[OSPF/150] 02:41:48, metric 0, tag 0
> to 172.20.77.2 via em1.0
to 172.20.66.2 via em2.0
*[Static/5] 00:04:37
> to 172.20.101.10 via em4.101
*[Static/5] 00:04:37
> to 172.20.101.10 via em4.101
*[Static/5] 00:04:37
> to 172.20.101.10 via em4.101
*[OSPF/150] 02:41:48, metric 0, tag 0
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[OSPF/150] 02:41:48, metric 0, tag 0
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[OSPF/150] 02:41:48, metric 0, tag 0
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[Direct/0] 02:48:07
> via lo0.0
*[OSPF/10] 00:01:08, metric 1
> to 172.20.101.10 via em4.101
*[OSPF/10] 02:46:50, metric 1
> to 172.20.77.2 via em1.0
to 172.20.66.2 via em2.0
*[OSPF/10] 02:48:13, metric 1
MultiRecv
Cuestin: El router srxAX tiene en su tabla las entradas a las rutas con
destinos internos y externos?
Si, en este punto se debera tener las mismas rutas que se muestran en el
listado anterior.
Parte 2: Configurando y Monitorizando Filtros Firewall
En esta parte del laboratorio se aprender a configurar y monitorizar filtros

firewall.
131
2.1.
Desde el router srxAX, accede al modo de configuracin y sitate en el

nivel [edit firewall].
root@srxA1# top edit firewall
[edit firewall]
root@srxA1#
2.2.
Ejecuta el comando edit family ? y responde a la siguiente cuestin:

[edit firewall]
root@srxA1# edit family ?
Possible completions:
> any
Protocol-independent filter
> ccc
Protocol family CCC for firewall filter
> inet
Protocol family IPv4 for firewall filter
> inet6
Protocol family IPv6 for firewall filter
> mpls
Protocol family MPLS for firewall filter
> vpls
Protocol family VPLS for firewall filter
[edit firewall]
root@srxA1# edit family
Cuestin: Basndose en las opciones mostradas, Qu opcin se utiliza
para los filtros firewall IPv4?
La opcin family inet es la que se utiliza en los filtros firewall del tipo IPv4.
2.3.
Ejecuta el comando edit family inet filter protect-host para iniciar la

creacin de un nuevo filtro firewall denominado protect-host.
[edit firewall]
root@srxA1# edit family inet filter protect-host
[edit firewall family inet filter protect-host]
root@srxA1#
2.4.
Crea un trmino denominado limit-icmp que solamente permita paquetes

ICMP entrantes desde la subred 10.210.0.0/16.
root@srxA1# set term limit-icmp from protocol icmp
132

root@srxA1# set term limit-icmp from source-address 10.210.0.0/16
root@srxA1# set term limit-icmp then accept
2.5.
Crea un trmino denominado limit-ftp que solamente permita paquetes

FTP entrantes desde la subred 10.210.0.0/16.
root@srxA1# set term limit-ftp from protocol icmp
root@srxA1# set term limit- ftp from source-address 10.210.0.0/16
root@srxA1# set term limit- ftp then accept
2.6.
Crea un trmino denominado limit-ssh que solamente permita paquetes

SSH entrantes desde la subred 10.210.0.0/16.
root@srxA1# set term limit-ssh from protocol icmp
root@srxA1# set term limit-ssh from source-address 10.210.0.0/16
root@srxA1# set term limit-ssh then accept
2.7.
Crea un trmino denominado limit-telnet que solamente permita paquetes

Telnet entrantes desde la subred 10.210.0.0/16.
root@srxA1# set term limit-telnet from protocol tcp port telnet
root@srxA1# set term limit-telnet from source-address 10.210.0.0/16
root@srxA1# set term limit-telnet then accept
133
2.8.
Situarse en el nivel [edit interfaces lo0] y aplicar el filtro protect-host

como un filtro de entrada. Confirmar la nueva configuracin y activarla con
el comando commit.
root@srxA1# top edit interfaces lo0
root@srxA1# set unit 0 family inet filter input protect-host
[edit interfaces lo0]
root@srxA1# commit
commit complete
root@srxA1#
2.9.
Desde el router vr10X utiliza el ping para comprobar la comunicacin con

los direcciones loopback de los routers y del Host de Internet.
PING 192.168.1.1 (192.168.1.1): 56 data bytes
.........................
PING 172.31.15.1 (172.31.15.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
root@vr101>
Cuestin: Los pings fueron satisfactorios? Fue el resultado esperado?

Como se muestra, el ping a la IP loopback del router fall pero el ping al
Host de Internet funcion. Esta respuesta es la esperada ya que el filtro
slo permite trfico ICMP de la subred 10.210.0.0/16, pero este filtro no
afecta al trfico de trnsito, es decir al 172.31.15.1.
134
2.10. Desde el router vr10X intenta establecer una sesin FTP, TELNET y SSH
al router srxAX. Utiliza el usuario lab para comprobar los servicios.
root@vr101> ftp 192.168.1.1
^C
root@vr101> ssh lab@192.168.1.1
^C
Trying 192.168.1.1...
^C
root@vr101>
Cuestin: Se han establecido las sesiones FTP, SSH y TELNET? Dada la

configuracin actual, este comportamiento es el esperado?
Tal y como se muestra en la captura, ninguna sesin se ha establecido.
Debido a que el origen de las sesiones no es desde la subred
10.210.0.0/16, stas fallan y no contestan los servicios.
2.11. Desde el Host en la subred 10.210.0.0/16 realizar un ping, TELNET y SSH

al router srxAX para confirmar el funcionamiento del filtro.
lab> ping 172.31.15.1 rapid count 25
PING 172.31.15.1 (172.31.15.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
lab> ftp 192.168.1.1
Name (192.168.1.1:root): lab
Password:
ftp> bye
221 Goodbye.
lab> ssh lab@192.168.1.1
135
--- JUNOS 10.1R1.8 built 2010-02-12 17:15:05 UTC

lab@srxA1> quit
lab> telnet 192.168.1.1
Trying 192.168.1.1...
srxA1 (ttyp0)
login: lab
Password:******
--- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC
lab@srxA1> exit
Cuestin: Han funcionado los servicios ping, FTP, SSH y TELNET?

Si porque las sesiones se han realizado desde dentro de la subred
10.210.0.0/16.
2.12. Desde el router srxAX ejecuta los comandos run show ospf neighbor y
run show route para comprobar el estado actual de los vecinos OSPF y
de las entradas en la tabla de enrutamiento.
root@srxA1# run show ospf neighbor
root@srxA1# run show route
0.0.0.0/0
10.210.14.128/28
10.210.14.131/32
172.18.1.0/30
136
*[Static/5] 01:24:51
> to 172.18.1.1 via em3.0
*[Direct/0] 01:24:54
> via em0.0
*[Local/0] 01:24:54
Local via em0.0
*[Direct/0] 01:24:54
> via em3.0
172.18.1.2/32
172.20.66.0/30
172.20.66.1/32
172.20.77.0/30
172.20.77.1/32
172.20.101.0/24
172.20.101.1/32
172.21.0.0/24
172.21.1.0/24
172.21.2.0/24
192.168.1.1/32
224.0.0.5/32
*[Local/0] 01:24:54
Local via em3.0
*[Direct/0] 01:24:54
> via em2.0
*[Local/0] 01:24:54
Local via em2.0
*[Direct/0] 01:24:54
> via em1.0
*[Local/0] 01:24:54
Local via em1.0
*[Direct/0] 00:38:32
> via em4.101
*[Local/0] 00:38:32
Local via em4.101
*[Static/5] 00:38:32
> to 172.20.101.10 via em4.101
*[Static/5] 00:38:32
> to 172.20.101.10 via em4.101
*[Static/5] 00:38:32
> to 172.20.101.10 via em4.101
*[Direct/0] 01:24:54
> via lo0.0
*[OSPF/10] 01:24:56, metric 1
MultiRecv

root@srxA1#
Cuestin: El router muestra adyacencias de vecinos OSPF o rutas

aprendidas a travs de OSPF? Puedes explicar por qu?
Tal y como se muestra en la captura, el router no detecta ningn vecino
OSPF en este instante. La razn es debida al filtro firewall implementado
ya que limita el trfico para protocolos especficos como OSPF.
Resolveremos esta situacin en los siguientes pasos.
2.13. Desactiva el filtro firewall aplicado a la interface loopback y activa los

cambios.
root@srxA1# deactivate unit 0 family inet filter
root@srxA1# show
137
unit 0 {
family inet {
inactive: filter {
input protect-host;
}
address 192.168.1.1/32;
}
}
root@srxA1# commit
commit complete
root@srxA1#
2.14. Ejecuta los comandos run show ospf neighbor y run show route otra vez
para comprobar el estado de los vecinos OSPF y de las entradas en la
tabla de enrutamiento.
Address
Interface
State ID
172.20.77.2 em1.0
Full 192.168.2.1
172.20.66.2 em2.0
Full 192.168.2.1
Pri Dead
128 33
128 32

0.0.0.0/0
10.210.14.128/28
10.210.14.131/32
172.18.1.0/30
172.18.1.2/32
138
*[Static/5] 02:04:56
> to 172.18.1.1 via em3.0
[OSPF/150] 00:22:21, metric 0, tag 0
> to 172.20.77.2 via em1.0
to 172.20.66.2 via em2.0
*[Direct/0] 02:04:59
> via em0.0
*[Local/0] 02:04:59
Local via em0.0
*[Direct/0] 02:04:59
> via em3.0
*[Local/0] 02:04:59
Local via em3.0
172.18.2.0/30
172.20.66.0/30
172.20.66.1/32
172.20.77.0/30
172.20.77.1/32
172.20.101.0/24
172.20.101.1/32
172.20.102.0/24
172.21.0.0/24
172.21.1.0/24
172.21.2.0/24
172.22.0.0/24
172.22.1.0/24
172.22.2.0/24
192.168.1.1/32
192.168.2.1/32
224.0.0.5/32
*[OSPF/150] 00:22:21, metric 0, tag 0

to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[Direct/0] 02:04:59
> via em2.0
*[Local/0] 02:04:59
Local via em2.0
*[Direct/0] 02:04:59
> via em1.0
*[Local/0] 02:04:59
Local via em1.0
*[Direct/0] 00:22:36
> via em4.101
*[Local/0] 00:22:36
Local via em4.101
*[OSPF/150] 00:02:23, metric 0, tag 0
> to 172.20.77.2 via em1.0
to 172.20.66.2 via em2.0
*[Static/5] 00:22:36
> to 172.20.101.10 via em4.101
*[Static/5] 00:22:36
> to 172.20.101.10 via em4.101
*[Static/5] 00:22:36
> to 172.20.101.10 via em4.101
*[OSPF/150] 00:02:23, metric 0, tag 0
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[OSPF/150] 00:02:23, metric 0, tag 0
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[OSPF/150] 00:02:23, metric 0, tag 0
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[Direct/0] 02:04:59
> via lo0.0
*[OSPF/10] 00:22:21, metric 1
> to 172.20.77.2 via em1.0
to 172.20.66.2 via em2.0
*[OSPF/10] 02:05:01, metric 1
MultiRecv

root@srxA1#
Cuestin: Con el filtro firewall desactivado, vuelven a verse los vecinos

OSPF? Y las rutas aprendidas de los vecinos OSPF?
139
Tal y como se muestra, en el router srxAX vuelven a aparecer las

adyacencias a los dos vecinos OSPF y tambin aparecen las rutas
aprendidas por OSPF.
2.15. En el router srxAX, situarse en el nivel [edit firewall family inet filter
protect-host]. Reestructura el filtro firewall protect-host para lograr los

objetivos del paso anterior y as permitir el resto de trfico utilizando el
termino else-accept que implcitamente permite todo el resto del trfico.
Incluye un contador para cada trmino definido. Denomina cada uno de los
contadores count-X, donde X es el nombre del trmino asociado.
Nota: en la mayora de implementaciones de filtros firewall, normalmente

se utiliza la accin discard ms que la accin reject para evitar el envo de
notificaciones a los atacantes potenciales. En este laboratorio se podra
elegir la accin reject para simplificar la comprobacin de las pruebas. En
este laboratorio utilizaremos la accin discard para cada trmino definido.
root@srxA1# top edit firewall family inet filter protect-host
root@srxA1# set term limit-icmp from source-address 0/0
root@srxA1# set term limit-icmp from source-address 10.210.0.0/16 except
root@srxA1# set term limit-icmp then count count-limit-icmp
root@srxA1# set term limit-icmp then discard
root@srxA1# set term limit-ftp from source-address 0/0
root@srxA1# set term limit-ftp from source-address 10.210.0.0/16 except
root@srxA1# set term limit-ftp then count count-limit-ftp
140

root@srxA1# set term limit-ftp then discard
root@srxA1# set term limit-ssh from source-address 0/0
root@srxA1# set term limit-ssh from source-address 10.210.0.0/16 except
root@srxA1# set term limit-ssh then count count-limit-ssh
root@srxA1# set term limit-ssh then discard
root@srxA1# set term limit-telnet from source-address 0/0
root@srxA1# set term limit-telnet from source-address 10.210.0.0/16 except
root@srxA1# set term limit-telnet then count count-limit-telnet
root@srxA1# set term limit-telnet then discard
root@srxA1# set term else-accept then count count-else-accept
root@srxA1# set term else-accept then accept
root@srxA1# show
term limit-telnet {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol tcp;
port telnet;
}
then {
count count-limit-telnet;
141
discard;
}
}
term limit-icmp {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol icmp;
}
then {
count count-limit-icmp;
discard;
}
}
term limit-ftp {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol tcp;
port ftp;
}
then {
count count-limit-ftp;
discard;
}
}
term limit-ssh {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol tcp;
port ssh;
}
then {
count count-limit-ssh;
discard;
}
}
term else-accept {
then {
count count-else-accept;
142
accept;
}
}
root@srxA1#
2.16. Vuelve al nivel [edit interfaces lo0] y reactiva el filtro protect-host. Ejecuta
el comando commit para activar los cambios en la configuracin.
root@srxA1# activate unit 0 family inet filter
root@srxA1# show
unit 0 {
family inet {
filter {
input protect-host;
}
address 192.168.1.1/32;
}
}
root@srxA1# commit
commit complete
root@srxA1#
2.17. Ejecuta los comandos run show ospf neighbor y run show route otra vez
para comprobar el estado de los vecinos OSPF y de las entradas en la
tabla de enrutamiento.
Address
Interface
State ID
172.20.77.2 em1.0
Full 192.168.2.1
172.20.66.2 em2.0
Full 192.168.2.1
Pri Dead
128 36
128 39
143

0.0.0.0/0
10.210.14.128/28
10.210.14.131/32
172.18.1.0/30
172.18.1.2/32
172.18.2.0/30
172.20.66.0/30
172.20.66.1/32
172.20.77.0/30
172.20.77.1/32
172.20.101.0/24
172.20.101.1/32
172.20.102.0/24
172.21.0.0/24
172.21.1.0/24
172.21.2.0/24
172.22.0.0/24
172.22.1.0/24
144
*[Static/5] 02:43:17
> to 172.18.1.1 via em3.0
[OSPF/150] 01:00:42, metric 0, tag 0
> to 172.20.77.2 via em1.0
to 172.20.66.2 via em2.0
*[Direct/0] 02:43:20
> via em0.0
*[Local/0] 02:43:20
Local via em0.0
*[Direct/0] 02:43:20
> via em3.0
*[Local/0] 02:43:20
Local via em3.0
*[OSPF/150] 01:00:42, metric 0, tag 0
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[Direct/0] 02:43:20
> via em2.0
*[Local/0] 02:43:20
Local via em2.0
*[Direct/0] 02:43:20
> via em1.0
*[Local/0] 02:43:20
Local via em1.0
*[Direct/0] 00:01:18
> via em4.101
*[Local/0] 00:01:18
Local via em4.101
*[OSPF/150] 00:40:44, metric 0, tag 0
> to 172.20.77.2 via em1.0
to 172.20.66.2 via em2.0
*[Static/5] 01:00:57
> to 172.20.101.10 via em4.101
*[Static/5] 01:00:57
> to 172.20.101.10 via em4.101
*[Static/5] 01:00:57
> to 172.20.101.10 via em4.101
*[OSPF/150] 00:40:44, metric 0, tag 0
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[OSPF/150] 00:40:44, metric 0, tag 0
172.22.2.0/24
192.168.1.1/32
192.168.2.1/32
224.0.0.5/32
to 172.20.77.2 via em1.0

> to 172.20.66.2 via em2.0
*[OSPF/150] 00:40:44, metric 0, tag 0
to 172.20.77.2 via em1.0
> to 172.20.66.2 via em2.0
*[Direct/0] 02:43:20
> via lo0.0
*[OSPF/10] 01:00:42, metric 1
> to 172.20.77.2 via em1.0
to 172.20.66.2 via em2.0
*[OSPF/10] 02:43:22, metric 1
MultiRecv

root@srxA1#
Cuestin: Con el filtro firewall actualizado y activado, El router srxAX

todava tiene los dos vecinos OSPF? Y las rutas OSPF en su tabla de
enrutamiento?
Como ya hemos apreciado en las capturas, el router sigue viendo las dos
adyacencias con sus vecinos OSPF y siguen apareciendo las entradas
OSPF en la tabla.
2.18. Desde el router vr10X realizar un ping a la IP loopback del router srxAX y
comprobar la comunicacin.
PING 192.168.1.1 (192.168.1.1): 56 data bytes
.........................
2.19. Desde el router vr10X, intenta establecer una conexin FTP, SSH y
TELNET al router srxAX.
root@vr101> ftp 192.168.1.1
^C
root@vr101> ssh lab@192.168.1.1
^C
Trying 192.168.1.1...
^C
145
root@vr101>
Cuestin: Se han establecido las sesiones FTP, SSH y TELNET? Dada la

configuracin actual, este comportamiento es el esperado?
Tal y como se muestra en la captura, ninguna sesin se ha establecido.
Debido a que el origen de las sesiones no es desde la subred
10.210.0.0/16, stas fallan y no contestan los servicios.
2.20. Desde el Host en la subred 10.210.0.0/16 realizar un ping, TELNET y SSH

al router srxAX para confirmar el funcionamiento del filtro.
lab> ping 172.31.15.1 rapid count 25
PING 172.31.15.1 (172.31.15.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
lab> ftp 192.168.1.1
Name (192.168.1.1:root): lab
Password:
ftp> bye
221 Goodbye.
lab> ssh lab@192.168.1.1
--- JUNOS 10.1R1.8 built 2010-02-12 17:15:05 UTC
lab@srxA1> quit
lab> telnet 192.168.1.1
Trying 192.168.1.1...
srxA1 (ttyp0)
146
login: lab
Password:******
--- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC
lab@srxA1> exit
Cuestin: Han funcionado los servicios ping, FTP, SSH y TELNET?

Si porque las sesiones se han realizado desde dentro de la subred
10.210.0.0/16.
2.21. Volver al router srxAX y ejecutar el comando run show firewall para
determinar si los contadores se incrementan.
root@srxA1# run show firewall
Filter: protect-host
Counters:
Name
count-else-accept
count-limit-ftp
count-limit-icmp
count-limit-ssh
count-limit-telnet
Bytes
137938
256
6720
128
128
Packets
1524
4
80
2
2
Filter: __default_bpdu_filter__
root@srxA1#
Cuestin: Los contadores del filtro protect-host se incrementan?

Como podemos observar, s que se incrementan los contadores y ninguno
tiene el contador a cero.
147
Parte 3: Configurar servidor TFTP de copias de configuracin
Para realizar una copia de seguridad de los archivos juniper.conf de todos

nuestros routers, seguir los pasos descritos en la Parte 3 del Laboratorio 2.
A continuacin se muestran las configuraciones de los diferentes routers:

srxA1:
version 10.1R1.8;
system {
host-name srxA1;
encrypted-password "$1$khYtQ9ir$hSlWVunnZ05Vp87s/4was1"; ## SECRET-DATA
}
login {
user lab {
uid 2000;
class read-only;
authentication {
encrypted-password "$1$G.EH5a4K$mtw12P74z4.8CLxih.4sV1"; ## SECRETDATA
}
}
}
services {
ftp;
ssh;
telnet;
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
148
}
interfaces {
em0 {
unit 0 {
family inet {
address 10.210.14.131/28;
}
}
}
em1 {
unit 0 {
family inet {
address 172.20.77.1/30;
}
}
}
em2 {
unit 0 {
family inet {
address 172.20.66.1/30;
}
}
}
em3 {
unit 0 {
family inet {
address 172.18.1.2/30;
}
}
}
em4 {
vlan-tagging;
unit 101 {
vlan-id 101;
family inet {
address 172.20.101.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
filter {
input protect-host;
}
address 192.168.1.1/32;
}
149
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop 172.18.1.1;
route 172.21.0.0/24 next-hop 172.20.101.10;
route 172.21.1.0/24 next-hop 172.20.101.10;
route 172.21.2.0/24 next-hop 172.20.101.10;
}
}
protocols {
ospf {
export ospf-export;
area 0.0.0.0 {
interface em1.0;
interface em2.0;
interface lo0.0;
}
}
}
policy-options {
from {
protocol static;
}
then accept;
}
from {
}
then accept;
}
from {
protocol static;
}
then accept;
}
}
150
}
firewall {
family inet {
filter protect-host {
term limit-telnet {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol tcp;
port telnet;
}
then {
discard;
}
}
term limit-icmp {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol icmp;
}
then {
discard;
}
}
term limit-ftp {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol tcp;
port ftp;
}
then {
discard;
}
}
term limit-ssh {
from {
151
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol tcp;
port ssh;
}
then {
discard;
}
}
term else-accept {
then {
accept;
}
}
}
}
}
srxA2:
## Last changed: 2013-07-18 13:56:27 UTC
version 10.1R1.8;
system {
host-name srxA2;
encrypted-password "$1$khYtQ9ir$hSlWVunnZ05Vp87s/4was1";
}
login {
user lab {
uid 2000;
class read-only;
authentication {
encrypted-password "$1$G.EH5a4K$mtw12P74z4.8CLxih.4sV1";
}
}
}
services {
ftp;
ssh;
telnet;
}
syslog {
152
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
}
interfaces {
em1 {
unit 0 {
family inet {
address 172.20.66.2/30;
}
}
}
em2 {
unit 0 {
family inet {
address 172.20.77.2/30;
}
}
}
em3 {
unit 0 {
family inet {
address 172.18.2.2/30;
}
}
}
em4 {
vlan-tagging;
unit 102 {
vlan-id 102;
family inet {
address 172.20.102.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
filter {
153
input protect-host;
}
address 192.168.2.1/32;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop 172.18.2.1;
route 172.22.0.0/24 next-hop 172.20.102.10;
route 172.22.1.0/24 next-hop 172.20.102.10;
route 172.22.2.0/24 next-hop 172.20.102.10;
}
}
protocols {
ospf {
export ospf-export;
area 0.0.0.0 {
interface em1.0;
interface em2.0;
interface lo0.0;
}
}
}
policy-options {
from {
protocol static;
}
then accept;
}
from {
}
then accept;
}
from {
protocol static;
154
}
then accept;
}
}
}
firewall {
family inet {
filter protect-host {
term limit-telnet {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol tcp;
port telnet;
}
then {
discard;
}
}
term limit-icmp {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol icmp;
}
then {
discard;
}
}
term limit-ftp {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol tcp;
port ftp;
}
then {
discard;
155
}
}
term limit-ssh {
from {
source-address {
10.210.0.0/16 except;
0.0.0.0/0;
}
protocol tcp;
port ssh;
}
then {
discard;
}
}
term else-accept {
then {
accept;
}
}
}
}
}
vr101:
## Last changed: 2013-07-18 11:26:18 UTC
version 10.1R1.8;
system {
host-name vr101;
encrypted-password "$1$Lla6AF1X$HDveKaSFJYQs6yJfR7wCw0";
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
156
}
}
interfaces {
em0 {
vlan-tagging;
unit 101 {
vlan-id 101;
family inet {
address 172.20.101.10/24;
}
}
}
em1 {
unit 0 {
family inet {
address 172.21.0.1/24;
address 172.21.1.1/24;
address 172.21.2.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.2/32;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop 172.20.101.1;
}
}
protocols {
ospf {
area 0.0.0.0 {
interface em0.101;
interface lo0.0;
}
}
}
vr102:
## Last changed: 2013-07-18 13:17:14 UTC
157
version 10.1R1.8;
system {
host-name vr102;
encrypted-password "$1$JVkVKUrg$X6LDux9w1u2/qUblZHQpJ1";
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
}
interfaces {
em0 {
vlan-tagging;
unit 102 {
vlan-id 102;
family inet {
address 172.20.102.10/24;
}
}
}
em1 {
unit 0 {
family inet {
address 172.22.0.1/24;
address 172.22.1.1/24;
address 172.22.2.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.2.2/32;
}
}
}
}
routing-options {
158
static {
route 0.0.0.0/0 next-hop 172.20.102.1;
}
}
protocols {
ospf {
area 0.0.0.0 {
interface em0.102;
interface lo0.0;
}
}
}
INTERNET:
## Last changed: 2013-07-18 11:10:54 UTC
version 12.1R1.9;
system {
encrypted-password "$1$vb1hM25o$kGBx4oqIME5Q9czGWav/70";
}
services {
telnet;
}
syslog {
user * {
any emergency;
}
file messages {
any notice;
authorization info;
}
}
}
}
interfaces {
em0 {
unit 0 {
family inet {
address 172.18.1.1/30;
}
}
}
em1 {
159
unit 0 {
family inet {
address 172.18.2.1/30;
}
}
}
em2 {
unit 0 {
family inet {
address 172.31.1.1/16;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.3.1/32;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop 172.18.1.2;
}
}
160
7.
Lab 4: Clases de Servicios (CoS)
En este laboratorio se introduce la configuracin bsica de las Clases de Servicios

en dispositivos que ejecutan el sistema operativo JUNOS bajo el emulador GNS3.
Aunque ms adelante se ver que no se pueden aplicar y ejecutar los Mapas de

Planificacin en las interfaces em debido a que el sistema Junos muestra un error
por el tipo de interface utilizada por las Olivas, se ha creido conveniente incluir
este laboratorio para que sirva de gua en un entorno real. La gran mayora de los
comandos se pueden ejecutar y se aaden al fichero de configuracin excepto el
apartado 2.4 que es el que genera el error. Se comentar ms adelante.
En esta prctica se utilizar la lnea de comandos (CLI) para definir, aplicar y

monitorizar los componentes CoS.
El escenario completo del Laboratorio 4 es el siguiente:
Figura 58: Escenario original del laboratorio Clases de Servicios.
Vamos a implementar el escenario anterior en GNS3 con seis routers JUNOS

R10.1. El diseo del escenario en GNS3 quedar de la siguiente manera:
161
Figura 59: Escenario adaptado del laboratorio Clases de Servicios.

elementos:

3GB de memoria RAM.
162
Preparar los routers y comprobar su funcionamiento.
Configurar colas y mapas planificados.
Configurar la clasificacin multicampo.
Verificar el funcionamiento de la clasificacin multicampo.
Configurar el comportamiento global redefiniendo reglas y clasificadores.


1.1.

situarse en el nivel [edit firewall] y borrar toda la configuracin.
[edit]
root @srxA1# delete firewall
1.2.
Ejecutar el comando delete interfaces lo0 unit 0 family inet filter para
borrar la aplicacin del filtro firewall de la interface lo0.
[edit]
root@srxA1# delete interfaces lo0 unit 0 family inet filter
1.3.
Borrar las interfaces em2 y em3.

[edit]
root@srxA1# delete interfaces em2
[edit]
root@srxA1# delete interfaces em3
1.4.
Borrar la interface em2 del protocolo OSPF.

[edit]
root@srxA1# delete protocols ospf area 0 interface em2
1.5.
Borrar las actuales rutas estticas definidas.

[edit]
root@srxA1# delete routing-options
163
1.6.
Situarse en el nivel [edit interfaces] y configurar la interface lgica

em3.10X. y em4.20X.
[edit]
root@srxA1# edit interfaces
[edit interfaces]
root@srxA1# set em3 vlan-tagging
[edit interfaces]
root@srxA1# set em3 unit 101 vlan-id 101
[edit interfaces]
root@srxA1# set em3 unit 101 family inet address 172.20.101.1/24
[edit interfaces]
root@srxA1# set em4 vlan-tagging
[edit interfaces]
root@srxA1# set em4 unit 201 vlan-id 201
[edit interfaces]
1.7.
Muestra la actual configuracin y comprueba que todo es correcto. Una vez

comprobado, ejecuta el comando commit para activar los cambios.
[edit interfaces]
root@srxA1# show
em0 {
unit 0 {
family inet {
address 10.210.14.131/28;
}
}
}
em1 {
unit 0 {
family inet {
address 172.20.77.1/30;
}
}
}
em3 {
vlan-tagging;
164
unit 101 {
vlan-id 101;
family inet {
address 172.20.101.1/24;
}
}
}
em4 {
vlan-tagging;
unit 201 {
vlan-id 201;
family inet {
address 172.20.201.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
}
[edit interfaces]
root@srxA1# commit
commit complete
1.8.
Acceder al router vr10X y borrar la interface em1. Activar la VLAN 10X.

root@vr101> configure
[edit]
root@vr101# delete interfaces em1
[edit]
root@vr101# commit
commit complete
[edit]
root@vr101# deactivate interfaces em0
[edit]
root@vr101# commit
commit complete
[edit]
165
root@vr101# activate interfaces em0

[edit]
root@vr101# commit and-quit
commit complete
root@vr101> show interfaces terse | match em
Interface
Remote
demux0
up
up
em0
up
up
em0.101
up
up inet 172.20.101.10/24
em0.32767
up
up
em1
up
down
em2
up
down
em3
up
down
em4
up
down
1.9.
Acceder al router vr20X y configurar la interface em0.

[edit]
root@vr201# edit interfaces
[edit interfaces]
root@vr201# set em0 vlan-tagging
[edit interfaces]
root@vr201# set em0 unit 201 vlan-id 201
[edit interfaces]
root@vr201# set em0 unit 201 family inet address 172.20.201.10/24
[edit interfaces]
root@vr201# set lo0 unit 0 family inet address 192.168.1.3/32
[edit interfaces]
root@vr201# commit and-quit
commit complete
root@vr201> show interfaces terse | match em
Interface
Admin Link
Proto Local
Remote
demux0
up up
em0
up up
em0.201
up up
inet 172.20.201.10/24
em0.32767
up up
em1
up down
166
em2
em3
em4
up down
up down
up down
root@vr201>
1.10. Desde el router srxAX utilizar el ping para comprobar la comunicacin con
ambos routers vr10X y vr20X.
[edit interfaces]
root@srxA1# run ping 172.20.101.10 rapid count 25
PING 172.20.101.10 (172.20.101.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
[edit interfaces]
root@srxA1# run ping 172.20.201.10 rapid count 25
PING 172.20.201.10 (172.20.201.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
[edit interfaces]
root@srxA1#
Cuestin: Han funcionado los dos pings?
Si. En caso contrario repasa las configuraciones de los routers.
1.11. Situarse en el nivel [edit policy-options policy-statement ospf-export].

Ejecutar el comando para mostrar la configuracin actual para este nivel.
[edit interfaces]
root@srxA1# top edit policy-options policy-statement ospf-export
root@srxA1# show
from {
protocol static;
}
167
then accept;
}
from {
}
then accept;
}
from {
protocol static;
}
then accept;
}
root@srxA1#
1.12. Borrar los trminos match-default-static-route y match-other-static-
routes.
root@srxA1# delete term match-default-static-route
root@srxA1# delete term match-other-static-routes
1.13. Ejecutar el comando para ver el resultado de la configuracin. Borrar el
trmino que representa la conexin a Internet.
root@srxA1# show
from {
}
then accept;
}
168

root@srxA1# delete term match-interface-routes from route-filter 172.18.1.0/30
exact
1.14. Aadir una nueva ruta al trmino match-interface-routes para alcanzar la
nueva subred de la vlan 201.
root@srxA1# set term match-interface-routes from route-filter 172.20.201.0/24
exact
root@srxA1# show
from {
}
then accept;
}
root@srxA1# commit
commit complete
1.15. Ejecuta el comando run show ospf neighbor y run show route protocol
ospf para comprobar el estado actual de los vecinos OSPF y las entradas
en la tabla de enrutamiento.
[edit]
Address
Interface
State ID
Pri Dead
172.20.77.2 em1.0
Full 192.168.2.1 128 33
[edit]
root@srxA1# run show route protocol ospf
172.20.102.0/24 *[OSPF/150] 00:13:10, metric 0, tag 0
> to 172.20.77.2 via em1.0
172.20.202.0/24 *[OSPF/150] 00:00:18, metric 0, tag 0
> to 172.20.77.2 via em1.0
169
192.168.2.1/32
224.0.0.5/32
*[OSPF/10] 00:20:24, metric 1

> to 172.20.77.2 via em1.0
*[OSPF/10] 00:51:11, metric 1
MultiRecv
[edit]
root@srxA1#
Cuestin: En el router se muestran adyacencias de vecinos OSPF y rutas
OSPF?
Tal y como se muestra en la captura, existe una adyacencia con el vecino
192.168.2.1 y las rutas de la parte opuesta.
1.16. Desde los routers vr10X y vr20X comprobar con un ping la comunicacin
entre stos.
PING 172.20.102.10 (172.20.102.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 172.20.202.10 (172.20.202.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 172.20.101.10 (172.20.101.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
PING 172.20.201.10 (172.20.201.10): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
170
Cuestin: Respondieron satisfactoriamente los pings?

Tal y como se muestra en la captura, todos los ping respondieron. Si no es
as, repasa la configuracin y las rutas por defecto de los routers vr10x y
vr20X.
Parte 2: Configurando Colas y Mapas de Planificacin
Por defecto, los dispositivos Junos asignan todo el trfico a las clases best-effort y
network-control. Antes de poder asignar el trfico a otra clase, se debe configurar
un mapa planificado para cada interface con planificadores para dichas clases. En
esta parte del laboratorio se asociarn las colas con las clases de envo y se
configurarn planificadores y mapas de planificacin que se podrn aplicar a
todas las interfaces.
Utilizar la siguiente tabla como gua en esta parte:
Cola
2.1.
Clase de envo
Ancho de Banda y
Tamao Buffer (%)
Prioridad
Best-effodt
40
Low
Admin
45
Medium-low
Voip
10
High
Network-control
Medium-high
Acceder al router srxAX y situarse en el nivel [edit class-of-service
forwarding-classes]. Configurar la clase de envo a su respectiva cola tal

y como se muestra en la tabla.
root@srxA1# top
171
[edit]
root@srxA1# edit class-of-service forwarding-classes
[edit class-of-service forwarding-classes]
root@srxA1# set queue 1 admin
root@srxA1# set queue 2 voip
Cuestin: Se deben definir las clases de envo best-effort y networkcontrol o directamente asignarla a las colas 0 y 3?
No, no es necesario configurarlas ya que stas vienen definidas por
defecto en las definiciones de CoS.
2.2.
Configurar un planificador para cada clase de envo utilizando los

parmetros mostrados en la tabla. Define los planificadores como
forwarding-class-name-sched, donde forwarding-class-name es el
nombre del planificador correspondiente a la clase de envo.

root@srxA1# up
[edit class-of-service]
root@srxA1# edit schedulers best-effort-sched
[edit class-of-service schedulers best-effort-sched]
root@srxA1# set buffer-size percent 40
root@srxA1# set transmit-rate percent 40
root@srxA1# set priority low
root@srxA1# up
[edit class-of-service schedulers]
root@srxA1# edit admin-sched
[edit class-of-service schedulers admin-sched]
172

root@srxA1# set priority ?
Possible completions:
high
low
strict-high
root@srxA1# set priority low
root@srxA1# up
root@srxA1# edit voip-sched
[edit class-of-service schedulers voip-sched]
root@srxA1# set priority high
root@srxA1# up
root@srxA1# edit network-control-sched
[edit class-of-service schedulers network-control-sched]
root@srxA1# set priority high
root@srxA1#
173
2.3.
Configurar un mapa que se denomine my-sched-map que asocie cada

clase de envo con su correspondiente planificador. Guardaremos los
cambios generados en la configuracin. Hasta este momento no se debe
producir ningn error y el router debe aceptar el commit.
root@srxA1# up 2
[edit class-of-service]
root@srxA1# edit scheduler-maps my-sched-map
[edit class-of-service scheduler-maps my-sched-map]
root@srxA1# set forwarding-class best-effort scheduler best-effort-sched
root@srxA1# set forwarding-class admin scheduler admin-sched
root@srxA1# set forwarding-class voip scheduler voip-sched
root@srxA1# set forwarding-class network-control scheduler network-controlsched
[edit interfaces]
root@srxA1# commit and-quit
2.4.
En este punto en donde se produce el error ya que el sistema Junos no

permite asignar el mapa de planificacin creado en los puntos anteriores a
las interfaces.
Para poder continuar es recomendable omitir este apartado, si no el

sistema no dejar ejecutar los siguientes commit. Como prueba introducir
los siguientes comandos para confirmar que aparece el error y luego borrar
la configuracin con el comando delete.
[edit class-of-service interfaces]
root@srxA1# set em1 scheduler-map my-sched-map
174

[edit interfaces]
'em1'
Cannot configure class-of-service on interface em1.
error: configuration check-out failed
Cuestin: Qu resultados negativos podramos experimentar si erramos al

asignar un mapa a todas las interfaces?
Los dispositivos Junos podran utilizar un planificador por defecto para que
el trfico atraviese interfaces sin especificar. El planificador contiene buffers
para trfico solamente en las colas asociadas con las clases best-effort y
network-control (colas 0 y 3). Por lo tanto, el trfico que no sea el asociado
a stas clases podra desecharse.
Parte 3: Configurando Clasificacin Multicampo
En esta parte del laboratorio se configurar el router para colocar el trfico en una
clase de envo utilizando un clasificador multicampo.
3.1.
Situarse en el nivel [edit firewall family inet filter classify-traffic] para

crear un nuevo filtro firewall denominado classify-traffic.
root@srxA1# top edit firewall family inet filter classify-traffic
[edit firewall family inet filter classify-traffic]
root@srxA1#
3.2.
Crear un trmino denominado sip que asigne el trfico SIP originado desde
la subred 172.20.10X.0/24 en la clase de envo voip. El trfico SIP utiliza
UDP TCP y el puerto 5060.
175

root@srxA1# set term sip from source-address 172.20.101.0/24
root@srxA1# set term sip from protocol [tcp udp] port 5060
root@srxA1# set term sip then forwarding-class voip
root@srxA1# set term sip then accept
3.3.
Crear un trmino denominado rtp que asigne el trfico SIP originado desde
la subred 172.20.10X.0/24 en la clase de envo voip. El trfico RTP utiliza
UDP y el rango de puertos entre 16384-32767.
root@srxA1# set term rtp from source-address 172.20.101.0/24
root@srxA1# set term rtp from protocol udp port 16384-32767
root@srxA1# set term rtp then forwarding-class voip
root@srxA1# set term rtp then accept
3.4.
Crear un trmino denominado admin que asigne el trfico con una

direccin origen perteneciente a la red asociada con el router vr20X en la
clase de envo admin.
root@srxA1# set term admin from source-address 172.20.201.0/24
root@srxA1# set term admin then forwarding-class admin
root@srxA1# set term admin then accept
176
3.5.
Crear un trmino denominado accept-all que acepte todo el trfico y lo

asigne a la clase de envo por defecto.
root@srxA1# set term accept-all then accept
3.6.
Aplica el filtro firewall classify-traffic en las interfaces de las VLANs para

procesar el trfico entrante. Ejecuta el comando commit and-quit para
activar los cambios en la configuracin y volver al modo de operacin.
root@srxA1# top edit interfaces
[edit interfaces]
root@srxA1# set em3 unit 101 family inet filter input classify-traffic
[edit interfaces]
root@srxA1# set em4 unit 201 family inet filter input classify-traffic
[edit interfaces]
commit complete
Hasta aqu seran los pasos para configurar las Clases de Servicio en Junos y lo
que se puede implementar con Olivas. Para verificar el correcto funcionamiento
deberamos poder activar completamente los Mapas de Planificacin en las
interfaces y despus mostrar las estadsticas de trfico de las colas con el
comando show interface queue em0. Al no poder conseguirlo se ha omitido la
parte de comprobacin del laboratorio original.
177
178
8. Lab 5: IPv6
Este laboratorio demuestra la configuracin y monitorizacin de interfaces con IP
versin 6 (IPv6) sobre dispositivos que ejecutan el sistema operativo JUNOS bajo
el emulador GNS3. En esta prctica se utilizar la lnea de comandos (CLI) para
configurar y monitorizar interfaces, rotas estticas, OSPF bsico y tneles GRE
(Generic Routing Encapsulation).
El diseo del escenario en GNS3 quedar de la siguiente manera:
Figura 60: Escenario del laboratorio IPv6.

elementos:

179
3GB de memoria RAM.
Configurar y comprobar el funcionamiento de las interfaces IPv6.
Configurar y monitorizar enrutamiento esttico IPv6.
Configurar y monitorizar OSPF con interfaces IPv6.
Configurar una interface GRE para encapsular trfico IPv6 sobre una red
IPv4.
Parte 1: Configurar y Monitorizar Interfaces
En esta parte se configurarn las interfaces de red en los dispositivos del

diagrama. Luego se comprobar que las interfaces estn activas y que el sistema
aade las correspondientes entradas en la tabla de enrutamiento.
1.1.

cargar la configuracin por defecto de fbrica. Definir una contrasea para
el usuario root o no nos dejar guardar los cambios.
[edit]
root @srxA1# load factory-default
warning: activating factory configuration
[edit]
root@srxA1# set system root-authentication plain-text-password
New password:
[edit]
root@srxA1# commit
commit complete
180
1.2.
Comprobar que todas las interfaces no estn configuradas con el comando

run show interfaces terse.
[edit]
root@srxA1# run show interfaces terse
Interface
Admin Link
Proto
cbp0
up up
demux0
up up
dsc
up up
em0
up down
em1
up up
em2
up up
em3
up down
em4
up down
gre
up up
ipip
up up
irb
up up
lo0
up up
lo0.16384
up up
inet
lo0.16385
up up
inet
inet6
lsi
up up
mtun
up up
pimd
up up
pime
up up
pip0
up up
pp0
up up
tap
up up
Local
Remote
127.0.0.1
--> 0/0
128.0.0.4
--> 0/0
fe80::a00:27ff:fe58:7da4
[edit]
root@srxA1#
1.3.
Habilita los contadores IPv6 en el router utilizando el comando set

forwarding-options
family
inet6
route-accounting.
Activar
configuracin y salir del modo configuracin.

[edit]
root@srxA1# set forwarding-options family inet6 route-accounting
[edit]
root@srxA1# commit and quit
commit complete
181
la
1.4.
Ejecutar el comando show route table inet6 para mostrar el contenido de

la tabla de enrutamiento IPv6.
root@srxA1> show route table inet6
root@srxA1>
Cuestin: Hay alguna ruta?

No existe ninguna ruta ya que an no se ha configurado ninguna interface
con IPv6.
1.5.
Configurar las interfaces del router srxAX segn se indica en el diagrama.

Utilizar la unidad lgica unit 0 en todas las interfaces. Recuerda configurar
la interface loopback.
root@srxA1> configure
[edit]
[edit interfaces]
root@srxA1# set em1 unit 0 family inet6 address 2001:172:20:66::1/64
[edit interfaces]
root@srxA1# set em2 unit 0 family inet6 address 2001:172:18:1::2/64
[edit interfaces]
root@srxA1# set lo0 unit 0 family inet6 address 2001:192:168:1::1/128
[edit interfaces]
root@srxA1# commit
commit complete
1.6.
Mostrar
la
configuracin
comprobar
que
se
han
configurado
correctamente. Activar la configuracin y salir del modo configuracin. En

el momento que se configura la interface loopback con una direccin IPv6,
el router automticamente habilita el trfico IPv6.
[edit interfaces]
root@srxA1# show
182
em1 {
unit 0 {
family inet6 {
address 2001:172:20:66::1/64;
}
}
}
em2 {
unit 0 {
family inet6 {
address 2001:172:18:1::2/64;
}
}
}
lo0 {
unit 0 {
family inet6 {
address 2001:192:168:1::1/128;
}
}
}
[edit interfaces]
commit complete
1.7.
Ejecutar el comando show interfaces terse para comprobar el estado

actual de las interfaces.
root@srxA1> show interfaces terse
Interface
Remote
cbp0
up up
demux0
up up
dsc
up up
em0
up down
em1
up up
em1.0
up up
inet6 2001:172:20:66::1/64
fe80::a00:27ff:fe26:e02c/64
em2
up up
em2.0
up up
inet6 2001:172:18:1::2/64
fe80::a00:27ff:fe69:b14a/64
em3
up down
em4
up down
gre
up up
ipip
up up
183
irb
lo0
lo0.0
up up
up up
up up
lo0.16384
lo0.16385
up up
up up
lsi
mtun
pimd
pime
pip0
pp0
tap
up
up
up
up
up
up
up
inet6 2001:192:168:1::1
fe80::a00:27ff:fe58:7da4
inet 127.0.0.1
--> 0/0
inet 128.0.0.4
--> 0/0
inet6 fe80::a00:27ff:fe58:7da4
up
up
up
up
up
up
up
root@srxA1>
Cuestin: Cuntas direcciones IPv6 estn asociadas a cada una de las
interfaces?
Dos, la primera asociada a inet6 es la direccin configurada manualmente
y la segunda es la direccin EUI-64 de la interface local que se
corresponde a la direccin del nivel de enlace. Esta ltima direccin se
utiliza para descubrir vecinos, configuracin automtica de direcciones y
cuando no existen routers presentes.
Cuestin: Cmo son las otras direcciones creadas en el router?

Se componen por el prefijo inicial FE80, que por definicin corresponde a
una direccin unicast del enlace local, seguido de ceros y por ltimo la
direccin EUI-64, compuesta por el valor 0A00 y la direccin MAC de la
interface.
1.8.
Ejecutar el comando show route table inet6 para comprobar las entradas
actuales en la tabla IPv6.
root@srxA1> show route table inet6
inet6.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
2001:172:18:1::/64
184
*[Direct/0] 01:00:29
> via em2.0

2001:172:18:1::2/128
2001:172:20:66::/64
*[Local/0] 01:00:29
Local via em2.0
*[Direct/0] 01:00:29
> via em1.0
2001:172:20:66::1/128
*[Local/0] 01:00:29
Local via em1.0
2001:192:168:1::1/128
*[Direct/0] 01:00:29
> via lo0.0
fe80::/64
*[Direct/0] 01:00:29
> via em1.0
[Direct/0] 01:00:29
> via em2.0
fe80::a00:27ff:fe26:e02c/128
*[Local/0] 01:00:29
Local via em1.0
fe80::a00:27ff:fe58:7da4/128
*[Direct/0] 01:00:29
> via lo0.0
fe80::a00:27ff:fe69:b14a/128
*[Local/0] 01:00:29
Local via em2.0
root@srxA1>
Cuestin: Cuntas rutas se instalaron para cada una de las interfaces?

Dos, la primera se corresponde con la direccin configurada manualmente
y la segunda se corresponde a la direccin local que empieza por FE80.
Cuestin: Hay alguna ruta escondida?

No. Al inicio del listado nos muestra un breve resumen donde nos indica 0
hidden.
1.9.
Utiliza el ping para comprobar la comunicacin entre los dispositivos

vecinos.
root@srxA1> ping 2001:172:20:66::2 rapid count 25
PING6(56=40+8+8 bytes) 2001:172:20:66::1 --> 2001:172:20:66::2
!!!!!!!!!!!!!!!!!!!!!!!!!
185
--- 2001:172:20:66::2 ping6 statistics --25 packets transmitted, 25 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 0.591/1.143/2.098/0.375 ms
PING6(56=40+8+8 bytes) 2001:172:18:1::2 --> 2001:172:18:1::1
!!!!!!!!!!!!!!!!!!!!!!!!!
Cuestin: Han funcionado los pings?

Si, las interfaces vecinas han respondido a los pings. Si no es as, repasar
la configuracin.
1.10. Ejecutar el comando show ipv6 neighbors.

root@srxA1> show ipv6 neighbors
IPv6 Address
Linklayer Address
Interface
2001:172:18:1::1
08:00:27:8a:02:76
2001:172:20:66::2
08:00:27:69:b1:4a
State
stale
stale
Exp Rtr Secure

551 yes no
559 yes no
em2.0
em1.0
root@srxA1>
Cuestin: Cuntos vecinos nos aparecen?

Dos, que se corresponden a las interfaces vecinas que ve nuestro router
srxAX.
Parte 2: Configurando y Monitorizando Rutas Estticas
En esta parte configuraremos y monitorizaremos una ruta esttica IPv6 por

defecto.
2.1.
Realiza un ping al Host de Internet que aparece en el diagrama.

PING6(56=40+8+8 bytes) 2001:192:168:1::1 --> 2001:172:31:1::1
186
ping: sendmsg: No route to host

ping6: wrote 2001:172:31:1::1 16 chars, ret=-1
.ping: sendmsg: No route to host
ping6: wrote 2001:172:31:1::1 16 chars, ret=-1
.ping: sendmsg: No route to host
^C
root@srxA1>
Cuestin: Qu indica el resultado del ping?

No existe en la tabla de enrutamiento ninguna entrada a la subred indicada.
Cuestin: Basndose en el diagrama, Qu direccin IP debera utilizarse

como next-hop para alcanzar el Host de Internet?
La direccin como next-hop debera ser 2001:172:18:1::1.
2.2.
Acceder al modo configuracin y definir una ruta esttica por defecto. Para
ello, deberemos introducir una entrada en la tabla de enrutamiento IPv6,
RIB (Routing Information Table), denominada inet6.0. Utiliza la direccin IP
mencionada anteriormente como next-hop.
[edit]
root@srxA1# edit routing-options rib inet6.0
[edit routing-options rib inet6.0]
root@srxA1# set static route ::/0 next-hop 2001:172:18:1::1
root@srxA1#
2.3.
Aadir redundancia con una segunda ruta esttica por defecto.

root@srxA1# set static route ::/0 next-hop 2001:172:20:66::1
root@srxA1# show
187
static {
route ::/0 next-hop [ 2001:172:18:1::1 2001:172:20:66::1 ];
}
commit complete
root@srxA1>
2.4.
Ejecutar el comando show route 2001:172:31:15::1 para ver si existe

alguna ruta hacia dicho destino.
root@srxA1> show route 2001:172:31:15::1
::/0
*[Static/5] 01:46:44
> to 2001:172:18:1::1 via em2.0
Cuestin: Existe alguna ruta valida hacia el Host de Internet?

Si, la ruta por defecto configurada.
Cuestin: Cul es el valor preference de la ruta esttica por defecto?

Tal y como se muestra en la captura, el valor preference es de 5.
2.5.
Utiliza el ping hacia el Host de Internet para comprobar la comunicacin.

PING6(56=40+8+8 bytes) 2001:172:18:1::2 --> 2001:172:31:15::1
.........................
Cuestin: Fueron satisfactorios los pings?

No. Vamos a tratar de solucionar el problema.
188
2.6.
Acceder al router INTERNET y monitorizar la interface em0 para ver si

recibe el paquete ICMP echo request. Lanzar desde el router srxA1 un
nico ping.
root@INTERNET> monitor traffic interface em0
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on em0, capture size 96 bytes
Reverse lookup for 2001:172:31:15::1 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.
15:47:45.957321 Out IP6 2001:172:18:1::2 > 2001:172:31:15::1: ICMP6, echo
request, seq 0, length 16
15:47:50.965092 In IP6 truncated-ip6 - 12 bytes missing!fe80::a00:27ff:fe7f:910a
> 2001:172:31:1::1: ICMP6, neighbor solicitation[|icmp6]
15:47:50.965320 Out IP6 truncated-ip6 - 4 bytes missing!fe80::a00:27ff:fe3b:bc22
> fe80::a00:27ff:fe7f:910a: ICMP6, neighbor advertisment[|icmp6]
15:47:56.235483 In IP truncated-ip - 253 bytes missing! 0.0.0.0.bootpc >
255.255.255.255.bootps: BOOTP/DHCP, Request [|bootp]
^C
4 packets received by filter
0 packets dropped by kernel
root@INTERNET>
Cuestin: Se ha recibido un paquete echo request?

S. En la captura se puede observar que ha salido un paquete ICMP echo
request pero no se ha recibido en la interface ninguna contestacin por
parte del destinatario, (echo reply).
2.7.
Configurar en el Host de Internet la ruta por defecto hacia la direccin

2001:172:31:1::1.
root@box:~# ifconfig eth0 2001:172:31:15::1/48
root@box:~# route -A inet6 add ::0/0 gw 2001:172:31:1::1
2.8.
Utiliza el ping hacia el Host de Internet para comprobar la comunicacin.
189

PING6(56=40+8+8 bytes) 2001:172:18:1::2 --> 2001:172:31:15::1
!!!!!!!!!!!!!!!!!!!!!!!!!

S. En caso contrario repasar la configuracin de los dispositivos.
Parte 3: Configurando y Monitorizando OSPF
En esta parte configuraremos y monitorizaremos una interface IPv6 en OSPF

entre los routers srxA1 y srxA2, tal y como se observa en el siguiente diagrama.
Finalmente realizaremos las comprobaciones oportunas para ver que OSPF
funciona correctamente.
Figura 61: Escenario para la configuracin de OSPFv3.
En dispositivos Junos existen tres protocolos IGP (Interior Gateway Protocols) que
soportan IPv6, que son RIPng (RIP next generation), OSPF3, y por ltimo IS-IS.
En ste ltimo no se requiere de una nueva versin ya que soporta IPv6.
190
3.1.
Definir el rea OSPF 0 e incluir la interface interna que conecta los dos
routers srxA1 y srxA2. Asegurarse de que tambin se incluyen las
interfaces loopback. Recordar que OSPFv3 solamente soporta IPv6.
3.2.
Acceder al modo de configuracin y configurar el router ID.
[edit]
root@srxA1# set routing-options router-id 1.1.1.1
3.3.
Situarse en el nivel [protocols ospf3] y aadir las interfaces al rea 0.

[edit]
root@srxA1# edit protocols ospf3
[edit protocols ospf3]
root@srxA1# set area 0 interface lo0.0 passive
root@srxA1# set area 0 interface em1.0
root@srxA1#
Cuestin: Con la configuracin que acabamos de realizar, Cuntas

adyacencias entre vecinos OSPF se crearn?
En principio slo una.
3.4.
Activar la configuracin con el comando commit and quit y salir al modo

de operacin. Ejecutar el comando show ospf3 neighbor para comprobar
las adyacencias entre vecinos OSPF que se han establecido.
root@srxA1> show ospf3 neighbor
ID
Interface
State Pri Dead
2.2.2.2
em1.0
Full 128 36
Neighbor-address fe80::a00:27ff:fe9d:b3de
root@srxA1>
191
Cuestin: Qu estado tienen las adyacencias de vecinos OSPF?

El estado FULL.
Cuestin: Por qu el router ID se muestra como una direccin IPv4?

Porque el router ID, por definicin de OSPF3, es un identificador de 32 bits
y por lo tanto se utiliza la notacin IPv4.
3.5.
Ejecutar el comando show ospf3 interface para ver las interfaces que
estn ejecutando OSPF3 y el detalle.
root@srxA1> show ospf3 interface
Interface
em1.0
lo0.0
State Area
BDR 0.0.0.0
DR
0.0.0.0
DR ID
2.2.2.2
1.1.1.1
BDR ID
1.1.1.1
0.0.0.0
Nbrs
1
0
root@srxA1> show ospf3 interface detail

Interface
State Area
DR ID
BDR ID
Nbrs
em1.0
BDR 0.0.0.0
2.2.2.2
1.1.1.1
1
Address fe80::a00:27ff:fe69:b14a, Prefix-length 64
OSPF3-Intf-index 1, Type LAN, MTU 1500, Cost 1, Priority 128
Adj count: 1, Router LSA ID: 0
DR addr fe80::a00:27ff:fe9d:b3de, BDR addr fe80::a00:27ff:fe69:b14a
Hello 10, Dead 40, ReXmit 5, Not Stub
Protection type: None
lo0.0
DR 0.0.0.0
1.1.1.1
0.0.0.0
0
Address fe80::a00:27ff:fe58:7da4, Prefix-length 128
OSPF3-Intf-index 2, Type LAN, MTU 65535, Cost 0, Priority 128
Adj count: 0, Router LSA ID: DR addr fe80::a00:27ff:fe58:7da4
Hello 10, Dead 40, ReXmit 5, Not Stub
root@srxA1>
3.6.
Ejecutar el comando show route protocol ospf3 para ver las rutas OSPF
activas en la tabla de enrutamiento.
root@srxA1> show route protocol ospf3
192
2001:192:168:2::1/128
ff02::5/128
*[OSPF3/10] 00:22:40, metric 1

> to fe80::a00:27ff:fe9d:b3de via em1.0
*[OSPF3/10] 00:23:41, metric 1
MultiRecv
root@srxA1>
Cuestin: Cul es la direccin FF02::5/128?

Esta direccin es la direccin multicast de OSPF3.
Parte 4: Tunneling IPv6 sobre IPv4 utilizando Encapsulacin GRE
En esta parte del laboratorio vamos a configurar un tnel GRE para enviar el
trfico IPv6 sobre un enlace IPv4. El tnel lo vamos a crear desde el router srxA1
hasta el srxA2, pasando a travs del router INTERNET. El diagrama de esta parte
es diferente al anterior siendo como se muestra a continuacin.
Figura 62: Escenario para la configuracin del tnel GRE.
4.1.
Primero, borrar las estancias protocols y routing-options del modo de

configuracin. Despus borrar la configuracin de las interfaces em1, em2
y loopback.
193
[edit]
root@srxA1# delete routing-options
[edit]
root@srxA1# delete protocols
[edit]
root@srxA1# delete interfaces
[edit]
root@srxA1# commit
commit complete
4.2.
Configurar el direccionamiento IPv4 en las interfaces tal y como se muestra

en el diagrama. Finalmente, configura una ruta esttica hacia la el loopback
remoto utilizando la direccin de la interface em2 como next-hop.
[edit]
[edit interfaces]
root@srxA1# set lo0 unit 0 family inet address 192.168.1.1/32
[edit interfaces]
[edit interfaces]
root@srxA1# top edit routing-options
root@srxA1# set static route 192.168.2.1 next-hop 172.18.1.1
root@srxA1# commit
commit complete
4.3.
Acceder al router INTERNET y borrar la configuracin de las interfaces

em1 y em2. Configurar de nuevo dichas interfaces con las nuevas
direcciones IPv4.
194
root@INTERNET> configure
[edit]
root@INTERNET# edit interfaces
[edit interfaces]
root@INTERNET# delete em1
[edit interfaces]
root@INTERNET# delete em2
[edit interfaces]
root@INTERNET# set em1 unit 0 family inet address 172.18.1.1/30
[edit interfaces]
root@INTERNET# set em2 unit 0 family inet address 172.18.2.1/30
[edit interfaces]
root@INTERNET# top edit routing-options
root@INTERNET# set static route 192.168.1.1 next-hop 172.18.1.2
root@INTERNET# set static route 192.168.2.1 next-hop 172.18.2.2
root@INTERNET# commit
commit complete
4.4.
En este punto, ahora tenemos una red bsica IPv4. Comprueba la

comunicacin desde el router srxAX hacia la interface loopback del router
remoto con un ping.
root@srxA1> ping 192.168.2.1 rapid count 25
PING 192.168.2.1 (192.168.2.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!

195
Si. En caso contrario repasar la configuracin de los dispositivos.
4.5.
Definir una nueva interface GRE y un tnel utilizando las direcciones IP

asignadas a la interface loopback de tu dispositivo como la direccin origen
y la IP asignada a la interface loopback remota como la direccin destino.
Utilizar la unidad lgica 0.
root@srxA1# top edit interfaces
[edit interfaces]
root@srxA1# set gre unit 0 tunnel source 192.168.1.1
[edit interfaces]
root@srxA1# set gre unit 0 tunnel destination 192.168.2.1
[edit interfaces]
root@srxA1# commit
commit complete
4.6.
Ejecutar el comando run show interfaces terse para comprobar el estado

de la interface gre definida.
[edit interfaces]
root@srxA1# run show interfaces terse
Interface
Admin Link
Proto
cbp0
up up
demux0
up up
dsc
up up
em0
up down
em1
up up
em2
up up
em2.0
up up
inet
em3
up down
em4
up down
gre
up up
gre.0
up up
ipip
up up
irb
up up
lo0
up up
lo0.0
up up
inet
lo0.16384
up up
inet
lo0.16385
up up
inet
196
Local
Remote
172.18.1.2/30
192.168.1.1
127.0.0.1
128.0.0.4
0/0
0/0
0/0
inet6 fe80::a00:27ff:fe58:7da4
lsi
mtun
pimd
pime
up
up
up
up
up
up
up
up
[edit interfaces gre]

root@srxA1#
Cuestin: Cul es el estado actual de la interface gre.0?

El estado actual es activo, tanto el nivel de enlace como el administrativo.
4.7.
Configurar la direccin IPv6 a la interface del tnel gre y activar los

cambios.
[edit interfaces]
root@srxA1# set gre unit 0 family inet6 address 2001:c0ff:ee:100::1/64
[edit interfaces]
root@srxA1# show gre
unit 0 {
tunnel {
source 192.168.1.1;
destination 192.168.2.1;
}
family inet6 {
address 2001:c0ff:ee:100::1/64;
}
}
[edit interfaces]
root@srxA1# commit
commit complete
4.8.
Comprueba con un ping que se existe comunicacin hacia la direccin IPv6

remota.
[edit interfaces]
root@srxA1# run ping 2001:c0ff:ee:100::2 rapid count 25
PING6(56=40+8+8 bytes) 2001:c0ff:ee:100::1 2001:c0ff:ee:100::2
!!!!!!!!!!!!!!!!!!!!!!!!!
--- 2001:c0ff:ee:100::2 ping6 statistics --25 packets transmitted, 25 packets received, 0% packet loss
197
4.9.
Muestra la tabla de enrutamiento actual.

[edit interfaces]
0.0.0.0/0
172.18.1.0/30
172.18.1.2/32
192.168.1.1/32
*[Static/5] 00:45:43
> to 172.18.1.1 via em2.0
*[Direct/0] 02:06:32
> via em2.0
*[Local/0] 02:06:32
Local via em2.0
*[Direct/0] 02:09:34
> via lo0.0

2001:c0ff:ee:100::/64
*[Direct/0] 00:07:11
> via gre.0
2001:c0ff:ee:100::1/128
*[Local/0] 00:07:11
Local via gre.0
fe80::/64
*[Direct/0] 00:07:11
> via gre.0
fe80::a00:27ff:fe58:7da4/128
*[Local/0] 00:07:11
Local via gre.0
Cuestin: Cmo se enruta el trfico IPv6 a travs del 198nel?

El router detecta que tiene una entrada en la tabla de enrutamiento inet6.0
de dicha subred y reencamina el trfico hacia la interface gre.0.
4.10. Ejecuta el comando run show interfaces gre.0 y observa el campo IPHeader.
[edit interfaces]
root@srxA1# run show interfaces gre.0
Logical interface gre.0 (Index 70) (SNMP ifIndex 513)
Flags: Point-To-Point SNMP-Traps 0x4000
IP-Header 192.168.2.1:192.168.1.1:47:df:64:0000000000000000
198
Encapsulation: GRE-NULL
Input packets : 39
Output packets: 41
Protocol inet6, MTU: 1476
Flags: Is-Primary
Addresses, Flags: Is-Default Is-Preferred Is-Primary
Destination: 2001:c0ff:ee:100::/64, Local: 2001:c0ff:ee:100::1
Addresses, Flags: Is-Preferred
Destination: fe80::/64, Local: fe80::a00:27ff:fe58:7da4
[edit interfaces]
root@srxA1#
Cuestin: Qu nos indica el campo IP-Header?

Es el tipo de protocolo que transporta, siendo 47 a IP Protocol.
4.11. Ejecuta el comando run show route 192.168.2.1 para ver por dnde salen
los paquetes IPv6.
[edit interfaces]
root@srxA1# run show route 192.168.2.1
0.0.0.0/0
*[Static/5] 03:07:00
> to 172.18.1.1 via em2.0
[edit interfaces]
root@srxA1#
199
200
9. Troubleshooting JUNOS
En este captulo vamos a exponer los problemas encontrados en la fase de
pruebas de los laboratorios, cmo se han desarrollado para intentar solucionarlos,
y las conclusiones a las que se han llegado.
9.1.
Problema 1: Fallo enrutamiento OSPF
9.1.1. 1 Parte: escenario con OSPF IPv4
Los dos primeros laboratorios que se han desarrollado se probaron con la versin
JUNOS 9.6 R1.13 sin detectar ningn problema en el desarrollo de stos. En el
Laboratorio 3 se detect que no exista comunicacin entre los dos routers srxA1
y srxA2, an habiendo dos lneas de interconexin. A partir del Laboratorio 3, se
decidi migrar todas las mquinas virtuales a la versin JUNOS 10.1 R1.8 ya que
esta versin implementa el servicio SSH.
Figura 63: Escenario utilizado en el laboratorio 3: Filtros Firewalls.
201
Una vez cargadas las configuraciones desde el servidor TFTP, se detect que no
haba comunicacin entre todos los dispositivos del escenario: al realizar un ping
desde el router vr102 hacia el servidor TFTP o al srxA1 stos no contestaban. Al
interrogar la tabla de enrutamiento del router srxA1 con el comando show route
se detect que no estaban las rutas de las subredes del grupo opuesto (ramal
derecho), y lo mismo ocurra en el router srxA2. Para ms detalle se ejecut el
comando show route protocol ospf y se confirm que no haba ninguna ruta de
la parte opuesta.
root@srxA1> show route protocol ospf
192.168.1.2/32
224.0.0.5/32
*[OSPF/10] 00:00:14, metric 1

> to 172.20.101.10 via em4.101
*[OSPF/10] 00:05:39, metric 1
MultiRecv
Se comprobaron las interfaces que estaban actualmente configuradas con el

protocolo OSPF siendo las siguientes:
root@srxA1> show ospf interface
Interface
State Area
DR ID
em1.0
DR
0.0.0.0
192.168.1.1
em2.0
DR
0.0.0.0
192.168.1.1
em4.101
BDR 0.0.0.0
192.168.1.2
lo0.0
DR
0.0.0.0
192.168.1.1
BDR ID
Nbrs
0.0.0.0
0
0.0.0.0
0
192.168.1.1 1
0.0.0.0
0
Se comprob la tabla de adyacencias y se observ que solamente haba una

adyacencia establecida y era con el router vr10X. La adyacencia con el router
opuesto srxA2, se quedaba en el estado EXSTART y no evolucionaba al estado
FULL donde se empiezan a recibir actualizaciones OSPF.
root@srxA1> show ospf neighbor
Address
Interface
172.20.77.2
em1.0
172.20.66.2
em2.0
172.20.101.10
em4.101
202
State
ExStart
ExStart
Full
ID
192.168.2.1
192.168.2.1
192.168.1.2
Pri Dead
128 38
128 39
128 36
Llegados a este punto, se haba comprobado que la configuracin de los routers

era la correcta y que el problema del por qu no se reciban las rutas va OSPF
era porque no se estableca una adyacencia entre los routers srxA1 y srxA2.
Se crea un nuevo escenario solamente con los routers srxA1 y srxA2

interconectados entre s por las interfaces em1 y em2 tal y como est en el
laboratorio 3. Se configuran los dos routers tal y como vienen de fbrica con el
comando load factory-default y se configuran nica y exclusivamente las
interfaces em1 y em2 y OSPF.
Figura 64: Escenario de prueba con slo dos routers.
El resultado que nos encontramos es el mismo:

Address
Interface
State
172.20.77.2
em1.0
ExStart
172.20.66.2
em2.0
ExStart
ID
192.168.2.1
192.168.2.1
Pri Dead
128 38
128 39
No son capaces de crear la adyacencia ya que se quedan en el estado

EXSTART.
Se prueba la comunicacin con un ping entre los dos routers y se descubre que
no responde el router opuesto.
203
PING 172.20.66.2 (172.20.66.2): 56 data bytes

.........................
PING 172.20.77.2 (172.20.77.2): 56 data bytes
.........................
En este punto ya sabemos que los dos routers son incapaces de crear una
adyacencia entre ellos debido a que no existe comunicacin directa ninguna entre
ellos. Por qu estn fallando los pings en una configuracin tan bsica? Segn
documentacin de Juniper, es posible que el valor del parmetro MTU sea
diferente. Vemos las propiedades de las interfaces, tanto en OSPF como las
fsicas:
root@srxA1> show ospf interface extensive
Interface
State Area
DR ID
BDR ID
Nbrs
em1.0
DR 0.0.0.0
192.168.1.1 192.168.2.1
1
Type: LAN, Address: 172.20.77.1, Mask: 255.255.255.252, MTU: 1500, Cost: 1
DR addr: 172.20.77.1, BDR addr: 172.20.77.2, Priority: 128
Adj count: 0
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Topology default (ID 0) -> Cost: 1
em2.0
DR 0.0.0.0
192.168.1.1 192.168.2.1
1
Adj count: 0
Auth type: None
root@srxA1> show interfaces em1 extensive
Physical interface: em1, Enabled, Physical link is Up
Interface index: 9, SNMP ifIndex: 23, Generation: 132
Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Clocking: Unspecified,
Speed: 1000mbps
Device flags : Present Running
Interface flags: SNMP-Traps
204
Link type : Full-Duplex

Physical info : Unspecified
Hold-times : Up 0 ms, Down 0 ms
Current address: 08:00:27:26:e0:2c, Hardware address: 08:00:27:26:e0:2c
Alternate link address: Unspecified
Last flapped : Never
Statistics last cleared: Never
Traffic statistics:
Input bytes :
118406
Output bytes :
87816
Input packets:
1788
Output packets:
1878
IPv6 transit statistics:
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0,
Policed discards: 0, Resource errors: 0
Output errors:
Carrier transitions: 0, Errors: 0, Drops: 0, MTU errors: 0,
Resource errors: 0
Logical interface em1.0 (Index 65) (SNMP ifIndex 24) (Generation 130)
Flags: SNMP-Traps Encapsulation: ENET2
Traffic statistics:
Input bytes :
111254
Output bytes :
87816
Input packets:
1788
Output packets:
1878
Local statistics:
Input bytes :
111254
Output bytes :
87816
Input packets:
1788
Output packets:
1878
Protocol inet, MTU: 1500, Generation: 137, Route table: 0
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 172.20.77.0/30, Local: 172.20.77.1, Broadcast: 172.20.77.3,
Generation: 132
Y en el router srxA2 tenemos los siguientes parmetros:

root@srxA2> show ospf interface extensive
205
Interface
State Area
DR ID
BDR ID
Nbrs
em1.0
BDR 0.0.0.0
192.168.1.1 192.168.2.1
1
Adj count: 0
Auth type: None
em2.0
BDR 0.0.0.0
192.168.1.1 192.168.2.1
1
Adj count: 0
Auth type: None
root@srxA2> show interfaces em1 extensive
Interface index: 9, SNMP ifIndex: 23, Generation: 132
Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Clocking: Unspecified,
Speed: 1000mbps
Physical info : Unspecified
Hold-times : Up 0 ms, Down 0 ms
Alternate link address: Unspecified
Statistics last cleared: Never
Traffic statistics:
Input bytes :
123870
Output bytes :
86628
Input packets:
1874
Output packets:
1888
IPv6 transit statistics:
Input bytes :
0
Output bytes :
0
Input packets:
0
Output packets:
0
Input errors:
Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0,
Policed discards: 0, Resource errors: 0
Output errors:
Carrier transitions: 0, Errors: 0, Drops: 0, MTU errors: 0,
206
Resource errors: 0
Logical interface em1.0 (Index 64) (SNMP ifIndex 24) (Generation 129)
Traffic statistics:
Input bytes :
116374
Output bytes :
86628
Input packets:
1874
Output packets:
1888
Local statistics:
Input bytes :
116374
Output bytes :
86628
Input packets:
1874
Output packets:
1888
Protocol inet, MTU: 1500, Generation: 136, Route table: 0
Flags: Is-Primary
Destination: 172.20.77.0/30, Local: 172.20.77.2, Broadcast: 172.20.77.3,
Generation: 130
Como se ha visto, los parmetros que tienen las interfaces de ambos routers son
las mismas.
Si cambiamos las IPs y configuramos otras diferentes y pertenecientes a otra

subred totalmente diferente ocurre lo mismo.
Continuando con las pruebas se nos ocurre una nueva siendo muy determinante:
creamos un nuevo escenario de prueba con los dos routers, srxA1 y srxA2, y
configuramos las lneas cruzndolas de la siguiente manera:
srxA1.em1 -> srxA2.em2

srxA1.em2 -> srxA2.em1
para comprobar si contina comportndose de la misma manera.
207
Figura 65: Escenario de pruebas con las lneas intercambiadas.
Comprobamos que con esta disposicin de las lneas s que funciona el ping y s
que se crea la adyacencia entre los dos routers.
PING 172.20.66.2 (172.20.66.2): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
Address
Interface
State
172.20.77.2
em1.0
Full
172.20.66.2
em2.0
Full
ID
192.168.2.1
192.168.2.1
Pri Dead
128 38
128 39
Como ltima prueba y para saber si este comportamiento se produce entre ruters
de la misma versin o tambin entre diferentes versiones, creamos un nuevo
escenario de prueba con el router srxA1 con versin R10.1 y otro router srxB1 con
versin R12.1 con las lneas enfrentadas entre s y sin cruzar.
El comportamiento que encontramos es que s responden ambos routers a los

pings y se crean ambas adyacencias, por lo que podemos deducir que este
problema solamente acontece entre routers que tengan la misma versin.
208
9.1.2. Conclusiones - 1 Parte
En base a las pruebas realizadas podemos concluir que no se pueden

implementar en GNS3 un escenario con dos routers con la misma versin y
conectados entre s por el mismo nmero de interface. Si esto ocurre, esta lnea
fallar y no habr ninguna comunicacin entre ambos extremos, aunque el estado
de las interfaces aparezcan en UP. Siempre habr que utilizar un nmero de
interface diferente: si en un extremo se utiliza la interface em1, en el otro extremo
de la lnea se deber utilizar una interface distinta a la em1, nos valdra cualquiera
menos la em1.
9.1.3. 2 Parte: escenario con OSPFv3 IPv6
Hasta el momento hemos observado el comportamiento que tienen las interfaces

cuando las emparejamos por igual entre s, y en base al desarrollo de las
pruebas, cmo se ha llegado a la conclusin anteriormente citada.
A continuacin vamos a demostrar que dicha conclusin no es del todo cierta,

debido a las investigaciones realizadas posteriormente, y que dicha conclusin es
una consecuencia errnea de las pruebas llevadas a cabo en la primera parte. Se
ha decidido incluir una segunda parte, dejando tal cual la primera, para que se
vea todo el historial de investigacin hasta el descubrimiento de la falla con la
correspondiente conclusin final definitiva.
En el desarrollo de la parte 3 del laboratorio sobre IPv6, se observ un

comportamiento en el protocolo OSPFv3 un tanto similar a lo descrito
anteriormente: cuando se configuraba OSPFv3 en las interfaces pertinentes de
los routers srxA1 y srxA2, al interrogar las adyacencias creadas con los vecinos
se observaba que no apareca ninguna. A continuacin se muestra el escenario
de trabajo.
209
Figura 66: Escenario utilizado en el laboratorio 5.3: IPv6, OSPFv3.
Como ya se ha mencionado anteriormente, al activar OSPFv3 en las interfaces

em1 y em2 e interrogar las adyacencias, los routers no muestran nada tal y como
vemos a continuacin.

root@srxA1>
root@srxA2>
Pero s que existe comunicacin en la lnea ya que el resultado de un ping entre

ellos es satisfactorio y adems los routers detectan vecinos con IPv6 tal y como
se demuestra con el siguiente comando:
root@srxA1> show ipv6 neighbors
IPv6 Address
Linklayer Address
2001:172:18:1::1
08:00:27:8a:02:76
2001:172:20:66::2
08:00:27:69:b1:4a
State
stale
stale
Exp Rtr Secure Interface

551 yes no
em2.0
559 yes no
em1.0
root@srxA1>
210
Llegados a este punto, podemos decir que existe comunicacin tanto de trfico
ICMP como a nivel IPv6, pero se estn transmitiendo y recibiendo LSAs
OSPFv3? Con el siguiente comando vamos a ver las estadsticas y determinar si
se transmiten y reciben upgrades OSPFv3.
root@srxA1> show ospf3 statistics
Packet type
Hello
DbD
LSReq
LSUpdate
LSAck
Total
Sent Received
6
0
0
0
0
0
0
0
0
0
DBDs retransmitted
LSAs flooded
LSAs flooded high-prio
LSAs retransmitted
LSAs transmitted to nbr
LSAs requested
LSAs acknowledged
:
:
:
:
:
:
:
Flood queue depth

Total rexmit entries
db summaries
lsreq entries
:
:
:
:
Last 5 seconds
Sent Received
0
0
0
0
0
0
0
0
0
0
0, last 5 seconds :
0, last 5 seconds :
0, last 5 seconds :
0, last 5 seconds :
0, last 5 seconds :
0, last 5 seconds :
0, last 5 seconds :
0
0
0
0
0
0
0
0
0
0
0
Receive errors:
None
Packet type
Hello
DbD
LSReq
LSUpdate
LSAck
Total
Sent Received
4
0
0
0
0
0
0
0
0
0
DBDs retransmitted
LSAs flooded
LSAs retransmitted
:
:
:
:
:
Last 5 seconds
Sent Received
0
0
0
0
0
0
0
0
0
0
0, last 5 seconds :
0, last 5 seconds :
0, last 5 seconds :
0, last 5 seconds :
0, last 5 seconds :
0
0
0
0
0
211
LSAs requested
LSAs acknowledged
:
:
Flood queue depth

db summaries
lsreq entries
:
:
:
:
0, last 5 seconds :
0, last 5 seconds :
0
0
0
0
0
0
Receive errors:
None
Como podemos observar, por alguna razn no se reciben Hellos en ambos
routers. El router srxA1 nos indica que ha enviado 6 paquetes Hello, y el router
srxA2 nos indica que ha enviado 4 paquetes Hello.
Vamos a interrogar las dos interfaces em1 para observar los contadores de
paquetes enviados y recibidos.
root@srxA1> show interfaces em1
Interface index: 9, SNMP ifIndex: 23
Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps
Input packets : 1
Output packets: 110
Logical interface em1.0 (Index 64) (SNMP ifIndex 24)
Input packets : 1
Output packets: 110
Flags: Is-Primary
Destination: 2001:172:20:66::/64, Local: 2001:172:20:66::1
Addresses, Flags: Is-Preferred
Destination: fe80::/64, Local: fe80::a00:27ff:fe26:e02c
212

Input packets : 4
Output packets: 4
Logical interface em1.0 (Index 64) (SNMP ifIndex 24)
Input packets : 4
Output packets: 4
Flags: Is-Primary
Destination: 2001:172:20:66::/64, Local: 2001:172:20:66::2
Addresses, Flags: Is-Preferred Duplicate
Destination: fe80::/64, Local: fe80::a00:27ff:fe26:e02c
La siguiente prueba que vamos a realizar es asegurarse de que los paquetes

Hello estn saliendo de los routers. Para ello vamos a activar la monitorizacin del
trfico OSPF3 y ver qu ocurre.
[edit]
root@srxA1# edit protocols ospf3
root@srxA1# set traceoptions file prueba.txt
root@srxA1# set traceoptions flag hello
root@srxA1# set traceoptions flag error
root@srxA1# commit
commit complete
root@srxA1# run show log prueba.txt
Jul 29 12:34:45 trace_on: Tracing to "/var/log/prueba.txt" started
213
Jul 29 12:34:46.523842 OSPF sent Hello fe80::a00:27ff:fe26:e02c -> ff02::5 (em1.0

IFL 64 area 0.0.0.0)
Jul 29 12:34:46.523973 Version 3, length 36, ID 1.1.1.1, area 0.0.0.0
Jul 29 12:34:46.523987 checksum 0x0, instance-id 0
Jul 29 12:34:46.524000 intf_id 0.0.0.4, prio 128, opts 0x13, hello_ivl 10
Jul 29 12:34:46.524012 dead_ivl 40, DR 1.1.1.1, BDR 0.0.0.0
Jul 29 12:34:46.524174 OSPF sent Hello fe80::a00:27ff:fe26:e02c -> ff02::5 (em1.0
IFL 64 area 0.0.0.0)
Jul 29 12:34:46.524189 Version 3, length 36, ID 1.1.1.1, area 0.0.0.0
Jul 29 12:34:46.524201 checksum 0x0, instance-id 0
Jul 29 12:34:46.524213 intf_id 0.0.0.4, prio 128, opts 0x13, hello_ivl 10
Jul 29 12:34:46.524255 dead_ivl 40, DR 1.1.1.1, BDR 0.0.0.0
Jul 29 12:34:54.754819 OSPF periodic xmit from fe80::a00:27ff:fe26:e02c to
ff02::5 (IFL 64 area 0.0.0.0)
ff02::5 (IFL 64 area 0.0.0.0)
ff02::5 (IFL 64 area 0.0.0.0)
ff02::5 (IFL 64 area 0.0.0.0)
ff02::5 (IFL 64 area 0.0.0.0)
root@srxA1#
Para el router srxA2 tenemos la siguiente captura de monitorizacin:

root@srxA2# run show log prueba.txt
Jul 29 13:13:19 trace_on: Tracing to "/var/log/prueba.txt" started
root@srxA2#
Se puede observar que se estn enviando los paquetes Hello en el router srxA1 y
no se recibe nada. As lo corroboran los contadores de la interface anteriormente
vistos. Pero para el router srxA2 no se est enviando ni recibiendo ningn
paquete Hello ni se producen errores, ni los contadores de la interface aumentan.
214
Podramos pensar que este tipo de comportamiento es una limitacin impuesta

por el fabricante a la Olivas, que por algn tipo de mecanismo detecta que el IOS
no est corriendo en una plataforma con hardware original e impone ciertas
limitaciones. Pero esta teora nos resulta un tanto extraa aunque veremos en el
siguiente problema como s se cumple.
Despus de varias comprobaciones, de analizar todo el histrico de pruebas, y de

preguntarnos el hecho de por qu no salen los paquetes Hello y otros como
ICMPs s, descubrimos un detalle que parece insignificante: las MAC de las
interfaces conectadas entre s.
Si observamos detenidamente las capturas anteriores de las interfaces, tanto de

esta parte como de la primera parte, descubrimos que la direccin MAC de la
interface em1 de ambos routers es la misma.
Input packets : 1
Output packets: 110
Input packets : 4
Output packets: 4
215
Esta configuracin provoca que las tramas Ethernet, cuando sean procesadas en
cualquiera de las interfaces, lleven en su cabecera la misma direccin origen y
destino. Esta situacin puede generar incongruencias en el algoritmo de decisin
y por lo tanto no es una configuracin correcta.
Para confirmar que esta configuracin es la que nos est provocando los
problemas de adyacencias, vamos a cambiar la direccin MAC del router srxA2.
Para ello debemos apagar el router, y luego cambiar la configuracin en la
Mquina de Virtual Box.
[edit]
root@srxA2# exit
root@srxA2> request system halt
Halt the system ? [yes,no] (no) yes
Shutdown NOW!
[pid 2140]
root@srxA2>
*** FINAL System shutdown message from root@srxA2 ***
System going down IMMEDIATELY
Jul 29 13:45:45 Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `vnlru_mem' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 done
syncing disks... All buffers synced.
Uptime: 1h48m15s
recorded reboot as normal shutdown
The operating system has halted.
Please press any key to reboot.
Ejecutamos el Virtual Box y editamos la configuracin de la mquina virtual

asociada al router srxA2.
216
Figura 67: Configuracin direccin MAC en una MV de VirtualBox.
En el apartado de Red, Adaptador 2, en el panel Avanzadas tenemos el valor de

la direccin MAC. La cambiamos por otra generada aleatoriamente con el botn
de la derecha. Ahora estamos en disposicin de volver a probar los escenarios y
ver qu resultados obtenemos.
Para el escenario de la segunda parte, IPv6 con OSPFv3, volvemos a ver si se

han establecido las adyacencias y obtenemos el siguiente resultado:
root@srxA1# run show ospf3 neighbor
ID
Interface
State Pri Dead
2.2.2.2
em1.0
Full 128 35
Neighbor-address fe80::a00:27ff:fe42:ae91
root@srxA1# run show ospf3 statistics
Packet type
Total
Sent Received
Hello
39
3
DbD
3
2
Last 5 seconds
Sent Received
0
0
0
0
217
LSReq
LSUpdate
LSAck
1
2
3
1
3
1
0
0
0
DBDs retransmitted
LSAs flooded
LSAs retransmitted
LSAs requested
LSAs acknowledged
:
:
:
:
:
:
:
Flood queue depth

db summaries
lsreq entries
:
:
:
:
0
0
0
0, last 5 seconds :
0, last 5 seconds :
4, last 5 seconds :
0, last 5 seconds :
2, last 5 seconds :
2, last 5 seconds :
6, last 5 seconds :
0
0
0
0
0
0
0
0
0
0
0
Receive errors:
None
root@srxA1#

ID
Interface
State Pri Dead
1.1.1.1
em1.0
Full 128 35
Neighbor-address fe80::a00:27ff:fe26:e02c
Packet type
Sent
Hello
6
DbD
2
LSReq
1
LSUpdate
3
LSAck
1
Total
Received
3
3
1
2
3
DBDs retransmitted
LSAs flooded
LSAs retransmitted
LSAs requested
LSAs acknowledged
218
Last 5 seconds
Sent Received
0
0
0
0
0
0
0
0
0
0
:
:
:
:
:
:
:
0, last 5 seconds :
4, last 5 seconds :
0, last 5 seconds :
0, last 5 seconds :
2, last 5 seconds :
2, last 5 seconds :
5, last 5 seconds :
0
0
0
0
0
0
0
Flood queue depth

db summaries
lsreq entries
:
:
:
:
0
0
0
0
Receive errors:
None
root@srxA2>
Como podemos observar, la adyacencia entre vecinos OSPF3 s se ha

establecido por completo, estado FULL, y adems vemos en el resultado de las
estadsticas como se transmiten y reciben LSAs OSPF.
Por ltimo nos queda comprobar el escenario de la primera parte, IPv4 con OSPF,
y ver si con las mismas interfaces y con versin JUNOS 9.6, los dos routers son
capaces de establecer la adyacencia en FULL. Para ello cambiamos las MAC de
las interfaces em1 y em2 del router srxA2 e interrogamos para ver las
adyacencias.
Address
Interface
State
172.20.77.2 em1.0
Full
172.20.66.2 em2.0
Full
ID
Pri Dead
192.168.2.1 128 35
192.168.2.1 128 35
root@srxA1> show ospf statistics

Packet type
Hello
DbD
LSReq
LSUpdate
LSAck
Total
Sent
12
11
1
5
5
DBDs retransmitted
LSAs flooded
LSAs retransmitted
LSAs requested
Last 5 seconds
Received Sent Received
6
0
0
5
0
0
1
0
0
4
0
0
4
0
0
:
:
:
:
:
:
5, last 5 seconds :
6, last 5 seconds :
0, last 5 seconds :
0, last 5 seconds :
3, last 5 seconds :
3, last 5 seconds :
0
0
0
0
0
0
219
LSAs acknowledged
Flood queue depth

db summaries
lsreq entries
:
:
:
:
11, last 5 seconds :
0
0
0
0
Receive errors:
None
root@srxA1>

Address
Interface
State
172.20.77.1 em1.0
Full
172.20.66.1 em2.0
Full
ID
Pri Dead
192.168.1.1 128 37
192.168.1.1 128 39
root@srxA2> show ospf statistics

Packet type
Hello
DbD
LSReq
LSUpdate
LSAck
Total
Sent
12
5
1
4
4
Last 5 seconds
Received Sent Received
10
0
0
11
0
0
1
0
0
5
0
0
5
0
0
DBDs retransmitted
LSAs flooded
LSAs retransmitted
LSAs requested
LSAs acknowledged
:
:
:
:
:
:
:
Flood queue depth

db summaries
lsreq entries
:
:
:
:
1, last 5 seconds :
8, last 5 seconds :
0, last 5 seconds :
0, last 5 seconds :
3, last 5 seconds :
3, last 5 seconds :
8, last 5 seconds :
0
0
0
0
0
0
0
0
0
0
0
Receive errors:
None
220
Tambin en el escenario IPv4 funciona correctamente el protocolo OSPF,

establecindose las dos adyacencias y recibindose todo tipo de LSAs en ambos
routers.
9.1.4. Conclusiones Finales
Una vez que ya hemos determinado cual es el problema, comentar que esta
situacin se ha dado debido a que se han clonado las mquinas virtuales en base
a una original y por lo tanto todas ellas, y nuestros routers, tenan las direcciones
MAC iguales. Por este motivo, en la primera parte, cuando enfrentbamos dos
routers con el mismo nmero de interface el protocolo OSPF no funcionaba y los
pings tampoco.
Como conclusin final y establecindose como premisa de diseo de escenarios

en JUNOS y mquinas virtuales diremos que una vez se haya clonado una
mquina virtual JUNOS para su utilizacin, inmediatamente se debern cambiar
las direcciones MAC de la nueva mquina clonada.
Y esta premisa tambin es de aplicacin en entornos de simulacin con la

herramienta QEMU ya que una vez se tiene la mquina Oliva creada, en
diferentes artculos se indica que se generen tantas copias de la imagen como
dispositivos se tengan en el escenario, y esta regla conlleva a cometer el mismo
fallo.
221
9.2.
Problema 2: Fallo Filtros Firewall en versin R9.6
9.2.1. Desarrollo
En el desarrollo del Laboratorio 3 con MV JUNOS R9.6 se ha detectado que con

esta versin los filtros Firewall no funcionan correctamente. A continuacin se
expone la problemtica.
Del escenario del Laboratorio 3 con R9.6, arrancamos slo las MV

correspondientes a los routers srxA1 y vr101. Una vez funcionando, accedemos al
router srxA1 y comprobamos que el servicio TELNET y FTP est activado, sino lo
activamos.
[edit]
root@srxA1# edit system services
root@srxA1# show
ftp;
telnet;
root@srxA1#
Desde el router vr101 probamos los servicios ICMP, FTP y TELNET hacia la
interface loopback del router srxA1.
PING 192.168.1.1 (192.168.1.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
root@vr101> ftp 192.168.1.1
222
Name (192.168.1.1:root): lab

Password:
ftp> bye
221 Goodbye.
Trying 192.168.1.1...
srxA1 (ttyp0)
login: lab
Password:
--- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC
lab@srxA1> exit
root@vr101>
Como podemos observar, los servicios ICMP, FTP y TELNET funcionan

perfectamente desde el router vr101. Ahora probaremos estos mismos servicios
desde el Host ubicado en la subred 10.210.0.0/16 constatando que tambin
funcionan.
C:\Documents and Settings\LAB>ping 192.168.1.1
Haciendo ping a 192.168.1.1 con 32 bytes de datos:
Respuesta desde 192.168.1.1: bytes=32 tiempo=1ms TTL=64
Respuesta desde 192.168.1.1: bytes=32 tiempo<1m TTL=64
Estadsticas de ping para 192.168.1.1:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0 (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mnimo = 0ms, Mximo = 1ms, Media = 0ms
C:\Documents and Settings\LAB>ftp 192.168.1.1
Conectado a 192.168.1.1.
223

Usuario (192.168.1.1:(none)): lab
Contrasea:
ftp> bye
221 Goodbye.
C:\Documents and Settings\LAB>telnet 192.168.1.1
srxA1 (ttyp0)
login: lab
Password:
--- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC
lab@srxA1>
lab@srxA1> exit
Se ha perdido la conexin con el host.
Ahora configuraremos el filtro firewall protect-host para limitar estos servicios

solamente a la subred 10.210.0.0/16 por lo que en teora nadie puede acceder a
ellos excepto las mquinas ubicadas en la subred indicada.
[edit firewall]
root@srxA1# edit family inet filter protect-host
root@srxA1#
root@srxA1# set term limit-icmp from protocol icmp
root@srxA1# set term limit-icmp from source-address 10.210.0.0/16
root@srxA1# set term limit-icmp then accept
edit firewall family inet filter protect-host]
root@srxA1# set term limit-telnet from protocol tcp port telnet
root@srxA1# set term limit-telnet from source-address 10.210.0.0/16
224

root@srxA1# set term limit-telnet then accept
edit firewall family inet filter protect-host]
root@srxA1# set term limit-ftp from protocol tcp port ftp
root@srxA1# set term limit-ftp from source-address 10.210.0.0/16
root@srxA1# set term limit-ftp then accept
root@srxA1# commit
commit complete
root@srxA1#
Desde el router vr101 volvemos a probar los servicios ICMP, FTP y TELNET
hacia la interface loopback del router srxA1.
PING 192.168.1.1 (192.168.1.1): 56 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!
root@vr101> ftp 192.168.1.1
Name (192.168.1.1:root): lab
Password:
ftp> bye
221 Goodbye.
225

Trying 192.168.1.1...
srxA1 (ttyp0)
login: lab
Password:
--- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC
lab@srxA1> exit
root@vr101>
Como podemos observar, el filtro no funciona correctamente. El comportamiento

es como si no estuviera implementado el filtro. Desde el Host repetimos las
pruebas a los servicios por si encontrsemos alguna deficiencia y funcionan
correctamente.
Para descartar que este comportamiento sea exclusivo en las interfaces tipo
loopback, vamos a implementar y activar el filtro en la interface em0
correspondiente a la subred 10.210.0.0/16 y ver su respuesta. Borramos el filtro
de la interface lo0.
root@srxA1# show
unit 0 {
family inet {
filter {
input protect-host;
}
address 192.168.1.1/32;
}
}
root@srxA1# delete unit 0 family inet filter
226
root@srxA1# commit
commit complete
root@srxA1# show
unit 0 {
family inet {
address 192.168.1.1/32;
}
}
Definimos y activamos el filtro en la interface em0.

root@srxA1# top edit interfaces em0
root@srxA1# show
unit 0 {
family inet {
address 10.210.14.131/27;
}
}
[edit interfaces em0]
root@srxA1# show
unit 0 {
family inet {
filter {
input protect-host;
}
address 10.210.14.131/27;
}
}
root@srxA1# commit
commit complete
root@srxA1#
227
Volvemos a probar los servicios ICMP, FTP y TELNET desde el Host ubicado en
la subred 10.210.0.0/16.
C:\Documents and Settings\LAB>ping 192.168.1.1
Haciendo ping a 192.168.1.1 con 32 bytes de datos:
Estadsticas de ping para 192.168.1.1:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mnimo = 0ms, Mximo = 1ms, Media = 0ms
C:\Documents and Settings\LAB>ftp 192.168.1.1
Conectado a 192.168.1.1.
Usuario (192.168.1.1:(none)): lab
Contrasea:
ftp> bye
221 Goodbye.
C:\Documents and Settings\LAB>telnet 192.168.1.1
srxA1 (ttyp0)
login: lab
Password:
--- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC
lab@srxA1>
lab@srxA1> exit
Se ha perdido la conexin con el host.
Como podemos observar, el fallo sigue existiendo sea cual sea el tipo de interface
al que se le aplique el filtro. Comprobamos que nuestro router tenga los mdulos
JUNOS apropiados y concretamente el mdulo encargado de los filtros Firewall.
228
root@srxA1# run show version

Hostname: srxA1
Model: olive
root@srxA1#
Como ltima prueba, se ha ampliado la memoria a la MV del router srxA1 a

640MB para descartar que sea debido a una limitacin de espacio de memoria
para poder albergar los filtros y se han vuelto a repetir las pruebas constatando
que sigue fallando el filtro.
9.2.2. Conclusiones Finales
En base a los resultados de las pruebas realizadas podemos afirmar que las
Mquinas Virtuales JUNOS con R9.6 no funcionan los filtros firewall. Para
implementar esta caracterstica debemos utilizar una versin JUNOS R10.1 como
mnimo.
229
230
10. Conclusiones y Recomendaciones

Una vez finalizado este trabajo y teniendo en cuenta los objetivos marcados al
inicio de ste, podemos decir que se han cumplido todos los objetivos definidos
inicialmente.
Nuestro principal objetivo que era la creacin de una gua de laboratorios

prcticos para el aprendizaje de los routers Juniper, nivel de certificacin JNCIA, a
travs de una plataforma de virtualizacin y GNS3 se ha conseguido. En cada uno
de los laboratorios presentados en este trabajo se han comprobado que se
cumplen los objetivos didcticos y las funcionalidades de los routers en cada
escenario. Los escenarios se han adaptado para que puedan funcionar en GNS3.
Se ha aadido un captulo sobre la resolucin de los problemas que han ido

apareciendo a lo largo de todas las pruebas de los laboratorios en donde se ha
querido plasmar, no los comandos utilizados para su solucin, sino la metodologa
y anlisis empleada para llegar a la deteccin de fallas y luego a su solucin.
A continuacin pasamos a enumerar las conclusiones obtenidas:
GNS3 es una plataforma de emulacin perfectamente vlida para trabajar

con los routers Juniper. Es fcil de instalar y utilizar con la ventaja de ser
una herramienta gratuita.
GNS3 se sirve de los paquetes Dynamips y Dinagen para proporcionar la

emulacin. Si bien Dynamips es exclusivo para Cisco, la emulacin en
Juniper se realiza a travs de herramientas de virtualizacin como Virtual
Box que se enlazan con GNS3. Hay que indicar que si tenemos la
necesidad de utilizar un switch virtual, ste nos lo proporcionar el paquete
Dynamips.
231
Hasta la fecha, no existe forma de emular ningn dispositivo Switch

Ethernet de Juniper (familia EX), ni tampoco de Cisco. Pero GNS3
proporciona un switch virtual que implementa las funcionalidades bsicas
de un switch Ethernet pudiendo configurar VLANs de forma grfica.
En escenarios con routers Juniper no se ha conseguido que funcionara la

captura de paquetes con Wireshark. La herramienta GNS3 an no permite
esta caracterstica.
A la hora de clonar Mquinas Virtuales con IOS Juniper, Olivas, tener muy
presente que hay que cambiar las direcciones MAC de las mquinas
clonadas porque si no stas coincidirn y el trfico en los enlaces de
interconexin entre estos routers no funcionar.
Segn el estudio de rendimiento realizado, el escenario de trabajo para

conseguir el mximo rendimiento es instalar GNS3 en una mquina
anfitriona con un SO Linux, es preferible Ubuntu, y para la emulacin de los
dispositivos Juniper utilizar la herramienta Virtual Box. Se desaconseja la
utilizacin de QEMU.
Se recomienda que una vez creada una Oliva, se ajuste al mximo la

memoria utilizada por la mquina virtual. Cuando se lanzan los paquetes
de instalacin del software Junos, una de las comprobaciones que realiza
es la cantidad de memoria mnima que se necesita para iniciar la
instalacin. Una vez se han instalado todos los paquetes Junos, el
dispositivo puede ejecutarse con una menor cantidad de memoria RAM.
Para poder implementar escenarios relativamente grandes es muy
importante la cantidad de memoria que va a utilizar cada Oliva para
determinar el nmero mximo de dispositivos a insertar en el escenario.
Por ello cuanta menor memoria RAM se defina en las Olivas, siempre y
cuando no determine el funcionamiento del router, ms dispositivos
podremos emular en un escenario de GNS3.
232
La funcionalidad de Class of Service
de los dispositivos Juniper no
funciona en un entorno de emulacin. S que es posible definir las Clases y

los Mapas pero a la hora de asignarlos a una interface del tipo em no es
posible. El sistema Junos muestra un error que no permite configurarlo.
La funcionalidad de Filtros Firewall en Junos R9.6 no funciona

correctamente. El sistema s que te permite configurarlo y aplicarlo a una
interface pero a la hora de probarlo su comportamiento es como si no
estuviera el filtro. En la versin R10.1 s que han funcionado.
Se recomienda implementar Olivas con la versin Junos R10.4 por su gran

estabilidad de la IOS, su compromiso en la utilizacin de RAM por parte de
Virtual Box y por el tamao final del archivo de la mquina virtual.
El comportamiento y la apariencia en un dispositivo emulado Junos, Oliva,

es prcticamente similar y no se aprecia ninguna diferencia con respecto a
un dispositivo real.
233
234
11. Lneas Futuras

Tras la realizacin de este trabajo podemos resaltar las siguientes lneas futuras:
Intentar crear los escenarios para la siguiente certificacin, JNCIS, y probar

que se pueden configurar las Olivas as como su buen funcionamiento.
Crear una plataforma WEB de formacin donde se puedan elegir diferentes

escenarios de las certificaciones Juniper y ejecutar las mquinas virtuales
para su configuracin.
Probar plataformas diferentes, tales como XORP o sobre todo Vyatta, en el

entorno GNS3, estudiar su comportamiento y la interoperacin con
dispositivos Juniper.
Probar en Olivas con una versin JunOS ms actual, por ejemplo R12,
aquellas funcionalidades que no han funcionado correctamente con las
versiones probadas.
Realizar un estudio del comportamiento que tendrn las Olivas al introducir

trfico real en el entorno GNS3.
Estudiar la capacidad que incorpora GNS3 para el balanceo de carga de

procesamiento repartiendo los routers entre varios PCs externos.
235
236
12. Bibliografa
[1]. JNCIA. Juniper Networks Certified Internet Associate. Study Guide. Joseph M.
Soricelli. 2003-6. ISBN: 0-7821-4071-8.
[2]. JNCIA Junos Study Guide Part 1. 2010 Juniper Netwoks.
[3]. JNCIA Junos Study Guide Part 2. 2010 Juniper Netwoks.
[4]. Junos Software Routing Protocols Configuration Guide, Release 10.4. Octubre
2010, Juniper Networks, Inc.
[5]. Day One: Configuring Junos Basics. Sean Clarke. Enero 2011 v4. Juniper
Networks Books. ISBN: 978-1-936779-03-1.
[6]. Day One: Exploring IPv6. Chris Grundemann. Enero 2011 v3. Juniper
Networks Books. ISBN: 978-1-936779-07-9.
[7]. Junos Routing Essentials 11.a Detailed Lab Guide. Junio 2011 Juniper
Netwoks.
[8]. Junos Routing Essentials 11.a Lab Diagrams. Junio 2011 Juniper Netwoks.
[9]. Junos Routing Essentials 11.a High-Level Lab Guide. Junio 2011 Juniper
Netwoks.
[10]. Junos Routing Essentials 11.a Student Guide. Junio 2011 Juniper Netwoks.
[11]. Diseo e implementacin de un prototipo de red de comunicaciones basado
en virtualizacin y servicios web 2.0. PFC Manuel Miguel Torres Snchez.
[12]. Evaluacin de la herramienta GNS3 con conectividad a enrutadores reales.
PFC Lisset Daz Cervantes. UPC.
[13]. Despliegue de redes seuelo mediante el uso de herramientas de creacin
de escenarios virtuales. PFC Jorge Alejandro Rodrguez Villagr. ETSIT UPM.
[14]. GNS3 as a feasible teaching,testing and designing tool for network design.
James Mahon, Paul Flynn.
237
[15]. Foro web GNS3

http://forum.gns3.net/
[16]. Creacin Olivas en QEMU
http://muralirajanm.blogspot.com.es/
[17]. Creating an Olive with JunOS 12.1 on VirtualBox
http://pieknywidok.blogspot.com.es/2012/04/creating-olive-with-junos-121-on.html
[18]. Juniper Learning Portal
https://learningportal.juniper.net/juniper/user_fasttrack_home.aspx
[19]. CertCollection Juniper Shares
http://certcollection.org/forum/forum/155-juniper-shares/
[20]. Olive reloaded or how to emulate Juniper routers
http://blog.gns3.net/2009/10/olive-juniper/2/
[21]. Tutor Deploy Junos (juniper network) olive on virtualbox and install Jweb.
http://motaroirhaby.blogspot.com.es/2012/11/tutor-deploy-junos-junipernetwork.html
[22]. Vyatta Open Networking - Software-based Routing & Security
http://www.vyatta.com
238

Memoria GNS3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Memoria GNS3

Uploaded by

Copyright:

Available Formats

TRABAJO FIN DE MSTER

Mster Universitario en Ingeniera de Telecomunicacin

Estudio e implementacin de la herramienta de

Mster Universitario en Ingeniera de Telecomunicacin - UA

Pgina en blanco intencionadamente

Estudio e implementacin de la herramienta de simulacin de redes GNS3

UA - Mster Universitario en Ingeniera de Telecomunicacin

GNS3 GRAPHICAL NETWORK SIMULATOR ...................... 13

Historia de GNS3 ................................................................................... 15

Arquitectura del emulador .................................................................... 16

2.3.1. Dynamips .................................................................................................................... 16

Herramientas para GNS3 ...................................................................... 19

Routers actuando como PC ....................................................................23

Virtualizar un PC con VirtualBox .............................................................23

Emulacin de Routers .......................................................................... 24

2.5.1. Router de cdigo abierto: XORP............................................................................. 24

Anlisis de rendimiento: QEMU vs VirtualBox ................................... 27

INSTALACIN DE OLIVAS ..................................................... 31

Requisitos mnimos .............................................................................. 32

Instalacin de una Oliva ....................................................................... 32

3.3.1. Instalando FreeBSD .................................................................................................. 33

Mster Universitario en Ingeniera de Telecomunicacin - UA

Configurando la Oliva en GNS3 ..................................................................... 50

Comprobacin de la Oliva JWeb Junos 9.6 .............................................. 53

Instalacin IOS Junos 10.4R1.9...................................................................... 58

Instalacin FreeBSD ...............................................................................58

Instalacin Junos 10.4R1.9 .....................................................................60

Instalacin JWeb Junos10.4 ...................................................................65

Comprobacin de la Oliva JWeb Junos 10.4 ......................................68

LAB 1: FUNDAMENTOS DE ROUTING ................................... 71

LAB 2: POLTICAS DE ROUTING ........................................... 97

LAB 3: FILTROS FIREWALLS ............................................... 123

LAB 4: CLASES DE SERVICIOS (COS) ................................ 161

Estudio e implementacin de la herramienta de simulacin de redes GNS3

UA - Mster Universitario en Ingeniera de Telecomunicacin

LAB 5: IPV6 ............................................................................ 179

TROUBLESHOOTING JUNOS............................................... 201

Problema 1: Fallo enrutamiento OSPF ................................................................ 201

Conclusiones Finales ............................................................................221

Problema 2: Fallo Filtros Firewall en versin R9.6 ............................................. 222

Conclusiones Finales ............................................................................229

10. CONCLUSIONES Y RECOMENDACIONES .......................... 231

Estudio e implementacin de la herramienta de simulacin de redes GNS3

Mster Universitario en Ingeniera de Telecomunicacin - UA

Estudio e implementacin de la herramienta de simulacin de redes GNS3

UA - Mster Universitario en Ingeniera de Telecomunicacin

Estudio e implementacin de la herramienta de simulacin de redes GNS3

Mster Universitario en Ingeniera de Telecomunicacin - UA

Pgina en blanco intencionadamente

Estudio e implementacin de la herramienta de simulacin de redes GNS3

UA - Mster Universitario en Ingeniera de Telecomunicacin

El mantenimiento y optimizacin de una red, as como su respuesta ante posibles

Un emulador es un software que permite ejecutar instrucciones originarias de una

Mster Universitario en Ingeniera de Telecomunicacin - UA

Un simulador trata de reproducir el comportamiento del programa o sistema,

A la hora de elegir un emulador o un simulador, sin duda es ms real la opcin de

Estudio e implementacin de la herramienta de simulacin de redes GNS3

UA - Mster Universitario en Ingeniera de Telecomunicacin

Vyatta es un sistema operativo opensource que puede instalarse en cualquier

El presente PFC tiene los siguientes objetivos concretos:

Estudio e implementacin de la herramienta de simulacin de redes GNS3

Mster Universitario en Ingeniera de Telecomunicacin - UA

g. Probar la consecucin completa de cada uno de los laboratorios del JNCIA

Estudio e implementacin de la herramienta de simulacin de redes GNS3