Upload
julio-jornet-monteverde
View
8.434
Download
23
Embed Size (px)
DESCRIPTION
Implementación de los laboratorios JNCIA de Juniper con la herramienta de simulación GNS3
Citation preview
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
2 Estudio e implementación de la herramienta de simulación de redes GNS3
Página en blanco intencionadamente
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 3
Í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. Virtual PC ................................................................................................22
2.4.4.2. Routers actuando como PC ....................................................................23
2.4.4.3. Virtualizar un PC con VirtualBox .............................................................23
2.5. Emulación de Routers .......................................................................... 24
2.5.1. Router de código abierto: XORP ............................................................................. 24
2.5.2. Sistema Vyatta ........................................................................................................... 26
2.6. Análisis de rendimiento: QEMU vs VirtualBox ................................... 27
3. 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
Máster Universitario en Ingeniería de Telecomunicación - UA
4 Estudio e implementación de la herramienta de simulación de redes GNS3
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. Comprobación de la Oliva JWeb Junos 10.4 ......................................68
4. 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
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 5
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
Máster Universitario en Ingeniería de Telecomunicación - UA
6 Estudio e implementación de la herramienta de simulación de redes GNS3
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
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 7
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
Máster Universitario en Ingeniería de Telecomunicación - UA
8 Estudio e implementación de la herramienta de simulación de redes GNS3
Página en blanco intencionadamente
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 9
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
10 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 11
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
12 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 13
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
Máster Universitario en Ingeniería de Telecomunicación - UA
14 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 15
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
Máster Universitario en Ingeniería de Telecomunicación - UA
16 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 17
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
18 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 19
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
20 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 21
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
22 Estudio e implementación de la herramienta de simulación de redes GNS3
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
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 23
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
Máster Universitario en Ingeniería de Telecomunicación - UA
24 Estudio e implementación de la herramienta de simulación de redes GNS3
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
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 25
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
26 Estudio e implementación de la herramienta de simulación de redes GNS3
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
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 27
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
28 Estudio e implementación de la herramienta de simulación de redes GNS3
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
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 29
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.
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.
0,00
200,00
400,00
600,00
800,00
1000,00
UBUNTU W7 64b
TMA VB
TMA QEMU
Tiempo Medio de Arranque (Seg.)
Máster Universitario en Ingeniería de Telecomunicación - UA
30 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
0
0,5
1
1,5
2
UBUNTU W7 64b
Load MEM
0,00%
10,00%
20,00%
30,00%
UBUNTU W7 64b
% CPU
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 31
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
32 Estudio e implementación de la herramienta de simulación de redes GNS3
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/ISO-
IMAGES/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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 33
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
34 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 35
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
36 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 37
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
38 Estudio e implementación de la herramienta de simulación de redes GNS3
Figura 15: Menú de distribuciones FreeBSD.
3.3.1.9. En el siguiente menú elegimos el medio donde está nuestra distribu-
ció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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 39
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
40 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 41
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
42 Estudio e implementación de la herramienta de simulación de redes GNS3
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:
• jinstall-9.6R1.13-export-signed.tgz
• jweb-9.6R1.13-signed.tgz
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 43
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
Máster Universitario en Ingeniería de Telecomunicación - UA
44 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 45
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
46 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 47
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:
• jweb-9.6R1.13-signed.tgz
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).
Máster Universitario en Ingeniería de Telecomunicación - UA
48 Estudio e implementación de la herramienta de simulación de redes GNS3
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 plain-text-password New password: Retype 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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 49
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
50 Estudio e implementación de la herramienta de simulación de redes GNS3
root@oliva> configure Entering configuration mode [edit] root@oliva# set system services web-management http interface em0.0 [edit] root@oliva# commit and-quit commit complete Exiting configuration mode 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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 51
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
52 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 53
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
54 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 55
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.
root@oliva> configure Entering configuration mode [edit] root@oliva# set interfaces em0 unit 0 family inet address 192.168.1.200/24 [edit] root@oliva# commit and-quit commit complete Exiting configuration mode root@oliva> show interfaces terse Interface Admin Link Proto Local Remote dsc up up em0 up up
Máster Universitario en Ingeniería de Telecomunicación - UA
56 Estudio e implementación de la herramienta de simulación de redes GNS3
em0.0 up up inet 10.10.10.1/24 em1 up down em2 up down em3 up down gre up up ipip up up lo0 up up lo0.16384 up up inet 127.0.0.1 --> 0/0 lo0.16385 up up inet lsi up up mtun up up pimd up up pime up up tap up up 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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 57
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
58 Estudio e implementación de la herramienta de simulación de redes GNS3
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 labora-
torios 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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 59
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
60 Estudio e implementación de la herramienta de simulación de redes GNS3
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:
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 61
• jinstall-10.4R1.9-domestic-signed.tgz
• jweb-10.4R1.9-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.
Máster Universitario en Ingeniería de Telecomunicación - UA
62 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 63
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 jinstall-
olive.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
Máster Universitario en Ingeniería de Telecomunicación - UA
64 Estudio e implementación de la herramienta de simulación de redes GNS3
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
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 65
--- JUNOS 10.4R1.9 built 2010-12-04 09:20:43 UTC root@% cli root> show version Model: olive JUNOS Base OS boot [10.4R1.9] JUNOS Base OS Software Suite [10.4R1.9] JUNOS Kernel Software Suite [10.4R1.9] JUNOS Crypto Software Suite [10.4R1.9] JUNOS Packet Forwarding Engine Support (M/T Common) [10.4R1.9] JUNOS Packet Forwarding Engine Support (M20/M40) [10.4R1.9] JUNOS Online Documentation [10.4R1.9] JUNOS Voice Services Container package [10.4R1.9] JUNOS Border Gateway Function package [10.4R1.9] JUNOS Services AACL Container package [10.4R1.9] JUNOS Services LL-PDF Container package [10.4R1.9] JUNOS Services PTSP Container package [10.4R1.9] JUNOS Services Stateful Firewall [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 AppId Services [10.4R1.9] JUNOS IDP Services [10.4R1.9] JUNOS Runtime Software Suite [10.4R1.9] JUNOS Routing 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 Entering configuration mode [edit]
Máster Universitario en Ingeniería de Telecomunicación - UA
66 Estudio e implementación de la herramienta de simulación de redes GNS3
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 adminweb class super-user authentication plain-text-password New password: Retype new password: [edit] root# commit and-quit commit complete Exiting configuration mode
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.9-signed.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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 67
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 Base OS boot [10.4R1.9] JUNOS Base OS Software Suite [10.4R1.9] JUNOS Kernel Software Suite [10.4R1.9] JUNOS Crypto Software Suite [10.4R1.9] JUNOS Packet Forwarding Engine Support (M/T Common) [10.4R1.9] JUNOS Packet Forwarding Engine Support (M20/M40) [10.4R1.9] JUNOS Online Documentation [10.4R1.9] JUNOS Voice Services Container package [10.4R1.9] JUNOS Border Gateway Function package [10.4R1.9] JUNOS Services AACL Container package [10.4R1.9] JUNOS Services LL-PDF Container package [10.4R1.9] JUNOS Services PTSP Container package [10.4R1.9] JUNOS Services Stateful Firewall [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 AppId Services [10.4R1.9] JUNOS IDP Services [10.4R1.9] JUNOS Runtime Software Suite [10.4R1.9] JUNOS Routing 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.
root@oliva> configure Entering configuration mode [edit] root@oliva# set system services web-management http interface em0.0 [edit] root@oliva# commit and-quit
Máster Universitario en Ingeniería de Telecomunicación - UA
68 Estudio e implementación de la herramienta de simulación de redes GNS3
commit complete Exiting configuration mode
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 69
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.
root@oliva> configure Entering configuration mode [edit] root@oliva# set interfaces em0 unit 0 family inet address 192.168.1.210/24 [edit] root@oliva# commit and-quit commit complete Exiting configuration mode
3.7.4. Ahora comprobamos con un navegador que tenemos acceso al entorno
Web.
Máster Universitario en Ingeniería de Telecomunicación - UA
70 Estudio e implementación de la herramienta de simulación de redes GNS3
Figura 49: Pantalla de bienvenida JWEB 10.4.
3.7.5. Accedemos al sistema con el usuario creado anteriormente y verifica-
mos el acceso.
Figura 50: Pantalla configuración via Web Junos 10.4.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 71
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
72 Estudio e implementación de la herramienta de simulación de redes GNS3
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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 73
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 inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 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) + = Active Route, - = Last Active, * = Both 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) + = Active Route, - = Last Active, * = Both 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) + = Active Route, - = Last Active, * = Both 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
Máster Universitario en Ingeniería de Telecomunicación - UA
74 Estudio e implementación de la herramienta de simulación de redes GNS3
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 Entering configuration mode [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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 75
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-and-quit 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;
Máster Universitario en Ingeniería de Telecomunicación - UA
76 Estudio e implementación de la herramienta de simulación de redes GNS3
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 Exiting configuration mode 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 Proto Local Remote dsc up up em0 up up em0.0 up up inet 10.210.14.131/27 em1 up up em1.0 up up inet 172.20.77.1/30 em2 up up em2.0 up up inet 172.20.66.1/30 em3 up up em3.0 up up inet 172.18.1.2/30 em4 up up em4.101 up up inet 172.20.101.1/24 em4.32767 up up gre up up ipip up up lo0 up up lo0.0 up up inet 192.168.1.1 --> 0/0 lo0.16384 up up inet 127.0.0.1 --> 0/0 lo0.16385 up up inet lsi up up mtun up up pimd up up pime up up tap up up
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 77
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 inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.210.14.128/27 *[Direct/0] 02:17:46 > via em0.0 10.210.14.131/32 *[Local/0] 02:17:50 Local via em-0.0 172.18.1.0/30 *[Direct/0] 00:02:03 > via em-3.0 172.18.1.2/32 *[Local/0] 00:02:03 Local via em-3.0 172.20.66.0/30 *[Direct/0] 00:02:03 > via em-2.0 172.20.66.1/32 *[Local/0] 00:02:03 Local via em-2.0 172.20.77.0/30 *[Direct/0] 00:02:03 > via em-1.0 172.20.77.1/32 *[Local/0] 00:02:03 Local via em-1.0 172.20.101.0/24 *[Direct/0] 00:02:03 > via em-4.101 172.20.101.1/32 *[Local/0] 00:02:03 Local via em-4.101 192.168.1.1/32 *[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)
Máster Universitario en Ingeniería de Telecomunicación - UA
78 Estudio e implementación de la herramienta de simulación de redes GNS3
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 !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.20.66.2 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.776/6.841/29.045/4.672 ms lab@srxA1> ping 172.20.77.x rapid count 25 PING 172.20.77.2 (172.20.77.2): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.20.77.2 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.817/7.077/27.688/4.360 ms lab@srxA1> ping 172.20.10v.10 rapid count 25 PING 172.20.101.10 (172.20.101.10): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.20.101.10 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.499/4.644/6.253/0.871 ms 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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 79
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 ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ^C --- 172.31.15.1 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss 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 Entering configuration mode [edit] lab@srxA1# edit routing-options [edit routing-options] lab@srxA1# set static route 0/0 next-hop 172.18.x.1 [edit routing-options] lab@srxA1#
2.3. Activar la nueva ruta estática añadida y ejecutar el comando run show route 172.31.15.1.
[edit routing-options] lab@srxA1# commit commit complete
Máster Universitario en Ingeniería de Telecomunicación - UA
80 Estudio e implementación de la herramienta de simulación de redes GNS3
[edit routing-options] lab@srxA1# run show route 172.31.15.1 inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 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.
[edit routing-options] 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 64 bytes from 172.31.15.1: icmp_seq=1 ttl=64 time=3.558 ms 64 bytes from 172.31.15.1: icmp_seq=2 ttl=64 time=4.889 ms 64 bytes from 172.31.15.1: icmp_seq=3 ttl=64 time=3.727 ms 64 bytes from 172.31.15.1: icmp_seq=4 ttl=64 time=16.563 ms 64 bytes from 172.31.15.1: icmp_seq=5 ttl=64 time=4.260 ms ^C --- 172.31.15.1 ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.558/6.407/16.563/4.588 ms 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.
[edit routing-options] lab@srxA1# set static route 192.168.x.2/32 next-hop 172.20.10v.10
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 81
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.
[edit routing-options] lab@srxA1# set static route 192.168.x.1/32 next-hop 172.20.66.x [edit routing-options] lab@srxA1# set static route 192.168.x.2/32 next-hop 172.20.66.x [edit routing-options] 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.
[edit routing-options] lab@srxA1# set static route 192.168.x.1/32 qualified-next-hop 172.20.77.x preference 6 [edit routing-options] lab@srxA1# set static route 192.168.x.2/32 qualified-next-hop 172.20.77.x preference 6 [edit routing-options] 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.
[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 {
Máster Universitario en Ingeniería de Telecomunicación - UA
82 Estudio e implementación de la herramienta de simulación de redes GNS3
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; qualified-next-hop 172.20.77.2 {
preference 6; }
} route 172.20.102.0/24 {
next-hop 172.20.66.2; qualified-next-hop 172.20.77.2 {
preference 6; }
} } [edit routing-options] lab@srxA1# commit and-quit commit complete Exiting configuration mode lab@srxA1>
2.9. Ejecutar el comando show route protocol static para ver las rutas
estáticas actuales en la tabla de enrutamiento de nuestro dispositivo.
lab@srxA1> show route protocol static inet.0: 16 destinations, 19 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 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
Cuestión: ¿Cuántas rutas estáticas se muestran?
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 83
Se deberían mostrar cinco rutas estáticas.
Cuestión: ¿Se muestran varios next-hops en cada subred remota o
loopbacks? ¿Qué next-hop está activo? ¿Por qué?
Se deberían 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 deberían 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.
lab@srxA1> ping 192.168.x.1 rapid count 25 PING 192.168.2.1 (192.168.2.1): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 192.168.2.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.714/6.018/13.400/1.758 ms lab@srxA1> ping 192.168.1.2 rapid count 25 PING 192.168.1.2 (192.168.1.2): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 192.168.1.2 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.598/5.839/35.017/6.038 ms lab@srxA1> ping 192.168.2.2 rapid count 25 PING 192.168.2.2 (192.168.2.2): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 192.168.2.2 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.241/5.953/27.162/4.406 ms Cuestión: ¿Se realizaron correctamente los pings?
Debería ser afirmativo, si no repasar la configuración.
Máster Universitario en Ingeniería de Telecomunicación - UA
84 Estudio e implementación de la herramienta de simulación de redes GNS3
Parte 3: Configuración y Monitorización 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 realizarán algunas tareas de comprobación para asegurar que
OSPF funciona correctamente.
3.1. Acceder al modo de configuración y navegar hasta el nivel [edit protocols
ospf].
lab@srxA1> configure Entering configuration mode [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 configuración resultante.
Nota: Recuerda especificar la unidad lógica apropiada. Si no se especifica,
Junos OS asumirá por defecto la unidad lógica 0.
[edit protocols ospf] lab@srxA1# set area 0 interface em1.0 [edit protocols ospf] lab@srxA1# set area 0 interface em2.0 [edit protocols ospf] lab@srxA1# set area 0 interface em4.10v [edit protocols ospf] lab@srxA1# set area 0 interface lo0.0 [edit protocols ospf] lab@srxA1# show
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 85
area 0.0.0.0 { interface em1.0; interface em2.0; interface em4.101; interface lo0.0;
}
Cuestión: Con la configuración OSPF introducida, ¿Cuántas adyacencias
OSPF se deberían formar entre vecinos?
Aunque tengamos cuatro interfaces presentes en la configuración, sólo tres
de estas interfaces serán capaces de crear adyacencias OSPF entre
vecinos. La interface loopback lo0 no puede crear ninguna adyacencia.
3.2. Activar la configuración 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.
[edit protocols ospf] lab@srxA1# commit commit complete [edit protocols ospf] lab@srxA1# run show ospf neighbor Address Interface State ID Pri Dead 172.20.77.2 em1.0 Full 192.168.2.1 128 37 172.20.66.2 em2.0 Full 192.168.2.1 128 37 172.20.101.10 em4.101 Full 192.168.1.2 128 39 Cuestión: ¿Qué estado muestran las adyacencias entre vecinos OSPF?
El estado de los tres vecinos OSPF debería 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.
Máster Universitario en Ingeniería de Telecomunicación - UA
86 Estudio e implementación de la herramienta de simulación de redes GNS3
[edit protocols ospf] lab@srxA1# run show route protocol ospf inet.0: 17 destinations, 24 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.20.102.0/24 [OSPF/10] 00:01:33, metric 2
to 172.20.77.2 via em1.0 > to 172.20.66.2 via em2.0
192.168.1.2/32 [OSPF/10] 00:02:14, metric 1 > to 172.20.101.10 via em4.101
192.168.2.1/32 [OSPF/10] 00:01:33, metric 1 to 172.20.77.2 via em1.0 > to 172.20.66.2 via em2.0
192.168.2.2/32 [OSPF/10] 00:01:33, metric 2 to 172.20.77.2 via em1.0 > to 172.20.66.2 via em2.0
224.0.0.5/32 *[OSPF/10] 00:02:24, metric 1 MultiRecv
Cuestión: ¿Están activas todas las rutas OSPF para cada subred destino o
loopback?
No, todas las rutas OSPF para las subredes destino y loopback no están
activas (no tienen el * al inicio de la línea). Esto es debido a que la
preferencia para OSPF tiene un valor de 10 mientras si recordamos, las
rutas estáticas tienen un valor de preferencia de 5 y por lo tanto las hacen
más preferibles que las rutas OSPF.
3.4. Borrar todas las rutas estáticas utilizadas en el diagrama, excepto las rutas
estáticas por defecto utilizadas para el tráfico hacia Internet.
[edit protocols ospf] lab@srxA1# top edit routing-options [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;
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 87
qualified-next-hop 172.20.77.2 { preference 6;
} } route 192.168.2.2/32 {
next-hop 172.20.66.2; qualified-next-hop 172.20.77.2 {
preference 6; }
} route 172.22.102.0/24 {
next-hop 172.20.66.2; qualified-next-hop 172.20.77.2 {
preference 6; }
} } [edit routing-options] lab@srxA1# delete static route 192.168.1.2/32 [edit routing-options] lab@srxA1# delete static route 192.168.x.1/32 [edit routing-options] lab@srxA1# delete static route 192.168.2.2/32 [edit routing-options] lab@srxA1# delete static route 172.20.10v.0/24 [edit routing-options] lab@srxA1# show static {
route 0.0.0.0/0 next-hop 172.18.1.1; }
3.5. Activar la configuración y volver al modo operación. Ejecutar el comando
show route protocol ospf para verificar que las rutas OSPF están activas.
[edit routing-options] lab@srxA1# commit and-quit commit complete Exiting configuration mode lab@srxA1> show route protocol ospf inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
Máster Universitario en Ingeniería de Telecomunicación - UA
88 Estudio e implementación de la herramienta de simulación de redes GNS3
+ = Active Route, - = Last Active, * = Both 172.20.102.0/24 *[OSPF/10] 00:07:13, metric 2
to 172.20.77.2 via em1.0 > to 172.20.66.2 via em2.0
192.168.1.2/32 *[OSPF/10] 00:07:54, metric 1 > to 172.20.101.10 via em4.101
192.168.2.1/32 *[OSPF/10] 00:07:13, metric 1 to 172.20.77.2 via em1.0 > to 172.20.66.2 via em2.0
192.168.2.2/32 *[OSPF/10] 00:07:13, metric 2 to 172.20.77.2 via em1.0 > to 172.20.66.2 via em2.0
224.0.0.5/32 *[OSPF/10] 00:08:04, metric 1 MultiRecv lab@srxA1>
Cuestión: ¿Están 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 están
activas ya que tienen el *.
3.6. Realizar ping a las direcciones loopback de todos los routers del diagrama
y verificar la accesibilidad.
lab@srxA1> ping 192.168.1.2 rapid count 25 PING 192.168.1.2 (192.168.1.2): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 192.168.1.2 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.445/4.646/9.481/1.217 ms lab@srxA1> ping 192.168.x.1 rapid count 25 PING 192.168.2.1 (192.168.2.1): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 192.168.2.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.736/5.888/11.097/1.327 ms lab@srxA1> ping 192.168.2.2 rapid count 25 PING 192.168.2.2 (192.168.2.2): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 89
--- 192.168.2.2 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.069/7.120/54.837/9.810 ms lab@srxA1>
Parte 4: Guardar configuraciones
Si queremos conservar las configuraciones de los routers, tenemos dos maneras
de realizarlo. La más sencilla es la siguiente:
A. Salimos del entorno CLI con el comando exit. Observar que el prompt ha
cambiado y ahora es %. A continuación 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 configuración del router. Cada vez que
realizamos un commit, se guarda la configuración en el archivo
juniper.conf.gz guardando las últimas 9 configuraciones más recientes. Los
ficheros están comprimidos en el formato gz por lo que tendremos que
utilizar la herramienta gunzip para extraer el fichero de configuración
juniper.conf.
lab@srxA1% ls -l total 24 drwxrwxr-x 2 root wheel 512 May 2 17:20 .snap -rw-r----- 1 root wheel 1505 Jun 17 12:18 juniper.conf.gz -rw-r----- 1 root wheel 547 Jun 17 12:18 juniper.conf.1.gz -rw-r----- 1 root wheel 558 Jun 17 11:55 juniper.conf.2.gz -rw-r----- 1 root wheel 523 Jun 17 11:55 juniper.conf.3.gz ------S--- 1 root wheel 32 Jun 13 17:15 juniper.conf.md5 root@srxA1% gunzip juniper.conf.gz root@srxA1% ls -l total 24
Máster Universitario en Ingeniería de Telecomunicación - UA
90 Estudio e implementación de la herramienta de simulación de redes GNS3
drwxrwxr-x 2 root wheel 512 May 2 17:20 .snap -rw-r----- 1 root wheel 1505 Jun 17 12:18 juniper.conf -rw-r----- 1 root wheel 547 Jun 17 12:18 juniper.conf.1.gz -rw-r----- 1 root wheel 558 Jun 17 11:55 juniper.conf.2.gz -rw-r----- 1 root wheel 523 Jun 17 11:55 juniper.conf.3.gz ------S--- 1 root wheel 32 Jun 13 17:15 juniper.conf.md5 root@srxA1%
La manera más fácil de extraer la configuración es realizando un
copy/paste del archivo de configuración 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;
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 91
} } } 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; }
Máster Universitario en Ingeniería de Telecomunicación - UA
92 Estudio e implementación de la herramienta de simulación de redes GNS3
} } root@srxA1%
Guardamos dicha configuración en un fichero de texto y repetimos esta
operación para cada uno de los routers de nuestro diagrama.
La otra opción para guardar las configuraciones es más compleja.
B. Se trata de añadir una nueva conexión entre uno de los routers que
tenemos en el diagrama y nuestro equipo anfitrión. Esto se puede realizar
con el objeto NUBE de GNS3 y posteriormente definiendo en este objeto la
interface de nuestro equipo anfitrión que será la que se utilizará para la
comunicación. Con esta configuración lo que haremos será conectar
nuestro equipo físico con las MV de nuestro diagrama de red
Como ejemplo vamos a añadir una Nube en el router srxA1 y configurar la
interface.
Figura 52: Integración nodo de interconexión al escenario.
Hacemos doble click en la nube y accedemos a la configuración de este
objeto. Seleccionamos en el listado Generic Interfaces NIO la interface que
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 93
queremos utilizar (normalmente la conexión local Ethernet RJ45) y la
añadimos quedándonos tal y como se muestra a continuación.
Figura 53: Ventana configuración nodo de interconexión.
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 través 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 máquina anfitriona.
Máster Universitario en Ingeniería de Telecomunicación - UA
94 Estudio e implementación de la herramienta de simulación de redes GNS3
Figura 54: Ventana principal de Cisco TFTP Server.
Desde el router que queremos guardar el fichero de configuración, salimos
del modo CLI y nos situamos en el directorio /config. Ahora nos
conectaremos al servidor TFTP que tenemos corriendo en nuestra máquina
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> 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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 95
Figura 55: Logs de recepción de ficheros en el servidor TFTP.
En este momento ya habremos conseguido el fichero de configuración de
nuestro dispositivo en nuestra máquina anfitriona. Ahora lo que hay que
hacer es ir a cada uno de nuestros routers e ir conectándonos vía TFTP e ir
enviando los ficheros de configuración. Acordarse de renombra los ficheros
para no sobrescribirlos.
Máster Universitario en Ingeniería de Telecomunicación - UA
96 Estudio e implementación de la herramienta de simulación de redes GNS3
Página en blanco intencionadamente
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 97
5. Lab 2: Políticas de Routing
Este laboratorio demuestra la configuración y monitorización de las Políticas de
Enrutamiento 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
definir, aplicar y monitorizar las Políticas de Enrutamiento. Durante todas estas
tareas de configuración, conseguiremos familiarizarnos con la descripción de los
contenidos dichas políticas.
Se ha implementado una modificación del escenario original: se ha sustituido la
MV Linux que estaba asociada al router srxA1 por una interconexión directa a la
máquina anfitriona para facilitar el backup de los archivos de configuración de
todos los dispositivos. El objeto Nube tiene configurada la interface local generada
por Virtual Box y ello nos permite la comunicación entre el escenario de
simulación y la máquina anfitriona local. Cuando necesitemos realizar alguna
verificación de comunicación con ping simplemente tendremos que ejecutar la
línea de comandos Windows (CMD) o Linux y ejecutar el ping.
Figura 56: Escenario del laboratorio Politicas de Routing.
Máster Universitario en Ingeniería de Telecomunicación - UA
98 Estudio e implementación de la herramienta de simulación de redes GNS3
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 línea que define la conexión del em0 del router [[VBOX srxA1]].
Para implementar el escenario del laboratorio se necesitarán los siguientes
elementos:
• 5 Maquinas Virtual Box (MVB) con el SO JUNOS.
• 1 MVB con el SO Linux.
• 1 Nodo de Interconexión a la máquina anfitriona.
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 monitorizar las Políticas de enrutamiento.
• Configurar el acceso al Servidor TFTP desde todos los dispositivos.
Parte 1: Preparación del Sistema y Verificación
En esta parte se realizarán modificaciones a la configuración existente y se
verificará el funcionamiento. En esta parte del laboratorio, nos referiremos al
diagrama de red del Laboratorio 2.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 99
1.1. Acceder al modo de configuración y situarse en el nivel [edit protocols
ospf]. lab@srxA1> configure Entering configuration mode [edit] lab@srxA1# edit protocols ospf [edit protocols ospf] lab@srxA1#
1.2. Borrar la interface perteneciente a la VLAN de la configuración OSPF y
activar los cambios.
[edit protocols ospf] lab@srxA1# show area 0.0.0.0 {
interface em1.0; interface em2.0; interface em4.101; interface lo0.0;
} [edit protocols ospf] lab@srxA-1# delete area 0 interface em4.10v [edit protocols ospf] lab@srxA-1# commit commit complete
1.3. Configurar las tres subredes en el router vr10X utilizando la interface em1 y
asignándole tres IPs.
[edit] lab@ vr101# set interfaces em1 unit 0 family inet address 172.21.0.1/24 [edit] lab@ vr101# set interfaces em1 unit 0 family inet address 172.21.1.1/24 [edit] lab@ vr101# set interfaces em1 unit 0 family inet address 172.21.2.1/24 [edit] lab@srxA-1# commit
Máster Universitario en Ingeniería de Telecomunicación - UA
100 Estudio e implementación de la herramienta de simulación de redes GNS3
commit complete [edit] lab@vr101# run show interfaces terse Interface Admin Link Proto Local Remote 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 --> 0/0 lo0.16384 up up inet 127.0.0.1 --> 0/0 lo0.16385 up up inet lsi up up mtun up up pimd up up pime up up tap up up
1.4. Situarse en el nivel jerárquico [edit routing-options]. Definir una ruta
estática par cada una de las tres subredes conectadas al router vr10X.
[edit protocols ospf] lab@srxA1# top edit routing-options [edit routing-options] lab@srxA1# set static route 172.2x.0.0/24 next-hop 172.20.10v.10 [edit routing-options] lab@srxA1# set static route 172.2x.1.0/24 next-hop 172.20.10v.10 [edit routing-options] lab@srxA1# set static route 172.2x.2.0/24 next-hop 172.20.10v.10 [edit routing-options] lab@srxA1#
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 101
1.5. Ejecutar el comando show para mostrar los resultados de la configuración.
Una vez verificado, activar los cambios y volver al modo operación
utilizando el comando commit and-quit. [edit routing-options] 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;
} [edit routing-options] lab@srxA1# commit and-quit commit complete Exiting configuration mode lab@srxA1>
1.6. Ejecutar el comando show route protocol static para mostrar las rutas
estáticas 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 inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 01:30:15 > to 172.18.1.1 via em3.0 172.21.0.0/24 *[Static/5] 00:00:21 > to 172.20.101.10 via em4.101 172.21.1.0/24 *[Static/5] 00:00:21 > to 172.20.101.10 via em4.101 172.21.2.0/24 *[Static/5] 00:00:21 > to 172.20.101.10 via em4.101 Cuestión: ¿Están todas las rutas estáticas activas?
Deberían estarlo. Como se muestra en la salida, la ruta por defecto y las
tres rutas definidas deberían 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
Máster Universitario en Ingeniería de Telecomunicación - UA
102 Estudio e implementación de la herramienta de simulación de redes GNS3
PING 172.21.0.1 (172.21.0.1): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.21.0.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.613/5.812/31.180/5.299 ms lab@srxA1> ping 172.2x.1.1 rapid count 25 PING 172.21.1.1 (172.21.1.1): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.21.1.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.504/4.687/7.793/1.222 ms lab@srxA1> ping 172.2x.2.1 rapid count 25 PING 172.21.2.1 (172.21.2.1): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.21.2.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 3.704/6.512/55.396/10.040 ms Cuestión: ¿Los ping han sido correctos?
Deberían 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 State ID Pri Dead 172.20.77.2 em1.0 Full 192.168.2.1 128 39 172.20.66.2 em2.0 Full 192.168.2.1 128 32 Cuestión: ¿Cuántas adyacencias de vecinos OSPF hay ahora?
Existirán dos adyacencias, una proveniente de la interface em1.0 y la
segunda por la interface em2.0.Si no fuese así, repasar la configuración o
el estado de las interfaces.
Parte 2: Configurar y Monitorizar Políticas de Enrutamiento
En los siguientes apartados configuraremos y monitorizaremos las políticas de
enrutamiento. Primero crearemos una política de enrutamiento diseñada para
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 103
publicar rutas en OSPF. Lo siguiente será aplicar la política como una política
exportable situándonos en el nivel jerárquico [edit protocols ospf] para
configurarla. Luego verificaremos que la política está trabajando correctamente.
Veremos que las políticas 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 configuración es posible que
varíe 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 sólo
existe una entrada.
lab@srxA1> show route 0/0 exact inet.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 01:35:53 > to 172.18.1.1 via em3.0
2.2. Acceder al modo de configuración y situarse en el nivel [edit policy-options]. lab@srxA1> configure Entering configuration mode [edit] lab@srxA1# edit policy-options [edit policy-options] lab@srxA1#
2.2. Crear una nueva política llamada default-route que compruebe y acepte la
ruta estática por defecto existente. Utiliza la nomenclatura match-default-
static-route.
[edit policy-options] lab@srxA1# edit policy-statement default-route
Máster Universitario en Ingeniería de Telecomunicación - UA
104 Estudio e implementación de la herramienta de simulación de redes GNS3
[edit policy-options policy-statement default-route] lab@srxA1# set term match-default-static-route from protocol static [edit policy-options policy-statement default-route] lab@srxA1# set term match-default-static-route from route-filter 0/0 exact [edit policy-options policy-statement default-route] lab@srxA1# set term match-default-static-route then accept [edit policy-options policy-statement default-route] lab@srxA1#
2.3. Situarse en el nivel [edit protocols ospf] y aplicar la política definida como
una política OSPF exportable. Activar los cambios en la configuración.
[edit policy-options policy-statement default-route] lab@srxA1# top edit protocols ospf [edit protocols ospf] lab@srxA1# set export default-route [edit protocols ospf] lab@srxA1# commit commit complete [edit protocols ospf] lab@srxA1#
2.4. En este paso se requiere coordinación entre los grupos de prácticas 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 también observan la ruta OSPF por defecto en su
dispositivo.
[edit protocols ospf] lab@srxA1# run show route 0/0 exact inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden)
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 105
+ = Active Route, - = Last Active, * = Both 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
Cuestión: ¿Tu router muestra una ruta por defecto OSPF en su tabla?
En este punto, ambos grupos deberían observar una ruta por defecto
OSPF. SI no es así, comprobar con el grupo remoto que se ha definido
correctamente la política.
Cuestión: ¿Está activa la ruta por defecto OSPF? ¿Por qué?
No está activa porque su valor de preferencia es mayor que la actual. La
política configurada inserta una ruta OSPF en la tabla pero se la considera
una ruta OSPF externa. Por esta razón la preferencia asignada es de 150
que pertenece a las rutas OSPF externas, para las rutas OSPF internas el
valor es de 10.
Cuestión: Basándonos en la entrada actual de ruta por defecto, ¿Qué
pasaría si la conexión física de nuestro dispositivo hacia Internet fallara?
La actual configuración proporciona redundancia para este fallo. Si la
conexión física entre el router srxA1 e Internet falla, el router marcará como
activa la ruta por defecto OSPF y empezará a enrutar tráfico.
2.5. Ejecutar el comando run show route protocol ospf para mostra las rutas
actuales de OSPF.
lab@srxA1# run show route protocol ospf inet.0: 17 destinations, 18 routes (17 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 [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 192.168.2.1/32 *[OSPF/10] 01:52:37, metric 1 > to 172.20.77.2 via em1.0
Máster Universitario en Ingeniería de Telecomunicación - UA
106 Estudio e implementación de la herramienta de simulación de redes GNS3
to 172.20.66.2 via em2.0 224.0.0.5/32 *[OSPF/10] 01:53:34, metric 1 MultiRecv
2.6. Volver al nivel de configuración [edit policy-options]. [edit protocols ospf] lab@srxA1# top edit policy-options [edit policy-options] lab@srxA1#
2.7. Definir una nueva política llamada interface-routes que compruebe y
acepte las rutas asociadas con las interfaces de tu dispositivo que
conectan a Internet y al router vr10X. Nómbrala como match-interface-
routes.
[edit policy-options] 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 [edit policy-options policy-statement interface-routes] lab@srxA1# set term match-interface-routes from route-filter 172.20.10v.0/24 exact [edit policy-options policy-statement interface-routes] lab@srxA1# set term match-interface-routes then accept [edit policy-options policy-statement interface-routes] lab@srxA1#
2.8. Situarse en el nivel [edit protocols ospf] y aplicar la política interface-
routes como una política OSPF exportable. Activar los cambios en la
configuración.
[edit policy-options policy-statement interface-routes] lab@srxA1# top edit protocols ospf [edit protocols ospf]
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 107
lab@srxA1# set export interface-routes [edit protocols ospf] 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.
[edit protocols ospf] lab@srxA1# run show route protocol ospf inet.0: 19 destinations, 20 routes (19 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 [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
172.18.2.0/30 *[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
172.20.102.0/24 *[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
192.168.2.1/32 *[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
224.0.0.5/32 *[OSPF/10] 00:39:20, metric 1 MultiRecv
Cuestión: ¿Se muestran las rutas OSPF esperadas en la tabla de
enrutamiento del vuestro router?
En este punto, en ambos routers se debería de mostrar las rutas OSPF
esperadas. Si no es así, comprobar en ambos routers la configuración de
las políticas.
2.10. Situarse en el nivel [edit policy-options].
Máster Universitario en Ingeniería de Telecomunicación - UA
108 Estudio e implementación de la herramienta de simulación de redes GNS3
[edit protocols ospf] lab@srxA1# top edit policy-options [edit policy-options] lab@srxA1#
2.11. Definir una tercera política llamada other-static-routes que compruebe y
acepte las tres rutas estáticas definidas recientemente hacia las subredes
conectadas al router vr10X. Defínela como match-other-static-routes.
[edit policy-options] 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 [edit policy-options policy-statement other-static-routes] lab@srxA1# set term match-other-static-routes from route-filter 172.2x.0.0/24 exact [edit policy-options policy-statement other-static-routes] lab@srxA1# set term match-other-static-routes from route-filter 172.2x.1.0/24 exact [edit policy-options policy-statement other-static-routes] lab@srxA1# set term match-other-static-routes from route-filter 172.2x.2.0/24 exact [edit policy-options policy-statement other-static-routes] lab@srxA1# set term match-other-static-routes then accept [edit policy-options policy-statement other-static-routes] lab@srxA1#
2.12. Situarse en el nivel [edit protocols ospf] y aplicar la política other-static-
routes como una política OSPF exportable. Activar los cambios en la
configuración.
[edit policy-options policy-statement other-static-routes] lab@srxA1# top edit protocols ospf [edit protocols ospf] lab@srxA1# set export other-static-routes
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 109
[edit protocols ospf] lab@srxA1# commit commit complete [edit protocols ospf] 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.
[edit protocols ospf] lab@srxA1# run show route protocol ospf inet.0: 22 destinations, 23 routes (22 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 [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
172.18.2.0/30 *[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
172.20.102.0/24 *[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
172.22.0.0/24 *[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
172.22.1.0/24 *[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
172.22.2.0/24 *[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
192.168.2.1/32 *[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
224.0.0.5/32 *[OSPF/10] 01:44:47, metric 1 MultiRecv
Máster Universitario en Ingeniería de Telecomunicación - UA
110 Estudio e implementación de la herramienta de simulación de redes GNS3
Cuestión: ¿El router muestra las rutas OSPF esperadas en la tabla de
enrutamiento?
En este punto, en ambos routers se debería de mostrar las rutas OSPF
esperadas. Si no es así, comprobar en ambos routers la configuración de
las políticas.
2.14. Situarse en el nivel [edit policy-options] y mostrar las políticas
configuradas.
[edit protocols ospf] lab@srxA1# top edit policy-options [edit policy-options] 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 {
route-filter 172.18.1.0/30 exact; route-filter 172.20.101.0/24 exact;
} then accept;
} } policy-statement other-static-routes {
term match-other-static-routes { from {
protocol static; route-filter 172.21.0.0/24 exact; route-filter 172.21.1.0/24 exact; route-filter 172.21.2.0/24 exact;
} then accept;
} }
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 111
[edit policy-options] lab@srxA1#
2.15. Utilizar las políticas existentes como una guía. Crear una nueva política
llamada ospf-export con tres términos distintos: match-default-route,
match-interface-routes, y match-other-static-routes. Comprobar que la
nueva política logra los mismos objetivos que las tres políticas existentes.
[edit policy-options] 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 [edit policy-options policy-statement ospf-export] lab@srxA1# set term match-default-static-route from route-filter 0/0 exact [edit policy-options policy-statement ospf-export] lab@srxA1# set term match-default-static-route then accept [edit policy-options policy-statement ospf-export] lab@srxA1# set term match-interface-routes from route-filter 172.18.x.0/30 exact [edit policy-options policy-statement ospf-export] lab@srxA1# set term match-interface-routes from route-filter 172.20.10v.0/24 exact [edit policy-options policy-statement ospf-export] lab@srxA1# set term match-interface-routes then accept [edit policy-options policy-statement ospf-export] lab@srxA1# set term match-other-static-routes from protocol static [edit policy-options policy-statement ospf-export] lab@srxA1# set term match-other-static-routes from route-filter 172.2x.0.0/24 exact [edit policy-options policy-statement ospf-export] lab@srxA1# set term match-other-static-routes from route-filter 172.2x.1.0/24 exact [edit policy-options policy-statement ospf-export]
Máster Universitario en Ingeniería de Telecomunicación - UA
112 Estudio e implementación de la herramienta de simulación de redes GNS3
lab@srxA1# set term match-other-static-routes from route-filter 172.2x.2.0/24 exact [edit policy-options policy-statement ospf-export] lab@srxA1# set term match-other-static-routes then accept [edit policy-options policy-statement ospf-export] lab@srxA1#
2.16. Situarse en el nivel [edit protocols ospf] y borrar las políticas exportadas
aplicadas.
[edit policy-options policy-statement ospf-export] lab@srxA1# top edit protocols ospf [edit protocols ospf] lab@srxA1# delete export [edit protocols ospf] lab@srxA1#
2.17. Configurar la política como una política OSPF exportable y aplicar los cambios. [edit protocols ospf] lab@srxA1# set export ospf-export [edit protocols ospf] 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.
[edit protocols ospf] lab@srxA1# run show route protocol ospf inet.0: 22 destinations, 23 routes (22 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 [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
172.18.2.0/30 *[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
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 113
172.20.102.0/24 *[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.22.0.0/24 *[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
172.22.1.0/24 *[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
172.22.2.0/24 *[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
192.168.2.1/32 *[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
224.0.0.5/32 *[OSPF/10] 01:52:26, metric 1 MultiRecv
Cuestión: ¿El router muestra las rutas OSPF esperadas en la tabla de
enrutamiento?
Se deberían mostrar las rutas OSPF configuradas. Comprobar en el equipo
remoto que aparecen las rutas OSPF definidas en las políticas.
2.19. Mostrar la configuración actual de las políticas configuradas hasta el
momento y de las que se están exportando.
[edit policy-options] 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 { route-filter 172.18.1.0/30 exact; route-filter 172.20.101.0/24 exact; } then accept;
Máster Universitario en Ingeniería de Telecomunicación - UA
114 Estudio e implementación de la herramienta de simulación de redes GNS3
} } policy-statement ospf-export { term match-default-static-route { from { protocol static; route-filter 0.0.0.0/0 exact; } then accept; } term match-interface-routes { from { route-filter 172.18.1.0/30 exact; route-filter 172.20.101.0/24 exact; } then accept; } term match-other-static-routes { from { protocol static; route-filter 172.21.0.0/24 exact; route-filter 172.21.1.0/24 exact; route-filter 172.21.2.0/24 exact; } then accept; } } policy-statement other-static-routes { term match-other-static-routes { from { protocol static; route-filter 172.21.0.0/24 exact; route-filter 172.21.1.0/24 exact; route-filter 172.21.2.0/24 exact; } then accept; } } [edit policy-options] lab@srxA1# top edit protocols ospf [edit protocols ospf] lab@srxA1# show export ospf-export; area 0.0.0.0 { interface em1.0;
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 115
interface em2.0; interface lo0.0; } [edit protocols ospf] lab@srxA1#
2.20. Volver al nivel y borrar las políticas de enrutamiento no utilizadas. Activar
los cambios y volver al modo de operación.
[edit protocols ospf] lab@srxA1# top edit policy-options [edit policy-options] lab@srxA1# delete policy-statement default-route [edit policy-options] lab@srxA1# delete policy-statement interface-routes [edit policy-options] lab@srxA1# delete policy-statement other-static-routes [edit policy-options] lab@srxA1# commit and-quit commit complete Exiting configuration mode lab@srxA1>
2.21. Mostrar cómo ha quedado la configuración actual de las políticas.
[edit policy-options] lab@srxA1# show policy-statement ospf-export { term match-default-static-route { from { protocol static; route-filter 0.0.0.0/0 exact; } then accept; } term match-interface-routes { from { route-filter 172.18.1.0/30 exact;
Máster Universitario en Ingeniería de Telecomunicación - UA
116 Estudio e implementación de la herramienta de simulación de redes GNS3
route-filter 172.20.101.0/24 exact; } then accept; } term match-other-static-routes { from { protocol static; route-filter 172.21.0.0/24 exact; route-filter 172.21.1.0/24 exact; route-filter 172.21.2.0/24 exact; } then accept; } } [edit policy-options] lab@srxA1#
Parte 3: Configurar servidor TFTP de copias de configuración
A continuación vamos a configurar el escenario del Lab 2 para que el Servidor
TFTP ubicado en nuestra máquina anfitriona, a través de la interconexión de
Nube, pueda ser accesible por todos los dispositivos del escenario y enviar la
configuración de cada dispositivo.
3.1. Realizar ping a la máquina 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 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 8671 0 0000 40 01 2cd2 172.18.2.2 10.210.14.129 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 8672 0 0000 40 01 2cd2 172.18.2.2 10.210.14.129
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 117
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 8673 0 0000 40 01 2cd2 172.18.2.2 10.210.14.129 ^C --- 10.210.14.129 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss Cuestión: ¿Por qué no contesta el ping la máquina 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 través de OSPF al no estar configurada en
la política de enrutamiento.
3.2. Añadir un nuevo término a la política OSPF del router srxA1 para que
se pueda exportar y aceptar con commit.
[edit policy-options policy-statement ospf-export] lab@srxA1# set term match-interface-routes from route-filter 10.210.14.128/27 exact [edit policy-options policy-statement ospf-export] 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 inet.0: 21 destinations, 22 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 [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 10.210.14.128/27 *[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 172.18.1.0/30 *[OSPF/150] 01:09:24, metric 0, tag 0 > to 172.20.77.1 via em1.0
Máster Universitario en Ingeniería de Telecomunicación - UA
118 Estudio e implementación de la herramienta de simulación de redes GNS3
to 172.20.66.1 via em2.0 172.20.101.0/24 *[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 172.21.0.0/24 *[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 172.21.1.0/24 *[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 172.21.2.0/24 *[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 192.168.1.1/32 *[OSPF/10] 01:09:24, metric 1 to 172.20.77.1 via em1.0 > to 172.20.66.1 via em2.0 224.0.0.5/32 *[OSPF/10] 01:09:42, metric 1 MultiRecv Cuestión: Si realizamos un ping a la IP del servidor TFTP 10.210.14.129
desde srxA2, ¿son satisfactorios?
Deberían de ser satisfactorios. Si no responde, comprobar que la
interface de la máquina anfitriona tiene configurada la puerta de enlace.
lab@srxA2> ping 10.210.14.129 rapid count 25 PING 10.210.14.129 (10.210.14.129): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 10.210.14.129 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.022/2.360/21.938/4.018 ms
3.4. Ahora ya tenemos acceso al servidor y podemos enviar el archivo de
configuración del router srxA2. Desde el modo de operación podemos
realizar un listado de los archivos tal y como se muestra a continuación.
Nos salimos del entorno cli y accedemos al sistema Linux. Luego
ejecutamos el comando que nos permite enviar el archivo de
configuración al servidor TFTP.
lab@srxA2> file list /config /config: .snap/
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 119
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.gz juniper.conf.1.gz juniper.conf.3.gz juniper.conf.md5 lab@srxA2% gunzip juniper.conf.gz lab@srxA2% ls .snap juniper.conf.1.gz juniper.conf.3.gz juniper.conf juniper.conf.2.gz juniper.conf.md5 lab@srxA2% ls -l total 28 drwxrwxr-x 2 root wheel 512 May 2 17:20 .snap -rw-r----- 1 root wheel 2460 Jul 2 13:23 juniper.conf -rw-r----- 1 root wheel 647 Jul 2 13:17 juniper.conf.1.gz -rw-r----- 1 root wheel 658 Jul 2 13:01 juniper.conf.2.gz -rw-r----- 1 root wheel 647 Jul 2 12:17 juniper.conf.3.gz ------S--- 1 root wheel 32 Jun 13 17:15 juniper.conf.md5 lab@srxA2% 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 2572 bytes in 0.0 seconds tftp> q
lab@srxA2%
3.5. Aunque no se ha tocado nada la configuración 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 ping: sendto: No route to host
Máster Universitario en Ingeniería de Telecomunicación - UA
120 Estudio e implementación de la herramienta de simulación de redes GNS3
ping: sendto: No route to host ping: sendto: No route to host ^C --- 10.210.14.129 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss Cuestión: ¿Por qué no contesta el ping la máquina 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 DR ID BDR ID Nbrs em1.0 DR 0.0.0.0 192.168.1.1 192.168.2.1 1 em2.0 DR 0.0.0.0 192.168.1.1 192.168.2.1 1 lo0.0 DR 0.0.0.0 192.168.1.1 0.0.0.0 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 estática en el router vr101 para poder
acceder al servidor.
lab@vr101> configure Entering configuration mode [edit] lab@vr101# edit routing-options [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; }
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 121
[edit routing-options] lab@vr101# set static route 10.210.14.128/27 next-hop 172.20.101.1 [edit routing-options] lab@vr101# commit commit complete [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; route 10.210.14.128/27 next-hop 172.20.101.1; } [edit routing-options] lab@vr101# run ping 10.210.14.129 rapid count 25 PING 10.210.14.129 (10.210.14.129): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 10.210.14.129 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.149/2.779/19.661/3.743 ms [edit routing-options] 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
configuración que para el vr101. Se configurará una nueva ruta estática
hacia el router srxA2.
lab@vr102> ping 10.210.14.129 PING 10.210.14.129 (10.210.14.129): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ^C
Máster Universitario en Ingeniería de Telecomunicación - UA
122 Estudio e implementación de la herramienta de simulación de redes GNS3
--- 10.210.14.129 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss lab@vr102> configure Entering configuration mode [edit] lab@vr102# edit routing-options [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; } [edit routing-options] lab@vr102# set static route 10.210.14.128/27 next-hop 172.20.102.1 [edit routing-options] lab@vr102# commit commit complete [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; route 10.210.14.128/27 next-hop 172.20.102.1; } [edit routing-options] lab@vr102# run ping 10.210.14.129 rapid count 25 PING 10.210.14.129 (10.210.14.129): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 10.210.14.129 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.522/2.257/4.092/0.766 ms [edit routing-options] 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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 123
6. Lab 3: Filtros Firewalls
Este laboratorio demuestra la configuración y monitorización de Filtros Firewall 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 definir, aplicar y
monitorizar los Filtros Firewall.
En este laboratorio, el software JUNOS de las máquinas virtuales se ha migrado a
la versión R10.1, el cual implementa el servicio SSH y además los filtros
funcionan perfectamente, cosa que no ocurre en la versión R9.6.
Hay que tener especial cuidado cuando interconectamos dos routers utilizando la
misma interface en ellos: como ya se ha descrito en el capítulo Troubleshooting
Junos, debemos asegurarnos que se han cambiado la direcciones MAC de las
interfaces a utilizar en la interconexión debido a la clonación de las MV, sino
provocará que no funcionen las líneas de interconexión ni los pings.
Figura 57: Escenario del laboratorio Filtros Firewalls.
Máster Universitario en Ingeniería de Telecomunicación - UA
124 Estudio e implementación de la herramienta de simulación de redes GNS3
Una vez hayamos arrancado las dos MV de los routers srxA1 y srxA2,
comprobaremos que la comunicación entre ellos funciona correctamente a través
de las dos líneas realizando varios pings entre ellos.
Para implementar el escenario del laboratorio se necesitarán los siguientes
elementos:
• 5 Maquinas Virtual Box (MVB) con el SO JUNOS (mínimo R10.1).
• 1 MVB con el SO Linux.
• 1 Nodo de Interconexión a la máquina anfitriona.
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 monitorizar Filtros Firewall.
• Configurar el acceso al Servidor TFTP desde todos los dispositivos.
Parte 1: Preparación del Sistema y Verificación
En esta parte se realizarán modificaciones a la configuración existente y se
verificará el funcionamiento. En esta parte del laboratorio, nos referiremos al
diagrama de red del Laboratorio 3.
1.1. Acceder por consola al router srxAX, acceder al modo de configuración y
situarse en el nivel [edit system services]. Se nos mostrarán los servicios
actualmente activados.
root @srxA1> configure
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 125
Entering configuration mode [edit] root @srxA1# edit system services [edit system services] root @srxA1# show [edit system services] root @srxA1# Cuestión: ¿Qué servicios hay actualmente habilitados?
Tal y como se observa, no existe ningún servicio al no mostrarse nada.
1.9. Habilitar el servicio ftp, telnet, ssh y activar la configuración con el
comando commit. [edit system services] lab root srxA1# set ftp [edit system services] root @srxA1# set telnet [edit system services] root @srxA1# set ssh [edit system services] root @srxA1# commit commit complete [edit system services] root @srxA1# show ftp; ssh; telnet; [edit system services] 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
Máster Universitario en Ingeniería de Telecomunicación - UA
126 Estudio e implementación de la herramienta de simulación de redes GNS3
New password: Retype 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 State ID Pri Dead 172.20.77.2 em1.0 Full 192.168.2.1 128 38 172.20.66.2 em2.0 Full 192.168.2.1 128 37 root@srxA1> Cuestión: ¿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 comunicación 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 !!!!!!!!!!!!!!!!!!!!!!!!! --- 192.168.1.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.549/0.942/2.118/0.325 ms root@vr101> ping 192.168.2.1 rapid count 25 PING 192.168.2.1 (192.168.2.1): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 192.168.2.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.805/1.932/2.799/0.587 ms
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 127
root@vr101> ping 172.31.15.1 rapid count 25 PING 172.31.15.1 (172.31.15.1): 56 data bytes ......................... --- 172.31.15.1 ping statistics --- 25 packets transmitted, 0 packets received, 100% packet loss Cuestión: ¿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 situación 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 inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.18.1.0/30 *[Direct/0] 00:51:03 > via em0.0 172.18.1.1/32 *[Local/0] 00:51:03 Local via em0.0 172.18.2.0/30 *[Direct/0] 00:51:00 > via em1.0 172.18.2.1/32 *[Local/0] 00:51:00 Local via em1.0 172.31.0.0/16 *[Direct/0] 00:50:59 > via em2.0 172.31.1.1/32 *[Local/0] 00:50:59 Local via em2.0 192.168.3.1/32 *[Direct/0] 00:51:03 > via lo0.0 root@INTERNET>
Máster Universitario en Ingeniería de Telecomunicación - UA
128 Estudio e implementación de la herramienta de simulación de redes GNS3
1.14. Acceder al modo de configuración y crear una ruta por defecto hacia el
router srxA1.
root@INTERNET> configure Entering configuration mode [edit] root@INTERNET# edit routing-options [edit routing-options] root@INTERNET# set static route 0/0 next-hop 172.18.1.2 [edit routing-options] root@INTERNET# commit and-quit commit complete Exiting configuration mode root@INTERNET>
1.15. Volver a comprobar la conectividad con un ping desde el router vr10X.
root@vr101> ping 172.31.15.1 rapid count 25 PING 172.31.15.1 (172.31.15.1): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.31.15.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.994/2.846/7.155/1.151 ms root@vr101>
1.16. Desde el router vr10X, intenta establecer una sesión FTP con tu dispositivo
asignado. Utiliza la dirección 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 Connected to 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.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 129
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> Cuestión: ¿Se ha establecido la sesión FTP?
Tal y como se muestra, la conexión con el servidor FTP se ha establecido
correctamente.
1.17. Desde el router vr10X, intenta establecer una sesión SSH con tu dispositivo
asignado. Utiliza la dirección de configurada en el router como la IP del
servidor SSH. Accede con el usuario lab para comprobar el servicio.
root@vr101> ssh [email protected] [email protected]'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 sesión TELNET con tu
dispositivo asignado. Utiliza la dirección 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... Connected to 192.168.1.1. Escape character is '^]'. srxA1 (ttyp0) login: lab Password:****** --- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC
Máster Universitario en Ingeniería de Telecomunicación - UA
130 Estudio e implementación de la herramienta de simulación de redes GNS3
lab@srxA1> exit Connection closed by foreign host. root@vr101> Cuestión: ¿Se ha establecido la sesión TELNET?
Tal y como se muestra, la conexión 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 inet.0: 23 destinations, 24 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[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 10.210.14.128/27 *[Direct/0] 02:48:07 > via em0.0 10.210.14.131/32 *[Local/0] 02:48:07 Local via em0.0 172.18.1.0/30 *[Direct/0] 02:48:05 > via em3.0 172.18.1.2/32 *[Local/0] 02:48:05 Local via em3.0 172.18.2.0/30 *[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 172.20.66.0/30 *[Direct/0] 02:48:06 > via em2.0 172.20.66.1/32 *[Local/0] 02:48:06 Local via em2.0 172.20.77.0/30 *[Direct/0] 02:48:07 > via em1.0 172.20.77.1/32 *[Local/0] 02:48:07 Local via em1.0
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 131
172.20.101.0/24 *[Direct/0] 00:04:37 > via em4.101 172.20.101.1/32 *[Local/0] 00:04:37 Local via em4.101 172.20.102.0/24 *[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 172.21.0.0/24 *[Static/5] 00:04:37 > to 172.20.101.10 via em4.101 172.21.1.0/24 *[Static/5] 00:04:37 > to 172.20.101.10 via em4.101 172.21.2.0/24 *[Static/5] 00:04:37 > to 172.20.101.10 via em4.101 172.22.0.0/24 *[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 172.22.1.0/24 *[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 172.22.2.0/24 *[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 192.168.1.1/32 *[Direct/0] 02:48:07 > via lo0.0 192.168.1.2/32 *[OSPF/10] 00:01:08, metric 1 > to 172.20.101.10 via em4.101 192.168.2.1/32 *[OSPF/10] 02:46:50, metric 1 > to 172.20.77.2 via em1.0 to 172.20.66.2 via em2.0 224.0.0.5/32 *[OSPF/10] 02:48:13, metric 1 MultiRecv Cuestión: ¿El router srxAX tiene en su tabla las entradas a las rutas con
destinos internos y externos?
Si, en este punto se debería 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.
Máster Universitario en Ingeniería de Telecomunicación - UA
132 Estudio e implementación de la herramienta de simulación de redes GNS3
2.1. Desde el router srxAX, accede al modo de configuración y sitúate en el
nivel [edit firewall]. [edit system services] root@srxA1# top edit firewall [edit firewall] root@srxA1#
2.2. Ejecuta el comando edit family ? y responde a la siguiente cuestión:
[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 Cuestión: Basándose en las opciones mostradas, ¿Qué opción se utiliza
para los filtros firewall IPv4?
La opción 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
creación 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 término denominado limit-icmp que solamente permita paquetes
ICMP entrantes desde la subred 10.210.0.0/16.
[edit firewall family inet filter protect-host] root@srxA1# set term limit-icmp from protocol icmp
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 133
[edit firewall family inet filter protect-host] root@srxA1# set term limit-icmp from source-address 10.210.0.0/16 [edit firewall family inet filter protect-host] root@srxA1# set term limit-icmp then accept
2.5. Crea un término denominado limit-ftp que solamente permita paquetes
FTP entrantes desde la subred 10.210.0.0/16.
[edit firewall family inet filter protect-host] root@srxA1# set term limit-ftp from protocol icmp [edit firewall family inet filter protect-host] root@srxA1# set term limit- ftp from source-address 10.210.0.0/16 [edit firewall family inet filter protect-host] root@srxA1# set term limit- ftp then accept
2.6. Crea un término denominado limit-ssh que solamente permita paquetes
SSH entrantes desde la subred 10.210.0.0/16.
[edit firewall family inet filter protect-host] root@srxA1# set term limit-ssh from protocol icmp [edit firewall family inet filter protect-host] root@srxA1# set term limit-ssh from source-address 10.210.0.0/16 [edit firewall family inet filter protect-host] root@srxA1# set term limit-ssh then accept
2.7. Crea un término denominado limit-telnet que solamente permita paquetes
Telnet entrantes desde la subred 10.210.0.0/16.
[edit firewall family inet filter protect-host] root@srxA1# set term limit-telnet from protocol tcp port telnet [edit firewall family inet filter protect-host] root@srxA1# set term limit-telnet from source-address 10.210.0.0/16 [edit firewall family inet filter protect-host] root@srxA1# set term limit-telnet then accept
Máster Universitario en Ingeniería de Telecomunicación - UA
134 Estudio e implementación de la herramienta de simulación de redes GNS3
2.8. Situarse en el nivel [edit interfaces lo0] y aplicar el filtro protect-host como un filtro de entrada. Confirmar la nueva configuración y activarla con
el comando commit. [edit firewall family inet filter protect-host] root@srxA1# top edit interfaces lo0 [edit firewall family inet filter protect-host] root@srxA1# set unit 0 family inet filter input protect-host [edit interfaces lo0] root@srxA1# commit commit complete [edit interfaces lo0] root@srxA1#
2.9. Desde el router vr10X utiliza el ping para comprobar la comunicación con
los direcciones loopback de los routers y del Host de Internet.
root@vr101> ping 192.168.1.1 rapid count 25 PING 192.168.1.1 (192.168.1.1): 56 data bytes ......................... --- 192.168.1.1 ping statistics --- 25 packets transmitted, 0 packets received, 100% packet loss root@vr101> ping 172.31.15.1 rapid count 25 PING 172.31.15.1 (172.31.15.1): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.31.15.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.879/2.561/6.438/0.859 ms root@vr101> Cuestión: ¿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
sólo permite tráfico ICMP de la subred 10.210.0.0/16, pero este filtro no
afecta al tráfico de tránsito, es decir al 172.31.15.1.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 135
2.10. Desde el router vr10X intenta establecer una sesión 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 [email protected] ^C root@vr101> telnet 192.168.1.1 Trying 192.168.1.1... ^C root@vr101> Cuestión: ¿Se han establecido las sesiones FTP, SSH y TELNET? Dada la
configuración actual, ¿este comportamiento es el esperado?
Tal y como se muestra en la captura, ninguna sesión 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 !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.31.15.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.994/2.846/7.155/1.151 ms lab> ftp 192.168.1.1 Connected to 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. ftp> bye 221 Goodbye. lab> ssh [email protected] [email protected]'s password:
Máster Universitario en Ingeniería de Telecomunicación - UA
136 Estudio e implementación de la herramienta de simulación de redes GNS3
--- JUNOS 10.1R1.8 built 2010-02-12 17:15:05 UTC lab@srxA1> quit Connection to 192.168.1.1 closed. lab> telnet 192.168.1.1 Trying 192.168.1.1... Connected to 192.168.1.1. Escape character is '^]'. srxA1 (ttyp0) login: lab Password:****** --- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC lab@srxA1> exit Connection closed by foreign host. Cuestión: ¿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.
[edit interfaces lo0] root@srxA1# run show ospf neighbor [edit interfaces lo0] root@srxA1# run show route inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 01:24:51 > to 172.18.1.1 via em3.0 10.210.14.128/28 *[Direct/0] 01:24:54 > via em0.0 10.210.14.131/32 *[Local/0] 01:24:54 Local via em0.0 172.18.1.0/30 *[Direct/0] 01:24:54 > via em3.0
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 137
172.18.1.2/32 *[Local/0] 01:24:54 Local via em3.0 172.20.66.0/30 *[Direct/0] 01:24:54 > via em2.0 172.20.66.1/32 *[Local/0] 01:24:54 Local via em2.0 172.20.77.0/30 *[Direct/0] 01:24:54 > via em1.0 172.20.77.1/32 *[Local/0] 01:24:54 Local via em1.0 172.20.101.0/24 *[Direct/0] 00:38:32 > via em4.101 172.20.101.1/32 *[Local/0] 00:38:32 Local via em4.101 172.21.0.0/24 *[Static/5] 00:38:32 > to 172.20.101.10 via em4.101 172.21.1.0/24 *[Static/5] 00:38:32 > to 172.20.101.10 via em4.101 172.21.2.0/24 *[Static/5] 00:38:32 > to 172.20.101.10 via em4.101 192.168.1.1/32 *[Direct/0] 01:24:54 > via lo0.0 224.0.0.5/32 *[OSPF/10] 01:24:56, metric 1 MultiRecv [edit interfaces lo0] root@srxA1# Cuestión: ¿El router muestra adyacencias de vecinos OSPF o rutas
aprendidas a través de OSPF? ¿Puedes explicar por qué?
Tal y como se muestra en la captura, el router no detecta ningún vecino
OSPF en este instante. La razón es debida al filtro firewall implementado
ya que limita el tráfico para protocolos específicos como OSPF.
Resolveremos esta situación en los siguientes pasos.
2.13. Desactiva el filtro firewall aplicado a la interface loopback y activa los
cambios.
[edit interfaces lo0] root@srxA1# deactivate unit 0 family inet filter [edit interfaces lo0] root@srxA1# show
Máster Universitario en Ingeniería de Telecomunicación - UA
138 Estudio e implementación de la herramienta de simulación de redes GNS3
unit 0 { family inet { inactive: filter { input protect-host; } address 192.168.1.1/32; } } [edit interfaces lo0] root@srxA1# commit commit complete [edit interfaces lo0] 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.
[edit interfaces lo0] root@srxA1# run show ospf neighbor Address Interface State ID Pri Dead 172.20.77.2 em1.0 Full 192.168.2.1 128 33 172.20.66.2 em2.0 Full 192.168.2.1 128 32 [edit interfaces lo0] root@srxA1# run show route inet.0: 18 destinations, 19 routes (18 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[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 10.210.14.128/28 *[Direct/0] 02:04:59 > via em0.0 10.210.14.131/32 *[Local/0] 02:04:59 Local via em0.0 172.18.1.0/30 *[Direct/0] 02:04:59 > via em3.0 172.18.1.2/32 *[Local/0] 02:04:59 Local via em3.0
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 139
172.18.2.0/30 *[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 172.20.66.0/30 *[Direct/0] 02:04:59 > via em2.0 172.20.66.1/32 *[Local/0] 02:04:59 Local via em2.0 172.20.77.0/30 *[Direct/0] 02:04:59 > via em1.0 172.20.77.1/32 *[Local/0] 02:04:59 Local via em1.0 172.20.101.0/24 *[Direct/0] 00:22:36 > via em4.101 172.20.101.1/32 *[Local/0] 00:22:36 Local via em4.101 172.20.102.0/24 *[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 172.21.0.0/24 *[Static/5] 00:22:36 > to 172.20.101.10 via em4.101 172.21.1.0/24 *[Static/5] 00:22:36 > to 172.20.101.10 via em4.101 172.21.2.0/24 *[Static/5] 00:22:36 > to 172.20.101.10 via em4.101 172.22.0.0/24 *[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 172.22.1.0/24 *[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 172.22.2.0/24 *[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 192.168.1.1/32 *[Direct/0] 02:04:59 > via lo0.0 192.168.2.1/32 *[OSPF/10] 00:22:21, metric 1 > to 172.20.77.2 via em1.0 to 172.20.66.2 via em2.0 224.0.0.5/32 *[OSPF/10] 02:05:01, metric 1 MultiRecv [edit interfaces lo0] root@srxA1# Cuestión: Con el filtro firewall desactivado, ¿vuelven a verse los vecinos
OSPF? ¿Y las rutas aprendidas de los vecinos OSPF?
Máster Universitario en Ingeniería de Telecomunicación - UA
140 Estudio e implementación de la herramienta de simulación de redes GNS3
Tal y como se muestra, en el router srxAX vuelven a aparecer las
adyacencias a los dos vecinos OSPF y también 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 tráfico utilizando el
termino else-accept que implícitamente permite todo el resto del tráfico.
Incluye un contador para cada término definido. Denomina cada uno de los
contadores count-X, donde X es el nombre del término asociado.
Nota: en la mayoría de implementaciones de filtros firewall, normalmente
se utiliza la acción discard más que la acción reject para evitar el envío de
notificaciones a los atacantes potenciales. En este laboratorio se podría
elegir la acción reject para simplificar la comprobación de las pruebas. En
este laboratorio utilizaremos la acción discard para cada término definido.
[edit interfaces lo0] root@srxA1# top edit firewall family inet filter protect-host [edit firewall family inet filter protect-host] root@srxA1# set term limit-icmp from source-address 0/0 [edit firewall family inet filter protect-host] root@srxA1# set term limit-icmp from source-address 10.210.0.0/16 except [edit firewall family inet filter protect-host] root@srxA1# set term limit-icmp then count count-limit-icmp [edit firewall family inet filter protect-host] root@srxA1# set term limit-icmp then discard [edit firewall family inet filter protect-host] root@srxA1# set term limit-ftp from source-address 0/0 [edit firewall family inet filter protect-host] root@srxA1# set term limit-ftp from source-address 10.210.0.0/16 except [edit firewall family inet filter protect-host] root@srxA1# set term limit-ftp then count count-limit-ftp
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 141
[edit firewall family inet filter protect-host] root@srxA1# set term limit-ftp then discard [edit firewall family inet filter protect-host] root@srxA1# set term limit-ssh from source-address 0/0 [edit firewall family inet filter protect-host] root@srxA1# set term limit-ssh from source-address 10.210.0.0/16 except [edit firewall family inet filter protect-host] root@srxA1# set term limit-ssh then count count-limit-ssh [edit firewall family inet filter protect-host] root@srxA1# set term limit-ssh then discard [edit firewall family inet filter protect-host] root@srxA1# set term limit-telnet from source-address 0/0 [edit firewall family inet filter protect-host] root@srxA1# set term limit-telnet from source-address 10.210.0.0/16 except [edit firewall family inet filter protect-host] root@srxA1# set term limit-telnet then count count-limit-telnet [edit firewall family inet filter protect-host] root@srxA1# set term limit-telnet then discard [edit firewall family inet filter protect-host] root@srxA1# set term else-accept then count count-else-accept [edit firewall family inet filter protect-host] root@srxA1# set term else-accept then accept [edit firewall family inet filter protect-host] 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;
Máster Universitario en Ingeniería de Telecomunicación - UA
142 Estudio e implementación de la herramienta de simulación de redes GNS3
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;
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 143
accept; } } [edit firewall family inet filter protect-host] 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 configuración.
[edit firewall family inet filter protect-host] root@srxA1# top edit interfaces lo0 [edit interfaces lo0] root@srxA1# activate unit 0 family inet filter [edit interfaces lo0] root@srxA1# show unit 0 { family inet { filter { input protect-host; } address 192.168.1.1/32; } } [edit interfaces lo0] root@srxA1# commit commit complete [edit interfaces lo0] 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.
[edit interfaces lo0] root@srxA1# run show ospf neighbor Address Interface State ID Pri Dead 172.20.77.2 em1.0 Full 192.168.2.1 128 36 172.20.66.2 em2.0 Full 192.168.2.1 128 39
Máster Universitario en Ingeniería de Telecomunicación - UA
144 Estudio e implementación de la herramienta de simulación de redes GNS3
[edit interfaces lo0] root@srxA1# run show route inet.0: 22 destinations, 23 routes (22 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[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 10.210.14.128/28 *[Direct/0] 02:43:20 > via em0.0 10.210.14.131/32 *[Local/0] 02:43:20 Local via em0.0 172.18.1.0/30 *[Direct/0] 02:43:20 > via em3.0 172.18.1.2/32 *[Local/0] 02:43:20 Local via em3.0 172.18.2.0/30 *[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 172.20.66.0/30 *[Direct/0] 02:43:20 > via em2.0 172.20.66.1/32 *[Local/0] 02:43:20 Local via em2.0 172.20.77.0/30 *[Direct/0] 02:43:20 > via em1.0 172.20.77.1/32 *[Local/0] 02:43:20 Local via em1.0 172.20.101.0/24 *[Direct/0] 00:01:18 > via em4.101 172.20.101.1/32 *[Local/0] 00:01:18 Local via em4.101 172.20.102.0/24 *[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 172.21.0.0/24 *[Static/5] 01:00:57 > to 172.20.101.10 via em4.101 172.21.1.0/24 *[Static/5] 01:00:57 > to 172.20.101.10 via em4.101 172.21.2.0/24 *[Static/5] 01:00:57 > to 172.20.101.10 via em4.101 172.22.0.0/24 *[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 172.22.1.0/24 *[OSPF/150] 00:40:44, metric 0, tag 0
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 145
to 172.20.77.2 via em1.0 > to 172.20.66.2 via em2.0 172.22.2.0/24 *[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 192.168.1.1/32 *[Direct/0] 02:43:20 > via lo0.0 192.168.2.1/32 *[OSPF/10] 01:00:42, metric 1 > to 172.20.77.2 via em1.0 to 172.20.66.2 via em2.0 224.0.0.5/32 *[OSPF/10] 02:43:22, metric 1 MultiRecv [edit interfaces lo0] root@srxA1# Cuestión: Con el filtro firewall actualizado y activado, ¿El router srxAX
todavía 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 comunicación.
root@vr101> ping 192.168.1.1 rapid count 25 PING 192.168.1.1 (192.168.1.1): 56 data bytes ......................... --- 192.168.1.1 ping statistics --- 25 packets transmitted, 0 packets received, 100% packet loss
2.19. Desde el router vr10X, intenta establecer una conexión FTP, SSH y
TELNET al router srxAX.
root@vr101> ftp 192.168.1.1 ^C root@vr101> ssh [email protected] ^C root@vr101> telnet 192.168.1.1 Trying 192.168.1.1... ^C
Máster Universitario en Ingeniería de Telecomunicación - UA
146 Estudio e implementación de la herramienta de simulación de redes GNS3
root@vr101> Cuestión: ¿Se han establecido las sesiones FTP, SSH y TELNET? Dada la
configuración actual, ¿este comportamiento es el esperado?
Tal y como se muestra en la captura, ninguna sesión 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 !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.31.15.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.856/2.611/6.723/1.315 ms lab> ftp 192.168.1.1 Connected to 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. ftp> bye 221 Goodbye. lab> ssh [email protected] [email protected]'s password: --- JUNOS 10.1R1.8 built 2010-02-12 17:15:05 UTC lab@srxA1> quit Connection to 192.168.1.1 closed. lab> telnet 192.168.1.1 Trying 192.168.1.1... Connected to 192.168.1.1. Escape character is '^]'. srxA1 (ttyp0)
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 147
login: lab Password:****** --- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC lab@srxA1> exit Connection closed by foreign host. Cuestión: ¿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.
[edit interfaces lo0] root@srxA1# run show firewall Filter: protect-host Counters: Name Bytes Packets count-else-accept 137938 1524 count-limit-ftp 256 4 count-limit-icmp 6720 80 count-limit-ssh 128 2 count-limit-telnet 128 2 Filter: __default_bpdu_filter__ [edit interfaces lo0] root@srxA1#
Cuestión: ¿Los contadores del filtro protect-host se incrementan?
Como podemos observar, sí que se incrementan los contadores y ninguno
tiene el contador a cero.
Máster Universitario en Ingeniería de Telecomunicación - UA
148 Estudio e implementación de la herramienta de simulación de redes GNS3
Parte 3: Configurar servidor TFTP de copias de configuración
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 continuación se muestran las configuraciones de los diferentes routers:
srxA1:
version 10.1R1.8; system { host-name srxA1; root-authentication { 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"; ## SECRET-DATA } } } services { ftp; ssh; telnet; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } }
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 149
} 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; }
Máster Universitario en Ingeniería de Telecomunicación - UA
150 Estudio e implementación de la herramienta de simulación de redes GNS3
} } } 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 { policy-statement ospf-export { term match-default-static-route { from { protocol static; route-filter 0.0.0.0/0 exact; } then accept; } term match-interface-routes { from { route-filter 172.18.1.0/30 exact; route-filter 172.20.101.0/24 exact; } then accept; } term match-other-static-routes { from { protocol static; route-filter 172.21.0.0/24 exact; route-filter 172.21.1.0/24 exact; route-filter 172.21.2.0/24 exact; } then accept; } }
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 151
} 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 { count count-limit-telnet; 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 {
Máster Universitario en Ingeniería de Telecomunicación - UA
152 Estudio e implementación de la herramienta de simulación de redes GNS3
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; accept; } } } } }
srxA2:
## Last changed: 2013-07-18 13:56:27 UTC version 10.1R1.8; system { host-name srxA2; root-authentication { 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 {
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 153
user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } } } 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 {
Máster Universitario en Ingeniería de Telecomunicación - UA
154 Estudio e implementación de la herramienta de simulación de redes GNS3
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 { policy-statement ospf-export { term match-default-static-route { from { protocol static; route-filter 0.0.0.0/0 exact; } then accept; } term match-interface-routes { from { route-filter 172.18.2.0/30 exact; route-filter 172.20.102.0/24 exact; } then accept; } term match-other-static-routes { from { protocol static; route-filter 172.22.0.0/24 exact; route-filter 172.22.1.0/24 exact; route-filter 172.22.2.0/24 exact;
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 155
} 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 { count count-limit-telnet; 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;
Máster Universitario en Ingeniería de Telecomunicación - UA
156 Estudio e implementación de la herramienta de simulación de redes GNS3
} } 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; accept; } } } } }
vr101:
## Last changed: 2013-07-18 11:26:18 UTC version 10.1R1.8; system { host-name vr101; root-authentication { encrypted-password "$1$Lla6AF1X$HDveKaSFJYQs6yJfR7wCw0"; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; }
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 157
} } 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
Máster Universitario en Ingeniería de Telecomunicación - UA
158 Estudio e implementación de la herramienta de simulación de redes GNS3
version 10.1R1.8; system { host-name vr102; root-authentication { encrypted-password "$1$JVkVKUrg$X6LDux9w1u2/qUblZHQpJ1"; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } } } 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 {
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 159
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 { root-authentication { encrypted-password "$1$vb1hM25o$kGBx4oqIME5Q9czGWav/70"; } services { telnet; } syslog { user * { any emergency; } file messages { any notice; authorization info; } file interactive-commands { interactive-commands any; } } } interfaces { em0 { unit 0 { family inet { address 172.18.1.1/30; } } } em1 {
Máster Universitario en Ingeniería de Telecomunicación - UA
160 Estudio e implementación de la herramienta de simulación de redes GNS3
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; } }
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 161
7. Lab 4: Clases de Servicios (CoS)
En este laboratorio se introduce la configuración básica de las Clases de Servicios
en dispositivos que ejecutan el sistema operativo JUNOS bajo el emulador GNS3.
Aunque más adelante se verá que no se pueden aplicar y ejecutar los Mapas de
Planificación 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 guía en un entorno real. La gran mayoría de los
comandos se pueden ejecutar y se añaden al fichero de configuración excepto el
apartado 2.4 que es el que genera el error. Se comentará más adelante.
En esta práctica se utilizará la línea 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 diseño del escenario en GNS3 quedará de la siguiente manera:
Máster Universitario en Ingeniería de Telecomunicación - UA
162 Estudio e implementación de la herramienta de simulación de redes GNS3
Figura 59: Escenario adaptado del laboratorio Clases de Servicios.
Para implementar el escenario del laboratorio se necesitarán los siguientes
elementos:
• 6 Maquinas Virtual Box (MVB) con el SO JUNOS (mínimo R10.1).
• 1 Nodo de Interconexión a la máquina anfitriona.
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:
• Preparar los routers y comprobar su funcionamiento.
• Configurar colas y mapas planificados.
• Configurar la clasificación multicampo.
• Verificar el funcionamiento de la clasificación multicampo.
• Configurar el comportamiento global redefiniendo reglas y clasificadores.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 163
Parte 1: Preparación del Sistema y Verificación
En esta parte se realizarán modificaciones a la configuración existente y se
verificará el funcionamiento. En esta parte del laboratorio, nos referiremos al
diagrama de red del Laboratorio 4.
1.1. Acceder por consola al router srxAX, acceder al modo de configuración y
situarse en el nivel [edit firewall] y borrar toda la configuración.
root @srxA1> configure Entering configuration mode [edit] root @srxA1# delete firewall
1.2. Ejecutar el comando delete interfaces lo0 unit 0 family inet filter para
borrar la aplicación 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 estáticas definidas.
[edit] root@srxA1# delete routing-options
Máster Universitario en Ingeniería de Telecomunicación - UA
164 Estudio e implementación de la herramienta de simulación de redes GNS3
1.6. Situarse en el nivel [edit interfaces] y configurar la interface lógica
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] root@srxA1# set em4 unit 201 family inet address 172.20.201.1/24
1.7. Muestra la actual configuración 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;
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 165
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 Entering configuration mode [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]
Máster Universitario en Ingeniería de Telecomunicación - UA
166 Estudio e implementación de la herramienta de simulación de redes GNS3
root@vr101# activate interfaces em0 [edit] root@vr101# commit and-quit commit complete Exiting configuration mode root@vr101> show interfaces terse | match em Interface Admin Link Proto Local 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 Exiting configuration mode 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
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 167
em2 up down em3 up down em4 up down root@vr201>
1.10. Desde el router srxAX utilizar el ping para comprobar la comunicación 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 !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.20.101.10 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.657/1.156/1.999/0.414 ms [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 !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.20.201.10 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.826/2.376/22.697/4.175 ms [edit interfaces] root@srxA1# Cuestión: ¿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 configuración actual para este nivel.
[edit interfaces] root@srxA1# top edit policy-options policy-statement ospf-export [edit policy-options policy-statement ospf-export] root@srxA1# show term match-default-static-route { from { protocol static; route-filter 0.0.0.0/0 exact; }
Máster Universitario en Ingeniería de Telecomunicación - UA
168 Estudio e implementación de la herramienta de simulación de redes GNS3
then accept; } term match-interface-routes { from { route-filter 172.18.1.0/30 exact; route-filter 172.20.101.0/24 exact; } then accept; } term match-other-static-routes { from { protocol static; route-filter 172.21.0.0/24 exact; route-filter 172.21.1.0/24 exact; route-filter 172.21.2.0/24 exact; } then accept; } [edit policy-options policy-statement ospf-export] root@srxA1#
1.12. Borrar los términos match-default-static-route y match-other-static-
routes.
[edit policy-options policy-statement ospf-export] root@srxA1# delete term match-default-static-route [edit policy-options policy-statement ospf-export] root@srxA1# delete term match-other-static-routes
1.13. Ejecutar el comando para ver el resultado de la configuración. Borrar el
término que representa la conexión a Internet.
[edit policy-options policy-statement ospf-export] root@srxA1# show term match-interface-routes { from { route-filter 172.18.1.0/30 exact; route-filter 172.20.101.0/24 exact; } then accept; }
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 169
[edit policy-options policy-statement ospf-export] root@srxA1# delete term match-interface-routes from route-filter 172.18.1.0/30 exact
1.14. Añadir una nueva ruta al término match-interface-routes para alcanzar la
nueva subred de la vlan 201.
[edit policy-options policy-statement ospf-export] root@srxA1# set term match-interface-routes from route-filter 172.20.201.0/24 exact [edit policy-options policy-statement ospf-export] root@srxA1# show term match-interface-routes { from { route-filter 172.20.101.0/24 exact; route-filter 172.20.201.0/24 exact; } then accept; } [edit policy-options policy-statement ospf-export] 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] root@srxA1# run show ospf neighbor 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 inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 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
Máster Universitario en Ingeniería de Telecomunicación - UA
170 Estudio e implementación de la herramienta de simulación de redes GNS3
192.168.2.1/32 *[OSPF/10] 00:20:24, metric 1 > to 172.20.77.2 via em1.0 224.0.0.5/32 *[OSPF/10] 00:51:11, metric 1 MultiRecv [edit] root@srxA1#
Cuestión: ¿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 comunicación
entre éstos.
root@vr101> ping 172.20.102.10 rapid count 25 PING 172.20.102.10 (172.20.102.10): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.20.102.10 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.811/2.291/3.904/0.453 ms root@vr201> ping 172.20.202.10 rapid count 25 PING 172.20.202.10 (172.20.202.10): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.20.202.10 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.443/4.532/39.986/7.512 ms root@vr202> ping 172.20.101.10 rapid count 25 PING 172.20.101.10 (172.20.101.10): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.20.101.10 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.483/2.304/4.584/0.713 ms root@vr102> ping 172.20.201.10 rapid count 25 PING 172.20.201.10 (172.20.201.10): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.20.201.10 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.553/2.328/4.640/0.636 ms
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 171
Cuestión: ¿Respondieron satisfactoriamente los pings?
Tal y como se muestra en la captura, todos los ping respondieron. Si no es
así, repasa la configuración y las rutas por defecto de los routers vr10x y
vr20X.
Parte 2: Configurando Colas y Mapas de Planificación
Por defecto, los dispositivos Junos asignan todo el tráfico a las clases best-effort y
network-control. Antes de poder asignar el tráfico a otra clase, se debe configurar
un mapa planificado para cada interface con planificadores para dichas clases. En
esta parte del laboratorio se asociarán las colas con las clases de envío y se
configurarán planificadores y mapas de planificación que se podrán aplicar a
todas las interfaces.
Utilizar la siguiente tabla como guía en esta parte:
Cola Clase de envío Ancho de Banda y
Tamaño Buffer (%) Prioridad
0 Best-effodt 40 Low
1 Admin 45 Medium-low
2 Voip 10 High
3 Network-control 5 Medium-high
2.1. Acceder al router srxAX y situarse en el nivel [edit class-of-service
forwarding-classes]. Configurar la clase de envío a su respectiva cola tal
y como se muestra en la tabla.
[edit policy-options policy-statement ospf-export] root@srxA1# top
Máster Universitario en Ingeniería de Telecomunicación - UA
172 Estudio e implementación de la herramienta de simulación de redes GNS3
[edit] root@srxA1# edit class-of-service forwarding-classes [edit class-of-service forwarding-classes] root@srxA1# set queue 1 admin [edit class-of-service forwarding-classes] root@srxA1# set queue 2 voip Cuestión: ¿Se deben definir las clases de envío best-effort y network-
control 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 envío utilizando los
parámetros 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 envío. [edit class-of-service forwarding-classes] 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 [edit class-of-service schedulers best-effort-sched] root@srxA1# set transmit-rate percent 40 [edit class-of-service schedulers best-effort-sched] root@srxA1# set priority low [edit class-of-service schedulers best-effort-sched] root@srxA1# up [edit class-of-service schedulers] root@srxA1# edit admin-sched [edit class-of-service schedulers admin-sched] root@srxA1# set buffer-size percent 45
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 173
[edit class-of-service schedulers admin-sched] root@srxA1# set transmit-rate percent 45 [edit class-of-service schedulers admin-sched] root@srxA1# set priority ? Possible completions: high low strict-high [edit class-of-service schedulers admin-sched] root@srxA1# set priority low [edit class-of-service schedulers admin-sched] root@srxA1# up [edit class-of-service schedulers] root@srxA1# edit voip-sched [edit class-of-service schedulers voip-sched] root@srxA1# set buffer-size percent 10 [edit class-of-service schedulers voip-sched] root@srxA1# set transmit-rate percent 10 [edit class-of-service schedulers voip-sched] root@srxA1# set priority high [edit class-of-service schedulers voip-sched] root@srxA1# up [edit class-of-service schedulers] root@srxA1# edit network-control-sched [edit class-of-service schedulers network-control-sched] root@srxA1# set buffer-size percent 5 [edit class-of-service schedulers network-control-sched] root@srxA1# set transmit-rate percent 5 [edit class-of-service schedulers network-control-sched] root@srxA1# set priority high [edit class-of-service schedulers network-control-sched] root@srxA1#
Máster Universitario en Ingeniería de Telecomunicación - UA
174 Estudio e implementación de la herramienta de simulación de redes GNS3
2.3. Configurar un mapa que se denomine my-sched-map que asocie cada
clase de envío con su correspondiente planificador. Guardaremos los
cambios generados en la configuración. Hasta este momento no se debe
producir ningún error y el router debe aceptar el commit. [edit class-of-service schedulers network-control-sched] 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 [edit class-of-service scheduler-maps my-sched-map] root@srxA1# set forwarding-class admin scheduler admin-sched [edit class-of-service scheduler-maps my-sched-map] root@srxA1# set forwarding-class voip scheduler voip-sched [edit class-of-service scheduler-maps my-sched-map] root@srxA1# set forwarding-class network-control scheduler network-control-sched [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 planificación 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 configuración con el comando delete.
[edit class-of-service interfaces] root@srxA1# edit interfaces [edit class-of-service interfaces] root@srxA1# set em1 scheduler-map my-sched-map
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 175
[edit class-of-service interfaces] root@srxA1# set em3 scheduler-map my-sched-map [edit class-of-service interfaces] root@srxA1# set em4 scheduler-map my-sched-map [edit interfaces] root@srxA1# commit and-quit [edit class-of-service interfaces] 'em1' Cannot configure class-of-service on interface em1. error: configuration check-out failed Cuestión: ¿Qué resultados negativos podríamos experimentar si erramos al
asignar un mapa a todas las interfaces?
Los dispositivos Junos podrían utilizar un planificador por defecto para que
el tráfico atraviese interfaces sin especificar. El planificador contiene buffers
para tráfico solamente en las colas asociadas con las clases best-effort y
network-control (colas 0 y 3). Por lo tanto, el tráfico que no sea el asociado
a éstas clases podría desecharse.
Parte 3: Configurando Clasificación Multicampo
En esta parte del laboratorio se configurará el router para colocar el tráfico en una
clase de envío 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.
[edit class-of-service interfaces] root@srxA1# top edit firewall family inet filter classify-traffic [edit firewall family inet filter classify-traffic] root@srxA1#
3.2. Crear un término denominado sip que asigne el tráfico SIP originado desde
la subred 172.20.10X.0/24 en la clase de envío voip. El tráfico SIP utiliza
UDP ó TCP y el puerto 5060.
Máster Universitario en Ingeniería de Telecomunicación - UA
176 Estudio e implementación de la herramienta de simulación de redes GNS3
[edit firewall family inet filter classify-traffic] root@srxA1# set term sip from source-address 172.20.101.0/24 [edit firewall family inet filter classify-traffic] root@srxA1# set term sip from protocol [tcp udp] port 5060 [edit firewall family inet filter classify-traffic] root@srxA1# set term sip then forwarding-class voip [edit firewall family inet filter classify-traffic] root@srxA1# set term sip then accept
3.3. Crear un término denominado rtp que asigne el tráfico SIP originado desde
la subred 172.20.10X.0/24 en la clase de envío voip. El tráfico RTP utiliza
UDP y el rango de puertos entre 16384-32767.
[edit firewall family inet filter classify-traffic] root@srxA1# set term rtp from source-address 172.20.101.0/24 [edit firewall family inet filter classify-traffic] root@srxA1# set term rtp from protocol udp port 16384-32767 [edit firewall family inet filter classify-traffic] root@srxA1# set term rtp then forwarding-class voip [edit firewall family inet filter classify-traffic] root@srxA1# set term rtp then accept
3.4. Crear un término denominado admin que asigne el tráfico con una
dirección origen perteneciente a la red asociada con el router vr20X en la
clase de envío admin.
[edit firewall family inet filter classify-traffic] root@srxA1# set term admin from source-address 172.20.201.0/24 [edit firewall family inet filter classify-traffic] root@srxA1# set term admin then forwarding-class admin [edit firewall family inet filter classify-traffic] root@srxA1# set term admin then accept
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 177
3.5. Crear un término denominado accept-all que acepte todo el tráfico y lo
asigne a la clase de envío por defecto.
[edit firewall family inet filter classify-traffic] 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 tráfico entrante. Ejecuta el comando commit and-quit para
activar los cambios en la configuración y volver al modo de operación.
[edit firewall family inet filter classify-traffic] 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] root@srxA1# commit and-quit commit complete Exiting configuration mode
Hasta aquí serían los pasos para configurar las Clases de Servicio en Junos y lo que se puede implementar con Olivas. Para verificar el correcto funcionamiento deberíamos poder activar completamente los Mapas de Planificación en las interfaces y después mostrar las estadísticas de tráfico de las colas con el comando show interface queue em0. Al no poder conseguirlo se ha omitido la parte de comprobación del laboratorio original.
Máster Universitario en Ingeniería de Telecomunicación - UA
178 Estudio e implementación de la herramienta de simulación de redes GNS3
Página en blanco intencionadamente
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 179
8. Lab 5: IPv6
Este laboratorio demuestra la configuración y monitorización de interfaces con IP
versión 6 (IPv6) sobre 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, rotas estáticas, OSPF básico y túneles GRE
(Generic Routing Encapsulation).
El diseño del escenario en GNS3 quedará de la siguiente manera:
Figura 60: Escenario del laboratorio IPv6.
Para implementar el escenario del laboratorio se necesitarán los siguientes
elementos:
• 3 Maquinas Virtual Box (MVB) con el SO JUNOS (mínimo R10.1).
• 1 Nodo de Interconexión a la máquina anfitriona.
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.
Máster Universitario en Ingeniería de Telecomunicación - UA
180 Estudio e implementación de la herramienta de simulación de redes GNS3
• 3GB de memoria RAM.
• Windows XP, preferiblemente Ubuntu 12.x.
Para completar este laboratorio se realizarán las siguientes tareas:
• Configurar y comprobar el funcionamiento de las interfaces IPv6.
• Configurar y monitorizar enrutamiento estático IPv6.
• Configurar y monitorizar OSPF con interfaces IPv6.
• Configurar una interface GRE para encapsular tráfico IPv6 sobre una red
IPv4.
Parte 1: Configurar y Monitorizar Interfaces
En esta parte se configurarán las interfaces de red en los dispositivos del
diagrama. Luego se comprobará que las interfaces están activas y que el sistema
añade las correspondientes entradas en la tabla de enrutamiento.
1.1. Acceder por consola al router srxAX, acceder al modo de configuración y
cargar la configuración por defecto de fábrica. Definir una contraseña para
el usuario root o no nos dejará guardar los cambios. root @srxA1> configure Entering configuration mode [edit] root @srxA1# load factory-default warning: activating factory configuration [edit] root@srxA1# set system root-authentication plain-text-password New password: Retype new password: [edit] root@srxA1# commit commit complete
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 181
1.2. Comprobar que todas las interfaces no están configuradas con el comando
run show interfaces terse.
[edit] root@srxA1# run show interfaces terse Interface Admin Link Proto Local Remote 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 127.0.0.1 --> 0/0 lo0.16385 up up inet 128.0.0.4 --> 0/0 inet6 fe80::a00:27ff:fe58:7da4 lsi up up mtun up up pimd up up pime up up pip0 up up pp0 up up tap up up [edit] root@srxA1#
1.3. Habilita los contadores IPv6 en el router utilizando el comando set forwarding-options family inet6 route-accounting. Activar la
configuración y salir del modo configuración.
[edit] root@srxA1# set forwarding-options family inet6 route-accounting [edit] root@srxA1# commit and quit commit complete
Máster Universitario en Ingeniería de Telecomunicación - UA
182 Estudio e implementación de la herramienta de simulación de redes GNS3
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> Cuestión: ¿Hay alguna ruta?
No existe ninguna ruta ya que aún no se ha configurado ninguna interface
con IPv6.
1.5. Configurar las interfaces del router srxAX según se indica en el diagrama.
Utilizar la unidad lógica unit 0 en todas las interfaces. Recuerda configurar
la interface loopback.
root@srxA1> configure Entering configuration mode [edit] root@srxA1# edit interfaces [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 configuración y comprobar que se han configurado
correctamente. Activar la configuración y salir del modo configuración. En
el momento que se configura la interface loopback con una dirección IPv6,
el router automáticamente habilita el tráfico IPv6.
[edit interfaces] root@srxA1# show
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 183
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] root@srxA1# commit and-quit commit complete Exiting configuration mode
1.7. Ejecutar el comando show interfaces terse para comprobar el estado
actual de las interfaces.
root@srxA1> show interfaces terse Interface Admin Link Proto Local 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
Máster Universitario en Ingeniería de Telecomunicación - UA
184 Estudio e implementación de la herramienta de simulación de redes GNS3
irb up up lo0 up up lo0.0 up up inet6 2001:192:168:1::1 fe80::a00:27ff:fe58:7da4 lo0.16384 up up inet 127.0.0.1 --> 0/0 lo0.16385 up up inet 128.0.0.4 --> 0/0 inet6 fe80::a00:27ff:fe58:7da4 lsi up up mtun up up pimd up up pime up up pip0 up up pp0 up up tap up up root@srxA1>
Cuestión: ¿Cuántas direcciones IPv6 están asociadas a cada una de las
interfaces?
Dos, la primera asociada a inet6 es la dirección configurada manualmente
y la segunda es la dirección EUI-64 de la interface local que se
corresponde a la dirección del nivel de enlace. Esta última dirección se
utiliza para descubrir vecinos, configuración automática de direcciones y
cuando no existen routers presentes.
Cuestión: ¿Cómo son las otras direcciones creadas en el router?
Se componen por el prefijo inicial FE80, que por definición corresponde a
una dirección unicast del enlace local, seguido de ceros y por último la
dirección EUI-64, compuesta por el valor 0A00 y la dirección 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) + = Active Route, - = Last Active, * = Both 2001:172:18:1::/64 *[Direct/0] 01:00:29
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 185
> via em2.0 2001:172:18:1::2/128 *[Local/0] 01:00:29 Local via em2.0 2001:172:20:66::/64 *[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> Cuestión: ¿Cuántas rutas se instalaron para cada una de las interfaces?
Dos, la primera se corresponde con la dirección configurada manualmente
y la segunda se corresponde a la dirección local que empieza por FE80.
Cuestión: ¿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 comunicación 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 !!!!!!!!!!!!!!!!!!!!!!!!!
Máster Universitario en Ingeniería de Telecomunicación - UA
186 Estudio e implementación de la herramienta de simulación de redes GNS3
--- 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 root@srxA1> ping 2001:172:18:1::1 rapid count 25 PING6(56=40+8+8 bytes) 2001:172:18:1::2 --> 2001:172:18:1::1 !!!!!!!!!!!!!!!!!!!!!!!!! --- 2001:172:18:1::1 ping6 statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/std-dev = 0.462/0.759/1.879/0.285 ms
Cuestión: ¿Han funcionado los pings?
Si, las interfaces vecinas han respondido a los pings. Si no es así, repasar
la configuración.
1.10. Ejecutar el comando show ipv6 neighbors.
root@srxA1> show ipv6 neighbors IPv6 Address Linklayer Address State Exp Rtr Secure Interface 2001:172:18:1::1 08:00:27:8a:02:76 stale 551 yes no em2.0 2001:172:20:66::2 08:00:27:69:b1:4a stale 559 yes no em1.0 root@srxA1>
Cuestión: ¿Cuántos vecinos nos aparecen?
Dos, que se corresponden a las interfaces vecinas que ve nuestro router
srxAX.
Parte 2: Configurando y Monitorizando Rutas Estáticas
En esta parte configuraremos y monitorizaremos una ruta estática IPv6 por
defecto.
2.1. Realiza un ping al Host de Internet que aparece en el diagrama.
root@srxA1> ping 2001:172:31:1::1 rapid count 25 PING6(56=40+8+8 bytes) 2001:192:168:1::1 --> 2001:172:31:1::1
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 187
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 --- 2001:172:31:1::1 ping6 statistics --- 5 packets transmitted, 0 packets received, 100% packet loss root@srxA1>
Cuestión: ¿Qué indica el resultado del ping?
No existe en la tabla de enrutamiento ninguna entrada a la subred indicada.
Cuestión: Basándose en el diagrama, ¿Qué dirección IP debería utilizarse
como next-hop para alcanzar el Host de Internet?
La dirección como next-hop debería ser 2001:172:18:1::1.
2.2. Acceder al modo configuración y definir una ruta estática por defecto. Para
ello, deberemos introducir una entrada en la tabla de enrutamiento IPv6,
RIB (Routing Information Table), denominada inet6.0. Utiliza la dirección 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 [edit routing-options rib inet6.0] root@srxA1#
2.3. Añadir redundancia con una segunda ruta estática por defecto.
[edit routing-options rib inet6.0] root@srxA1# set static route ::/0 next-hop 2001:172:20:66::1 [edit routing-options rib inet6.0] root@srxA1# show
Máster Universitario en Ingeniería de Telecomunicación - UA
188 Estudio e implementación de la herramienta de simulación de redes GNS3
static { route ::/0 next-hop [ 2001:172:18:1::1 2001:172:20:66::1 ]; } [edit routing-options rib inet6.0] root@srxA1# commit and-quit commit complete Exiting configuration mode 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 inet6.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both ::/0 *[Static/5] 01:46:44 > to 2001:172:18:1::1 via em2.0 Cuestión: ¿Existe alguna ruta valida hacia el Host de Internet?
Si, la ruta por defecto configurada.
Cuestión: ¿Cuál es el valor preference de la ruta estática 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 comunicación.
root@srxA1> ping 2001:172:31:15::1 rapid count 25 PING6(56=40+8+8 bytes) 2001:172:18:1::2 --> 2001:172:31:15::1 ......................... --- 2001:172:31:15::1 ping6 statistics --- 25 packets transmitted, 0 packets received, 100% packet loss Cuestión: ¿Fueron satisfactorios los pings?
No. Vamos a tratar de solucionar el problema.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 189
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>
Cuestión: ¿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 contestación por
parte del destinatario, (echo reply).
2.7. Configurar en el Host de Internet la ruta por defecto hacia la dirección
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 comunicación.
Máster Universitario en Ingeniería de Telecomunicación - UA
190 Estudio e implementación de la herramienta de simulación de redes GNS3
root@srxA1> ping 2001:172:31:15::1 rapid count 25 PING6(56=40+8+8 bytes) 2001:172:18:1::2 --> 2001:172:31:15::1 !!!!!!!!!!!!!!!!!!!!!!!!! --- 2001:172:31:15::1 ping6 statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/std-dev = 1.385/2.047/3.142/0.437 ms Cuestión: ¿Fueron satisfactorios los pings?
Sí. En caso contrario repasar la configuración 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 configuración 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 versión ya que soporta IPv6.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 191
3.1. Definir el área OSPF 0 e incluir la interface interna que conecta los dos
routers srxA1 y srxA2. Asegurarse de que también se incluyen las
interfaces loopback. Recordar que OSPFv3 solamente soporta IPv6.
3.2. Acceder al modo de configuración y configurar el router ID.
root@srxA1> configure Entering configuration mode [edit] root@srxA1# set routing-options router-id 1.1.1.1
3.3. Situarse en el nivel [protocols ospf3] y añadir las interfaces al área 0.
[edit] root@srxA1# edit protocols ospf3 [edit protocols ospf3] root@srxA1# set area 0 interface lo0.0 passive [edit protocols ospf3] root@srxA1# set area 0 interface em1.0 [edit protocols ospf3] root@srxA1# Cuestión: Con la configuración que acabamos de realizar, ¿Cuántas
adyacencias entre vecinos OSPF se crearán?
En principio sólo una.
3.4. Activar la configuración con el comando commit and quit y salir al modo
de operación. 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>
Máster Universitario en Ingeniería de Telecomunicación - UA
192 Estudio e implementación de la herramienta de simulación de redes GNS3
Cuestión: ¿Qué estado tienen las adyacencias de vecinos OSPF?
El estado FULL.
Cuestión: ¿Por qué el router ID se muestra como una dirección IPv4?
Porque el router ID, por definición de OSPF3, es un identificador de 32 bits
y por lo tanto se utiliza la notación IPv4.
3.5. Ejecutar el comando show ospf3 interface para ver las interfaces que
están ejecutando OSPF3 y el detalle.
root@srxA1> show ospf3 interface Interface State Area DR ID BDR ID Nbrs em1.0 BDR 0.0.0.0 2.2.2.2 1.1.1.1 1 lo0.0 DR 0.0.0.0 1.1.1.1 0.0.0.0 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 Protection type: None 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 inet6.0: 11 destinations, 12 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 193
2001:192:168:2::1/128 *[OSPF3/10] 00:22:40, metric 1 > to fe80::a00:27ff:fe9d:b3de via em1.0 ff02::5/128 *[OSPF3/10] 00:23:41, metric 1 MultiRecv root@srxA1> Cuestión: ¿Cuál es la dirección FF02::5/128?
Esta dirección es la dirección multicast de OSPF3.
Parte 4: Tunneling IPv6 sobre IPv4 utilizando Encapsulación GRE
En esta parte del laboratorio vamos a configurar un túnel GRE para enviar el
tráfico IPv6 sobre un enlace IPv4. El túnel lo vamos a crear desde el router srxA1
hasta el srxA2, pasando a través del router INTERNET. El diagrama de esta parte
es diferente al anterior siendo como se muestra a continuación.
Figura 62: Escenario para la configuración del túnel GRE.
4.1. Primero, borrar las estancias protocols y routing-options del modo de
configuración. Después borrar la configuración de las interfaces em1, em2
y loopback.
Máster Universitario en Ingeniería de Telecomunicación - UA
194 Estudio e implementación de la herramienta de simulación de redes GNS3
root@srxA1> configure Entering configuration mode [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 estática hacia la el loopback
remoto utilizando la dirección de la interface em2 como next-hop.
[edit] root@srxA1# edit interfaces [edit interfaces] root@srxA1# set lo0 unit 0 family inet address 192.168.1.1/32 [edit interfaces] root@srxA1# set em2 unit 0 family inet address 172.18.1.2/30 [edit interfaces] root@srxA1# top edit routing-options [edit routing-options] root@srxA1# set static route 192.168.2.1 next-hop 172.18.1.1 [edit routing-options] root@srxA1# commit commit complete
4.3. Acceder al router INTERNET y borrar la configuración de las interfaces
em1 y em2. Configurar de nuevo dichas interfaces con las nuevas
direcciones IPv4.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 195
root@INTERNET> configure Entering configuration mode [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 [edit routing-options] root@INTERNET# set static route 192.168.1.1 next-hop 172.18.1.2 [edit routing-options] root@INTERNET# set static route 192.168.2.1 next-hop 172.18.2.2 [edit routing-options] root@INTERNET# commit commit complete
4.4. En este punto, ahora tenemos una red básica IPv4. Comprueba la
comunicación 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 !!!!!!!!!!!!!!!!!!!!!!!!! --- 192.168.2.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.949/1.581/2.341/0.356 ms Cuestión: ¿Fueron satisfactorios los pings?
Máster Universitario en Ingeniería de Telecomunicación - UA
196 Estudio e implementación de la herramienta de simulación de redes GNS3
Si. En caso contrario repasar la configuración de los dispositivos.
4.5. Definir una nueva interface GRE y un túnel utilizando las direcciones IP
asignadas a la interface loopback de tu dispositivo como la dirección origen
y la IP asignada a la interface loopback remota como la dirección destino.
Utilizar la unidad lógica 0.
[edit routing-options] 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 Local Remote cbp0 up up demux0 up up dsc up up em0 up down em1 up up em2 up up em2.0 up up inet 172.18.1.2/30 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 192.168.1.1 0/0 lo0.16384 up up inet 127.0.0.1 0/0 lo0.16385 up up inet 128.0.0.4 0/0
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 197
inet6 fe80::a00:27ff:fe58:7da4 lsi up up mtun up up pimd up up pime up up [edit interfaces gre] root@srxA1#
Cuestión: ¿Cuál 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 dirección IPv6 a la interface del túnel 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 comunicación hacia la dirección 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 round-trip min/avg/max/std-dev = 1.154/1.598/2.347/0.324 ms
Máster Universitario en Ingeniería de Telecomunicación - UA
198 Estudio e implementación de la herramienta de simulación de redes GNS3
4.9. Muestra la tabla de enrutamiento actual.
[edit interfaces] root@srxA1# run show route inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 00:45:43 > to 172.18.1.1 via em2.0 172.18.1.0/30 *[Direct/0] 02:06:32 > via em2.0 172.18.1.2/32 *[Local/0] 02:06:32 Local via em2.0 192.168.1.1/32 *[Direct/0] 02:09:34 > via lo0.0 inet6.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 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 Cuestión: ¿Cómo se enruta el tráfico IPv6 a través del 198únel?
El router detecta que tiene una entrada en la tabla de enrutamiento inet6.0
de dicha subred y reencamina el tráfico hacia la interface gre.0.
4.10. Ejecuta el comando run show interfaces gre.0 y observa el campo IP-
Header.
[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
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 199
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# Cuestión: ¿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 dónde salen
los paquetes IPv6.
[edit interfaces] root@srxA1# run show route 192.168.2.1 inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 03:07:00 > to 172.18.1.1 via em2.0 [edit interfaces] root@srxA1#
Máster Universitario en Ingeniería de Telecomunicación - UA
200 Estudio e implementación de la herramienta de simulación de redes GNS3
Página en blanco intencionadamente
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 201
9. Troubleshooting JUNOS
En este capítulo vamos a exponer los problemas encontrados en la fase de
pruebas de los laboratorios, cómo 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 versión
JUNOS 9.6 R1.13 sin detectar ningún problema en el desarrollo de éstos. En el
Laboratorio 3 se detectó que no existía comunicación entre los dos routers srxA1
y srxA2, aún habiendo dos líneas de interconexión. A partir del Laboratorio 3, se
decidió migrar todas las máquinas virtuales a la versión JUNOS 10.1 R1.8 ya que
esta versión implementa el servicio SSH.
Figura 63: Escenario utilizado en el laboratorio 3: Filtros Firewalls.
Máster Universitario en Ingeniería de Telecomunicación - UA
202 Estudio e implementación de la herramienta de simulación de redes GNS3
Una vez cargadas las configuraciones desde el servidor TFTP, se detectó que no
había comunicación 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 ocurría en el router srxA2. Para más detalle se ejecutó el
comando show route protocol ospf y se confirmó que no había ninguna ruta de
la parte opuesta.
root@srxA1> show route protocol ospf inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.1.2/32 *[OSPF/10] 00:00:14, metric 1 > to 172.20.101.10 via em4.101 224.0.0.5/32 *[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 BDR ID Nbrs em1.0 DR 0.0.0.0 192.168.1.1 0.0.0.0 0 em2.0 DR 0.0.0.0 192.168.1.1 0.0.0.0 0 em4.101 BDR 0.0.0.0 192.168.1.2 192.168.1.1 1 lo0.0 DR 0.0.0.0 192.168.1.1 0.0.0.0 0
Se comprobó la tabla de adyacencias y se observó que solamente había 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 State ID Pri Dead 172.20.77.2 em1.0 ExStart 192.168.2.1 128 38 172.20.66.2 em2.0 ExStart 192.168.2.1 128 39 172.20.101.10 em4.101 Full 192.168.1.2 128 36
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 203
Llegados a este punto, se había comprobado que la configuración de los routers
era la correcta y que el problema del por qué no se recibían las rutas vía OSPF
era porque no se establecía 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 fábrica 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 sólo dos routers.
El resultado que nos encontramos es el mismo:
root@srxA1> show ospf neighbor Address Interface State ID Pri Dead 172.20.77.2 em1.0 ExStart 192.168.2.1 128 38 172.20.66.2 em2.0 ExStart 192.168.2.1 128 39
No son capaces de crear la adyacencia ya que se quedan en el estado
EXSTART.
Se prueba la comunicación con un ping entre los dos routers y se descubre que
no responde el router opuesto.
root@srxA1> ping 172.20.66.2 rapid count 25
Máster Universitario en Ingeniería de Telecomunicación - UA
204 Estudio e implementación de la herramienta de simulación de redes GNS3
PING 172.20.66.2 (172.20.66.2): 56 data bytes ......................... --- 172.20.66.2 ping statistics --- 25 packets transmitted, 0 packets received, 100% packet loss root@srxA1> ping 172.20.77.2 rapid count 25 PING 172.20.77.2 (172.20.77.2): 56 data bytes ......................... --- 172.20.77.2 ping statistics --- 25 packets transmitted, 0 packets received, 100% packet loss
En este punto ya sabemos que los dos routers son incapaces de crear una
adyacencia entre ellos debido a que no existe comunicación directa ninguna entre
ellos. ¿Por qué están fallando los pings en una configuración tan básica? Según
documentación de Juniper, es posible que el valor del parámetro MTU sea
diferente. Vemos las propiedades de las interfaces, tanto en OSPF como las
físicas:
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 Protection type: None Topology default (ID 0) -> Cost: 1 em2.0 DR 0.0.0.0 192.168.1.1 192.168.2.1 1 Type: LAN, Address: 172.20.66.1, Mask: 255.255.255.252, MTU: 1500, Cost: 1 DR addr: 172.20.66.1, BDR addr: 172.20.66.2, Priority: 128 Adj count: 0 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 1 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
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 205
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 parámetros:
root@srxA2> show ospf interface extensive
Máster Universitario en Ingeniería de Telecomunicación - UA
206 Estudio e implementación de la herramienta de simulación de redes GNS3
Interface State Area DR ID BDR ID Nbrs em1.0 BDR 0.0.0.0 192.168.1.1 192.168.2.1 1 Type: LAN, Address: 172.20.77.2, 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 Protection type: None Topology default (ID 0) -> Cost: 1 em2.0 BDR 0.0.0.0 192.168.1.1 192.168.2.1 1 Type: LAN, Address: 172.20.66.2, Mask: 255.255.255.252, MTU: 1500, Cost: 1 DR addr: 172.20.66.1, BDR addr: 172.20.66.2, Priority: 128 Adj count: 0 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None Topology default (ID 0) -> Cost: 1 root@srxA2> 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 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 : 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,
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 207
Resource errors: 0 Logical interface em1.0 (Index 64) (SNMP ifIndex 24) (Generation 129) Flags: SNMP-Traps Encapsulation: ENET2 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 Addresses, Flags: Is-Preferred 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 parámetros 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 líneas cruzándolas de la siguiente manera:
srxA1.em1 -> srxA2.em2
srxA1.em2 -> srxA2.em1
para comprobar si continúa comportándose de la misma manera.
Máster Universitario en Ingeniería de Telecomunicación - UA
208 Estudio e implementación de la herramienta de simulación de redes GNS3
Figura 65: Escenario de pruebas con las líneas intercambiadas.
Comprobamos que con esta disposición de las líneas sí que funciona el ping y sí
que se crea la adyacencia entre los dos routers.
root@srxA1> ping 172.20.66.2 rapid count 25 PING 172.20.66.2 (172.20.66.2): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 172.20.66.2 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.062/0.130/1.511/0.284 ms
root@srxA1> show ospf neighbor Address Interface State ID Pri Dead 172.20.77.2 em1.0 Full 192.168.2.1 128 38 172.20.66.2 em2.0 Full 192.168.2.1 128 39
Como última prueba y para saber si este comportamiento se produce entre ruters
de la misma versión o también entre diferentes versiones, creamos un nuevo
escenario de prueba con el router srxA1 con versión R10.1 y otro router srxB1 con
versión R12.1 con las líneas 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 versión.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 209
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 versión y
conectados entre sí por el mismo número de interface. Si esto ocurre, esta línea
fallará y no habrá ninguna comunicación entre ambos extremos, aunque el estado
de las interfaces aparezcan en UP. Siempre habrá que utilizar un número de
interface diferente: si en un extremo se utiliza la interface em1, en el otro extremo
de la línea se deberá utilizar una interface distinta a la em1, nos valdría 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, cómo se ha llegado a la conclusión anteriormente citada.
A continuación vamos a demostrar que dicha conclusión no es del todo cierta,
debido a las investigaciones realizadas posteriormente, y que dicha conclusión es
una consecuencia errónea 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 investigación hasta el descubrimiento de la falla con la
correspondiente conclusión 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 aparecía ninguna. A continuación se muestra el escenario
de trabajo.
Máster Universitario en Ingeniería de Telecomunicación - UA
210 Estudio e implementación de la herramienta de simulación de redes GNS3
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 continuación.
root@srxA1> show ospf3 neighbor root@srxA1>
root@srxA2> show ospf3 neighbor root@srxA2>
Pero sí que existe comunicación en la línea ya que el resultado de un ping entre
ellos es satisfactorio y además los routers detectan vecinos con IPv6 tal y como
se demuestra con el siguiente comando:
root@srxA1> show ipv6 neighbors IPv6 Address Linklayer Address State Exp Rtr Secure Interface 2001:172:18:1::1 08:00:27:8a:02:76 stale 551 yes no em2.0 2001:172:20:66::2 08:00:27:69:b1:4a stale 559 yes no em1.0 root@srxA1>
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 211
Llegados a este punto, podemos decir que existe comunicación tanto de tráfico
ICMP como a nivel IPv6, pero ¿se están transmitiendo y recibiendo LSAs
OSPFv3? Con el siguiente comando vamos a ver las estadísticas y determinar si
se transmiten y reciben upgrades OSPFv3.
root@srxA1> show ospf3 statistics Packet type Total Last 5 seconds Sent Received Sent Received Hello 6 0 0 0 DbD 0 0 0 0 LSReq 0 0 0 0 LSUpdate 0 0 0 0 LSAck 0 0 0 0 DBDs retransmitted : 0, last 5 seconds : 0 LSAs flooded : 0, last 5 seconds : 0 LSAs flooded high-prio : 0, last 5 seconds : 0 LSAs retransmitted : 0, last 5 seconds : 0 LSAs transmitted to nbr : 0, last 5 seconds : 0 LSAs requested : 0, last 5 seconds : 0 LSAs acknowledged : 0, last 5 seconds : 0 Flood queue depth : 0 Total rexmit entries : 0 db summaries : 0 lsreq entries : 0 Receive errors: None
root@srxA2> show ospf3 statistics Packet type Total Last 5 seconds Sent Received Sent Received Hello 4 0 0 0 DbD 0 0 0 0 LSReq 0 0 0 0 LSUpdate 0 0 0 0 LSAck 0 0 0 0 DBDs retransmitted : 0, last 5 seconds : 0 LSAs flooded : 0, last 5 seconds : 0 LSAs flooded high-prio : 0, last 5 seconds : 0 LSAs retransmitted : 0, last 5 seconds : 0 LSAs transmitted to nbr : 0, last 5 seconds : 0
Máster Universitario en Ingeniería de Telecomunicación - UA
212 Estudio e implementación de la herramienta de simulación de redes GNS3
LSAs requested : 0, last 5 seconds : 0 LSAs acknowledged : 0, last 5 seconds : 0 Flood queue depth : 0 Total rexmit entries : 0 db summaries : 0 lsreq entries : 0 Receive errors: None
Como podemos observar, por alguna razón 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 Physical interface: em1, Enabled, Physical link is Up Interface index: 9, SNMP ifIndex: 23 Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps Device flags : Present Running Interface flags: SNMP-Traps Link type : Full-Duplex Current address: 08:00:27:26:e0:2c, Hardware address: 08:00:27:26:e0:2c Last flapped : Never Input packets : 1 Output packets: 110 Logical interface em1.0 (Index 64) (SNMP ifIndex 24) Flags: SNMP-Traps Encapsulation: ENET2 Input packets : 1 Output packets: 110 Protocol inet6, MTU: 1500 Flags: Is-Primary Addresses, Flags: Is-Preferred 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 root@srxA2> show interfaces em1 Physical interface: em1, Enabled, Physical link is Up
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 213
Interface index: 9, SNMP ifIndex: 23 Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps Device flags : Present Running Interface flags: SNMP-Traps Link type : Full-Duplex Current address: 08:00:27:26:e0:2c, Hardware address: 08:00:27:26:e0:2c Last flapped : Never Input packets : 4 Output packets: 4 Logical interface em1.0 (Index 64) (SNMP ifIndex 24) Flags: SNMP-Traps Encapsulation: ENET2 Input packets : 4 Output packets: 4 Protocol inet6, MTU: 1500 Flags: Is-Primary Addresses, Flags: Is-Preferred 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 están saliendo de los routers. Para ello vamos a activar la monitorización del
tráfico OSPF3 y ver qué ocurre.
[edit] root@srxA1# edit protocols ospf3 [edit protocols ospf3] root@srxA1# set traceoptions file prueba.txt [edit protocols ospf3] root@srxA1# set traceoptions flag hello [edit protocols ospf3] root@srxA1# set traceoptions flag error [edit protocols ospf3] root@srxA1# commit commit complete [edit protocols ospf3] root@srxA1# run show log prueba.txt
Jul 29 12:34:45 trace_on: Tracing to "/var/log/prueba.txt" started
Máster Universitario en Ingeniería de Telecomunicación - UA
214 Estudio e implementación de la herramienta de simulación de redes GNS3
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) Jul 29 12:35:02.487735 OSPF periodic xmit from fe80::a00:27ff:fe26:e02c to ff02::5 (IFL 64 area 0.0.0.0) Jul 29 12:35:12.281586 OSPF periodic xmit from fe80::a00:27ff:fe26:e02c to ff02::5 (IFL 64 area 0.0.0.0) Jul 29 12:35:20.969060 OSPF periodic xmit from fe80::a00:27ff:fe26:e02c to ff02::5 (IFL 64 area 0.0.0.0) Jul 29 12:35:29.463450 OSPF periodic xmit from fe80::a00:27ff:fe26:e02c to ff02::5 (IFL 64 area 0.0.0.0)
[edit protocols ospf3] root@srxA1#
Para el router srxA2 tenemos la siguiente captura de monitorización:
[edit protocols ospf3] root@srxA2# run show log prueba.txt Jul 29 13:13:19 trace_on: Tracing to "/var/log/prueba.txt" started [edit protocols ospf3] root@srxA2#
Se puede observar que se están 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 ningún
paquete Hello ni se producen errores, ni los contadores de la interface aumentan.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 215
Podríamos pensar que este tipo de comportamiento es una limitación impuesta
por el fabricante a la Olivas, que por algún tipo de mecanismo detecta que el IOS
no está corriendo en una plataforma con hardware original e impone ciertas
limitaciones. Pero esta teoría nos resulta un tanto extraña aunque veremos en el
siguiente problema como sí se cumple.
Después de varias comprobaciones, de analizar todo el histórico 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 dirección MAC de la
interface em1 de ambos routers es la misma.
root@srxA1> show interfaces em1 Physical interface: em1, Enabled, Physical link is Up Interface index: 9, SNMP ifIndex: 23 Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps Device flags : Present Running Interface flags: SNMP-Traps Link type : Full-Duplex Current address: 08:00:27:26:e0:2c, Hardware address: 08:00:27:26:e0:2c Last flapped : Never Input packets : 1 Output packets: 110 root@srxA2> show interfaces em1 Physical interface: em1, Enabled, Physical link is Up Interface index: 9, SNMP ifIndex: 23 Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps Device flags : Present Running Interface flags: SNMP-Traps Link type : Full-Duplex Current address: 08:00:27:26:e0:2c, Hardware address: 08:00:27:26:e0:2c Last flapped : Never Input packets : 4 Output packets: 4
Máster Universitario en Ingeniería de Telecomunicación - UA
216 Estudio e implementación de la herramienta de simulación de redes GNS3
Esta configuración provoca que las tramas Ethernet, cuando sean procesadas en
cualquiera de las interfaces, lleven en su cabecera la misma dirección origen y
destino. Esta situación puede generar incongruencias en el algoritmo de decisión
y por lo tanto no es una configuración correcta.
Para confirmar que esta configuración es la que nos está provocando los
problemas de adyacencias, vamos a cambiar la dirección MAC del router srxA2.
Para ello debemos apagar el router, y luego cambiar la configuración en la
Máquina de Virtual Box.
[edit] root@srxA2# exit Exiting configuration mode 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 configuración de la máquina virtual
asociada al router srxA2.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 217
Figura 67: Configuración dirección MAC en una MV de VirtualBox.
En el apartado de Red, Adaptador 2, en el panel Avanzadas tenemos el valor de
la dirección MAC. La cambiamos por otra generada aleatoriamente con el botón
de la derecha. Ahora estamos en disposición 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:
[edit protocols ospf3] 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 [edit protocols ospf3] root@srxA1# run show ospf3 statistics Packet type Total Last 5 seconds Sent Received Sent Received Hello 39 3 0 0 DbD 3 2 0 0
Máster Universitario en Ingeniería de Telecomunicación - UA
218 Estudio e implementación de la herramienta de simulación de redes GNS3
LSReq 1 1 0 0 LSUpdate 2 3 0 0 LSAck 3 1 0 0 DBDs retransmitted : 0, last 5 seconds : 0 LSAs flooded : 0, last 5 seconds : 0 LSAs flooded high-prio : 4, last 5 seconds : 0 LSAs retransmitted : 0, last 5 seconds : 0 LSAs transmitted to nbr : 2, last 5 seconds : 0 LSAs requested : 2, last 5 seconds : 0 LSAs acknowledged : 6, last 5 seconds : 0 Flood queue depth : 0 Total rexmit entries : 0 db summaries : 0 lsreq entries : 0 Receive errors: None [edit protocols ospf3] root@srxA1#
…
root@srxA2> show ospf3 neighbor ID Interface State Pri Dead 1.1.1.1 em1.0 Full 128 35 Neighbor-address fe80::a00:27ff:fe26:e02c root@srxA2> show ospf3 statistics Packet type Total Last 5 seconds Sent Received Sent Received Hello 6 3 0 0 DbD 2 3 0 0 LSReq 1 1 0 0 LSUpdate 3 2 0 0 LSAck 1 3 0 0 DBDs retransmitted : 0, last 5 seconds : 0 LSAs flooded : 4, last 5 seconds : 0 LSAs flooded high-prio : 0, last 5 seconds : 0 LSAs retransmitted : 0, last 5 seconds : 0 LSAs transmitted to nbr : 2, last 5 seconds : 0 LSAs requested : 2, last 5 seconds : 0 LSAs acknowledged : 5, last 5 seconds : 0
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 219
Flood queue depth : 0 Total rexmit entries : 0 db summaries : 0 lsreq entries : 0 Receive errors: None root@srxA2>
Como podemos observar, la adyacencia entre vecinos OSPF3 sí se ha
establecido por completo, estado FULL, y además vemos en el resultado de las
estadísticas 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 versión 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.
root@srxA1> show ospf neighbor Address Interface State ID Pri Dead 172.20.77.2 em1.0 Full 192.168.2.1 128 35 172.20.66.2 em2.0 Full 192.168.2.1 128 35 root@srxA1> show ospf statistics Packet type Total Last 5 seconds Sent Received Sent Received Hello 12 6 0 0 DbD 11 5 0 0 LSReq 1 1 0 0 LSUpdate 5 4 0 0 LSAck 5 4 0 0 DBDs retransmitted : 5, last 5 seconds : 0 LSAs flooded : 6, last 5 seconds : 0 LSAs flooded high-prio : 0, last 5 seconds : 0 LSAs retransmitted : 0, last 5 seconds : 0 LSAs transmitted to nbr : 3, last 5 seconds : 0 LSAs requested : 3, last 5 seconds : 0
Máster Universitario en Ingeniería de Telecomunicación - UA
220 Estudio e implementación de la herramienta de simulación de redes GNS3
LSAs acknowledged : 11, last 5 seconds : 0 Flood queue depth : 0 Total rexmit entries : 0 db summaries : 0 lsreq entries : 0 Receive errors: None root@srxA1> … root@srxA2> show ospf neighbor Address Interface State ID Pri Dead 172.20.77.1 em1.0 Full 192.168.1.1 128 37 172.20.66.1 em2.0 Full 192.168.1.1 128 39 root@srxA2> show ospf statistics Packet type Total Last 5 seconds Sent Received Sent Received Hello 12 10 0 0 DbD 5 11 0 0 LSReq 1 1 0 0 LSUpdate 4 5 0 0 LSAck 4 5 0 0 DBDs retransmitted : 1, last 5 seconds : 0 LSAs flooded : 8, last 5 seconds : 0 LSAs flooded high-prio : 0, last 5 seconds : 0 LSAs retransmitted : 0, last 5 seconds : 0 LSAs transmitted to nbr : 3, last 5 seconds : 0 LSAs requested : 3, last 5 seconds : 0 LSAs acknowledged : 8, last 5 seconds : 0 Flood queue depth : 0 Total rexmit entries : 0 db summaries : 0 lsreq entries : 0 Receive errors: None
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 221
También en el escenario IPv4 funciona correctamente el protocolo OSPF,
estableciéndose las dos adyacencias y recibiéndose 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
situación se ha dado debido a que se han clonado las máquinas virtuales en base
a una original y por lo tanto todas ellas, y nuestros routers, tenían las direcciones
MAC iguales. Por este motivo, en la primera parte, cuando enfrentábamos dos
routers con el mismo número de interface el protocolo OSPF no funcionaba y los
pings tampoco.
Como conclusión final y estableciéndose como premisa de diseño de escenarios
en JUNOS y máquinas virtuales diremos que una vez se haya clonado una
máquina virtual JUNOS para su utilización, inmediatamente se deberán cambiar
las direcciones MAC de la nueva máquina clonada.
Y esta premisa también es de aplicación en entornos de simulación con la
herramienta QEMU ya que una vez se tiene la máquina Oliva creada, en
diferentes artículos 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.
Máster Universitario en Ingeniería de Telecomunicación - UA
222 Estudio e implementación de la herramienta de simulación de redes GNS3
9.2. Problema 2: Fallo Filtros Firewall en versión R9.6
9.2.1. Desarrollo
En el desarrollo del Laboratorio 3 con MV JUNOS R9.6 se ha detectado que con
esta versión los filtros Firewall no funcionan correctamente. A continuación se
expone la problemática.
Del escenario del Laboratorio 3 con R9.6, arrancamos sólo 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.
root@srxA1> configure Entering configuration mode [edit] root@srxA1# edit system services [edit system services] root@srxA1# show ftp; telnet; [edit system services] root@srxA1#
Desde el router vr101 probamos los servicios ICMP, FTP y TELNET hacia la
interface loopback del router srxA1.
root@vr101> ping 192.168.1.1 rapid count 25 PING 192.168.1.1 (192.168.1.1): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 192.168.1.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.663/1.034/1.778/0.266 ms root@vr101> ftp 192.168.1.1 Connected to 192.168.1.1. 220 srxA1 FTP server (Version 6.00LS) ready.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 223
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. ftp> bye 221 Goodbye. root@vr101> telnet 192.168.1.1 Trying 192.168.1.1... Connected to 192.168.1.1. Escape character is '^]'. srxA1 (ttyp0) login: lab Password:
--- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC lab@srxA1> exit Connection closed by foreign host. 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 también
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=1ms TTL=64 Respuesta desde 192.168.1.1: bytes=32 tiempo<1m TTL=64 Respuesta desde 192.168.1.1: bytes=32 tiempo<1m TTL=64 Estadísticas de ping para 192.168.1.1: Paquetes: enviados = 4, recibidos = 4, perdidos = 0 (0% perdidos), Tiempos aproximados de ida y vuelta en milisegundos: Mínimo = 0ms, Máximo = 1ms, Media = 0ms C:\Documents and Settings\LAB>ftp 192.168.1.1 Conectado a 192.168.1.1.
Máster Universitario en Ingeniería de Telecomunicación - UA
224 Estudio e implementación de la herramienta de simulación de redes GNS3
220 srxA1 FTP server (Version 6.00LS) ready. Usuario (192.168.1.1:(none)): lab 331 Password required for lab. Contraseña: 230 User lab logged in. 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 conexión 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 teoría nadie puede acceder a
ellos excepto las máquinas ubicadas en la subred indicada.
[edit firewall] root@srxA1# edit family inet filter protect-host [edit firewall family inet filter protect-host] root@srxA1# [edit firewall family inet filter protect-host] root@srxA1# set term limit-icmp from protocol icmp [edit firewall family inet filter protect-host] root@srxA1# set term limit-icmp from source-address 10.210.0.0/16 [edit firewall family inet filter protect-host] 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 [edit firewall family inet filter protect-host] root@srxA1# set term limit-telnet from source-address 10.210.0.0/16
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 225
[edit firewall family inet filter protect-host] 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 [edit firewall family inet filter protect-host] root@srxA1# set term limit-ftp from source-address 10.210.0.0/16 [edit firewall family inet filter protect-host] root@srxA1# set term limit-ftp then accept
[edit firewall family inet filter protect-host] root@srxA1# top edit interfaces lo0 [edit firewall family inet filter protect-host] root@srxA1# set unit 0 family inet filter input protect-host [edit interfaces lo0] root@srxA1# commit commit complete [edit interfaces lo0] root@srxA1#
Desde el router vr101 volvemos a probar los servicios ICMP, FTP y TELNET
hacia la interface loopback del router srxA1.
root@vr101> ping 192.168.1.1 rapid count 25 PING 192.168.1.1 (192.168.1.1): 56 data bytes !!!!!!!!!!!!!!!!!!!!!!!!! --- 192.168.1.1 ping statistics --- 25 packets transmitted, 25 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.588/1.084/1.930/0.287 ms
root@vr101> ftp 192.168.1.1 Connected to 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. ftp> bye 221 Goodbye.
Máster Universitario en Ingeniería de Telecomunicación - UA
226 Estudio e implementación de la herramienta de simulación de redes GNS3
root@vr101> telnet 192.168.1.1 Trying 192.168.1.1... Connected to 192.168.1.1. Escape character is '^]'. srxA1 (ttyp0) login: lab Password:
--- JUNOS 9.6R1.13 built 2009-08-01 09:02:46 UTC lab@srxA1> exit Connection closed by foreign host. 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 encontrásemos 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.
[edit interfaces lo0] root@srxA1# show unit 0 { family inet { filter { input protect-host; } address 192.168.1.1/32; } } [edit interfaces lo0] root@srxA1# delete unit 0 family inet filter [edit interfaces lo0]
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 227
root@srxA1# commit commit complete [edit interfaces lo0] root@srxA1# show unit 0 { family inet { address 192.168.1.1/32; } }
Definimos y activamos el filtro en la interface em0.
[edit interfaces lo0] root@srxA1# top edit interfaces em0 root@srxA1# show unit 0 { family inet { address 10.210.14.131/27; } } [edit interfaces em0] root@srxA1# set unit 0 family inet filter input protect-host [edit interfaces em0] root@srxA1# show unit 0 { family inet { filter { input protect-host; } address 10.210.14.131/27; } } [edit interfaces em0] root@srxA1# commit commit complete [edit interfaces em0] root@srxA1#
Máster Universitario en Ingeniería de Telecomunicación - UA
228 Estudio e implementación de la herramienta de simulación de redes GNS3
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: Respuesta desde 192.168.1.1: bytes=32 tiempo=1ms TTL=64 Respuesta desde 192.168.1.1: bytes=32 tiempo<1m TTL=64 Respuesta desde 192.168.1.1: bytes=32 tiempo<1m TTL=64 Respuesta desde 192.168.1.1: bytes=32 tiempo<1m TTL=64 Estadísticas de ping para 192.168.1.1: Paquetes: enviados = 4, recibidos = 4, perdidos = 0 (0% perdidos), Tiempos aproximados de ida y vuelta en milisegundos: Mínimo = 0ms, Máximo = 1ms, Media = 0ms
C:\Documents and Settings\LAB>ftp 192.168.1.1 Conectado a 192.168.1.1. 220 srxA1 FTP server (Version 6.00LS) ready. Usuario (192.168.1.1:(none)): lab 331 Password required for lab. Contraseña: 230 User lab logged in. 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 conexión 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 módulos
JUNOS apropiados y concretamente el módulo encargado de los filtros Firewall.
[edit interfaces em0]
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 229
root@srxA1# run show version Hostname: srxA1 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] [edit interfaces em0] 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 limitación 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
Máquinas Virtuales JUNOS con R9.6 no funcionan los filtros firewall. Para
implementar esta característica debemos utilizar una versión JUNOS R10.1 como
mínimo.
Máster Universitario en Ingeniería de Telecomunicación - UA
230 Estudio e implementación de la herramienta de simulación de redes GNS3
Página en blanco intencionadamente
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 231
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 creación de una guía de laboratorios
prácticos para el aprendizaje de los routers Juniper, nivel de certificación JNCIA, a
través de una plataforma de virtualización y GNS3 se ha conseguido. En cada uno
de los laboratorios presentados en este trabajo se han comprobado que se
cumplen los objetivos didácticos y las funcionalidades de los routers en cada
escenario. Los escenarios se han adaptado para que puedan funcionar en GNS3.
Se ha añadido un capítulo sobre la resolución 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 solución, sino la metodología
y análisis empleada para llegar a la detección de fallas y luego a su solución.
A continuación pasamos a enumerar las conclusiones obtenidas:
• GNS3 es una plataforma de emulación perfectamente válida para trabajar
con los routers Juniper. Es fácil de instalar y utilizar con la ventaja de ser
una herramienta gratuita.
• GNS3 se sirve de los paquetes Dynamips y Dinagen para proporcionar la
emulación. Si bien Dynamips es exclusivo para Cisco, la emulación en
Juniper se realiza a través de herramientas de virtualización 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.
Máster Universitario en Ingeniería de Telecomunicación - UA
232 Estudio e implementación de la herramienta de simulación de redes GNS3
• Hasta la fecha, no existe forma de emular ningún dispositivo Switch
Ethernet de Juniper (familia EX), ni tampoco de Cisco. Pero GNS3
proporciona un switch virtual que implementa las funcionalidades básicas
de un switch Ethernet pudiendo configurar VLANs de forma gráfica.
• En escenarios con routers Juniper no se ha conseguido que funcionara la
captura de paquetes con Wireshark. La herramienta GNS3 aún no permite
esta característica.
• A la hora de clonar Máquinas Virtuales con IOS Juniper, Olivas, tener muy
presente que hay que cambiar las direcciones MAC de las máquinas
clonadas porque si no éstas coincidirán y el tráfico en los enlaces de
interconexión entre estos routers no funcionará.
• Según el estudio de rendimiento realizado, el escenario de trabajo para
conseguir el máximo rendimiento es instalar GNS3 en una máquina
anfitriona con un SO Linux, es preferible Ubuntu, y para la emulación de los
dispositivos Juniper utilizar la herramienta Virtual Box. Se desaconseja la
utilización de QEMU.
• Se recomienda que una vez creada una Oliva, se ajuste al máximo la
memoria utilizada por la máquina virtual. Cuando se lanzan los paquetes
de instalación del software Junos, una de las comprobaciones que realiza
es la cantidad de memoria mínima que se necesita para iniciar la
instalación. 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 número máximo 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, más dispositivos
podremos emular en un escenario de GNS3.
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 233
• La funcionalidad de Class of Service de los dispositivos Juniper no
funciona en un entorno de emulación. 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 versión R10.1 sí que han funcionado.
• Se recomienda implementar Olivas con la versión Junos R10.4 por su gran
estabilidad de la IOS, su compromiso en la utilización de RAM por parte de
Virtual Box y por el tamaño final del archivo de la máquina virtual.
• El comportamiento y la apariencia en un dispositivo emulado Junos, Oliva,
es prácticamente similar y no se aprecia ninguna diferencia con respecto a
un dispositivo real.
Máster Universitario en Ingeniería de Telecomunicación - UA
234 Estudio e implementación de la herramienta de simulación de redes GNS3
Página en blanco intencionadamente
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 235
11. Líneas Futuras
Tras la realización de este trabajo podemos resaltar las siguientes líneas futuras:
• Intentar crear los escenarios para la siguiente certificación, JNCIS, y probar
que se pueden configurar las Olivas así como su buen funcionamiento.
• Crear una plataforma WEB de formación donde se puedan elegir diferentes
escenarios de las certificaciones Juniper y ejecutar las máquinas virtuales
para su configuración.
• Probar plataformas diferentes, tales como XORP o sobre todo Vyatta, en el
entorno GNS3, estudiar su comportamiento y la interoperación con
dispositivos Juniper.
• Probar en Olivas con una versión JunOS más actual, por ejemplo R12,
aquellas funcionalidades que no han funcionado correctamente con las
versiones probadas.
• Realizar un estudio del comportamiento que tendrán las Olivas al introducir
tráfico 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.
Máster Universitario en Ingeniería de Telecomunicación - UA
236 Estudio e implementación de la herramienta de simulación de redes GNS3
Página en blanco intencionadamente
UA - Máster Universitario en Ingeniería de Telecomunicación
Estudio e implementación de la herramienta de simulación de redes GNS3 237
12. Bibliografía
[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]. Diseño e implementación de un prototipo de red de comunicaciones basado
en virtualización y servicios web 2.0. PFC Manuel Miguel Torres Sánchez.
[12]. Evaluación de la herramienta GNS3 con conectividad a enrutadores reales. PFC Lisset Díaz Cervantes. UPC.
[13]. Despliegue de redes señuelo mediante el uso de herramientas de creación de escenarios virtuales. PFC Jorge Alejandro Rodríguez Villagrá. ETSIT UPM.
[14]. GNS3 as a feasible teaching,testing and designing tool for network design. James Mahon, Paul Flynn.
Máster Universitario en Ingeniería de Telecomunicación - UA
238 Estudio e implementación de la herramienta de simulación de redes GNS3
[15]. Foro web GNS3
http://forum.gns3.net/
[16]. Creación 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-juniper-network.html
[22]. Vyatta Open Networking - Software-based Routing & Security http://www.vyatta.com