Implementación de GNS3 para simulación de redes

TRABAJO FIN DE MÁSTER
Máster Universitario en Ingeniería de Telecomunicación

Estudio e implementación de la herramienta de
simulación de redes GNS3

Autor:
Julio Jornet Monteverde

Directores:
Carolina Pascual Villalobos
Adolfo Albaladejo Blázquez

Septiembre, 2013

Máster Universitario en Ingeniería de Telecomunicación - UA

Página en blanco intencionadamente

2

Estudio e implementación de la herramienta de simulación de redes GNS3

UA - Máster Universitario en Ingeniería de Telecomunicación

ÍNDICE

1. PREÁMBULO ................................................................................. 9
1.1.

Introducción ............................................................................................ 9

1.2.

Objetivos ................................................................................................ 11

2.

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

2.1.

Introducción .......................................................................................... 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. Simulación de PCs .................................................................................................... 22
2.4.4.1.
2.4.4.2.

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

2.4.4.3.

2.5.

Virtual PC ................................................................................................22

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

Emulación de Routers .......................................................................... 24

2.5.1. Router de código abierto: XORP............................................................................. 24
2.5.2. Sistema Vyatta ........................................................................................................... 26

2.6.

3.

Análisis de rendimiento: QEMU vs VirtualBox ................................... 27

INSTALACIÓN DE OLIVAS ..................................................... 31

3.1.

Introducción .......................................................................................... 31

3.2.

Requisitos mínimos .............................................................................. 32

3.3.

Instalación de una Oliva ....................................................................... 32

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

3

3.3.2. Configuración Post-Instalación ................................................................................ 39
3.3.3. Configuración Virtual Serial Port Emulator ............................................................ 40
3.3.4. Instalación IOS Junos 9.6 ........................................................................................ 42
3.3.5. Instalación JWeb Junos 9.6 ..................................................................................... 47

3.4.

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

3.5.

Comprobación de la Oliva JWeb Junos 9.6 .............................................. 53

3.6.

Instalación IOS Junos 10.4R1.9...................................................................... 58

3.6.1.

Instalación FreeBSD ...............................................................................58

3.6.2.

Instalación Junos 10.4R1.9 .....................................................................60

3.6.3.

Instalación JWeb Junos10.4 ...................................................................65

3.7.

4.

Comprobación de la Oliva JWeb Junos 10.4 ......................................68

LAB 1: FUNDAMENTOS DE ROUTING ................................... 71
Parte 1: Configuración y Monitorización de Interfaces .................................................... 72
Parte 2: Configuración y Monitorización de Rutas Estáticas .......................................... 78
Parte 3: Configuración y Monitorización OSPF ................................................................ 84
Parte 4: Guardar configuraciones ....................................................................................... 89

5.

LAB 2: POLÍTICAS DE ROUTING ........................................... 97
Parte 1: Preparación del Sistema y Verificación ............................................................... 98
Parte 2: Configurar y Monitorizar Políticas de Enrutamiento ........................................ 102
Parte 3: Configurar servidor TFTP de copias de configuración ................................... 116

6.

LAB 3: FILTROS FIREWALLS ............................................... 123
Parte 1: Preparación del Sistema y Verificación ............................................................. 124
Parte 2: Configurando y Monitorizando Filtros Firewall ................................................. 131
Parte 3: Configurar servidor TFTP de copias de configuración ................................... 148

7.

LAB 4: CLASES DE SERVICIOS (COS) ................................ 161
Parte 1: Preparación del Sistema y Verificación ............................................................. 163
Parte 2: Configurando Colas y Mapas de Planificación ................................................ 171
Parte 3: Configurando Clasificación Multicampo ............................................................ 175

4



8.

LAB 5: IPV6 ............................................................................ 179
Parte 1: Configurar y Monitorizar Interfaces .................................................................... 180
Parte 2: Configurando y Monitorizando Rutas Estáticas ............................................... 186
Parte 3: Configurando y Monitorizando OSPF ................................................................ 190
Parte 4: Tunneling IPv6 sobre IPv4 utilizando Encapsulación 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 versión R9.6 ............................................. 222

9.2.2.

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

10. CONCLUSIONES Y RECOMENDACIONES .......................... 231
11. LÍNEAS FUTURAS ................................................................. 235
12. BIBLIOGRAFÍA ...................................................................... 237


5


