simulación de redes juniper con gns3 - jncia

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



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



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



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



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



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.



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.



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.



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.



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



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.



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



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.



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.



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.



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.



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.



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.



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



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



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



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.



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



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.



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



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.)



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



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.



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.

ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/ISO-IMAGES/4.11/4.11-RELEASE-i386-miniinst.iso

ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/ISO-IMAGES/4.11/4.11-RELEASE-i386-miniinst.iso



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.



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.



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.



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.



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.



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.



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.



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.



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.



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



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



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.



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.



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.



3.3.5. Instalación JWeb Junos 9.6

Para completar nuestra Oliva, vamos a instalar el entorno WEB. Para ello

necesitamos tener en el disco duro de nuestra Oliva el siguiente paquete:


Si recuerdan, este paquete ya se copió al directorio /var/tmp/. A continuación

describimos los pasos para la instalación:

3.3.5.1. Arrancamos la MV y esperaremos a que nos aparezca el login.

Recordar que no aparecerán los mensajes de información de

arranque ya que éstos están dirigidos hacia el puerto serie. Si

abrimos una sesión terminal al puerto serie virtual veremos la traza

de arranque. Accedemos como root e interrogamos al router para

saber qué versiones y paquetes se han instalado.

Figura 28: Captura de los paquetes instalados en la Oliva (comando show

version).



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.



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.



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.



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.



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.



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.



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.



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



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.



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.



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.



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.



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:



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


Por lo demás, se seguirán las mismas indicaciones que en la versión Junos 9.6

excepto un nuevo paso:

3.6.2.1. Montar la unidad CD/DVD con el fichero ISO que contiene los

paquetes. Copiar los ficheros IOS en el directorio /var/tmp/.

Olive# cd /var/tmp/ Olive# mount /cdrom Olive# cp /cdrom/* .

3.6.2.2. Descomprimir los ficheros jinstall,

Olive# mkdir signed Olive# cd signed/ Olive# tar zxvf ../jinstall-10.4R1.9-domestic-signed.tgz Olive# mkdir jinst Olive# cd jinst Olive# tar zxvf ../jinstall-10.4R1.9-domestic.tgz

3.6.2.3. En este nuevo paso vamos a editar los ficheros +INSTALL y +

REQUIRE, que se han extraído del último fichero jinstall-

10.4R1.9-domestic.tgz, y sustituiremos una línea de código.

Empezaremos por el fichero +INSTALL y buscamos la siguiente

parte del código que se encuentra en la línea 2110:

Olive# edit ./+INSTALL

Nos desplazamos hasta la línea 2110 y dejamos la función tal y como

indicamos.



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.



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



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



--- 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]



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.



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



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.



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.



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.



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.



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.



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



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.



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 {


} } em2 { unit 0 {


} } em3 { unit 0 {


} } em4 { vlan-tagging; unit 101 {

vlan-id 101;




} } lo0 { unit 0 {


} } [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



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)



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.



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



[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



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 {



next-hop 172.20.66.2; qualified-next-hop 172.20.77.2 {

preference 6; }

} route 192.168.2.2/32 {


preference 6; }

} route 172.20.102.0/24 {


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?



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.



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



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.



[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;



qualified-next-hop 172.20.77.2 { preference 6;

} } route 192.168.2.2/32 {


preference 6; }

} route 172.22.102.0/24 {


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)



+ = 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 !!!!!!!!!!!!!!!!!!!!!!!!!



--- 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



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;



} } } 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; }



} } 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



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.



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.



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.



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.



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]].


elementos:

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


• 1 Nodo de Interconexión a la máquina anfitriona.







• 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.



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



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#



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



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



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



[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)



+ = 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



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]



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


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].



[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



[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.


to 172.20.77.2 via ge-0/0/1.0 > to 172.20.66.2 via ge-0/0/2.0










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;

} }



[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]



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.


to 172.20.77.2 via ge-0/0/1.0 > to 172.20.66.2 via ge-0/0/2.0










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;



} } 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;



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;



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



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



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/



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



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; }



[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



--- 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.



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.



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.


elementos:

• 5 Maquinas Virtual Box (MVB) con el SO JUNOS (mínimo R10.1).









• Configurar y monitorizar Filtros Firewall.

• Configurar el acceso al Servidor TFTP desde todos los dispositivos.





1.1. Acceder por consola al router srxAX, acceder al modo de configuración y

situarse en el nivel [edit system services]. Se nos mostrarán los servicios

actualmente activados.

root @srxA1> configure



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



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



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>



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.



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



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



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.



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



[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



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.



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:



--- 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



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



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



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?



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



[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;



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;



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



[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



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



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)



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.



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; } }



} 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; }



} } } 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; } }



} 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 {



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 {



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 {



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;



} 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;



} } 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; }



} } 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



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 {



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 {



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; } }



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:



Figura 59: Escenario adaptado del laboratorio Clases de Servicios.


elementos:









• 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.








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



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;



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]



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



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; }



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; }



[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



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



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



[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



[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#



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



[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.



[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



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.



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.


elementos:











• 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.


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



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



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



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



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



> 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 !!!!!!!!!!!!!!!!!!!!!!!!!



--- 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



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



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.



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.



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.



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>



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



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.



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.



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?



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



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



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



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#



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.



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



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



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



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



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,



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.



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.



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.



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>



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



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



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



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.



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



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.



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



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



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



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



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.



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.



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.



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



[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.



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]



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#



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]



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.



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.



• 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.



• 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.



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.



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.



[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

http://forum.gns3.net/

http://muralirajanm.blogspot.com.es/

http://pieknywidok.blogspot.com.es/2012/04/creating-olive-with-junos-121-on.html

https://learningportal.juniper.net/juniper/user_fasttrack_home.aspx

http://certcollection.org/forum/forum/155-juniper-shares/

http://blog.gns3.net/2009/10/olive-juniper/2/



http://www.vyatta.com/

simulación de redes juniper con gns3 - jncia

Technology