Listado de Figuras
Figura 1: Bloques software de la herramienta GNS3 .......................................................13
Figura 2: Ventana principal de VirtualBox incluyendo máquinas virtuales. .......................20
Figura 3: Escenario utilizado para análisis de rendimiento. ..............................................28
Figura 4: Tabla de tiempos y carga del sistema anfitrión. ................................................28
Figura 5: Tiempo medio que tardan en arrancar las Olivas según el sistema operativo y el
sistema de virtualización. .................................................................................29
Figura 6: a) Carga de memoria según SO. b) Carga de la CPU según SO. .....................30
Figura 7: Pantallas para la creación de una máquina virtual con el VirtualBox. ................34
Figura 8: Propiedades de configuración de una MV. ........................................................34
Figura 9: Pantalla de arranque inicial de la MV con FreeBSD. .........................................35
Figura 10: Menú de configuración del kernel FreeBSD. ...................................................35
Figura 11: Pantalla principal de instalación 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 instalación FreeBSD. ........................................................38
Figura 17: Menú configuración de red. .............................................................................39
Figura 18: Menú principal SysInstall FreeBSD. ................................................................40
Figura 19: Configuración puerto serie de la MV ...............................................................41
Figura 20: Ventana principal VSPE. .................................................................................41
Figura 21: a) Definición tipo de conexión. b) Definición puerto virtual. .............................42
Figura 22: Ventana principal con el estado del puerto serie virtual...................................42
Figura 23: Mensajes iniciales de la instalación del paquete Junos. ..................................44
Figura 24: Mensaje de error de instalación paquete Junos. .............................................45
Figura 25: Reinicio previo al comienzo de la instalación paquete Junos. .........................45
Figura 26: Captura del inicio de la instalación Junos con el programa Putty y a través del
puerto serie virtual. ........................................................................................46
Figura 27: Arranque inicial de la Oliva con versión Junos 9.6R1.13. ................................46
Figura 28: Captura de los paquetes instalados en la Oliva (comando show version). ......47
Figura 29: Mensajes iniciales instalación paquete JWEB. ................................................49
Figura 30: Ventana Preferences de GNS3: comprobación comunicación con VirtualBox.51
Figura 31: Ventana Preferences de GNS3: definición de las MV. ....................................52
Figura 32: Administración de símbolos 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: Configuración de nodo: asignación de interfaces. ...........................................54
Figura 36: Acceso a la Oliva con GNS3. ..........................................................................55
Figura 37: Pantalla de bienvenida al acceso vía Web. .....................................................56
Figura 38: Pantalla de configuración del router con el JWEB. ..........................................57
Figura 39: Definición del tamaño del disco duro para una MV en VirtualBox. ..................58
Figura 40: Propiedades de configuración de la MV para Junos 10.4................................59
Figura 41: Tabla de particiones de FreeBSD para Junos 10.4. ........................................60
Figura 42: Distribución del filesystem para Junos 10.4. ...................................................60
Figura 43: Modificación archivo +INSTALL. .....................................................................62
Figura 44: Mensajes iniciales instalación paquete Junos 10.4. ........................................64
Figura 45: Proceso de instalación Junos 10.4. .................................................................64
Figura 46: Proceso de instalación paquete JWEB 10.4....................................................66
Figura 47: Listado definiciones de MV en GNS3. .............................................................68
Figura 48: Configuración de la Oliva 10.4 en un escenario. .............................................69
Figura 49: Pantalla de bienvenida JWEB 10.4. ................................................................70
Figura 50: Pantalla configuración via Web Junos 10.4. ....................................................70
Figura 51: Escenario del laboratorio Fundamentos de Routing. .......................................71
Figura 52: Integración nodo de interconexión al escenario. .............................................92
Figura 53: Ventana configuración nodo de interconexión. ................................................93
Figura 54: Ventana principal de Cisco TFTP Server. .......................................................94
Figura 55: Logs de recepción 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 configuración de OSPFv3. ................................................190
Figura 62: Escenario para la configuración del túnel GRE. ............................................193
Figura 63: Escenario utilizado en el laboratorio 3: Filtros Firewalls. ...............................201
Figura 64: Escenario de prueba con sólo dos routers. ...................................................203
Figura 65: Escenario de pruebas con las líneas intercambiadas. ...................................208
Figura 66: Escenario utilizado en el laboratorio 5.3: IPv6, OSPFv3. ..............................210
Figura 67: Configuración dirección MAC en una MV de VirtualBox. ...............................217


7


Página en blanco intencionadamente

8



1.

Preámbulo

1.1. Introducción

El mantenimiento y optimización de una red, así como su respuesta ante posibles
fallos o sobrecargas es una tarea peligrosa porque cualquier modificación en su
configuración conlleva un impacto sobre el tráfico real y por lo tanto sobre el
cliente final ya que estas redes se encuentran en producción. Esta situación hace
que las empresas y operadores se planteen alternativas para el estudio y
optimización de sus redes, tales como implementar maquetas o realizar
simulaciones con programas específicos. La primera de las opciones, creación de
maquetas, puede resultar muy costosa ya que conlleva la adquisición de
equipamiento real y en escenarios grandes puede resultar inviable. También a la
hora de adquirir formación 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 más común que empresas y estudiantes se
decanten por programas de emulación/simulación, tales como OPNET o GNS3,
para probar nuevos protocolos o aprender conceptos que más adelante los
aplicarán 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 serían VMware ó VirtualBox que emulan sistemas operativos ó GNS3
que emula dispositivos de red a partir de imágenes reales de IOS CISCO.

9


Un simulador trata de reproducir el comportamiento del programa o sistema,
permitiendo representar ciertas características o comportamientos claves
(modelo) del sistema físico o abstracto que se quiere simular, y por lo tanto el
sistema resultante será más limitado. Un ejemplo de un simulador de routers sería
BOSON o Juniper Simulator, diseñados con fines académicos para soportar las
funcionalidades requeridas para la obtención de certificaciones CISCO o
JUNIPER, como serían JNCIA o JNCIS.

A la hora de elegir un emulador o un simulador, sin duda es más real la opción 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, fácil de instalar y manejar. En un principio fue creado para la emulación
de dispositivos CISCO y para ello utiliza la IOS original de CISCO la cual es
propietaria y requiere de permisos para su obtención. Esto de por sí ya es una
limitación y hace que el paquete no sea tan “libre”. Una alternativa a esta
limitación sería 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 código abierto con capacidad de
ofrecer multicast integrado. Posee una arquitectura modular que permite una
rápida introducción de nuevos protocolos, características 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 configuración y el fichero
de configuración son iguales. Este sistema operativo se encuentra disponible de
forma gratuita en Internet en su versión más limitada, si se desea obtener
funcionalidades más complejas este software deja de ser gratuito.

1.2. Objetivos

El objetivo principal que se persigue en este trabajo es realizar una guía completa
para la creación, configuración y consecución de los laboratorios existentes en la
certificación JNCIA de Juniper utilizando la herramienta GNS3, junto con un
sistema de virtualización 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 máquina virtual,
llamadas Olivas, en varios sistemas de virtualización, QEMU y VirtualBox.
b. Estimar los requerimientos hardware que son necesarios para la creación
de las Olivas.
c. Comprobar y estudiar las capacidades que ofrece el entorno GNS3 para la
simulación de redes con dispositivos Juniper emulados.
d. Detallar el uso de las características del entorno GNS3 para los
dispositivos Juniper.
e. Determinar qué sistema de virtualización utilizado por GNS3 es el más
óptimo.
f. Adaptar los escenarios de los laboratorios del JNCIA para el entorno
GNS3.


11


g. Probar la consecución completa de cada uno de los laboratorios del JNCIA
creados por Juniper.
h. Probar el correcto funcionamiento y configuración de los protocolos de
enrutamiento IPv6 en el entorno GNS3.

12



2. GNS3 – Graphical Network Simulator
2.1. Introducción

GNS3 son las siglas de Graphical Network Simulator. Esta aplicación está
enfocada a la simulación de redes complejas para su estudio. Este entorno visual
usa como motor de ejecución la plataforma Dynamips/Dynagen, creada
originalmente para ejecutar y emular el firmware de los routers y dispositivos de
Cisco Systems (IOS) y Juniper (JunOS), además de establecer topologías
(escenarios)

para

conectarlos.

Dichas

topologías

pueden,

a

su

vez,

interconectarse con otras ejecutándose 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 máquinas).

GNS3 se ha desarrollado en Python y usa las librerías de Dynagen para crear una
interfaz gráfica (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 unión de Dynamips-Dynagen-GNS3, como se observa en la siguiente figura,
crea una plataforma que permite el fácil diseño de topologías de red complejas ya
que se realizan tan sólo arrastrando los componentes y dibujando líneas entre
routers de forma intuitiva. Por lo tanto, GNS3 es idóneo para el entrenamiento de
estudiantes que desean familiarizarse con dispositivos de red.

Figura 1: Bloques software de la herramienta GNS3

13


Las capacidades más destacables que podemos obtener de GNS3 y por las
cuales nos hemos decantado para su utilización en este trabajo son las
siguientes:
•

Se encuentra disponible de forma gratuita en la red.

•

Es fácil de instalar ya que todos los programas que necesita para funcionar
se encuentran en un solo paquete de instalación.

•

Está en constante actualización y periódicamente se puede encontrar
versiones de la aplicación más robustas y con nuevas funcionalidades.

•

Permite la conexión Telnet a la consola de un router virtual, de forma fácil
directamente desde la interfaz gráfica.

•

Alternativamente también permite trabajar directamente desde consola de
gestión de Dynagen.

•

Permite la comunicación entre redes virtuales con redes del mundo real.

•

Es apropiado para simular redes de grandes tamaños ya que permite que
un cliente GNS3 pueda correr en una máquina 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 aplicación ampliamente
utilizada.

GNS3 no es la única aplicación 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 sólo existía 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 imágenes IOS propias de los routers Cisco. Se
podría ejecutar Dynamips desde la línea de comandos y tener un router Cisco
emulado ejecutándose 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, habría
que iniciar dos instancias del programa con un montón de opciones de línea de
comandos cuidadosamente construidos. Por lo que haría que su CPU estuviera
trabajando al 100% y por lo tanto no sería operativo.

En el 2006, se lanzó la versión 0.2.5 que hizo posible ejecutar Dynamips en modo
Hipervisor, el cual permite simular varios routers en una simple instancia y añadir
la opción Idle-PC, que te permite ajustar la utilización de la CPU del PC y por lo
tanto no saturarlo. Pero es más importante la característica Hipervisor que
permitió a Greg Anuzelli poner un front-end a todas aquellas opciones de la línea
de comandos con su programa llamado Dynagen. Aquí fue donde se creó el
formato del fichero .net, y que GNS3 utiliza junto con las librerías de Dynagen. De
hecho, el panel inferior de GNS3 es una consola de Dynagen adaptado.

En ese momento, Dynagen era bueno, pero tenía un problema: el mantenimiento
del fichero .net era una pesadilla, un solo error en la definición de un objeto o
conexión y el Hipervisor no arrancaba.

En Septiembre de 2007 salió la primera versión de GNS3 (versión 0.3). Se
añadieron nuevos colaboradores como Jeremy Grossmann y Xavier Alt al grupo
de desarrollo. En esta versión ya se podían arrastrar y soltar los iconos en el
panel central y automáticamente GNS3 creaba dichas conexiones en el fichero
.net para que posteriormente Dynagen hiciera magia con Dynamips para controlar

15


los routers. También se añadieron varias configuraciones extras al fichero .net
(ahora llamado topology.net por defecto) para que se pudiera recordar dónde se
habían 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 pequeña aplicación llamada VPCS que nos permitió simular PCs y
asociarlos fácilmente a nuestras redes virtuales GNS3. Desde entonces, cada
nueva versión ha ido aportando nuevas funcionalidades con respecto a las
versiones anteriores aumentando la comunidad de usuarios, pero todavía 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 emulación que permite emular diferentes plataformas
hardware usando imágenes 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 básicas.

En cuando a la emulación de switches, Dynamips no es capaz de emular
switches, ni de la familia Cisco Catalyst ni Juniper EX, sino que provee una
versión limitada de un switch virtual, cuyas limitaciones pueden ser resueltas
usando métodos alternativos como la emulación 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 través de Dynagen.

16



Como ya hemos comentado, inicialmente Dynamips consume grandes cantidades
de CPU del PC anfitrión, esto se debe principalmente a que realiza la emulación
de los routers instrucción por instrucción y a que no puede saber cuándo un router
virtual está inactivo, de modo que ejecuta instrucciones como si la imagen del IOS
estuviera realizando algún trabajo útil. Para resolver el problema del excesivo uso
de CPU se crea un proceso llamado IDLE-PC. Este parámetro se debe ajustar
para la familia de dispositivos CISCO, pero para Juniper no es el caso ya que
estos dispositivos se emulan virtualmente a través de herramientas de
virtualización, tales como VirtualBox y no se utiliza Dynamips.

Por otro lado, Dynamips también consume memoria RAM del PC emulador, ya
que, en teoría cada router virtual debe tener a su disposición, como mínimo, toda
la cantidad de memoria RAM que necesita para poder trabajar, por lo tanto, esta
cantidad se hace impráctica 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 virtualización, por
ejemplo VirtualBox. Cada router que se incorpore a un escenario consumirá una
serie de recursos en la máquina 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 máquinas virtuales y asignarles la memoria y CPU, ya que de esos
parámetros dependerá el número total de routers que podamos insertar en
nuestros escenarios.


17


2.3.2. Dynagen

Dynagen es una interfaz escrita en Python que provee la gestión, mediante línea
de comando (CLI), de las plataformas emuladas por Dynamips haciendo más fácil
su uso. Usa el modo “Hypervisor” para comunicarse con Dynamips y ambas
pueden correr en la misma o en diferente PC. También simplifica la gestión de las
redes virtuales ya que implementa comandos para listar, iniciar, parar, reiniciar,
suspender, reanudar los diferentes dispositivos emulados, además 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 añadir Firewalls CISCO en las topologías. Además 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 fácil interpretación llamado “Network File”, con
extensión “.net”, para conocer todas las características 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 configuración de todos los dispositivos de red de la topología 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 conexión 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 solución open source de virtualización 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-virtualización, lo cual penaliza su rendimiento
comparado con otros sistemas de virtualización como Xen, pero maximiza su
compatibilidad dado que puede ejecutar cualquier máquina huésped que funcione
en una máquina x86 (32 o 64 bits).

Durante los últimos años VirtualBox se ha convertido en una de las herramientas
de virtualización más usada, debido a su Interfaz amigable y a que tiene versiones
instalable en multitud de Sistemas Operativos incluyendo Windows, Linux y Mac,
además 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
máquinas llamado VboxManage y luego varios entornos gráficos o terminales
para acceder a las máquinas. Incluso incorpora un módulo PHP para crear un
servidor web donde se muestra la misma interface de aplicación y las máquinas
virtuales.


19


Figura 2: Ventana principal de VirtualBox incluyendo máquinas virtuales.

Las máquinas virtuales pueden ser creadas y gestionadas desde el entorno
gráfico o directamente desde la línea de comandos mediante VboxManage. Por
ejemplo, para arrancar una máquina virtual desde la linea de comandos
escribiremos lo siguiente:

VBoxManage startvm "Junos Olive R12"

Una vez arrancadas las máquinas 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 máquina sin interferir en el
sistema huésped.

20



De esta manera es como GNS3 interactúa con las máquinas virtuales de
VirtualBox.

2.4.2. QEMU

GNS3 tiene la capacidad de poder interactuar con el emulador QEMU que no es
más que un programa de virtualización de código libre. GNS3 lo utiliza para
ejecutar IOS de Cisco ASA, PIX e IDS, y en él también se puede implementar
JUNOS con QEMU.
QEMU emula un sistema informático completo, incluyendo procesador y varios
periféricos. 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 además la emulación de varias plataformas de hardware, incluyendo
x86, AMD64, Alpha, Mips, y Sparc.
La mayoría del programa está bajo licencia LGPL, y el modo de emulación de
usuario tiene licencia GPL.
Existe un módulo para el kernel Linux (se han hecho adaptaciones preliminares
para FreeBSD y Windows), denominados kqemu o acelerador QEMU. Esto
acelera la emulación de i386 en plataformas i386 hasta un nivel ligeramente
inferior a la ejecución en modo nativo. Se alcanza lo dicho ejecutando el modo de
usuario y virtual en modo de código 8086 directamente sobre la CPU del
computador. Además, sólo se usa la emulación del procesador y de los periféricos
en modo kernel y en modo de código 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 máquina virtual con Junos
9.6 y realizar comparativas de rendimiento junto con VirtualBox. Más adelante se
expondrán los resultados.


21


2.4.3. Wireshark

El paquete de instalación GNS3 lleva consigo la instalación 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
máquinas virtuales y por lo tanto no se ha podido conseguir la captura de
paquetes. GNS3 muestra un error indicando que esta característica solo está
disponible para Hipervisors locales.

2.4.4. Simulación de PCs

GNS3 permite, además de los equipos de red, la incorporación de PCs en las
topologías creadas, lo que facilita la comprobación y el estudio de las redes
simuladas. Las formas existentes de simulación de PCs en GNS3 son las
siguientes:
2.4.4.1.

Virtual PC

Esta primera forma de simulación de PCs se realiza utilizando un programa
llamado “Virtual Pc Simulator” o VPC que usa puertos UDP para la comunicación
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
llamaría 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
máximo de nueve (09) PCs simulados simultáneamente.

2.4.4.2.

Routers actuando como PC

En este método, la incorporación de un PC a la topología es la más simple, ya
que solo se trata de añadir un router para que se puedan ejecutar comandos para
comprobaciones, la desventaja de este método es que utiliza demasiados
recursos de memoria y procesamiento.

Los comandos que debemos usar para configurar cada router son básicamente
para configurar una dirección IP y un Gateway a la interfaz de conexión, y además
se deshabilitarán las funciones de enrutamiento del dispositivo.

2.4.4.3.

Virtualizar un PC con VirtualBox

Este método es el más real ya que implementamos un PC por completo, con
todas sus características y programas, e incluso con la posibilidad de activar
servicios y así poder asumir el roll de Servidor en nuestros escenarios.

La carga que añade a nuestros escenarios dependerá de cómo se haya creado la
máquina 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
utilizarán 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 actúe
como servidor HTTP, MAIL, etc.

2.5. Emulación de Routers

Como ya se ha comentado, en un principio GNS3 se empleó para la emulación de
routers Cisco, y posteriormente a través de plataformas de emulación, los routers
Juniper. Aunque GNS3 es de licencia libre, la utilización de las IOS conlleva
disponer de una licencia para su utilización, 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 código abierto: XORP

XORP son las siglas de eXtensible Open Router Platform, un trabajo GNU para la
creación de una plataforma de código abierto que permite la creación de
dispositivos de interconexión software multiplataforma. XORP tiene una
arquitectura modular y flexible, que permite implementar distintos protocolos de
encaminamiento, los cuales se cargarán y ejecutarán cuando sea requerido por el
administrador del dispositivo.

La versión 1.6 incluye los siguientes módulos de protocolos y tecnologías 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 página web a través de live CD
o como fuentes para Windows y Unix/Linux. De nuevo, y siguiendo nuestra
propuesta, XORP podría ser virtualizado sobre el ordenador anfitrión que esté
ejecutando GNS3. Para ello, se puede recurrir a la plataforma de virtualización
VirtualBox, que según 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 configuración de un router tipo Cisco y uno
XORP, la consola de configuración es similar (CLI o command-line interpreter). La
única diferencia reseñable, 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.

Según estudios y pruebas realizadas por grupos de investigación, como en la
Universidad de Málaga, las pruebas con XORP han sido muy satisfactorias, y el
consumo de recursos en el PC anfitrión se reduce considerablemente al usar
routers XORP, por lo que las topologías pueden contener más elementos y
realizar tareas de encaminamiento más complejas. XORP no tiene todas las
capacidades de un router comercial, pero los protocolos de que dispone son más
que suficientes para su utilización 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 económica 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 máquina física 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
económico appliance de red de clase empresarial, comparable a cualquier
solución propietaria, en todo entorno de producción.

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.

•

Añadir 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 también 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 catálogo de Vyatta en:
http://www.vyatta.com/downloads/datasheets/vyatta_solutions_guide.pdf

Vyatta, al igual que las soluciones de Cisco, también incluye una interfaz de
manejo por línea de comandos, así como una interfaz web muy completa. El
sistema viene como un LiveCD. La línea de comandos y su configuración es muy
similar a los routers Juniper.

2.6. Análisis 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 virtualización
nos pueden servir pero para ver qué opción es la más apropiada se ha realizado
un estudio comparativo y así poder determinar cuál se comporta mejor, tanto en
rendimiento como en utilización de recursos.

El estudio ha consistido en la creación 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 análisis de rendimiento.

Se ha implementado y ejecutado dicho escenario en una máquina 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 anfitrión.

Como podemos observar en la tabla resumen, la diferencia entre utilizar máquinas
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
máquinas virtuales funcionan mucho mejor con el sistema de virtualización
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 según el
sistema operativo y el sistema de virtualización.

En la gráfica 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 están en segundos. La mejor configuración para utilizar Olivas, en
cuanto a tiempo y máximo número de MV en un escenario, es utilizar un
ordenador anfitrión con un sistema operativo Linux Ubuntu 12.0, GNS3 y
VirtualBox para Linux. En esta configuración, a GNS3 no hay que ajustarle ningún
parámetro tal como IDLE-PC, ya que éste sólo es útil para IOS de CISCO y no
para MV.


29


Load MEM

% CPU

2

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 según SO. b) Carga de la CPU según SO.

En un ordenador estándar, que utilice Windows, la diferencia de utilizar VirtualBox
a QEMU es bastante importante: de tardar apenas unos 2 minutos con VirtualBox
a tardar más de 14,5 minutos con QEMU.

Si queremos simular escenarios grandes para ver cómo se comportan protocolos
tales como OSPF o BGP, en donde hayan una gran cantidad de routers Juniper,
la mejor opción será utilizar la plataforma Ubuntu 12.0 y VirtualBox.

30



3.

Instalación de Olivas

3.1. Introducción

Una Oliva es el apodo utilizado para referirse al software JUNOS, que se ejecuta
en los dispositivos Juniper, pero ejecutándose en un PC normal. Podríamos
pensar que este software es una versión especial o distribuida exclusivamente
para su ejecución 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 específico.
No se trata de un simulador de router, ni tampoco un equipo que es capaz de
llevar tráfico real y por lo tanto ponerlo en producción. Estas máquinas
normalmente se utilizan para fines educativos, ya que es la única forma
económica de tener acceso al equipamiento Juniper y así poder practicar para las
certificaciones. También suelen utilizarse en laboratorios para pruebas con fines
de investigación.

Hay que tener presente que la posición oficial del fabricante Juniper es que las
Olivas no existen. Estas plataformas de por sí no disponen de licencia ni
autorización por parte del fabricante y por lo tanto son plataformas ilegales, sin
ningún 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 fácilmente
podría implementar controles adicionales al software para impedir que funcione.

En este capítulo vamos a explicar cómo crear una máquina virtual que
implemente el IOS JUNOS versión 9.6 y versión 10.4.


31


3.2. Requisitos mínimos

Para la versión Junos 9.6, que es con la que se van a implementar los dos
primeros laboratorios, los requisitos mínimos en cuanto al Hardware son:
•

PC genérico 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 instalación FreeBSD 4.11 mini-iso i386, que se puede
descargar gratuitamente de la dirección:
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. Instalación de una Oliva

Para crear la máquina virtual en un sistema Windows se necesitará tener
instalado la versión de VirtualBox 4.2.16 para host Windows. También se
requerirá tener instalado el programa Virtual Serial Port Emulator, en la versión
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 instalación 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 instalación 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 configuración son los siguientes:
3.3.1.1.

Creación nueva instancia en VirtualBox.


33


Figura 7: Pantallas para la creación de una máquina virtual con el VirtualBox.

3.3.1.2.

Una vez creada la instancia de nuestra nueva máquina virtual,
editamos la configuración y le indicamos dónde tenemos la imagen
ISO del sistema FreeBSD. También es importante configurar el
Puerto Serie de nuestra máquina que lo haremos más adelante.

Figura 8: Propiedades de configuración de una MV.

3.3.1.3.

Iniciamos nuestra MV que iniciará el proceso de instalación del SO
FreeBSD y en el Menu de Configuración del Kernel escogemos la
primera opción: Skip kernel configuration and continue with
installation.

34



Figura 9: Pantalla de arranque inicial de la MV con FreeBSD.

Figura 10: Menú de configuración del kernel FreeBSD.

3.3.1.4.

En el menú principal de instalación escogemos la instalación
Standard.


35


Figura 11: Pantalla principal de instalación 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 instalación del Boot Manager escogemos la primera
opción: 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 continuación.
Para finalizar teclear Q.

Figura 14: Editor de filesistems de FreeBSD.

3.3.1.8.

En el menú de distribución 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 distribución, CD/DVD. Nos preguntará si estamos seguros de realizar la
instalación, elegimos YES. En este momento comenzará la
instalación de FreeBSD.

Figura 16: Menú de origen de instalación FreeBSD.

38



3.3.2. Configuración Post-Instalación

3.3.2.1.

Configuramos la interface Ethernet. Seleccionamos el tipo em0,
Intel PRO/1000 ethernet card. NO configuración IPv6. SI DHCP.

Figura 17: Menú configuración 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,
España.

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 instalación. Finalizamos
definitivamente la instalación y automáticamente 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 instalación FreeBSD.

3.3.3. Configuración Virtual Serial Port Emulator

A continuación vamos a configurar una conexión serial virtual entre la MV y un
programa de conexión terminal como Putty. Se trata de hacer como si fuera un
túnel entre el puerto serie COM1 de la MV y un puerto serie de nuestra máquina
anfitriona.

3.3.3.1.

Vamos a las propiedades de la MV y en la pestaña de Puertos
Serie lo configuramos de la siguiente manera.

40



Figura 19: Configuración puerto serie de la MV

3.3.3.2.

Ahora ejecutamos el programa Virtual Serial Port Emulator y
apretamos el botón de Create new device.

Figura 20: Ventana principal VSPE.

3.3.3.3.

En la ventana de configuración de la nueva conexión elegiremos el
tipo de conexión Connector, y el COM3 como Virtual Serial Port.


41


Figura 21: a) Definición tipo de conexión. b) Definición puerto virtual.

3.3.3.4.

Una vez finalizada la configuración de la conexión virtual,
tendremos ya listo y preparado el túnel serie.

Figura 22: Ventana principal con el estado del puerto serie virtual.

3.3.4. Instalación IOS Junos 9.6

A continuación 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 través de un servidor FTP en nuestra
máquina anfitriona y luego simplemente descargando los ficheros, o creando un
archivo ISO y montándolo en la MV. En el ejemplo vamos a utilizar éste último
método.

3.3.4.1.

Accedemos a las propiedades de la MV y en la pestaña de
Almacenamiento asociamos nuestra imagen ISO , fichero JUNOS
R9.6.ISO, en el CD/DVD. Arrancamos la MV y accedemos como
root con la contraseña que definimos en la instalación.

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 versión JUNOS 7.4, Juniper implantó una protección
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 instalación y procederemos a
su instalación. Es muy importante que antes de iniciar la
instalación tengamos abierta una sesión 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
algún error.

Olive# pkg_add /var/tmp/jinstall-9.6R1-13-export-olive.tgz

3.3.4.5.

Nos aparecerá un mensaje informándonos que se iniciará la
instalación después de reiniciar.

Figura 23: Mensajes iniciales de la instalación 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 creación de la
Oliva con en Linux o Windows 7.

44



Figura 24: Mensaje de error de instalación paquete Junos.

3.3.4.7.

Una vez iniciada la instalación nos pedirá realizar un reboot. A
partir de este momento todos los mensajes aparecerán en la
sesión Putty.

Figura 25: Reinicio previo al comienzo de la instalación paquete Junos.

3.3.4.8.

Es más que probable que se produzcan varios reinicios. En la
sesión Putty empezará a aparecernos lo siguiente.


45


Figura 26: Captura del inicio de la instalación Junos con el programa Putty y a
través del puerto serie virtual.

3.3.4.9.

Una vez finalizada la instalación nos aparecerá el inicio de sesión y
ya habremos concluido la creación de la Oliva.

Figura 27: Arranque inicial de la Oliva con versión Junos 9.6R1.13.

46



3.3.5. Instalación 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 continuación
describimos los pasos para la instalación:

3.3.5.1.

Arrancamos la MV y esperaremos a que nos aparezca el login.
Recordar que no aparecerán los mensajes de información de
arranque ya que éstos están dirigidos hacia el puerto serie. Si
abrimos una sesión 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 configuración 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 instalación del paquete web.

root@oliva> request system software add /var/tmp/jweb-9.6R1.13-signed.tgz

3.3.5.4.

Nos aparecerán los mensajes de la instalación del paquete y nos
pedirá reiniciar el entorno de comandos cli.

48



Figura 29: Mensajes iniciales instalación paquete JWEB.

3.3.5.5.

Volvemos a acceder al router y ejecutamos otra vez el comando

show versión. 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 configuración 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 continuación 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 botón Test
Settings. Si la prueba NO ha sido satisfactoria, desinstalar el Virtualbox
y volverlo a instalar con la versión más reciente.

50



Figura 30: Ventana Preferences de GNS3: comprobación comunicación con
VirtualBox.

3.4.2. Una vez comprobada la configuración con VirtualBox, nos situamos en
la pestaña VirtualBox Guest. Definimos una nueva máquina virtual tal y
como mostramos a continuación. Recordar actualizar el listado de MV
del VirtualBox por medio del botón Refresh VM List. Guardamos nuestra
nueva máquina.


51


Figura 31: Ventana Preferences de GNS3: definición de las MV.

3.4.3. Ahora nos situamos en el menú, Editar/Symbol Manager. Se nos abrirá
una ventana donde crearemos un nuevo símbolo para nuestros
dispositivos Junos. Crearemos un nuevo símbolo tal y como mostramos
a continuación.

52



Figura 32: Administración de símbolos en GNS3.

3.5.

Comprobación de la Oliva JWeb Junos 9.6

Una vez hemos configurado el entorno del GNS3, nos quedaría comprobar que
tenemos acceso al cli de nuestro nuevo dispositivo Junos y que tenemos en
ejecución el entorno de configuración WEB Junos.

3.5.1. Creamos un nuevo escenario, seleccionamos nuestro nuevo símbolo 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 máquina 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 conexión
Conexión de área local.

Figura 35: Configuración de nodo: asignación de interfaces.
54



3.5.4. Apretamos el botón de agregar vínculos 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 sólo 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 máquina
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 vía Web.

3.5.7. Accedemos al router con el usuario webadmin y nos aparecerá el
entorno web.

56



Figura 38: Pantalla de configuración del router con el JWEB.

Una vez se ha finalizado por completo la creación de la máquina virtual con la
versión 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 anfitrión cuando tengamos en marcha varias MV
en ejecución. Antes no se puede disminuir porque si no la instalación del software
Junos nos hubiera dado un error por falta de memoria. Otro comportamiento
anómalo que se ha detectado y por ello nos obliga a ajustar el tamaño de la
memoria RAM es que si consumimos muchos recursos RAM en el sistema
anfitrión (varias Olivas en ejecución), dejando poca memoria para el SO anfitrión,
entonces es muy probable que alguna MV Oliva no nos arranque bien y se quede
bloqueada al inicio de su arranque.


57


3.6.

Instalación IOS Junos 10.4R1.9

En este apartado vamos a explicar los pasos para crear una Oliva con la versión
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 versión son idénticos que en la versión Junos 9.6,
por lo que se omitirá su explicación y desarrollo.

3.6.1. Instalación FreeBSD

Realizaremos los mismos pasos que en la versión anterior pero modificando los
siguientes parámetros:

3.6.1.1.

El tamaño del disco duro en VirtualBox será de 8GB.

Figura 39: Definición del tamaño del disco duro para una MV en
VirtualBox.
58



3.6.1.2.

Utilizaremos la misma distribución FreeBSD.

Figura 40: Propiedades de configuración de la MV para Junos 10.4.

3.6.1.3.

El tamaño de memoria RAM será de 512MB.

3.6.1.4.

Las particiones a crear tendrán el siguiente tamaño:
-

1GB para directorio raíz /.

-

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: Distribución del filesystem para Junos 10.4.

El resto de pasos será el mismo que en la versión 9.6.

3.6.2. Instalación Junos 10.4R1.9

Para la instalación del IOS Junos 10.4R1.9 crearemos un archivo ISO con los
siguientes ficheros:
60



•

jinstall-10.4R1.9-domestic-signed.tgz

•


Por lo demás, se seguirán las mismas indicaciones que en la versión 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 extraído del último fichero jinstall-

10.4R1.9-domestic.tgz, y sustituiremos una línea de código.
Empezaremos por el fichero +INSTALL y buscamos la siguiente
parte del código que se encuentra en la línea 2110:
Olive# edit ./+INSTALL

Nos desplazamos hasta la línea 2110 y dejamos la función 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 carácter # apretar shift+3.Para salir del editor apretar la
tecla ESC, leave editor y luego save changes.

Figura 43: Modificación archivo +INSTALL.

3.6.2.4.

Ahora realizamos la misma operación en el fichero +REQUIRE.

Olive# edit ./+REQUIRE

Nos desplazamos hasta la línea 2110 y dejamos la función 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 carácter # 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 instalación paquete Junos 10.4.

3.6.2.8.

Una vez hayamos reiniciado la MV, empezará la instalación y
veremos la traza en el terminal Putty.

Figura 45: Proceso de instalación 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. Instalación JWeb Junos10.4

Para la instalación del paquete JWEB 10.4R1.9 realizaremos los mismos pasos
que para la versión 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 instalación del paquete web.

root@oliva> request system software add /var/tmp/jweb-10.4R1.9signed.tgz

3.6.3.3.

Nos aparecerán los mensajes de la instalación del paquete y nos
pedirá reiniciar el entorno de comandos cli.

Figura 46: Proceso de instalación paquete JWEB 10.4.
66



3.6.3.4.

Volvemos a acceder al router y ejecutamos otra vez el comando

show versión. 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 configuración y activamos el servicio
HTTP.

[edit]
root@oliva# set system services web-management http interface em0.0
[edit]

67


commit complete

3.7.

Comprobación 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 versión 9.6 y añadir un
nuevo dispositivo con Junos 10.4.

3.7.1. Accedemos al GNS3, Editar/Preferencias, y añadimos 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: Configuración 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 configuración via Web Junos 10.4.

70



4.

Lab 1: Fundamentos de Routing

Este laboratorio demuestra la configuración y monitorización del nivel 3 de routing
en dispositivos que ejecutan el sistema operativo JUNOS bajo el emulador GNS3.
En esta práctica se utilizará la línea de comandos (CLI) para configurar y
monitorizar interfaces, rutas estáticas y OSPF. Durante todas estas tareas de
configuración, conseguiremos familiarizarnos con la descripción 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 necesitarán los siguientes
elementos:
•

5 Maquinas Virtual Box (MVB) con el SO JUNOS.

•

4 MVB con el SO Linux.


71


Los requerimientos mínimos en cuanto al Hardware/Software de la máquina
anfitriona para poder emular las máquinas virtuales serán:
•

Intel/AMD con cuatro núcleos a 2.4 GHz.

•

3GB de memoria RAM.

•

Windows XP, preferiblemente Ubuntu 12.x.

Para completar este laboratorio se realizarán las siguientes tareas:
•

Configurar y verificar el correcto funcionamiento de las interfaces de red.

•

Configurar y monitorizar las rutas estáticas.

•

Configurar y monitorizar OSPF.

Parte 1: Configuración y Monitorización de Interfaces

En esta parte se configurarán las interfaces de red del equipo asignado. Se
verificará que las interfaces están funcionando correctamente y que el sistema
añade 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.

Cuestión: ¿Cuál es la dirección de gestión asignada a tu PC?
Como ejemplo, si tenemos asignado el equipo srxA1, la dirección IP de la
interface de salida hacia el PC de gestión será 10.210.14.131/27
perteneciendo a la subred 10.210.14.128/27. Por lo tanto, la IP de nuestro
PC de gestión 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

Cuestión: ¿Qué tabla de enrutamiento es la que se muestra con este
comando?
La salida debería 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
continuación:
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

Cuestión: ¿Qué entradas de rutas están presentes en la tabla inet.0?
En la tabla debe aparecer una única entrada DIRECT y otra LOCAL.
Ambas rutas están asociadas a la interface em0. La ruta DIRECT coincide

73


con la dirección IP asignada a la interface em0 mientras que la ruta LOCAL
coincide con la red de gestión.

1.3.

Accede al modo configuración y situarse en el nivel [edit interfaces].
lab@srxA1> configure
[edit]
lab@srxA1# edit interfaces
[edit interfaces]
lab@srxA1#

1.4.

Según el diagrama de red, configura las interfaces de tu equipo asignado.
Utiliza la VLAN-ID según 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
etiquetación 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 configuración.

1.5.

Mostrar la configuración de las interfaces y asegurarse de que coinciden
con el diagrama de red de este laboratorio. Una vez estemos seguros de
que dicha configuración es la correcta, ejecutar el comando commit-andquit para activar la configuración 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



Cuestión: ¿Qué significan los estados ADMIN y LINK en las interfaces
recientemente configuradas?
El estado ADMIN se corresponde al estado lógico que tiene actualmente la
interface pudiendo actuar sobre él activándolo o deshabilitándolo.
El estado LINK se corresponde al estado físico 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 añadidas.
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

Cuestión: ¿La tabla de enrutamiento muestra una entrada para cada una
de las interfaces y redes conectadas directamente?
La respuesta debería de ser sí.

Cuestión: ¿Cuál 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.

Cuestión: ¿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 están
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
!!!!!!!!!!!!!!!!!!!!!!!!!
Cuestión: ¿Son correctos los ping?
Si no son correctos comprobar la configuración.

Parte 2: Configuración y Monitorización de Rutas Estáticas

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
Cuestión: ¿Qué indica el resultado del ping?
Nos indica que no existe ninguna ruta al host referenciado.

Cuestión: Basándose en el diagrama, ¿Qué dirección IP debería 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 configuración y definir una ruta estática. Utilizar la IP del
paso anterior como el next-hop para la ruta estática por defecto.
lab@srxA1> configure
[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 estática añadida 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
Cuestión: ¿Se muestra ahora una ruta valida hacia la IP del host Internet?
Si, en este punto la ruta estática por defecto debería estar activa y todos
los destinos que no tengan una ruta más específica utilizarán la ruta por
defecto.

Cuestión: ¿Cuál es la preferencia de la ruta estática 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
Cuestión: ¿Ha funcionado el ping esta vez?
Sí.

2.5.

Añadir una ruta estática para la dirección 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 estáticas para permitir una conectividad
total hacia las subredes remotas y direcciones de loopback dentro de tu
área asignada. Utilizar la dirección IP asignada al ruter opuesto utilizando
la subred 172.20.66.0/30 como el next-hop en las rutas estáticas 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 dirección IP asignada al ruter opuesto en la subred
172.20.77.0/30 como qualified-next-hop para las rutas estáticas añadidas
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 configuración para revisar las rutas definidas. Una vez
comprobadas activar la configuración 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

Implementación de GNS3 para simulación de redes

Implementación de GNS3 para simulación de redes

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Implementación de GNS3 para simulación de redes

Similar a Implementación de GNS3 para simulación de redes (20)

Último

Último (20)

Implementación de GNS3 para simulación de redes