Escenarios de Enrutamiento Dinámico Avanzado en Entornos Virtuales mediante Tecnología Juniper

Escenarios de enrutamiento dinámico

avanzado en entornos virtuales

mediante tecnología Juniper

Máster Universitario en Ingeniería de

Telecomunicación

Trabajo Fin de Máster

Autor:

Antonio Belchí Hernández

Tutores:

Adolfo Albaladejo Blázquez

Carolina Pascual Villalobos

Junio 2014

Máster Universitario en Ingeniería de Telecomunicación Universidad de Alicante

2 Enrutamiento Dinámico Avanzado en Entornos Virtuales mediante tecnología Juniper

Página en blanco intencionalmente


Enrutamiento Dinámico Avanzado en Entornos Virtuales mediante tecnología Juniper 3

Índice

1 ABSTRACT ............................................................................................................. 7

2 INTRODUCCIÓN Y OBJETIVOS ....................................................................... 8

3 SIMULACIÓN DE REDES JUNIPER EN ENTORNOS VIRTUALES .......... 11

3.1 Tecnología Juniper ..................................................................................................... 11

3.2 Simulador de redes GNS3 ......................................................................................... 14

3.2.1 Instalación y Configuración de Olivas en GNS3 ............................................. 15

3.2.2 Simulación de PCs en GNS3.............................................................................. 28

4 ENRUTAMIENTO DINÁMICO AVANZADO ............................................... 32

4.1 Enrutamiento Estático ............................................................................................... 32

4.2 Enrutamiento Dinámico ............................................................................................ 34

4.2.1 Métrica y Distancia Administrativa .................................................................. 35

4.2.2 Protocolos IGP (Interior Gateway) y EGP (Exterior Gateway) ....................... 37

4.2.3 Protocolos Vector distancia y Estado de Enlace .............................................. 38

4.3 IPv6 ............................................................................................................................. 39

4.4 Conectividad Segura mediante VPN (Virtual Private Network) ........................... 42

4.5 Alta Disponibilidad mediante FHRP (First Hop Redundancy Protocols) ............ 45

5 LABORATORIOS ................................................................................................ 47

5.1 Lab 1: Protocol-Independent Routing ...................................................................... 51

5.1.1 Parte 1: Configuración y Monitorización de Interfaces ................................... 52

5.1.2 Parte 2: Configuración y Monitorización de Rutas Estáticas y Agregadas.... 56

5.1.3 Parte 3: Instancias de Enrutamiento ................................................................. 61



5.2 Lab 2: Load Balancing and Filter-Based Forwarding (FBF) .................................... 68

5.2.1 Parte 1: Configuración y Monitorización de Balanceo de Carga .................... 69

5.2.2 Parte 2: Configuración y Monitorización de FBF (Filter-Based Forwarding) 73

5.3 Lab 3: Open Shortest Path First (OSPF) ................................................................... 82

5.3.1 Parte 1: Configuración y Monitorización de OSPF .......................................... 83

5.3.2 Parte 2: Solución de problemas básicos en OSPF............................................. 90

5.4 Lab 4: Border Gateway Protocol (BGP) .................................................................... 95

5.4.1 Parte 1: Configuración y Monitorización de IBGP .......................................... 96

5.4.2 Parte 2: Configuración y Monitorización de EBGP ......................................... 98

5.5 Lab 5: IP Tunneling .................................................................................................. 102

5.5.1 Parte 1: Configuración y Monitorización de un túnel GRE .......................... 103

5.5.2 Parte 2: Configuración de interfaz GRE para participar en OSPF ................ 106

5.6 Lab 6: High Availability .......................................................................................... 111

5.6.1 Parte 1: Configuración y Monitorización de VRRP ....................................... 112

5.7 Lab 7: IPv6 ................................................................................................................ 117

5.7.1 Parte 1: Configuración y Monitorización de Interfaces ................................. 119

5.7.2 Parte 2: Configuración y Monitorización de Enrutamiento Estático............ 122

5.7.3 Parte 3: Configuración y Monitorización de OSPFv3 .................................... 124

5.7.4 Parte 4: Configuración de un túnel GRE para transportar tráfico IPv6 sobre

una red IPv4 .................................................................................................................... 126

5.8 Lab 8: IS-IS ................................................................................................................ 131

5.8.1 Parte 1: Configuración y Monitorización de IS-IS ......................................... 132

5.8.2 Parte 2: Solución de problemas básicos en IS-IS ............................................ 136

5.9 Troubleshooting Laboratorios ................................................................................ 140

6 CONCLUSIONES .............................................................................................. 146

7 LÍNEAS FUTURAS ............................................................................................ 148

8 BIBLIOGRAFÍA ................................................................................................. 150



Índice de Figuras

Figura 1: Logotipo de Juniper Networks ....................................................................................... 11

Figura 2: Logotipo del sistema operativo JUNOS ......................................................................... 12

Figura 3: Separación de los planos de control y reenvío en JUNOS............................................... 12

Figura 4: Logotipo de la certificación JNCIS ................................................................................. 13

Figura 5: Logotipo de GNS3 ........................................................................................................ 14

Figura 6: Logotipo de VirtualBox ................................................................................................. 14

Figura 7: VirtualBox - Conversión de .img a .vdi mediante VBoxManage .................................... 16

Figura 8: VirtualBox - Nombre y Sistema Operativo de la VM ..................................................... 18

Figura 9: VirtualBox - Tamaño de memoria de la VM .................................................................. 19

Figura 10: VirtualBox - Unidad de disco duro de la VM ............................................................... 20

Figura 11: VirtualBox - Creación de la VM .................................................................................. 21

Figura 12: VitualBox - Clonación de VMs .................................................................................... 22

Figura 13: VirtualBox - Nombre de la clonación ........................................................................... 23

Figura 14: VirtualBox - Tipo de clonación .................................................................................... 23

Figura 15: GNS3 - Conexión con VirtualBox ............................................................................... 24

Figura 16: GNS3 - Importar VMs desde VirtualBox .................................................................... 25

Figura 17: GNS3 - Selección de dispositivos................................................................................. 26

Figura 18: GNS3 - Creación de un escenario completo ................................................................. 27

Figura 19: VPCS - Configuraciones previas en GNS3 .................................................................. 28

Figura 20: VPCS - Selección de PCs virtuales .............................................................................. 29

Figura 21: VPCS - Puesta en marcha de los PCs virtuales ............................................................ 30

Figura 22: VPCS - Configuración de los PCs virtuales ................................................................. 30



Figura 23: VPCS - Comprobación de conectividad entre PCs virtuales ......................................... 31

Figura 24: Clasificación de protocolos de enrutamiento dinámico ................................................. 37

Figura 25: Ejemplo de protocolos IGPs y EGPs ............................................................................ 38

Figura 26: Direcciones IPv6 ......................................................................................................... 39

Figura 27: Migración a IPv6 (Dual Stack) ................................................................................... 40

Figura 28: Migración a IPv6 (Tunneling) .................................................................................... 41

Figura 29: Migración a IPv6 (NAT64) ........................................................................................ 41

Figura 30: VPN Punto-a-Punto ................................................................................................... 43

Figura 31: VPN Acceso Remoto ................................................................................................... 44

Figura 32: Limitaciones sin características de Alta Disponibilidad ............................................... 45

Figura 33: Alta Disponibilidad mediante FHRP........................................................................... 46

Figura 34: Simulación de la nube (Internet) en GNS3 .................................................................. 47

Figura 35: Escenario del Lab 1 "Protocol-Independent Routing".................................................. 51

Figura 36: Escenario del Lab 2 "Load Balancing and Filter-Based Forwarding" ........................... 68

Figura 37: Escenario del Lab 3 "OSPF" ....................................................................................... 82

Figura 38: Escenario del Lab 4 "BGP" ......................................................................................... 95

Figura 39: Escenario del Lab 5 "IP Tunneling".......................................................................... 102

Figura 40: Escenario del Lab 6 "High Availability" ................................................................... 111

Figura 41: Escenarios del Lab 7 "IPv6"...................................................................................... 118

Figura 42: Escenario del Lab 8 "IS-IS" ...................................................................................... 131

Figura 43: Troubleshooting Laboratorios .................................................................................... 140



1 Abstract

Juniper technology is experiencing a large increase in popularity due mainly to the

advantages of its peculiar operating system, named JUNOS. The great

disadvantage of Juniper over other technologies like Cisco is that it hasn't its own

network simulation tools, which makes it extremely difficult for a network

administrator practice with Juniper virtual devices. They always need to work with

Juniper physical devices.

The main objective of this work is getting simulate the behavior of advanced

dynamic routing scenarios in virtual environments using Juniper technology. To

achieve this, we will perform the labs of the Juniper certification JNCIS (Juniper

Networks Certified Specialist) using the network simulator program GNS3

(Graphical Network Simulator).



2 Introducción y Objetivos

La situación ideal en un entorno profesional de trabajo sería que todo funcionara de una

forma correcta indefinidamente. Lo mismo ocurre con la infraestructura de red que da

soporte a todo ello, la cual es instalada y configurada con el objetivo de que esté

funcionando correctamente durante todo el tiempo posible. Pero la realidad es otra, ya

que los problemas que ocurren en otros ámbitos profesionales, también aparecen en forma

de problemas técnicos en el funcionamiento interno de una red. Es por ello, que cada día

son más importantes las tareas de análisis y mantenimiento de la misma. Dichas tareas

suelen realizarse en períodos de inactividad de la red, para que afecte lo menos posible al

rendimiento de la misma.

Por otra parte, antes de poner en funcionamiento una red, es conveniente haber realizado

una serie de pruebas previas para analizar el correcto funcionamiento de la misma. Es

evidente la inviabilidad que existe de que todas estas pruebas previas, así como las tareas

de análisis de comportamientos posteriores y demás, sean realizadas directamente sobre

equipamiento físico real, ya que el coste asociado a las mismas, entre otras cosas, harían

muy complejas y costosas todas estas tareas.

Por todo ello, surge la necesidad de que existan herramientas software capaces de emular

el comportamiento físico real que tienen los dispositivos que forman la infraestructura de

red. Gracias a estas herramientas software, el administrador de red podrá realizar todas

las pruebas necesarias antes de la implantación final de la red, así como su posterior

análisis y mantenimiento de la misma. Una vez el administrador de red sea consciente del

comportamiento que tiene la red bajo determinadas condiciones, podrá comprar el

equipamiento físico para montar la red con cierta seguridad de que se obtendrá el

comportamiento deseado.



Otro motivo para la utilización de estas herramientas de simulación sería lo relacionado a

tareas de aprendizaje. Cada día son más necesarios los profesionales altamente

cualificados para llevar a cabo la instalación y puesta en marcha de las infraestructuras de

red, así como su posterior mantenimiento. Dichos profesionales necesitan ser previamente

preparados técnicamente para posteriormente ser capaces de desarrollar sus funciones de

una forma adecuada. Estas tareas de aprendizaje serían mucho más complicadas y

costosas si no existieran herramientas software de simulación de redes, ya que es inviable

que cada técnico dispusiera de todo el equipamiento físico real para realizar pruebas

sobre el mismo.

Existen actualmente varios programas capaces de emular el comportamiento físico real de

cualquier infraestructura de red, independientemente de la tecnología empleada (Cisco,

Juniper, Huawei, etc.). Dichos programas son cada vez más avanzados, ya que mientras

que al comienzo sólo eran capaces de simular ciertas configuraciones básicas de los

dispositivos, actualmente la diferencia entre el comportamiento físico real y el emulado

por dichos programas es cada vez menor. Dicho esto, está claro que las prestaciones que

pueden conseguirse con equipamiento físico son superiores.

El programa utilizado en nuestro Trabajo Fin de Máster (en adelante, TFM) será GNS3

(Graphical Network Simulator), y la tecnología empleada, Juniper. Concretamente,

analizaremos el comportamiento de algunas características de enrutamiento dinámico

avanzado en entornos virtuales mediante tecnología Juniper. Para ello, realizaremos los

laboratorios correspondientes a la parte de enrutamiento de la certificación JNCIS (Juniper

Networks Certified Specialist) de Juniper.

Los principales objetivos marcados en el presente TFM serán los siguientes:

Realizar una breve introducción a la tecnología Juniper para conocer algunas de las

características más importantes que presenta dicha tecnología.

Analizar las ventajas que presenta, así como la configuración de las mismas, el

programa de simulación de redes GNS3.



Describir algunas características básicas de enrutamiento dinámico avanzado, para

posteriormente ponerlas en práctica en los laboratorios del JNCIS de Juniper.

Llevar a cabo el montaje y simulación en GNS3 de los laboratorios correspondientes a

la parte de enrutamiento de la certificación JNCIS de Juniper. Dichos laboratorios

incluyen, entre otras cosas, la configuración de varios protocolos de enrutamiento

dinámico (OSPF, IS-IS y BGP), así como otras características de enrutamiento

avanzado (balanceo de carga, filtros, túneles GRE, IPv6, VRRP, etc.).

Comprobar el correcto funcionamiento de dichos laboratorios, así como posibles

problemas encontrados en los mismos.

Una vez detectados dichos problemas, analizar sus posibles causas y encontrar

soluciones a los mismos.

Finalmente, comentar las líneas futuras que tendría este trabajo, para el caso de querer

seguir avanzando en la simulación de escenarios virtuales.



3 Simulación de Redes Juniper en Entornos Virtuales

El principal objetivo de este trabajo es comprobar el correcto funcionamiento de

escenarios de enrutamiento dinámico avanzado en entornos virtuales. Dichas pruebas

serán llevadas a cabo en los laboratorios posteriores. Pero antes, hemos de aclarar algunos

conceptos básicos sobre el programa que vamos a utilizar en este trabajo para simular

dichas redes (GNS3), así como hacer una breve descripción de las principales

características que presenta la tecnología Juniper, ya que los laboratorios realizados son

los correspondientes a la parte de enrutamiento de la certificación JNCIS de Juniper.

3.1 Tecnología Juniper

Como sabemos, existe una amplia variedad de fabricantes de dispositivos de red, pero

sólo algunos de ellos presentan una amplia cuota de mercado (Cisco, Juniper, Huawei,...).

En nuestro caso, hemos decidido realizar este trabajo utilizando tecnología Juniper, la cual

está tomando bastante fuerza a nivel mundial, sobre todo en Europa.

Figura 1: Logotipo de Juniper Networks

Dado que el objetivo de este trabajo no es entrar en detalle en dicha tecnología,

simplemente vamos a pasar a describir algunos aspectos que consideramos importantes a

la hora de familiarizarse con el entorno Juniper.

Una de las peculiaridades que tiene Juniper es su sistema operativo, el llamado JUNOS.

JUNOS es un sistema operativo de red cuyo kernel está basado en el sistema operativo



FreeBSD de UNIX, un sistema de software abierto. Entre sus principales ventajas destacan

su robustez, modularidad y escalabilidad.

Figura 2: Logotipo del sistema operativo JUNOS

Todas las plataformas que corren el sistema operativo JUNOS usan el mismo código

fuente base dentro de sus imágenes específicas de cada plataforma, es decir, que se

asegura una manera de trabajar muy consistente entre todas las plataformas que corren

JUNOS. Además, debido a que la mayoría de características y servicios son configurados

y gestionados del mismo modo, las tareas de configuración y mantenimiento dentro de la

red serán simplificadas.

Otro aspecto importante a tener en cuenta del sistema operativo JUNOS es la separación

que presenta entre el plano de control y el plano de reenvío (control plane & forwarding

plane). Es decir, los procesos que controlan los protocolos de enrutamiento y conmutación

están separados de los procesos que reenvían frames o paquetes. Ésta es una de las

principales razones por las que JUNOS puede soportar diferentes plataformas con un

código base común.

Figura 3: Separación de los planos de control y reenvío en JUNOS



En la figura de arriba podemos observar la separación existente entre los planos de

control y reenvío. En el plano de control encontramos el RE (Routing Engine), el cual es el

cerebro de las plataformas, es decir, el responsable de hacer funcionar los protocolos y la

administración del sistema. El RE está basado en una arquitectura X86 o PowerPC,

dependiendo de la plataforma específica donde corra el sistema operativo JUNOS.

Mantiene las tablas de enrutamiento y de reenvío (routing & forwarding tables).

El PFE (Packet Forwarding Engine) normalmente corre en hardware separado y es

responsable del reenvío de paquetes. Normalmente, el PFE usa ASICs (Application-Specific

Integrated Circuits) para aumentar el rendimiento. El PFE recibe la FT (Forwarding Table)

desde el RE a través de un enlace interno. Podríamos decir que en el PFE habrá una

especie de caché local para no tener que acceder siempre al RE cada vez que se tenga que

reenviar un paquete. Debido a que el RE provee la "inteligencia", el PFE puede trabajar

simplemente "aceptando órdenes", consiguiendo así un alto grado de estabilidad y

rendimiento determinista.

Por último, para finalizar esta breve introducción al mundo Juniper, es conveniente

comentar que Juniper, al igual que otros fabricantes, presenta una serie de certificaciones

para que los expertos del sector TIC puedan estar actualizados con un continuo

aprendizaje sobre las últimas novedades en cuanto a tecnología se refiere. Los laboratorios

que vamos a realizar posteriormente están basados en la certificación JNCIS (Juniper

Networks Certified Specialist). Dicha certificación se divide en dos partes: Una parte de

switching (layer 2 protocols, spanning-tree, etc.) y otra de routing (layer 3 protocols, IPv6,

etc.). Nuestro trabajo está enfocado en esta segunda parte: JNCIS-Routing.

Figura 4: Logotipo de la certificación JNCIS



3.2 Simulador de redes GNS3

Existen varios programas capaces de simular redes y analizar el comportamiento de las

mismas. En nuestro caso, debido entre otras cosas a su fácil manejo e intuitiva interfaz

gráfica, así como su compatibilidad con la mayoría de tecnologías (Cisco, Juniper,...),

hemos decidido utilizar GNS3 (Graphical Network Simulator), un software de código abierto

capaz de simular redes complejas consiguiendo un rendimiento muy cercano al de redes

físicas reales.

Figura 5: Logotipo de GNS3

Con el objetivo de proporcionar simulaciones completas y precisas, GNS3 actualmente

utiliza los siguientes emuladores para ejecutar los mismos sistemas operativos que se

ejecutan en redes físicas reales:

Dynamics: Para el IOS de Cisco.

VirtualBox: Para S.O. de escritorio y servidores, así como del JunOS de Juniper.

Qemu: Emulador genérico de código abierto, que ejecuta Cisco ASA, PIX y el IPS.

En nuestro caso, debido a que vamos a trabajar con el sistema operativo JunOS de Juniper,

utilizaremos VirtualBox.

Figura 6: Logotipo de VirtualBox



3.2.1 Instalación y Configuración de Olivas en GNS3

El objetivo de este trabajo es conseguir simular y analizar el comportamiento de

escenarios de enrutamiento avanzado en entornos virtuales mediante tecnología Juniper,

es decir, que los dispositivos utilizados en dichos escenarios (en su mayoría, routers)

deberán correr el sistema operativo JUNOS. Una Oliva es el apodo utilizado para referirse

al software JUNOS, pero ejecutándose sobre un PC normal, es decir, sería el sistema

operativo JUNOS emulado en entornos virtuales.

Una cosa importante a tener en cuenta es que no se trata de una versión especial limitada

o algo por el estilo, si no del mismo software convencional que se carga en los equipos

físicos Juniper. Estas Olivas se utilizan normalmente con fines educativos o de

investigación, facilitando el acceso a equipamiento Juniper sin necesidad de tener que

comprar los equipos físicos, con lo cual es posible trabajar en un entorno Juniper de una

forma económica.

Dado que nuestro objetivo en el presente trabajo no es la creación de una Oliva en sí, lo

que haremos será conseguirla directamente (por ejemplo, descargándola de Internet) y la

configuraremos para su correcto funcionamiento y puesta en marcha sobre GNS3. Para

ello, seguiremos los siguientes pasos:

Paso 1. Descargar la Oliva

Una vez tengamos ya instalados previamente los programas GNS3 y VirtualBox,

pasamos a descargar la Oliva en cuestión. En nuestro caso, la Oliva que vamos a

utilizar en todos los laboratorios será la versión JunOS Olive 12.1R1.9.

[Para descargar la JunOS Olive 12.1R1.9, pinche aquí]

http://www.gns3.net/download/

https://www.virtualbox.org/wiki/Downloads

http://www.firedrive.com/file/D999D642F771461F



Paso 2. Convertir .img a .vdi

Una vez descargada la Oliva (en formato .img), el siguiente paso será convertirla en .vdi

(virtual disk image) para poder ejecutarla en VirtualBox. Para ello, utilizaremos la

aplicación que lleva incorporada VirtualBox y que nos permite convertir archivos .img

en .vdi. Se trata de VBoxManage. Lo haremos mediante la línea de comandos (cmd).

Figura 7: VirtualBox - Conversión de .img a .vdi mediante VBoxManage

Como podemos ver en la figura de arriba, ya se ha creado y guardado la Oliva en

formato .vdi. Se encuentra en la misma carpeta donde teníamos la .img.



Paso 3. Hacer X copias del archivo .vdi con diferentes nombres

Una vez tenemos la Oliva en formato .vdi, realizaremos las copias que sean necesarias

para el montaje de los posteriores laboratorios. Es decir, ahora mismo tenemos una

Oliva "virgen" (sin configurar), con lo cual, sería recomendable tener tantas copias de

esta Oliva como laboratorios vayamos a realizar, ya que de lo contrario, si primero

configuramos la Oliva y posteriormente realizamos las copias, la configuración de la

primera Oliva afectará a todas las demás, ya que se trata del mismo .vdi. La idea sería la

siguiente:

- JunOS-12.1R1.9-Lab1.vdi



- ...

NOTA: Otra opción sería cargar y descargar las configuraciones de los dispositivos mediante TFTP por

ejemplo, y guardarlas en un fichero .txt. En nuestros laboratorios, para evitar tener que cargar y descargar

las configuraciones de los dispositivos, hemos optado por la opción de tener ya de antemano tantas Olivas

"vírgenes" como laboratorios realizaremos.

Paso 4. Crear X máquinas virtuales con diferentes nombres (clones)

Una vez tengamos las Olivas "vírgenes" (un .vdi para cada laboratorio), lo que haremos

a continuación será crear para cada laboratorio las Olivas que sean necesarias, es decir,

si por ejemplo en un laboratorio necesitáramos montar cinco routers, necesitaremos

cinco Olivas independientes (cinco clones), una para cada router. Hemos de recordar

que cada Oliva será montada (a través de VirtualBox) como una máquina virtual en sí,

con lo cual, cada dispositivo tendrá que llevar incorporado su propia máquina virtual

con el sistema operativo JUNOS ejecutándose. Para realizar este paso, utilizaremos

VirtualBox.



Paso 4.1. Elección de Nombre y Sistema Operativo:

Al crear una máquina virtual con VirtualBox, lo primero que te piden es identificarla

con un nombre y elegir el sistema operativo. La nombraremos para poder diferenciar

cada Oliva, es decir, para saber a qué laboratorio corresponde y dentro del mismo, a qué

dispositivo (esto se hará clonando las Olivas). Como sistema operativo elegimos la

versión FreeBSD (recordad que JUNOS está basado en FreeBSD de UNIX).

Figura 8: VirtualBox - Nombre y Sistema Operativo de la VM



Paso 4.2. Tamaño de memoria:

En principio, y para no tener problemas, elegiremos un tamaño de memoria de 512 MB.

Posteriormente, si se considerara oportuno, este tamaño podría reducirse.

Figura 9: VirtualBox - Tamaño de memoria de la VM



Paso 4.3. Creación del disco duro:

A continuación, el siguiente paso será la creación del disco duro virtual. En nuestro

caso, simplemente tendremos que seleccionarlo, ya que disponemos de uno previamente.

Con lo cual, tendremos que elegir la tercera opción "Usar un archivo de disco duro

virtual existente" y seleccionar el archivo .vdi que hemos creado en pasos anteriores.

Figura 10: VirtualBox - Unidad de disco duro de la VM



Paso 4.4. Creación de la Máquina Virtual:

Por último, al pulsar el botón de "Crear" ya tendremos nuestra máquina virtual

corriendo el sistema operativo JUNOS de Juniper, es decir, ya tendremos nuestra Oliva

JunOS-12.1R1.9 preparada para poder utilizarla en cualquier dispositivo en GNS3.

Por supuesto, una vez creada la máquina virtual, tendremos la oportunidad de

modificar cualquier ajuste de la misma en la opción "Configuración" de VirtualBox.

Figura 11: VirtualBox - Creación de la VM



Paso 4.5. Creación de clones:

Finalmente, para poder montar y ejecutar varios dispositivos corriendo estas máquinas

virtuales en un mismo escenario, es necesario clonar dichas máquinas virtuales para

evitar que las configuraciones en un dispositivo afecten al resto.

La clonación de una máquina virtual con VirtualBox se realiza de una forma sencilla,

simplemente hay que tener en cuenta la activación de la casilla "Reinicializar la

dirección MAC de todas las tarjetas de red" a la hora de clonar, ya que de lo

contrario la nueva máquina virtual sería idéntica a la original en cuanto a capa 2 se

refiere, produciéndose problemas de conectividad entre ambos dispositivos una vez

montados en el escenario.

Figura 12: VitualBox - Clonación de VMs



Figura 13: VirtualBox - Nombre de la clonación

Figura 14: VirtualBox - Tipo de clonación



Paso 5. Crear X VirtualBox Guests en GNS3 con diferentes nombres

Ya tenemos tantas máquinas virtuales como dispositivos vamos a utilizar en los

laboratorios. Cada máquina virtual (con el JUNOS incorporado) será montada en el

dispositivo que sea conveniente. Este paso se realiza ya directamente desde GNS3.

Paso 5.1. Verificar que existe conexión entre GNS3 y VirtualBox:

Una vez creadas las máquinas virtuales (VMs) con VirtualBox, el siguiente paso será

que desde GNS3 puedan seleccionarse dichas VMs. En primer lugar, debemos verificar

que existe una conexión correcta entre GNS3 y VirtualBox. Para ello:

Edit > Preferences > VirtualBox > General Settings > Test Settings

Figura 15: GNS3 - Conexión con VirtualBox



Paso 5.2. Importar VMs desde VirtualBox a GNS3:

Una vez comprobado que no existen problemas de compatibilidad entre las versiones de

GNS3 y VirtualBox, pasamos a importar las VMs creadas anteriormente desde

VirtualBox a GNS3. Para ello:

Edit > Preferences > VirtualBox > VirtualBox Guest

En este apartado, podremos nombrar la VM (lo normal es ponerle el nombre del

dispositivo donde se va a montar dicha VM), seleccionar la VM en cuestión (habrá un

listado con todas las VMs creadas anteriormente en VirtualBox; en caso de no aparecer

alguna VM, habrá que pinchar en el botón "Refresh VM List" que aparece más abajo),

elegir el número de NICs que tendrá el dispositivo, etc. Finalmente, al guardar (botón

"Save"), nos aparecerá la VM en el listado de abajo "VirtualBox Virtual Machine" para

poder ser seleccionada posteriormente.

Figura 16: GNS3 - Importar VMs desde VirtualBox



Paso 5.3. Selección de dispositivos en GNS3:

Ya tenemos incorporadas las VMs desde VirtualBox a GNS3. Ahora ya sólo tenemos

que seleccionar los dispositivos que queremos utilizar en nuestro laboratorio. En este

caso, tendremos que seleccionar los dispositivos llamados "VirtualBox Guest", los

cuales llevarán incorporado la VM en cuestión. En la siguiente figura podemos apreciar

con claridad este procedimiento.

Figura 17: GNS3 - Selección de dispositivos



Paso 5.4. Creación y puesta en marcha de un escenario completo en GNS3:

El procedimiento a seguir para crear un escenario completo es muy sencillo. Basta con

repetir lo explicado en el Paso 5.3 para cada uno de los dispositivos que formarán el

escenario virtual. La conexión entre dispositivos, el cambio de símbolo (botón derecho

sobre el dispositivo y "Change Symbol") y otros ajustes básicos, son muy intuitivos

gracias a la interfaz fácil y amigable que presenta GNS3.

En la siguiente figura, de ejemplo, podemos ver el escenario correspondiente al

laboratorio 1. Para que se inicialicen las máquinas virtuales que llevan incorporadas los

dispositivos, y así poder configurarlas, basta con ejecutar el botón "Start" que aparece

en el menú de arriba. Una vez inicializadas, ya podremos entrar en la consola de cada

dispositivo (botón derecho sobre el dispositivo > "Console") para configurarlo

convenientemente.

Figura 18: GNS3 - Creación de un escenario completo



3.2.2 Simulación de PCs en GNS3

Además de los dispositivos de red, lo normal es que en los laboratorios aparezcan PCs,

principalmente para comprobar la conectividad existente y demás. En GNS3, existen

varias formas de simular dichos PCs (routers actuando como PCs, virtualizando un PC

con VirtualBox, etc.). Sin embargo, dado que simplemente se van a utilizar dichos PCs

para realizar algunos pings y traceroutes, hemos adoptado la forma más sencilla que tiene

GNS3 para simular PCs: "Virtual PC Simulator (VPCS)".

VPCS suele llevarlo incorporado GNS3 (en caso de no ser así, puede descargarse

fácilmente desde aquí). Se trata de un simple programita que usa puertos UDP para

conectar el simulador con cada uno de los PCs simulados (nos proporciona hasta un total

de 9 PCs). Su principal ventaja es el escaso uso que hace de memoria y CPU, además de su

extremada facilidad para usarse.

Paso previo: Hacer que el "Computer" de GNS3 sea de tipo "Cloud"

El objetivo de esto es que un dispositivo "Computer" lleve incorporadas todas las

conexiones UDP necesarias para poder simularse mediante el programa VPCS.

Para ello: Edit > Symbol Manager

Figura 19: VPCS - Configuraciones previas en GNS3

http://sourceforge.net/projects/vpcs/



A continuación, vamos a ver un ejemplo de cómo usar VPCS:

Paso 1. Selección de PCs

En nuestro caso, vamos a elegir dos PCs (PC_A y PC_B), los cuales van a estar

conectados a través de un switch (recordamos que GNS3, aunque aún no es capaz de

realizar switching avanzado, sí dispone de switches capaces de realizar las funciones

básicas de capa 2). Las conexiones de los PCs van a ser las siguientes:

PC_A → nio_udp:30000:127.0.0.1:20000

PC_B → nio_udp:30001:127.0.0.1:20001

Figura 20: VPCS - Selección de PCs virtuales

NOTA: Existen nueve conexiones UDP, una para cada PC virtual. Su correspondencia con los PCs

simulados en VPCS es la siguiente:

nio_udp:30000:127.0.0.1:20000 → VPCS [1]

nio_udp:30000:127.0.0.1:20001 → VPCS [2]

...

nio_udp:30000:127.0.0.1:20008 → VPCS [9]

Con lo cual, el PC_A corresponderá al VPCS [1] y el PC_B al VPCS [2].



Paso 2. Puesta en marcha de VPCS

Una vez tenemos los PCs sobre el escenario, pasamos a abrir VPCS. Para ello:

Tools > VPCS

Una vez abierto, podemos "movernos" de un PC virtual (VPCS) a otro simplemente

escribiendo el número del PC virtual donde queremos situarnos.

Figura 21: VPCS - Puesta en marcha de los PCs virtuales

Paso 3. Configuración de los VPCS

Una vez tenemos abierto el programa, pasamos a configurar los PCs virtuales (VPCS)

son sus respectivas IPs, máscaras de red y direcciones gateway.

Figura 22: VPCS - Configuración de los PCs virtuales



Paso 4. Comprobación de que existe conectividad entre ambos VPCS

Finalmente, realizaremos un par de pruebas (ping y traceroute) para comprobar el

perfecto funcionamiento de ambos PCs virtuales (recordad que el VPCS[1] corresponde

al PC_A y el VPCS[2] al PC_B).

Figura 23: VPCS - Comprobación de conectividad entre PCs virtuales



4 Enrutamiento Dinámico Avanzado

Como hemos comentado anteriormente, los laboratorios que realizaremos posteriormente

serán los correspondientes a la certificación JNCIS de Juniper. En concreto, dicha

certificación se divide en dos partes bien diferenciadas: Switching y Routing. Los

laboratorios que vamos a analizar en el presente trabajo son los correspondientes a esta

segunda parte, es decir, a todo lo relacionado con el enrutamiento avanzado (JNCIS-

Routing). Es por ello, que vemos conveniente hacer un breve repaso de los principales

conceptos sobre enrutamiento que podremos encontrarnos después en los laboratorios,

para así tener claros dichos conceptos a la hora de realizar el montaje y posterior análisis

de los laboratorios.

4.1 Enrutamiento Estático

Un dispositivo de capa 3 (normalmente un router) puede aprender rutas hacia redes

remotas de dos formas diferentes:

Manualmente (Enrutamiento Estático): Las redes remotas son introducidas

manualmente en la tabla de enrutamiento usando rutas estáticas, es decir, el

administrador de red configura manualmente en el dispositivo de capa 3 las rutas

adecuadas hacia la red de destino deseada.

Dinámicamente (Enrutamiento Dinámico): Las redes remotas son aprendidas

automáticamente usando protocolos de enrutamiento dinámico, es decir, el

administrador de red configura en el dispositivo de capa 3 algún protocolo de

enrutamiento dinámico, el cual será el encargado de aprender automáticamente las



rutas adecuadas hacia todas las redes de destino (donde también tendrá que haber

sido configurado dicho protocolo de enrutamiento).

El enrutamiento estático presenta algunas ventajas sobre el enrutamiento dinámico. Éstas

serían las más importantes:

- Mayor seguridad, ya que las rutas no son anunciadas sobre la red.

- Menor consumo de ancho de banda y CPU, ya que no existe intercambio de

mensajes entre dispositivos de capa 3 para actualizar las tablas de enrutamiento.

- El camino que recorre un paquete a través de una ruta estática es siempre

conocido.

Por otra parte, el enrutamiento estático también presenta algunas desventajas respecto al

enrutamiento dinámico. Éstas serían algunas de ellas:

- Mayor consumo de tiempo a la hora de realizar configuraciones iniciales y su

posterior mantenimiento.

- La configuración manual es más propensa a errores, especialmente en grandes

redes.

- Se requiere la intervención del administrador para cambiar información de rutas.

- Baja escalabilidad, ya que conforme va creciendo la red, el mantenimiento llega a

ser muy costoso.

- Requiere un conocimiento completo de la red entera para llevar a cabo su

implementación.

Una vez vistas las principales ventajas e inconvenientes del enrutamiento estático,

pasamos a describir cuándo se usa. El enrutamiento estático tiene tres usos principales:

o En redes pequeñas donde no se espera un crecimiento significativo.

o En redes stubs, es decir, redes que sólo pueden ser accedidas por una ruta simple a

través de un solo router.



o En rutas por defecto, es decir, una simple ruta que representa el camino hacia

cualquier red que no tiene una ruta establecida más específica en la tabla de

enrutamiento. A esta ruta se le llama ruta por defecto y aparece en la tabla de

enrutamiento como 0.0.0.0/0.

NOTA: Algunas características más avanzadas del enrutamiento estático, así como la configuración de las

mismas, serán tratadas y puestas en práctica directamente a lo largo de los laboratorios posteriores.

4.2 Enrutamiento Dinámico

En el punto anterior ya hemos visto en qué consiste el enrutamiento dinámico.

Básicamente, consiste en la configuración de protocolos de enrutamiento dinámico en los

dispositivos de capa 3, los cuales serán los responsables de aprender las rutas hacia las

redes remotas automáticamente. Los principales objetivos que se buscan configurando

dichos protocolos son los siguientes:

- Descubrir redes remotas.

- Mantener actualizadas las tablas de enrutamiento.

- Elegir el mejor camino hacia las redes de destino.

- Habilidad para encontrar un nuevo mejor camino en caso de caerse el actual.

Los principales componentes de los protocolos de enrutamiento son los siguientes:

o Estructuras de datos: Tablas o bases de datos de referencia que los protocolos usan

para sus operaciones. Esta información es mantenida en la RAM.

o Intercambio de mensajes: Los protocolos usan varios tipos de mensajes para

descubrir routers vecinos, intercambiar información entre ellos y otras tareas, con el

objetivo de mantener actualizadas las tablas de enrutamiento.

o Algoritmos: Los protocolos usan algoritmos para calcular y determinar la mejor ruta

hacia un destino específico.



A continuación, pasamos a describir brevemente los pasos que siguen los protocolos de

enrutamiento dinámico una vez se encuentran configurados en los dispositivos de capa 3,

para conseguir tener una red donde todos los dispositivos implicados contienen

información específica sobre todas las rutas hacia redes remotas, es decir, lo que se conoce

como una red convergida.

1º. Encendido de dispositivos de capa 3: Una vez encendidos los routers en cuestión, éstos

cargan sus configuraciones establecidas anteriormente.

2º. Aprendizaje de interfaces directamente conectadas: Lo primero que hace un router,

una vez cargada su configuración inicial, es aprender sobre sus interfaces, es decir, sobre

las redes que están configuradas en ellas.

3º. Intercambio de mensajes entre routers: Todos aquellos routers configurados con un

determinado protocolo de enrutamiento dinámico, se intercambiarán mensajes que

contienen información específica sobre cada router y sus interfaces.

4º. Actualización y cálculo de la mejor ruta: Una vez los routers se han intercambiado

mensajes que contienen información específica de cada router, cada uno de estos routers

actualiza sus tablas y calcula la mejor ruta hacia las redes remotas.

5º. Red convergida: Cuando todos los routers implicados tengan actualizadas sus tablas de

enrutamiento con las mejores rutas instaladas, podemos considerarla una red convergida.

4.2.1 Métrica y Distancia Administrativa

Antes de pasar a describir los diferentes protocolos de enrutamiento dinámico que

existen, es conveniente tener claros un par de conceptos: Métrica y Distancia

Administrativa.

El concepto de métrica se refiere al coste que tendrá una ruta desde un dispositivo fuente

a otro destino. Los protocolos de enrutamiento determinan el mejor camino hacia una red



destino basándose en la ruta con menor coste, es decir, la que presente una métrica menor.

Además, hay que tener en cuenta que cada protocolo usa diferentes parámetros para el

cálculo de la métrica (número de saltos, ancho de banda, retardos, etc.), con lo cual, cada

protocolo obtendrá una métrica diferente hacia el destino.

En cuanto a la distancia administrativa, simplemente decir que se trata de la medida

usada por los dispositivos de capa 3 para seleccionar la mejor ruta cuando hay dos o más

rutas diferentes hacia el mismo destino para dos protocolos de enrutamiento. Podríamos

decir que la distancia administrativa define la fiabilidad de un protocolo de enrutamiento,

ya que en caso de existir varias rutas hacia un mismo destino, prevalecerá aquella

aprendida por el protocolo cuya distancia administrativa sea menor.

Por último, hay que tener en cuenta que la distancia administrativa asignada a cada

protocolo de enrutamiento será diferente dependiendo de la tecnología empleada. Por

ejemplo, a continuación podemos observar las distancias administrativas asignadas

cuando trabajamos con tecnología Cisco y cuando trabajamos con Juniper (en Juniper, la

distancia administrativa se llama "preferencia de ruta"):

PROTOCOLO CISCO (Distancia Administrativa)

JUNIPER (Preferencia de Ruta)

Directamente conectada 0 0

Ruta Estática 1 5

EIGRP (ruta sumarizada) 5 -

OSPF (interna) - 10

IS-IS (nivel 1 interna) - 15

IS-IS (nivel 2 interna) - 18

BGP (externa) 20 -

EIGRP (interna) 90 -

OSPF 110 -

IS-IS 115 -

RIP 120 100

OSPF (externa) - 150

IS-IS (nivel 1 externa) - 160

IS-IS (nivel 2 externa) - 165

EIGRP (externa) 170 -

BGP - 170

BGP (interna) 200 -



4.2.2 Protocolos IGP (Interior Gateway) y EGP (Exterior Gateway)

Los protocolos de enrutamiento dinámico pueden ser clasificados de diferentes maneras,

atendiendo a su propósito (IGP o EGP), operativa (vector distancia, estado de enlace,...) o

comportamiento (con clase o sin clase). En el siguiente diagrama podemos observar una

clasificación de dichos protocolos:

Figura 24: Clasificación de protocolos de enrutamiento dinámico

Atendiendo al propósito que tengan dichos protocolos, podemos diferenciar entre:

IGPs (Interior Gateway Protocols): Usados para el enrutamiento dentro de un AS

(Autonomous System). Compañías, organizaciones e incluso proveedores de servicios

usan un IGP en sus redes internas. Ejemplos de IGPs: RIP, EIGRP (propietario de

Cisco), OSPF e IS-IS.

EGPs (Exterior Gateway Protocols): Usados para el enrutamiento entre ASs.

Proveedores de servicios y grandes compañías pueden interconectarse usando un

EGP. BGP (Border Gateway Protocol) es el único EGP actual viable que se usa y es el

protocolo de enrutamiento oficial usado por Internet.

Protocolos de Enrutamiento Dinámico

IGPs (Interior Gateway Protocols)

Vector Distancia

RIP EIGRP

Estado de Enlace

OSPF IS-IS

EGPs (Exterior Gateway Protocols)

Vector Camino

BGP



A continuación, en la siguiente figura podemos observar un ejemplo del empleo de estos

protocolos. En ella, podemos observar las diferencias que existen entre los protocolos

IGPs usados dentro de cada AS (en este caso, RIP, EIGRP, OSPF y IS-IS) y los protocolos

EGPs usados entre ASs (en este caso, el protocolo usado es BGP).

Figura 25: Ejemplo de protocolos IGPs y EGPs

NOTA: Las características más avanzadas de estos protocolos de enrutamiento, así como su configuración y

puesta en marcha, serán tratadas directamente en los laboratorios posteriores. Concretamente, los protocolos

de enrutamiento que serán tratados en dichos laboratorios serán: OSPF (Lab.3), BGP (Lab.4) e IS-IS (Lab.8).

4.2.3 Protocolos Vector distancia y Estado de Enlace

Otra clasificación de los protocolos de enrutamiento dentro de los referidos como IGPs,

así como sus principales características, sería la siguiente:

Protocolos Vector Distancia:

- Las rutas se anuncian como vectores (con su distancia y dirección).

- Se crea una visión incompleta de la topología de red.

- Por lo general, se realizan actualizaciones periódicas.

- Ejemplos: RIP (RIPv1 y RIPv2) y EIGRP (propietario de Cisco).



Protocolos Estado de Enlace (Link-State):

- Se crea una visión completa de la topología de red.

- Las actualizaciones no son periódicas (sólo se dan cuando se producen cambios).

- Ejemplos: OSPF e IS-IS.

En las descripciones comentadas, ya podemos comprobar las ventajas que presentan los

protocolos de Estado de Enlace frente a los de Vector Distancia. No obstante, habrá que

tener en cuenta a la hora de elegir que dichos protocolos de Estado de Enlace también

requieren un mayor ancho de banda para su correcto funcionamiento, así como mayores

requerimiento de memoria y CPU.

4.3 IPv6

Debido al imparable crecimiento que ha tenido Internet en los últimos años, al espacio

limitado de direcciones IPv4 existente y a problemas con NAT (Network Address

Translation), así como las perspectivas que se presentan con el IoT (Internet of Things), el

paso de IPv4 a IPv6 es cada vez más necesario. De hecho, varios estudios muestran que

los RIRs (Regional Internet Registry), organismos encargados de la asignación de

direcciones IP, se quedarán sin direcciones IPv4 entre los años 2015 y 2020.

Las principales características que presentan las direcciones IPv6 son las siguientes:

- Las direcciones IPv6 están formadas por 128 bits (en IPv4 eran 32 bits), expresadas en

formato hexadecimal. La distribución de esos 128 bits, normalmente, es la siguiente:

Figura 26: Direcciones IPv6



- Además de direcciones unicast (un destino) y multicast (varios destinos), aparecen las

direcciones anycast (algunos destinos dentro de un grupo).

- Desaparecen las direcciones broadcast. Sin embargo, hay una dirección IPv6 all-nodes

multicast que esencialmente tiene el mismo significado.

- No usa la máscara de subred para diferenciar la parte de red y parte de usuario. En su

lugar, usa lo que se llama longitud de prefijo. (Ej: 2001:ODB8:ACAD::/64)

NOTA: El objetivo de este apartado es simplemente introducir algunos conceptos básicos sobre IPv6, ya que

se va a realizar un laboratorio (en concreto, el Lab.7) donde se configurarán y probarán direcciones IPv6. No

obstante, queda fuera del alcance de nuestro trabajo la explicación de otras características más avanzadas de

IPv6 (tipos de direcciones IPv6, SLAAC, EUI-64, subnetting en IPv6, etc.).

Por último, indicar que la migración de IPv4 a IPv6 va a durar varios años. La IETF

(Internet Engineering Task Force) ha creado varios protocolos y herramientas para ayudar a

llevar a cabo dicha migración. Estas técnicas de migración están divididas en tres

categorías:

o Dual Stack: Permite a IPv4 e IPv6 coexistir en la misma red. Los dispositivos corren

los stack de protocolos IPv4 e IPv6 simultáneamente.

Figura 27: Migración a IPv6 (Dual Stack)



o Tunneling: Permite transportar un paquete IPv6 sobre una red IPv4. El paquete IPv6

es encapsulado dentro de un paquete IPv4 (lo veremos en el Lab.7).

Figura 28: Migración a IPv6 (Tunneling)

o Translation: NAT64 (Network Address Translation 64) permite a un dispositivo con IPv6

comunicarse con dispositivos con IPv4 usando una técnica de traducción similar al

NAT de IPv4. Un paquete IPv6 es traducido a un paquete IPv4, y viceversa.

Figura 29: Migración a IPv6 (NAT64)



4.4 Conectividad Segura mediante VPN (Virtual Private Network)

Una de las cosas más importantes a tener en cuenta a la hora de montar una red es la

seguridad, ya que de lo contrario dicha red podría ser vulnerable ante cualquier amenaza.

En los últimos años, ha aparecido una técnica llamada VPN (Virtual Private Network), con

el objetivo de establecer conexiones punto a punto seguras. Se trata de una red privada

creada vía túnel sobre una red pública, normalmente Internet. Para implementar una VPN

es necesario un VPN gateway (normalmente un router o firewall).

Entre las principales ventajas que presenta una VPN están las siguientes:

- Ahorro de costes.

- Alta escalabilidad.

- Compatibilidad con otras tecnologías.

- Seguridad.

Existen dos tipos de VPNs:

o Punto a Punto:

- Es una extensión de las redes WAN clásicas (línea alquilada o Frame Relay). Debido

a que la mayoría de corporaciones tienen acceso a Internet actualmente, esas

conexiones WAN clásicas son reemplazadas por VPNs punto a punto.

- Los dispositivos en ambos lados de la conexión VPN son conscientes de la

configuración de la VPN de antemano.

- Los hosts internos no tienen conocimiento de que existe una VPN.

- Los hosts finales envían y reciben el tráfico TCP/IP normal a través de una puerta

de enlace VPN.



- La puerta de enlace VPN se encarga de encapsular y cifrar el tráfico de salida para

todo el tráfico de un sitio en particular.

- La puerta de enlace VPN envía entonces el tráfico a través de un túnel VPN a

través de Internet hacia la puerta de enlace VPN del otro sitio.

- Al recibirlo, la puerta de enlace VPN retira los encabezados, descifra el contenido y

retransmite el paquete hacia el host de destino dentro de su red privada.

- Ejemplo de VPN punto-a-punto: GRE (Generic Routing Encapsulation)

Figura 30: VPN Punto-a-Punto

o Acceso Remoto:

- Soporta las necesidades de tele-trabajadores, usuarios móviles y extranet.

- Presenta una arquitectura cliente/servidor, donde el cliente VPN (host remoto)

consigue un acceso seguro a la red corporativa a través de un servidor VPN

situado en el borde de la red corporativa.

- Se utiliza para conectar hosts individuales que deben acceder a su red corporativa

de forma segura a través de Internet.



- Necesario instalar un software cliente VPN en dispositivo final del usuario móvil.

- Cuando el host intenta enviar todo el tráfico, el software cliente VPN encapsula y

encripta este tráfico y lo envía a través de Internet a la puerta de enlace VPN

situada en el borde de la red de destino.

- Ejemplos de VPN de acceso remoto: IPsec y SSL.

Figura 31: VPN Acceso Remoto

Las principales diferencias que existen entre IPsec y SSL son las siguientes:

SSL IPsec

Aplicaciones Web, email, ftp Todas

Encriptación Moderada a fuerte (40-256 bits) Fuerte (56-256 bits)

Autenticación Moderada Fuerte

Complejidad de

conexión Baja Media

Opciones de

conexión Cualquier dispositivo

Sólo dispositivos con

configuraciones específicas



4.5 Alta Disponibilidad mediante FHRP (First Hop Redundancy Protocols)

Debido, entre otras cosas, al espectacular aumento que ha experimentado el sector TIC, es

cada vez más importante que las infraestructuras de red garanticen un acceso ilimitado a

los servicios, así como una fiabilidad máxima. Existen muchas técnicas de redundancia

que permiten mantener en continuo funcionamiento todos los servicios ofrecidos por los

proveedores. No obstante, en este apartado nos vamos a centrar particularmente en una,

la llamada FHRP (First Hop Redundancy Protocolos).

Como sabemos, los dispositivos finales suelen ser configurados con una única dirección IP

como puerta de enlace predeterminada. Esta dirección no cambia, incluso si la red sufre

modificaciones. En el caso de que la dirección de puerta de enlace predeterminada sea

inalcanzable (debido, por ejemplo, a la caída de un enlace), el dispositivo local no podrá

tener acceso fuera de su red local hasta que se resuelva el problema, con la consiguiente

pérdida de la disponibilidad de los servicios que estaba utilizando.

Figura 32: Limitaciones sin características de Alta Disponibilidad



Para resolver este problema surge lo que se llama "router virtual". La idea es disponer de

dos o tres routers actuando como uno solo, compartiendo una dirección IP y una

dirección MAC. Un protocolo de redundancia provee el mecanismo necesario para que

uno de esos routers esté en modo activo (master) y el otro en modo standby (backup). En

caso de fallar el router master, será el router backup quien pase a funcionar de una forma

activa (este proceso es transparente para los dispositivos finales).

Figura 33: Alta Disponibilidad mediante FHRP

Existen varios protocolos FHRP que realizan estas funciones:

o Propietarios de Cisco:

- HSRP (Hot Standby Router Protocol)

- GLBP (Gateway Load Balancing Protocol)

o No propietarios:

- IRDP (ICMP Router Discovery Protocol)

- VRRP (Virtual Router Redundancy Protocol) NOTA: Su configuración y comportamiento serán analizados en el Lab.6



5 Laboratorios

Antes de empezar con los laboratorios, es conveniente explicar y aclarar algunas cosas

que deben tenerse en cuenta a la hora de realizar los laboratorios sobre GNS3. Está claro

que, aunque gracias a herramientas como GNS3 es posible simular escenarios y conseguir

que funcionen la mayoría de configuraciones realizadas sobre dispositivos como si éstos

fueran dispositivos físicos reales, hemos de tener en cuenta algunas limitaciones que nos

presentan este tipo de herramientas.

Con el objetivo de facilitar el montaje de escenarios y su posterior configuración y puesta

en marcha, previamente debemos considerar algunos ajustes realizados sobre los

escenarios. Las principales cosas a tener en cuenta en la realización de los laboratorios

serán las siguientes:

Simulación de la nube (Internet): Debido a que el objetivo a conseguir mediante la

simulación de una nube (Internet) es separar diferentes redes, se ha considerado

oportuno simular dicha nube simplemente mediante un router, ya que se consigue el

objetivo de separar redes y se simplifica muchísimo la implementación sobre GNS3.

En la figura siguiente se puede apreciar gráficamente lo comentado:

em1 (.1) em1 (.2)

172.20.66.0/30

Internet

(.1)

172.31.15.1

Internet Host

srx-1 srx-2

172.18.2.0/30(.2) em

3

(.1)

172.

18.1

.0/3

0

(.2) e

m3

em1 (.1) em1 (.2)

172.20.66.0/30

(.1)

172.31.15.1

Internet Host

srx-1 srx-2

172.18.2.0/30(.2) em

3

(.1)

172.

18.1

.0/3

0

(.2) e

m3

Internet

Caso Real Simulación

Figura 34: Simulación de la nube (Internet) en GNS3



Interfaces: Los dispositivos físicos reales presentan una amplia variedad de interfaces

(Ethernet, ATM, SONET, etc.). En GNS3, debido a que trabajaremos con máquinas

virtuales que emulan el comportamiento del sistema operativo Junos de cada

dispositivo, tan solo disponemos de un tipo de interfaces internas em, las cuales

simulan el comportamiento de interfaces ethernet, además de las interfaces loopback de

cada dispositivo (otras interfaces internas serán creadas automáticamente, pero no

tienen ninguna importancia a la hora de realizar los laboratorios). A continuación,

podemos observar un ejemplo de las interfaces de un dispositivo:

root@srx-1> show interfaces terse

Interface Admin Link Proto Local Remote

cbp0 up up

demux0 up up

dsc up up

em0 up up

em0.0 up up inet 10.210.14.133/26

em1 up up

em1.0 up up inet 172.20.77.1/30

gre 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:270f:fc70:ba5a

lsi up up

mtun up up

pimd up up

pime up up

pip0 up up

pp0 up up

tap up up

Equipos trabajando en paralelo: A la hora de realizar los laboratorios, los enunciados

de los mismos se refieren siempre a la configuración de un dispositivo en particular.

Hemos de tener en cuenta que para el correcto funcionamiento del escenario

completo, es OBLIGATORIO realizar las configuraciones necesarias en los demás

dispositivos presentes en el escenario, ya que de lo contrario no se irán cumpliendo los

objetivos planteados.



Routers virtualizados: Existen algunos laboratorios donde se habla de routers

virtualizados (routers virtuales creados dentro de otros routers reales). Debido a la

complejidad de crear un router virtual dentro de otro router real (cabe recordar que

estamos trabajando con routers cuyo sistema operativo ya es una máquina virtual en

sí), se ha considerado tratar a estos routers virtualizados como si fueran routers reales,

ya que además de simplificar el montaje en GNS3, conseguimos los mismos resultados

(NOTA: Estos routers serán nombrados como routers virtuales en los enunciados de los laboratorios, pero

serán tratados como routers reales).

Carga de configuraciones iniciales: Normalmente, al empezar cualquier laboratorio,

como paso previo, se lleva a cabo la carga de un paquete concreto donde están

presentes las configuraciones iniciales del dispositivo para después realizar los pasos

que te van indicando en cada laboratorio. Pues bien, debido a que no disponemos de

dichos paquetes, lo que hacemos es realizar individualmente en cada dispositivo las

configuraciones básicas iniciales, para así poder realizar el laboratorio conforme a las

configuraciones previas establecidas. A continuación, podemos ver un ejemplo de las

configuraciones básicas introducidas en un dispositivo (en concreto, en el router srx-1

del lab 6) como paso previo al inicio de cualquier laboratorio.

% Accedemos al router en modo "root" y ponemos una contraseña

Amnesiac (ttyd0)

login: root

root@% cli

root> configure

Entering configuration mode

[edit]

root# set system root-authentication plain-text-password

New password: ******

Retype new password: ******

% Creamos un Usuario nuevo:

- Nombre: lab6

- Clase: super-user (todos los privilegios)

- UID: 100 (identificación del dispositivo)

- Authentication: plain-text-password (no necesitamos encriptación)



[edit]

root# edit system login

[edit system login]

root# set user lab6 class super-user uid 100 authentication plain-text-password

New password: ******

Retype new password: ******

% Activamos cambios y volvemos al inicio para acceder como usuario

[edit system login]

root# commit and-quit

commit complete

Exiting configuration mode

root> exit

root@% exit

logout

Amnesiac (ttyd0)

login: lab6

Password: ******

% Cambiamos el nombre del dispositivo y activamos cambios

lab6> configure


[edit]

lab6# set system host-name srx-1

[edit]

lab6# commit

commit complete

[edit]

lab6@srx-1#

% Ya tenemos el router configurado para acceder a él con Usuario y Contraseña

A continuación, pasamos a realizar los laboratorios correspondientes a la parte de routing

de la certificación JNCIS de Juniper.



5.1 Lab 1: Protocol-Independent Routing

En este laboratorio se configurarán y monitorizarán características de enrutamiento

independientes de protocolos en dispositivos que ejecutan el sistema operativo Junos. En

este laboratorio, se utilizará la línea de comandos (CLI) para configurar y monitorizar

interfaces, rutas estáticas y agregadas, e instancias de enrutamiento.

El escenario con el que trabajaremos en este laboratorio es el siguiente:

em2 (.1)

em1 (.1)

em2 (.2)

em1 (.2)

172.20.66.0/30

172.20.77.0/30

Internet

em3 (.

2)

172.1

8.1.0

/30

(.1

) (.1) 172.18.2.0/30 (.2) em3

172.31.15.1

Internet Host

srx-1 srx-2

vr113 vr114

em4.113 (.1)

172.20.113.0/24

em1.113 (.10)

(.1) em4.114

172.20.114.0/24

(.10) em1.114

lo0: 192.168.1.1

lo0: 192.168.1.2

lo0: 192.168.2.1

lo0: 192.168.2.2

Tagged Interface

Figura 35: Escenario del Lab 1 "Protocol-Independent Routing"

Para completar este laboratorio, llevaremos a cabo las siguientes tareas:

o Parte 1: Comprobar y verificar el correcto funcionamiento de las interfaces de red.

o Parte 2: Configurar y monitorizar rutas estáticas y agregadas.

o Parte 3: Configurar instancias de enrutamiento y compartir rutas entre ellas

usando grupos de tablas de enrutamiento.



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

En esta parte del laboratorio, configurará las interfaces de red del dispositivo que le ha

sido asignado. A continuación, verificará el estado y correcto funcionamiento de las

interfaces y cómo el sistema añade dichas interfaces a las tablas de enrutamiento

correspondientes.

Paso 1.1. Sitúese en el nivel jerárquico [edit interfaces]. Fíjese en el diagrama de

red y configure las interfaces de su dispositivo asignado. Use VLAN-ID como

el valor de la unidad lógica para la interfaz etiquetada. Use la unidad lógica 0

para todas las demás interfaces.

[edit]

lab1@srx-1# edit interfaces

[edit interfaces]

lab1@srx-1# set lo0 unit 0 family inet address 192.168.1.1/32

[edit interfaces]

lab1@srx-1# set em1 unit 0 family inet address 172.20.77.1/30

[edit interfaces]


[edit interfaces]


[edit interfaces]

lab1@srx-1# set em4 vlan-tagging

[edit interfaces]

lab1@srx-1# set em4 unit 113 vlan-id 113

[edit interfaces]


Paso 1.2. Muestre la configuración de las interfaces para asegurarse que coincide con el

diagrama de red de este laboratorio. A continuación, ejecute el comando

commit-and-quit para activar la configuración y volver al modo

operacional.

[edit interfaces]

lab1@srx-1# show

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

vlan-id 113;

family inet {

address 172.20.113.1/24;

}

}

}

lo0 {

unit 0 {

family inet {

address 192.168.1.1/32;

}

}

}

[edit interfaces]

lab1@srx-1# commit and-quit

commit complete


Paso 1.3. Ejecute el comando show interfaces terse para verificar el estado actual

de las interfaces recientemente configuradas.

lab1@srx-1> show interfaces terse


cbp0 up up

demux0 up up

dsc up up

em0 up up

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.113 up up inet 172.20.113.1/24

gre 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:270f:fc70:ba5a

lsi up up

mtun up up

pimd up up

pime up up

pip0 up up

pp0 up up

tap up up

Pregunta (P, en adelante) - ¿Qué significan los estados Admin y Link en las interfaces que han sido

configuradas recientemente?

Respuesta (R, en adelante) - El estado Admin corresponde al estado "lógico" de la interfaz, el cual puede ser

activado o desactivado mediante comandos. En cambio, el estado Link corresponde

al estado "físico" de la interfaz, es decir, si el cable está conectado, si presenta algún

deterioro, etc.

Paso 1.4. Ejecute el comando show route para ver las entradas de rutas actuales.

lab1@srx-1> show route

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

172.18.1.0/30 *[Direct/0] 00:26:23

> via em3.0

172.18.1.2/32 *[Local/0] 00:26:23

Local via em3.0

172.20.66.0/30 *[Direct/0] 00:26:16

> via em2.0

172.20.66.1/32 *[Local/0] 00:26:16

Local via em2.0

172.20.77.0/30 *[Direct/0] 00:26:16

> via em1.0

172.20.77.1/32 *[Local/0] 00:26:16

Local via em1.0

172.20.113.0/24 *[Direct/0] 00:26:17

> via em4.113

172.20.113.1/32 *[Local/0] 00:26:17

Local via em4.113

192.168.1.1/32 *[Direct/0] 00:26:17

> via lo0.0

P - ¿Muestra la tabla de enrutamiento una entrada para todas las direcciones de interfaces locales y de

redes directamente conectadas?

R - Sí, como podemos observar en la salida mostrada arriba.

P - ¿Qué preferencia de ruta tienen las rutas Local y Direct?

R - Como podemos observar arriba, ambas tienen una preferencia de ruta ("rute preference") de 0.



P - ¿Hay alguna ruta oculta actualmente?

R - No, como podemos observar, no hay ninguna ruta oculta (0 hidden).

Paso 1.5. Use la utilidad ping para verificar la accesibilidad a los dispositivos vecinos

conectados a nuestro dispositivo. La siguiente captura muestra el ping desde

el dispositivo srx-1 al gateway Internet, srx-2 y vr113, que están conectados

directamente.

lab1@srx-1> ping 172.18.1.1 rapid count 25

PING 172.18.1.1 (172.18.1.1): 56 data bytes

92 bytes from 172.18.1.11: Redirect Network(New addr: 172.18.1.1)

Vr HL TOS Len ID Flg off TTL Pro cks Src Dst

4 5 00 0054 63a0 0 0000 3f 01 bde1 172.18.1.2 172.18.1.1

!!!!!!!!!!!!!!!!!!!!!!!!!

--- 172.18.1.1 ping statistics ---

25 packets transmitted, 25 packets received, 0% packet loss

round-trip min/avg/max/stddev = 1.139/2.210/16.469/2.929 ms


PING 172.20.66.2 (172.20.66.2): 56 data bytes

!!!!!!!!!!!!!!!!!!!!!!!!!





PING 172.20.77.2 (172.20.77.2): 56 data bytes

!!!!!!!!!!!!!!!!!!!!!!!!!





PING 172.20.113.10 (172.20.113.10): 56 data bytes

!!!!!!!!!!!!!!!!!!!!!!!!!

--- 172.20.113.10 ping statistics ---



P - ¿ Son satisfactorios los pings?

R - Sí, los pings se realizan satisfactoriamente.



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

Agregadas

En esta parte del laboratorio, configurará y monitorizará rutas estáticas y agregadas.

Paso 2.1. Mirando el diagrama de red de este laboratorio, responda a la siguiente

cuestión:

P - ¿Qué dirección IP usa su dispositivo como next-hop para alcanzar el host de Internet?

R - Depende del dispositivo asignado. Por ejemplo, para el router srx-1 la dirección IP que se utiliza como next-

hop para alcanzar el host de Internet es: 172.18.1.1. En cambio, para el dispositivo srx-2 es: 172.18.2.1

Paso 2.2. Entre al modo configuración y defina una ruta estática por defecto. Use la

dirección IP identificada en el paso anterior como next-hop para la ruta estática

por defecto:

[edit]

lab1@srx-1# edit routing-options

[edit routing-options]

lab1@srx-1# set static route 0/0 next-hop 172.18.1.1

Paso 2.3. Active la nueva ruta estática creada en el paso anterior y ejecute el comando

run show route 172.31.15.1


lab1@srx-1# commit

commit complete


lab1@srx-1# run show route 172.31.15.1



0.0.0.0/0 *[Static/5] 00:00:23

> to 172.18.1.1 via em3.0

P - ¿Aparece una entrada válida de la ruta asociada a la dirección IP del host de Internet?

R - Sí, en este momento todos los destinos que no tengan una ruta más específica usarán la ruta por defecto creada

anteriormente.



P - ¿Cuál es la preferencia de ruta de la ruta estática por defecto?

R - Como se puede observar, la preferencia de ruta para la ruta estática por defecto es 5 (es el valor por defecto).

Paso 2.4. Ejecute el comando run ping 172.31.15.1 para hacer ping en el host de

Internet.


lab1@srx-1# 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=63 time=2.900 ms





^C




P - ¿Fue satisfactorio el ping?

R - Sí, el ping fue satisfactorio.

Paso 2.5. Use la sentencia preference para asegurar que las rutas estáticas por defecto

mantengan la preferencia de ruta por defecto de 5 y que todas las futuras rutas

estáticas usen una preferencia de ruta de 20.


lab1@srx-1# set static route 0/0 preference 5


lab1@srx-1# set static defaults preference 20

Paso 2.6. Añada una ruta estática hacia la dirección de loopback del router virtual

directamente conectado.


lab1@srx-1# set static route 192.168.1.2/32 next-hop 172.20.113.10

Paso 2.7. Active la configuración y ejecute el comando run show route protocol

static para ver todas las rutas estáticas.




lab1@srx-1# commit

commit complete


lab1@srx-1# run show route protocol static



0.0.0.0/0 *[Static/5] 00:12:49

> to 172.18.1.1 via em3.0

192.168.1.2/32 *[Static/20] 00:00:07

> to 172.20.113.10 via em4.113

P - ¿Están ambas rutas estáticas activas? ¿Cuál es la preferencia de ruta de cada una de ellas?

R - Sí, ambas rutas estáticas están activas. La preferencia de ruta para la ruta estática por defecto es de 5 y para la

ruta estática hacia la dirección loopback del router virtual directamente conectado es de 20, tal y como lo

habíamos configurado anteriormente.

Paso 2.8. Haga ping sobre la dirección de loopback del router virtual que está

directamente conectado.



PING 192.168.1.2 (192.168.1.2): 56 data bytes






^C




P - ¿Es satisfactorio el ping?

R - Sí, el ping es satisfactorio.

Paso 2.9. Añada una ruta agregada para la red 10.1.0.0/16 ejecutando el comando set

aggregate route 10.1.0.0/16.


lab1@srx-1# set aggregate route 10.1.0.0/16



Paso 2.10. Active la ruta agregada anteriormente y ejecute el comando run show

route protocol aggregate.


lab1@srx-1# commit

commit complete


lab1@srx-1# run show route protocol aggregate


P - ¿Está activa la ruta agregada añadida anteriormente?

R - No, como podemos observar en la salida del comando anterior. Esta ruta agregada aparece como oculta

(hidden) porque no contiene rutas específicamente (contributing routes). La ruta oculta se puede ver usando el

comando run show route hidden detail como vemos a continuación.


lab1@srx-1# run show route hidden detail


10.1.0.0/16 (1 entry, 0 announced)

Aggregate

Next hop type: Reject

Address: 0x8f27f24

Next-hop reference count: 1

State: <Hidden Int Ext>

Age: 1:45

Task: Aggregate

AS path: I

Flags: Depth: 0 Inactive

Paso 2.11. Elimine la ruta agregada 10.1.0.0/16 y defina una nueva ruta agregada para la

red 172.20.64.0/18. Active la configuración cambiada y ejecute el comando run

show route protocol aggregate detail.


lab1@srx-1# delete aggregate




lab1@srx-1# commit

commit complete


lab1@srx-1# run show route protocol aggregate detail


172.20.64.0/18 (1 entry, 1 announced)



*Aggregate Preference: 130

Next hop type: Reject

Address: 0x8f27f24

Next-hop reference count: 2

State: <Active Int Ext>

Age: 12

Task: Aggregate

Announcement bits (1): 0-KRT

AS path: I (LocalAgg)

Flags: Depth: 0 Active

AS path list:

AS path: I Refcount: 3

Contributing Routes (3):

172.20.66.0/30 proto Direct

172.20.77.0/30 proto Direct

172.20.113.0/24 proto Direct

P - Respecto a la tabla de enrutamiento inet.0 ¿Tiene su dispositivo alguna ruta oculta?

R - No, ya que la ruta que estaba oculta anteriormente ha sido eliminada.

P - ¿Está activa la nueva ruta agregada? ¿Cuál es su preferencia de ruta?

R - Sí, está activa. Su preferencia de ruta es de 130 (el valor por defecto para las rutas agregadas).

P - ¿Cuáles son las rutas incluidas en la ruta agregada 172.20.64.0/18?

R - Las rutas incluidas ("contributing routes") en la ruta agregada son un total de tres: las dos rutas hacia el

dispositivo srx-2 (172.20.66.0/30 y 172.20.77.0/30) y la ruta hacia el router virtual conectado directamente

(172.20.113.0/24).

P - Basado en el tipo de next-hop asociado con la ruta agregada 172.29.64.0/18 ¿Qué acción llevará a

cabo el dispositivo si recibe un paquete destinado a una red para la cual no existe una ruta más

específica?

R - Por defecto, el next-hop asociado a la ruta agregada 172.20.64.0/18 es "reject", es decir, el paquete será

rechazado y el dispositivo mandará un mensaje del tipo "No route to host". Lo podemos ver a continuación.





172.20.64.0/18 *[Aggregate/130] 00:02:02

Reject



PING 172.20.64.1 (172.20.64.1): 56 data bytes

ping: sendto: No route to host


^C





5.1.3 Parte 3: Instancias de Enrutamiento

En esta parte del laboratorio, configurará una instancia de enrutamiento y usará grupos

de tablas de enrutamiento para compartir rutas entre la tabla de enrutamiento master y las

tablas de enrutamiento definidas por el usuario.

Paso 3.1. Sitúese en el nivel jerárquico [edit routing-instances]. Defina una

instancia de enrutamiento llamada instance-a que use el tipo de instancia

virtual-router y que incluya las interfaces em1 y em2.

[edit]

lab1@srx-1# edit routing-instances

[edit routing-instances]

lab1@srx-1# set instance-a instance-type virtual-router


lab1@srx-1# set instance-a interface em1


lab1@srx-1# set instance-a interface em2

Paso 3.2. Defina dos rutas estáticas: la primera es para las direcciones loopback

asignadas al dispositivo remoto srx-2 y el router virtual remoto vr114; la

segunda es para la subred remota que conecta el router srx-2 con su router

virtual remoto vr114. Ambas rutas estáticas deberían incluir dos direcciones

next-hop de las interfaces em1 y em2 del dispositivo remoto.


lab1@srx-1# set instance-a routing-options static route 192.168.2.0/30 next-hop

172.20.66.2


lab1@srx-1# set instance-a routing-options static route 192.168.2.0/30 next-hop

172.20.77.2


lab1@srx-1# set instance-a routing-options static route 172.20.114.0/24 next-

hop 172.20.66.2


lab1@srx-1# set instance-a routing-options static route 172.20.114.0/24 next-

hop 172.20.77.2


lab1@srx-1# show

instance-a {

instance-type virtual-router;

interface em1.0;



interface em2.0;

routing-options {

static {

route 192.168.2.0/30 next-hop [ 172.20.66.2 172.20.77.2 ];

route 172.20.114.0/24 next-hop [ 172.20.66.2 172.20.77.2 ];

}

}

}

Paso 3.3. Active los cambios y muestre las tablas de enrutamiento usando el comando

run show route.


lab1@srx-1# commit

commit complete


lab1@srx-1# run show route



0.0.0.0/0 *[Static/5] 00:15:43

> to 172.18.1.1 via em3.0

172.18.1.0/30 *[Direct/0] 00:15:43

> via em3.0

172.18.1.2/32 *[Local/0] 00:15:43

Local via em3.0

172.20.64.0/18 *[Aggregate/130] 00:16:01

Reject

172.20.113.0/24 *[Direct/0] 00:00:35

> via em4.113

172.20.113.1/32 *[Local/0] 00:00:35

Local via em4.113

192.168.1.1/32 *[Direct/0] 00:15:36

> via lo0.0

192.168.1.2/32 *[Static/20] 00:00:35

> to 172.20.113.10 via em4.113

instance-a.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)


172.20.66.0/30 *[Direct/0] 00:00:35

> via em2.0

172.20.66.1/32 *[Local/0] 00:00:35

Local via em2.0

172.20.77.0/30 *[Direct/0] 00:00:35

> via em1.0

172.20.77.1/32 *[Local/0] 00:00:35

Local via em1.0

172.20.114.0/24 *[Static/5] 00:00:35

> to 172.20.66.2 via em2.0

to 172.20.77.2 via em1.0

192.168.2.0/30 *[Static/5] 00:00:35

> to 172.20.66.2 via em2.0

to 172.20.77.2 via em1.0

P - ¿Qué tablas de enrutamiento se muestran?



R - Se visualizan las tablas de enrutamiento inet.0 (master) e instance-a.inet.0 (creada por el usuario).

P - ¿Qué rutas son instaladas en la nueva tabla de enrutamiento?

R - La nueva tabla de enrutamiento (instance-a.inet.0) muestra las rutas Direct y Local asociadas

con las interfaces asignadas a la instancia de enrutamiento definida anteriormente.

Paso 3.4. Verifique la conectividad al dispositivo remoto srx-2 usando el comando ping

address, donde address es la dirección asignada a la interfaz em2 del

router srx-2.



PING 172.20.66.2 (172.20.66.2): 56 data bytes




^C



P - ¿Ha sido satisfactorio el ping? Explique su respuesta.

R - El ping no ha sido satisfactorio. Esto es debido a que solamente la tabla de enrutamiento instance-

a.inet.0 creada por el usuario, contiene esa ruta. Con lo cual, el ping debe ser realizado desde esta tabla de

enrutamiento.

Paso 3.5. Añada la opción routing-instance instance-a al comando ping

anterior.


lab1@srx-1# run ping 172.20.66.2 routing-instance instance-a

PING 172.20.66.2 (172.20.66.2): 56 data bytes




^C




P - ¿Ha sido satisfactorio el ping?

R - Sí, como podemos apreciar en la salida del ping.

Paso 3.6. Intente hacer ping a la dirección loopback del dispositivo remoto virtual

vr114 desde la instancia de enrutamiento instance-a.




lab1@srx-1# run ping 192.168.2.2 routing-instance instance-a

PING 192.168.2.2 (192.168.2.2): 56 data bytes

36 bytes from 172.20.66.2: Destination Host Unreachable


4 5 00 0054 3a16 0 0000 40 01 8fd3 172.20.66.1 192.168.2.2



4 5 00 0054 3a17 0 0000 40 01 8fd2 172.20.66.1 192.168.2.2



4 5 00 0054 3a18 0 0000 40 01 8fd1 172.20.66.1 192.168.2.2

^C



P - ¿Ha sido satisfactorio el ping? Explique su respuesta.

R - No, ya que el dispositivo remoto srx-2 aún no tiene información sobre la ruta requerida para enviar los

paquetes a su destino. Una vez se configure dicha ruta en el dispositivo srx-2, el ping será satisfactorio.

Paso 3.7. Sitúese en el nivel jerárquico [edit routing-options]. Ejecute el

comando set rib-groups inet.0-to-instance-a import-rib

[inet.0 instance-a.inet.0] para crear un grupo de tabla de

enrutamiento que importe rutas desde la tabla inet.0 a la tabla instance-

a.inet.0.


lab1@srx-1# top edit routing-options


lab1@srx-1# set rib-groups inet.0-to-instance-a import-rib [inet.0 instance-

a.inet.0]

Paso 3.8. Ejecute el comando set rib-groups instance-a-to-inet.0 import-

rib [instance-a.inet.0 inet.0] para crear un grupo de tabla de

enrutamiento que importe rutas desde la tabla instance-a.inet.0 a la

tabla inet.0.


lab1@srx-1# set rib-groups instance-a-to-inet.0 import-rib [instance-a.inet.0

inet.0]



Paso 3.9. Aplique el grupo de tabla de enrutamiento inet.0-to-instance-a para

importar interfaces y rutas estáticas desde la tabla de enrutamiento inet.0 a

la tabla de enrutamiento instance-a.inet.0. Active los cambios y muestre

la tabla instance-a.inet.0 para asegurarse que las rutas fueron

importadas adecuadamente.


lab1@srx-1# set interface-routes rib-group inet inet.0-to-instance-a


lab1@srx-1# set static rib-group inet.0-to-instance-a


lab1@srx-1# commit

commit complete


lab1@srx-1# run show route table instance-a.inet.0

instance-a.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)


0.0.0.0/0 *[Static/5] 00:00:33

> to 172.18.1.1 via em3.0

172.18.1.0/30 *[Direct/0] 00:00:33

> via em3.0

172.18.1.2/32 *[Local/0] 00:00:33

Local via em3.0

172.20.66.0/30 *[Direct/0] 00:32:25

> via em2.0

172.20.66.1/32 *[Local/0] 00:32:25

Local via em2.0

172.20.77.0/30 *[Direct/0] 00:32:25

> via em1.0

172.20.77.1/32 *[Local/0] 00:32:25

Local via em1.0

172.20.113.0/24 *[Direct/0] 00:00:33

> via em4.113

172.20.113.1/32 *[Local/0] 00:00:33

Local via em4.113

172.20.114.0/24 *[Static/5] 00:32:25

> to 172.20.66.2 via em2.0

to 172.20.77.2 via em1.0

192.168.1.1/32 *[Direct/0] 00:00:33

> via lo0.0

192.168.1.2/32 *[Static/20] 00:00:33

> to 172.20.113.10 via em4.113

192.168.2.0/30 *[Static/5] 00:32:25

> to 172.20.66.2 via em2.0

to 172.20.77.2 via em1.0

P - ¿Fueron importadas las interfaces y rutas estáticas a la tabla de enrutamiento instance-

a.inet.0?

R - Como podemos observar en la salida, sí fueron importadas correctamente.



Paso 3.10. Sitúese en el nivel jerárquico [edit routing-instance instance-a].

Aplique el grupo de tabla de enrutamiento instance-a-to-inet.0 para

importar las rutas estáticas desde la tabla de enrutamiento instance-

a.inet.0 a la tabla inet.0.


lab1@srx-1# top edit routing-instances instance-a

[edit routing-instances instance-a]

lab1@srx-1# set routing-options interface-routes rib-group instance-a-to-inet.0


lab1@srx-1# set routing-options static rib-group instance-a-to-inet.0

Paso 3.11. Active los cambios y vuelva al modo operacional. A continuación, muestre la

tabla de enrutamiento inet.0 para asegurarse que las rutas fueron

importadas adecuadamente desde la tabla de enrutamiento instance-

a.inet.0.



commit complete

exiting configuration mode

lab1@srx-1> show route table inet.0



0.0.0.0/0 *[Static/5] 00:06:18

> to 172.18.1.1 via em3.0

172.18.1.0/30 *[Direct/0] 00:53:18

> via em3.0

172.18.1.2/32 *[Local/0] 00:53:18

Local via em3.0

172.20.64.0/18 *[Aggregate/130] 00:53:36

Reject

172.20.66.0/30 *[Direct/0] 00:00:15

> via em2.0

172.20.66.1/32 *[Local/0] 00:00:15

Local via em2.0

172.20.77.0/30 *[Direct/0] 00:00:15

> via em1.0

172.20.77.1/32 *[Local/0] 00:00:15

Local via em1.0

172.20.113.0/24 *[Direct/0] 00:00:14

> via em4.113

172.20.113.1/32 *[Local/0] 00:00:14

Local via em4.113

172.20.114.0/24 *[Static/5] 00:00:15

to 172.20.66.2 via em2.0

> to 172.20.77.2 via em1.0

192.168.1.1/32 *[Direct/0] 00:53:11

> via lo0.0



192.168.1.2/32 *[Static/20] 00:00:14

> to 172.20.113.10 via em4.113

192.168.2.0/30 *[Static/5] 00:00:15

> to 172.20.66.2 via em2.0

to 172.20.77.2 via em1.0

P - ¿Fueron importadas la interfaz y rutas estáticas desde la tabla de enrutamiento instance-

a.inet.0 a la tabla de enrutamiento instance-a.inet.0?

R - Como podemos observar en la salida, sí fueron importadas correctamente.

Paso 3.12. Haga ping a la dirección loopback del dispositivo srx-2 desde la instancia

master inet.0 y desde la instancia definida por el usuario instance-a.

lab2@srx-1> ping 192.168.2.1

PING 192.168.2.1 (192.168.2.1): 56 data bytes




^C




lab2@srx-1> ping 192.168.2.1 routing-instance instance-a

PING 192.168.2.1 (192.168.2.1): 56 data bytes




^C





R - En la salida podemos observar como el ping es satisfactorio en ambos casos, como era de esperar.



5.2 Lab 2: Load Balancing and Filter-Based Forwarding (FBF)

En este laboratorio se configurarán y monitorizarán el balanceo de carga y el reenvío

basado en filtros (FBF) en dispositivos que ejecutan el sistema operativo Junos. En este

laboratorio, se utilizará la línea de comandos (CLI) para configurar y monitorizar

balanceo de carga y FBF.


em2 (.1)

em1 (.1)

em2 (.2)

em1 (.2)

172.20.66.0/30

172.20.77.0/30

Internet

em3 (.

2)

172.1

8.1.0

/30

(.1

) (.1) 172.18.2.0/30 (.2) em3

172.31.15.1

Internet Host

srx-1 srx-2

vr113 vr114

em4.113 (.1)

172.20.113.0/24

em1.113 (.10)

(.1) em4.114

172.20.114.0/24

(.10) em1.114

lo0: 192.168.1.1

lo0: 192.168.1.2

lo0: 192.168.2.1

lo0: 192.168.2.2

Tagged Interface

Figura 36: Escenario del Lab 2 "Load Balancing and Filter-Based Forwarding"


o Parte 1: Configurar y monitorizar los efectos del balanceo de carga.

o Parte 2: Configurar y monitorizar FBF (Filter-Based Forwarding).



5.2.1 Parte 1: Configuración y Monitorización de Balanceo de Carga

En esta parte del laboratorio, añadirá rutas estáticas hacia el dispositivo remoto srx-2.

Verificará entonces el comportamiento por defecto del balanceo de carga. Finalmente,

configurará y monitorizará balanceos de carga.

Paso 1.1. Defina dos rutas estáticas a la dirección loopback del dispositivo remoto srx-2

y el router remoto virtual vr114 y la dirección de subred que une a ambos.

Ambas rutas estáticas deberían incluir las dos direcciones de las interfaces em1

y em2 del dispositivo remoto como direcciones de next-hop. Una vez realice

dicha configuración, active los cambios y vuelva al modo operacional.

lab2@srx-1> configure


[edit]











lab2@srx-1# show

static {

defaults {

preference 20;

}

route 0.0.0.0/0 {

next-hop 172.18.1.1;

preference 5;

}

route 192.168.1.2/32 next-hop 172.20.113.10;

route 192.168.2.0/30 next-hop [ 172.20.66.2 172.20.77.2 ];

route 172.20.114.0/24 next-hop [ 172.20.66.2 172.20.77.2 ];

}

aggregate {

route 172.20.64.0/18;

}



commit complete




Paso 1.2. Muestre las entradas de la tabla de enrutamiento hacia la dirección de

loopback del dispositivo remoto srx-2, el router virtual remoto vr114 y la

dirección de subred que conecta a ambos.

lab2@srx-1> show route 192.168.2.1/30



192.168.2.0/30 *[Static/20] 00:08:02

to 172.20.77.2 via em1.0

> to 172.20.66.2 via em2.0

lab2@srx-1> show route 172.20.114.0/24



172.20.114.0/24 *[Static/20] 00:08:07

to 172.20.77.2 via em1.0

> to 172.20.66.2 via em2.0

P - ¿Qué interfaz fue seleccionada como next-hop para estas dos rutas estáticas?

R - Debido a que el proceso de selección es aleatorio, la respuesta puede variar. En nuestro caso, la interfaz de

salida seleccionada para ambas rutas ha sido la interfaz em2.

Paso 1.3. Muestre las entradas de la tabla de reenvío para los mismos destinos y

responda a la cuestión que se le plantea.

lab2@srx-1> show route forwarding-table destination 192.168.2.0/30

Routing table: default.inet

Internet:

Destination Type RtRef Next hop Type Index NhRef Netif

192.168.2.0/30 user 0 172.20.66.2 ucst 549 4 em2.0

Routing table: __master.anon__.inet

Internet:


default perm 0 rjct 525 1

lab2@srx-1> show route forwarding-table destination 172.20.114.0/24


Internet:


172.20.114.0/24 user 0 172.20.66.2 ucst 549 4 em2.0


Internet:



P - ¿Qué interfaz fue seleccionada como next-hop para estas dos entradas de reenvío?



R - Sólo la interfaz seleccionada como next-hop por el proceso de enrutamiento anteriormente debería aparecer en

la tabla de reenvío. En nuestro caso, se trata de la interfaz em2.

Paso 1.4. Entre al modo de configuración y sitúese en el nivel jerárquico [edit

policy-options].



[edit]

lab2@srx-1# edit policy-options

[edit policy-options]

lab2@srx-1#

Paso 1.5. Defina una política de balanceo de carga llamada balance-traffic que

hará que exista balanceo de carga sobre todos los caminos de igual coste.


lab2@srx-1# set policy-statement balance-traffic then load-balance per-packet

Paso 1.6. Sitúese en el nivel jerárquico [edit routing-options forwarding-

table] y aplique la política balance-traffic como una política de

exportación. Ejecute el comando commit para activar los cambios.


lab2@srx-1# top edit routing-options forwarding-table

[edit routing-options forwarding-table]

lab2@srx-1# set export balance-traffic


lab2@srx-1# commit

commit complete

Paso 1.7. Muestre de nuevo las entradas de la tabla de reenvío para las direcciones de

loopback del dispositivo remoto srx-2 y del router virtual remoto vr114, así

como la dirección de subred que une a ambos dispositivos. Compare esta

salida con la mostrada anteriormente (Paso 1.3) y responda a las cuestiones.



lab2@srx-1# run show route forwarding-table destination 192.168.2.0/30

routing table: default.inet

internet:

destination type rtref next hop type index nhref netif

192.168.2.0/30 user 0 ulst 131070 3

172.20.77.2 ucst 550 2 em1.0

172.20.66.2 ucst 549 3 em2.0

routing table: __master.anon__.inet

internet:

destination type rtref next hop type index nhref netif



lab2@srx-1# run show route forwarding-table destination 172.20.114.0/24


Internet:


172.20.114.0/24 user 0 ulst 131070 3

172.20.77.2 ucst 550 2 em1.0

172.20.66.2 ucst 549 3 em2.0


Internet:



P - Comparada con la salida del Paso 1.3, ¿en qué se diferencian?

R - En esta salida podemos observar una lista uniscast (ulst) que contiene ambas direcciones unicast (ucst) como

next-hop hacia el destino. Se producirá un balanceo de carga entre las interfaces de salida em1 y em2.

Paso 1.8. Sitúese en el nivel jerárquico [edit forwarding-options] y configure su

dispositivo para evaluar información de puerto en Capa 3 y Capa 4 cuando se

produce el balanceo de carga para tráfico de IPv4. Active los cambios y vuelva

al modo operacional.


lab2@srx-1# top edit forwarding-options

[edit forwarding-options]

lab2@srx-1# set hash-key family inet layer-3


lab2@srx-1# set hash-key family inet layer-4


la2b@srx-1# commit and-quit

commit complete

exiting configuration mode

lab2@srx-1>



Paso 1.9. Realice una serie de operaciones traceroute desde su dispositivo asignado hacia

la dirección de loopback del dispositivo virtual remoto vr114.

lab2@srx-1> traceroute 192.168.2.2

traceroute to 192.168.2.2 (192.168.2.2), 30 hops max, 40 byte packets

1 172.20.66.2 (172.20.66.2) 1.188 ms 172.20.77.2 (172.20.77.2) 1.115 ms

0.816 ms

2 192.168.2.2 (192.168.2.2) 1.810 ms 1.295 ms 1.359 ms



1 172.20.77.2 (172.20.77.2) 1.193 ms 0.787 ms 172.20.66.2 (172.20.66.2)

0.738 ms

2 192.168.2.2 (192.168.2.2) 1.560 ms 1.699 ms 1.312 ms



1 172.20.66.2 (172.20.66.2) 0.810 ms 0.682 ms 172.20.77.2 (172.20.77.2)

0.670 ms

2 192.168.2.2 (192.168.2.2) 1.058 ms 0.816 ms 0.906 ms

P - Basado en los resultados del traceroute, ¿se realiza el balanceo de carga de paquetes UDP

correctamente a través de los dos caminos de igual coste?

R - Como podemos observar en la salida, el balanceo de carga se lleva a cabo correctamente, ya que podemos

apreciar como unas veces se elige la interfaz em1 como salida (next-hop 172.20.77.2) y otras, en cambio, se

elige la interfaz em2 como salida (next-hop 172.20.66.2).

5.2.2 Parte 2: Configuración y Monitorización de FBF (Filter-Based

Forwarding)

En esta parte del laboratorio, configurará y monitorizará FBF (Filter-Based Forwarding).

Paso 2.1. Entre al modo configuración y sitúese en el nivel jerárquico [edit

firewall family inet].


entering configuration mode

[edit]

lab2@srx-1# edit firewall family inet

[edit firewall family inet]

lab2@srx-1#



Paso 2.2. Ejecute el comando edit filter my-fbf-filter para definir un filtro

firewall llamado my-fbf-filter. Cree un término llamado match-172-

subnet que reenvíe el tráfico proveniente del dispositivo virtual local vr113 a

una instancia de reenvío llamada instance-66. Cree un segundo término

llamado match-192-subnet que reenvíe el tráfico proveniente de la subred

del loopback local a la instancia de reenvío llamada instance-77. Definirá

más adelante las instancia de reenvío referenciadas.

[edit firewall family inet]

lab2@srx-1# edit filter my-fbf-filter

[edit firewall family inet filter my-fbf-filter]

lab2@srx-1# set term match-172-subnet from source-address 172.20.113.0/24


lab2@srx-1# set term match-172-subnet then routing-instance instance-66


lab2@srx-1# set term match-192-subnet from source-address 192.168.1.0/30


lab2@srx-1# set term match-192-subnet then routing-instance instance-77


lab2@srx-1# show

term match-172-subnet {

from {

source-address {

172.20.113.0/24;

}

}

then {

routing-instance instance-66; ## 'instance-66' is not defined

}

}

term match-192-subnet {

from {

source-address {

192.168.1.0/30;

}

}

then {

routing-instance instance-77; ## 'instance-77' is not defined

}

}

Paso 2.3. Sitúese en el nivel jerárquico [edit interfaces em4] y aplique el nuevo

filtro adaptado como un filtro IPv4 de entrada a la interfaz lógica definida.


lab2@srx-1# top edit interfaces em4

[edit interfaces em4]

lab2@srx-1# set unit 113 family inet filter input my-fbf-filter



Paso 2.4. Sitúese en el nivel jerárquico [edit routing-instances] y cree una

nueva instancia llamada instance-66 usando el tipo de instancia

forwarding.


lab2@srx-1# top edit routing-instances


lab2@srx-1# set instance-66 instance-type forwarding

Paso 2.5. Defina dos rutas estáticas en la instancia instance-66 hacia las direcciones

loopback y de subred de los dispositivos remotos srx-2 y vr114. Use la

dirección asignada a la interfaz em2 del dispositivo remoto srx-2 como next-

hop para ambas rutas estáticas.


lab2@srx-1# set instance-66 routing-options static route 192.168.2.0/30 next-

hop 172.20.66.2


lab2@srx-1# set instance-66 routing-options static route 172.20.114.0/24 next-

hop 172.20.66.2

Paso 2.6. Use el comando copy para copiar el contenido definido en la instancia de

enrutamiento instance-66 a una nueva instancia de enrutamiento llamada

instance-77.


lab2@srx-1# copy instance-66 to instance-77


lab2@srx-1# show

instance-66 {

instance-type forwarding;

routing-options {

static {

route 192.168.2.0/30 next-hop 172.20.66.2;

route 172.20.114.0/24 next-hop 172.20.66.2;

}

}

}

instance-77 {


routing-options {

static {

route 192.168.2.0/30 next-hop 172.20.66.2;

route 172.20.114.0/24 next-hop 172.20.66.2;

}

}

}



Paso 2.7. Ejecute el comando edit instance-77 para situarse en el nivel jerárquico

[edit routing-instances instance-77]. A continuación, ejecute el

comando replace pattern 66 with 77 para modificar las direcciones

de next-hop de las rutas estáticas.


lab2@srx-1# edit instance-77

[edit routing-instances instance-77]

lab2@srx-1# replace pattern 66 with 77


lab2@srx-1# show


routing-options {

static {

route 192.168.2.0/30 next-hop 172.20.77.2;

route 172.20.114.0/24 next-hop 172.20.77.2;

}

}

Paso 2.8. Sitúese en el nivel [edit routing-options] y defina un grupo de tabla de

enrutamiento de entrada llamado fbf-rib-group que incluya las tablas de

enrutamiento inet.0, instance-66.inet.0 e instance-77.inet.0.




lab2@srx-1# set rib-groups fbf-rib-group import-rib [inet.0 instance-66.inet.0

instance-77.inet.0]

Paso 2.9. Ejecute el comando set interfaces-routes rib-group inet fbf-

rib-group para aplicar el nuevo grupo de tabla de enrutamiento e importar

rutas entre la instancia master y las instancias definidas por el usuario.


lab2@srx-1# set interface-routes rib-group inet fbf-rib-group

Paso 2.10. Active la configuración y ejecute el comando run show route para

asegurarse que las tablas de enrutamiento para las instancias definidas por el

usuario tienen la información de enrutamiento requerida.




lab2@srx-1# commit

commit complete


lab2@srx-1# run show route



0.0.0.0/0 *[Static/5] 00:42:47

> to 172.18.1.1 via em3.0

172.18.1.0/30 *[Direct/0] 00:42:51

> via em3.0

172.18.1.2/32 *[Local/0] 00:42:51

Local via em3.0

172.20.64.0/18 *[Aggregate/130] 00:43:03

Reject

172.20.66.0/30 *[Direct/0] 00:42:57

> via em2.0

172.20.66.1/32 *[Local/0] 00:42:57

Local via em2.0

172.20.77.0/30 *[Direct/0] 00:43:01

> via em1.0

172.20.77.1/32 *[Local/0] 00:43:01

Local via em1.0

172.20.113.0/24 *[Direct/0] 00:08:18

> via em4.113

172.20.113.1/32 *[Local/0] 00:08:18

Local via em4.113

172.20.114.0/24 *[Static/20] 00:42:47

> to 172.20.77.2 via em1.0

to 172.20.66.2 via em2.0

192.168.1.1/32 *[Direct/0] 00:42:38

> via lo0.0

192.168.1.2/32 *[Static/20] 00:08:18

> to 172.20.113.10 via em4.113

192.168.2.0/30 *[Static/20] 00:42:47

to 172.20.77.2 via em1.0

> to 172.20.66.2 via em2.0

instance-66.inet.0: 11 destinations, 11 routes (11 active, 0 holddown,0 hidden)


172.18.1.0/30 *[Direct/0] 00:00:08

> via em3.0

172.18.1.2/32 *[Local/0] 00:00:08

Local via em3.0

172.20.66.0/30 *[Direct/0] 00:00:08

> via em2.0

172.20.66.1/32 *[Local/0] 00:00:08

Local via em2.0

172.20.77.0/30 *[Direct/0] 00:00:08

> via em1.0

172.20.77.1/32 *[Local/0] 00:00:08

Local via em1.0

172.20.113.0/24 *[Direct/0] 00:00:05

> via em4.113

172.20.113.1/32 *[Local/0] 00:00:05

Local via em4.113

172.20.114.0/24 *[Static/5] 00:00:07

> to 172.20.66.2 via em2.0

192.168.1.1/32 *[Direct/0] 00:00:08

> via lo0.0



192.168.2.0/30 *[Static/5] 00:00:07

> to 172.20.66.2 via em2.0



172.18.1.0/30 *[Direct/0] 00:00:09

> via em3.0

172.18.1.2/32 *[Local/0] 00:00:09

Local via em3.0

172.20.66.0/30 *[Direct/0] 00:00:09

> via em2.0

172.20.66.1/32 *[Local/0] 00:00:09

Local via em2.0

172.20.77.0/30 *[Direct/0] 00:00:09

> via em1.0

172.20.77.1/32 *[Local/0] 00:00:09

Local via em1.0

172.20.113.0/24 *[Direct/0] 00:00:06

> via em4.113

172.20.113.1/32 *[Local/0] 00:00:06

Local via em4.113

172.20.114.0/24 *[Static/5] 00:00:08

> to 172.20.77.2 via em1.0

192.168.1.1/32 *[Direct/0] 00:00:09

> via lo0.0

192.168.2.0/30 *[Static/5] 00:00:08

> to 172.20.77.2 via em1.0

P - ¿Fueron las rutas estáticas e interfaces añadidas a las tablas de enrutamiento de las nuevas

instancias?

R - Sí, como podemos observar en la salida.

Paso 2.11. Desde el router virtual vr113, haga varias operaciones de traceroute a la

dirección loopback del router virtual remoto vr114.

lab2@vr113> traceroute 192.168.2.2


1 172.20.113.1 (172.20.113.1) 1.457 ms 0.920 ms 0.769 ms

2 172.20.66.2 (172.20.66.2) 0.995 ms 1.039 ms 0.946 ms

3 192.168.2.2 (192.168.2.2) 1.342 ms 1.473 ms 1.479 ms



1 172.20.113.1 (172.20.113.1) 0.776 ms 0.420 ms 0.473 ms

2 172.20.66.2 (172.20.66.2) 0.988 ms 0.954 ms 0.880 ms

3 192.168.2.2 (192.168.2.2) 1.296 ms 1.224 ms 1.791 ms



1 172.20.113.1 (172.20.113.1) 0.724 ms 0.642 ms 0.516 ms

2 172.20.66.2 (172.20.66.2) 0.865 ms 0.989 ms 1.313 ms

3 192.168.2.2 (192.168.2.2) 1.454 ms 1.403 ms 1.653 ms



P - ¿Qué camino tomaron los paquetes en el traceroute?

R - Como podemos observar en la salida de arriba, todos los paquetes toman el camino de la interfaz em2

(172.20.66.0/30) del router srx-1, ya que se ha configurado un filtro adaptado para que todo el tráfico que

provenga de la subred 172.20.113.0/24 y cuyo destino sea las direcciones loopback de los dispositivos remotos

srx-2 o vr114, adopten ese camino.

Paso 2.12. Usando la dirección loopback de su router virtual local vr113 como dirección

de origen, realice varias operaciones de traceroute a la dirección loopback del

router virtual remoto vr114.

lab2@vr113> traceroute 192.168.2.2 source 192.168.1.2

traceroute to 192.168.2.2 (192.168.2.2) from 192.168.1.2, 30 hops max, 40 byte

packets

1 172.20.113.1 (172.20.113.1) 1.042 ms 1.794 ms 1.715 ms

2 172.20.77.2 (172.20.77.2) 1.275 ms 0.882 ms 0.913 ms

3 192.168.2.2 (192.168.2.2) 1.612 ms 1.666 ms 1.161 ms



packets

1 172.20.113.1 (172.20.113.1) 0.673 ms 0.524 ms 0.611 ms

2 172.20.77.2 (172.20.77.2) 0.802 ms 1.371 ms 0.888 ms

3 192.168.2.2 (192.168.2.2) 1.902 ms 1.693 ms 2.030 ms



packets

1 172.20.113.1 (172.20.113.1) 0.680 ms 0.492 ms 0.493 ms

2 172.20.77.2 (172.20.77.2) 1.441 ms 1.114 ms 1.221 ms

3 192.168.2.2 (192.168.2.2) 1.319 ms 1.450 ms 1.030 ms

P - ¿Qué camino tomaron los paquetes en el traceroute?

R - Como podemos observar en la salida de arriba, todos los paquetes toman el camino de la interfaz em1

(172.20.77.0/30) del router srx-1, ya que se ha configurado un filtro adaptado para que todo el tráfico que

provenga de la subred 192.168.1.0/30 y cuyo destino sea las direcciones loopback de los dispositivos remotos

srx-2 o vr114, adopten ese camino.

Paso 2.13. Realice un ping para verificar que el router virtual vr113 puede alcanzar el

host de Internet (172.31.15.1).

lab2@vr113> ping 172.31.15.1

PING 172.31.15.1 (172.31.15.1): 56 data bytes



4 5 00 0054 352c 0 0000 40 01 6d3e 172.20.113.10 172.31.15.1



4 5 00 0054 352d 0 0000 40 01 6d3d 172.20.113.10 172.31.15.1





4 5 00 0054 352e 0 0000 40 01 6d3c 172.20.113.10 172.31.15.1

^C



P - ¿Fueron satisfactorios los pings? Explique su respuesta.

R - Como era de esperar, los pings no fueron satisfactorios, ya que tenemos configurado un filtro adaptado en el

router srx-1 según el cual todo el tráfico proveniente del router virtual vr113 será enviado a través de las dos

instancias de enrutamiento (bien por la instance-66 o bien por la instance-77), independientemente de la

dirección de destino.

Paso 2.14. Vuelva al router srx-1. A continuación, sitúese en el nivel jerárquico [edit

routing-instances] y defina una ruta estática por defecto que dirija el

tráfico a la tabla de enrutamiento inet.0 para ambas instancias. Active la

configuración y vuelva al modo operacional.


lab2@srx-1# top edit routing-instances


lab2@srx-1# set instance-66 routing-options static route 0/0 next-table inet.0


lab2@srx-1# set instance-77 routing-options static route 0/0 next-table inet.0



commit complete


Paso 2.15. Ejecute el comando show route table instance-66 protocol

static y asegúrese que la ruta estática por defecto fue instalada y dirige el

tráfico a la tabla de enrutamiento inet.0.

lab2@srx-1> show route table instance-66 protocol static



0.0.0.0/0 *[Static/5] 00:03:44

to table inet.0

172.20.114.0/24 *[Static/5] 01:38:05

> to 172.20.66.2 via em2.0

192.168.2.0/30 *[Static/5] 01:38:05

> to 172.20.66.2 via em2.0



lab2@srx-1> show route table instance-77 protocol static



0.0.0.0/0 *[Static/5] 00:04:01

to table inet.0

172.20.114.0/24 *[Static/5] 01:38:22

> to 172.20.77.2 via em1.0

192.168.2.0/30 *[Static/5] 01:38:22

> to 172.20.77.2 via em1.0

P - ¿Tienen instaladas las instancias definidas por el usuario las rutas estáticas por defecto que dirigen

el tráfico a la tabla de enrutamiento inet.0?

R - Como podemos observar en la salida, sí las tienen instaladas. Podemos apreciarlo donde pone "to table inet.0".

Paso 2.16. Vuelva al router virtual vr113. A continuación, realice un ping hacia el host de

Internet de nuevo.

lab2@vr113> ping 172.31.15.1

PING 172.31.15.1 (172.31.15.1): 56 data bytes






^C




P - ¿Fueron satisfactorios los pings realizados?

R - Como podemos apreciar en la salida de arriba, los pings han sido satisfactorios, ya que en el paso anterior se ha

redirigido el tráfico proveniente del router virtual hacia la tabla de enrutamiento inet.0 para que así no se le

aplique el filtro que bloqueaba dicho tráfico anteriormente.



5.3 Lab 3: Open Shortest Path First (OSPF)

En este laboratorio se configurará y monitorizará el protocolo OSPF (Open Shortest Path

First). En este laboratorio, se utilizará la línea de comandos (CLI) para configurar,

monitorizar y solucionar problemas en OSPF.


em2 (.1)

em1 (.1)

em2 (.2)

em1 (.2)

172.20.66.0/30

172.20.77.0/30

Internet

em3 (.

2)

172.1

8.1.0

/30

(.1

) (.1) 172.18.2.0/30 (.2) em3

172.31.15.1

Internet Host

srx-1 srx-2

vr113 vr114

em4.113 (.1)

172.20.113.0/24

em1.113 (.10)

(.1) em4.114

172.20.114.0/24

(.10) em1.114

lo0: 192.168.1.1

lo0: 192.168.1.2

lo0: 192.168.2.1

lo0: 192.168.2.2

OSPF Area 0.0.0.0OSPF Area 0.0.0.1

OSPF Area 0.0.0.2

Figura 37: Escenario del Lab 3 "OSPF"


o Parte 1: Configurar y monitorizar una red OSPF multiárea.

o Parte 2: Solucionar problemas básicos en OSPF.



5.3.1 Parte 1: Configuración y Monitorización de OSPF

En esta parte del laboratorio, configurará y monitorizará un red OSPF multiárea. Después

de realizar una configuración inicial básica, definirá un router-ID para su dispositivo. A

continuación, configurará su dispositivo para participar en una red OSPF multiárea y lo

verificará usando comandos en el modo operacional del CLI.

Paso 1.1. Sitúese en el nivel jerárquico [edit routing-options] y defina el router-

ID de su router usando la dirección IP asignada a su interfaz lo0 como valor.

[edit]



lab3@srx-1# set router-id 192.168.1.1

Paso 1.2. Sitúese en el nivel jerárquico [edit protocols ospf] y configure OSPF

Area 0. Fíjese en el diagrama de red si fuese necesario y recuerde incluir lo0.0.


lab3@srx-1# top edit protocols ospf

[edit protocols ospf]

lab3@srx-1# set area 0 interface lo0.0


lab3@srx-1# set area 0 interface em1.0



Paso 1.3. Active la configuración y ejecute el comando run show ospf neighbor.


lab3@srx-1# commit

commit complete


lab3@srx-1# run show ospf neighbor

Address Interface State ID Pri Dead

172.20.77.2 em1.0 2Way 192.168.2.1 128 38

172.20.66.2 em2.0 2Way 192.168.2.1 128 36

P - ¿Qué estado presentan las interfaces de los vecinos?



R - Al haber sido configurado OSPF en ambos routers (srx-1 y srx-2), el estado debe ser FULL.

P - ¿Qué valor es mostrado bajo la columna ID?

R - Se trata del router-ID asignado al dispositivo remoto (srx-2).

P - ¿Qué valor es mostrado bajo la columna Pri? ¿Qué ayuda este valor a determinar?

R - Se trata de la prioridad, valor tenido en cuenta entre otras cosas para la elección del router designado. En este

caso, 128 es el valor por defecto.

Paso 1.4. Ejecute el comando run show ospf interface para mostrar los detalles

de OSPF en las interfaces.


lab3@srx-1# run show ospf interface

Interface State Area DR ID BDR ID Nbrs

em1.0 BDR 0.0.0.0 192.168.2.1 192.168.1.1 1

em2.0 BDR 0.0.0.0 192.168.2.1 192.168.1.1 1

lo0.0 DR 0.0.0.0 192.168.1.1 0.0.0.0 0

P - ¿Qué interfaces son listadas en la salida? ¿Cuáles son los estados de dichas interfaces?

R - Las interfaces listadas son las que forman parte del área 0 de OSPF (em1.0, em2.0 y lo0.0). Los estados serán

DR (Designed Router) o BDR (Backup Designed Router), según el router-ID que haya sido configurado

anteriormente. En nuestro caso, el estado de em1.0 y em2.0 será BDR, ya que el valor del router-ID

configurado en el router remoto srx-2 es más alto (192.168.2.1), con lo cual será éste el elegido como DR.

Paso 1.5. Ejecute el comando run show ospf database para mostrar los detalles de

la base de datos OSPF.


lab3@srx-1# run show ospf database

OSPF database, Area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksum Len

Router *192.168.1.1 192.168.1.1 0x80000005 2055 0x22 0x2c78 60

Router 192.168.2.1 192.168.2.1 0x80000005 1181 0x22 0x633c 60

Network 172.20.66.2 192.168.2.1 0x80000003 886 0x22 0xb839 32

Network 172.20.77.2 192.168.2.1 0x80000002 2057 0x22 0x41a6 32

P - ¿Cuántos y qué tipos de LSAs (Link-State Advertisements) existen en la base de datos OSPF?

R - Aparecen cuatro LSAs. Dos LSAs tipo Router y otros dos tipo Network. En nuestro caso, vemos como tres de

esos cuatro son anunciados por el router srx-2 (DR) y sólo una (lo0.0) es anunciada por este router (está

indicada con un *).



Paso 1.6. Muestre rutas anunciadas y recibidas por OSPF usando el comando run

show ospf route.


lab3@srx-1# run show ospf route

Topology default Route Table:

Prefix Path Route NH Metric NextHop Nexthop

Type Type Type Interface Address/LSP

192.168.2.1 Intra Router IP 1 em1.0 172.20.77.2

em2.0 172.20.66.2

172.20.66.0/30 Intra Network IP 1 em2.0


192.168.1.1/32 Intra Network IP 0 lo0.0

192.168.2.1/32 Intra Network IP 1 em1.0 172.20.77.2

em2.0 172.20.66.2

P - ¿Cuál es la métrica asociada actualmente con las rutas OSPF mostradas?

R - Con la excepción de la métrica asociada a la dirección loopback local (valor por defecto de 0), todas las rutas

deberían mostrar una métrica de 1, el valor por defecto para las rutas directamente conectadas.

P - ¿Por qué la salida muestra dos entradas con el mismo prefijo?

R - Porque representa cosas distintas. Por un lado, "192.168.2.1 Router" representa el router-ID del router

remoto, y en cambio, "192.168.2.1 Network" representa la dirección loopback local de dicho dispositivo remoto.

Paso 1.7. Asocie una métrica de 100 a la interfaz em2.0 y active los cambios.


lab3@srx-1# set area 0 interface em2.0 metric 100


lab3@srx-1# commit

commit complete

P - Basado en los cambios realizados, ¿qué interfaz esperas que OSPF elegirá para enviar tráfico al

dispositivo remoto srx-2?

R - OSPF prefiere los enlaces con menor métrica, con lo cual elegirá la interfaz em1.0 para enviar.

Paso 1.8. Ejecute de nuevo el comando run show ospf route para ver los cambios.






192.168.2.1 Intra Router IP 1 em1.0 172.20.77.2







P - ¿Cuál es la métrica actualmente asociada a la ruta OSPF 172.20.66.0/30?

R - Como podemos observar en la salida, la métrica asociado es de 100.

P - ¿Qué efecto ha tenido este incremento de métrica en las rutas OSPF hacia la loopback remota ?

R - Al haberse aumentado la métrica de em2.0, solamente la interfaz em1.0 será anunciada como next-hop hacia la

dirección loopbak del router remoto srx-2. Anteriormente, al tener la misma métrica, ambas interfaces (em1.0 y

em2.0) eran anunciadas.

Paso 1.9. Ejecute el comando run show route protocol ospf para ver las rutas

OSPF insertadas en la tabla de enrutamiento.


lab3@srx-1# run show route protocol ospf



192.168.2.1/32 *[OSPF/10] 00:04:41, metric 1

> to 172.20.77.2 via em1.0

224.0.0.5/32 *[OSPF/10] 00:05:47, metric 1

MultiRecv

P - ¿Qué rutas OSPF aparecen en la tabla de enrutamiento?

R - Aparecen dos rutas aprendidas mediante el protocolo OSPF: Una ruta hacia la dirección loopback del router

remoto srx-2 y otra ruta multicast OSPF.

P - ¿Por qué no aparecen las rutas 172.20.66.0/30 y 172.20.77.0/30 ?

R - Porque son rutas conectadas directamente, con lo cual, aparecerán en la tabla de enrutamiento como tal.

Tenemos que recordar que la preferencia de ruta de las redes directamente conectadas (0) es inferior a la

preferencia de ruta de OSPF (10).

Paso 1.10. Configure su dispositivo para funcionar como un ABR (Area Border Router),

uniendo el Área 0 con una segunda área (en este caso, Área 1). Una vez

configurado, active los cambios realizados y vuelva al modo operacional.




lab3@srx-1# show

area 0.0.0.0 {

interface lo0.0;

interface em1.0;



interface em2.0 {

metric 100;

}

}

area 0.0.0.1 {

interface em4.113;

}



commit complete


Paso 1.11. Ejecute el comando show ospf neighbor para verificar las adyacencias

OSPF actuales en detalle.

lab3@srx-1> show ospf neighbor


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 35

172.20.113.10 em4.113 Full 192.168.1.2 128 32

P - ¿Cuántos vecinos OSPF aparecen y qué estados tienen?

R - Tres vecinos, los cuales están todos en estado Full.

Paso 1.12. Ejecute el comando show ospf database para mostrar la base de datos

OSPF actual.

lab3@srx-1> show ospf database



Router *192.168.1.1 192.168.1.1 0x8000000c 250 0x22 0xc672 60

Router 192.168.2.1 192.168.2.1 0x80000009 109 0x22 0x433 60

Network 172.20.66.2 192.168.2.1 0x80000004 357 0x22 0xb63a 32

Network 172.20.77.2 192.168.2.1 0x80000004 2439 0x22 0x3da8 32

Summary *172.20.113.0 192.168.1.1 0x80000004 1175 0x22 0xdebc 28

Summary 172.20.114.0 192.168.2.1 0x80000005 628 0x22 0xcacd 28

Summary *192.168.1.2 192.168.1.1 0x80000001 923 0x22 0xa9ba 28

Summary 192.168.2.2 192.168.2.1 0x80000001 869 0x22 0x97ca 28



Router *192.168.1.1 192.168.1.1 0x80000006 2626 0x22 0x925d 36

Router 192.168.1.2 192.168.1.2 0x80000005 884 0x22 0x2c3e 48

Network *172.20.113.1 192.168.1.1 0x80000002 1509 0x22 0xdbe6 32

Summary *172.20.66.0 192.168.1.1 0x80000002 2501 0x22 0xb9b2 28

Summary *172.20.77.0 192.168.1.1 0x80000002 2172 0x22 0x5e66 28

Summary *172.20.114.0 192.168.1.1 0x80000003 842 0x22 0xdfba 28

Summary *192.168.1.1 192.168.1.1 0x80000002 1842 0x22 0xa7bd 28

Summary *192.168.2.1 192.168.1.1 0x80000003 518 0x22 0xa4bd 28

Summary *192.168.2.2 192.168.1.1 0x80000001 868 0x22 0xa8b9 28



P - ¿Cuántas bases de datos OSPF aparecen en la salida?

R - Aparecen dos bases de datos OSPF, una para cada área.

P - ¿Qué tipos de LSAs aparecen en la salida?

R - Router, network y summary (external LSAs aparecen cuando existen rutas aprendidas externamente por otros

protocolos de enrutamiento).

Paso 1.13. Entre al modo configuración y sitúese en el nivel [edit policy-options].



[edit]

lab3@srx-1# edit policy-options


lab3@srx-1#

Paso 1.14. Defina una nueva política de enrutamiento llamada inject-default-

route. Incluya un término llamado match-default-route que inserte la

ruta estática por defecto a OSPF.


lab3@srx-1# edit policy-statement inject-default-route

[edit policy-options policy-statement inject-default-route]

lab3@srx-1# set term match-default-route from protocol static


lab3@srx-1# set term match-default-route from route-filter 0/0 exact


lab3@srx-1# set term match-default-route then accept

Paso 1.15. Sitúese en el nivel [edit protocols ospf] y aplique la política definida

anteriormente como una política export. A continuación, active los cambios.




lab3@srx-1# set export inject-default-route


lab3@srx-1# commit

commit complete



Paso 1.16. Ejecute el comando run show ospf database advertising-router

self para ver todos los LSAs OSPF en la base de datos que el dispositivo

local ha generado.


lab3@srx-1# run show ospf database advertising-router self



Router *192.168.1.1 192.168.1.1 0x8000000d 331 0x22 0xca6b 60

Summary *172.20.113.0 192.168.1.1 0x80000004 2217 0x22 0xdebc 28

Summary *192.168.1.2 192.168.1.1 0x80000001 1965 0x22 0xa9ba 28



Router *192.168.1.1 192.168.1.1 0x80000008 331 0x22 0x9457 36

Network *172.20.113.1 192.168.1.1 0x80000002 2551 0x22 0xdbe6 32

Summary *172.20.66.0 192.168.1.1 0x80000003 757 0x22 0xb7b3 28

Summary *172.20.77.0 192.168.1.1 0x80000003 489 0x22 0x5c67 28

Summary *172.20.114.0 192.168.1.1 0x80000003 1884 0x22 0xdfba 28

Summary *192.168.1.1 192.168.1.1 0x80000003 222 0x22 0xa5be 28

Summary *192.168.2.1 192.168.1.1 0x80000003 1560 0x22 0xa4bd 28

Summary *192.168.2.2 192.168.1.1 0x80000001 1910 0x22 0xa8b9 28

ASBRSum *192.168.2.1 192.168.1.1 0x80000001 17 0x22 0x9ac8 28

OSPF AS SCOPE link state database


Extern *0.0.0.0 192.168.1.1 0x80000001 331 0x22 0xe75f 36

P - ¿Está presente una entrada con la ruta estática por defecto recientemente insertada?

R - Sí, podemos verla en la última línea anunciada como una LSA externa..

Paso 1.17. Ejecute el comando run show route 0/0 exact para ver la tabla de

enrutamiento actual hacia la ruta por defecto.


lab3@srx-1# run show route 0/0 exact



0.0.0.0/0 *[Static/5] 01:07:18

> to 172.18.1.1 via em3.0

[OSPF/150] 00:06:27, metric 0, tag 0

> to 172.20.77.2 via em1.0

P - Basada en la salida anterior, ¿qué sucedería si la interfaz directamente conectada a Internet falla?

R - En la salida se pueden apreciar dos rutas aprendidas hacia Internet. Actualmente, se utilizará la ruta

configurada estáticamente en pasos anteriores, mientras que en caso de fallar esta ruta será la ruta aprendida

por el protocolo OSPF la que pase a estar activa. Esto es debido a que la ruta estática tiene una preferencia de

ruta mayor (menor valor) a la aprendida mediante el protocolo OSPF.



5.3.2 Parte 2: Solución de problemas básicos en OSPF

En esta parte del laboratorio, solucionará problemas básicos en OSPF. Primero, modificará

la configuración de su dispositivo para hacerlo incompatible con el router virtual

conectado. A continuación, habilitará traceroptions OSPF para registrar la actividad.

Finalmente, mostrará dichos registros y estadísticas OSPF para ver los errores asociados.

Paso 2.1. Ejecute el comando run show ospf statistics para mostrar las

estadísticas de OSPF.

[edit]

lab3@srx-1# run show ospf statistics

Packet type Total Last 5 seconds

Sent Received Sent Received

Hello 2788 2717 2 1

DbD 12 7 0 0

LSReq 1 2 0 0

LSUpdate 84 65 0 0

LSAck 60 60 0 0

DBDs retransmitted : 3, last 5 seconds : 0

LSAs flooded : 58, last 5 seconds : 0

LSAs flooded high-prio : 27, last 5 seconds : 0

LSAs retransmitted : 0, last 5 seconds : 0

LSAs transmitted to nbr: 6, last 5 seconds : 0

LSAs requested : 1, last 5 seconds : 0

LSAs acknowledged : 68, last 5 seconds : 0

Flood queue depth : 0

Total rexmit entries : 0

db summaries : 0

lsreq entries : 0

Receive errors:

None

P - ¿Muestra su dispositivo algún error registrado?

R - Como podemos observar en la salida, no existen errores.

Paso 2.2. Sitúese en el nivel [edit protocols ospf] y renombre el área nonbackbone

(Área 1 o Área 2 dependiendo si estás en el router srx-1 o srx-2) a area 3.

[edit]



lab3@srx-1# rename area 1 to area 3




lab3@srx-1# show

export inject-default-route;

area 0.0.0.0 {

interface lo0.0;

interface em1.0;

interface em2.0 {

metric 100;

}

}

area 0.0.0.3 {

interface em4.113;

}

Paso 2.3. Active los cambios y ejecute el comando run show ospf neighbor.


lab3@srx-1# commit

commit complete




172.20.77.2 em1.0 Full 192.168.2.1 128 34

172.20.66.2 em2.0 Full 192.168.2.1 128 34

P - ¿Cuántos vecinos OSPF tiene su dispositivo asignado?

R - El dispositivo srx-1 tiene actualmente dos vecinos OSPF (Área 0), ya que el Área 1 ha sido renombrada como

Área 3, con lo cual se ha perdido la adyacencia que había con el router virtual vr113.

Paso 2.4. Defina opciones de traceroute para OSPF para que los errores OSPF se

escriban en un archivo llamado trace-ospf. Incluya la opción detail con

el flag error para capturar detalles adicionales para los errores OSPF. Por

último, active los cambios.


lab3@srx-1# set traceoptions file trace-ospf


lab3@srx-1# set traceoptions flag error detail


lab3@srx-1# commit

commit complete



Paso 2.5. Ejecute el comando run show log trace-ospf para ver el contenido del

archivo trace-ospf.


lab3@srx-1# run show log trace-ospf

Mar 12 18:31:57 trace_on: Tracing to "/var/log/trace-ospf" started

Mar 12 18:32:05.586328 OSPF packet ignored: area mismatch (0.0.0.1) from

172.20.113.10 on intf em4.113 area 0.0.0.3

Mar 12 18:32:05.588189 OSPF rcvd Hello 172.20.113.10 -> 224.0.0.5 (em4.113 IFL

71 area 0.0.0.3)

Mar 12 18:32:05.588216 Version 2, length 44, ID 192.168.1.2, area 0.0.0.1

Mar 12 18:32:05.588250 checksum 0xd55, authtype 0

Mar 12 18:32:05.589284 mask 255.255.255.0, hello_ivl 10, opts 0x12, prio 128

Mar 12 18:32:05.589311 dead_ivl 40, DR 172.20.113.10, BDR 0.0.0.0

Mar 12 18:32:15.176562 OSPF packet ignored: area mismatch (0.0.0.1) from

172.20.113.10 on intf em4.113 area 0.0.0.3

Mar 12 18:32:15.176730 OSPF rcvd Hello 172.20.113.10 -> 224.0.0.5 (em4.113 IFL

71 area 0.0.0.3)

P - ¿Aparece el problema de adyacencia OSPF en el archivo de errores generado?

R - Como podemos observar en la salida, el problema de adyacencia es registrado en dicho archivo de errores. Nos

dice que existe un desajuste (mismatch) en el enlace del router srx-1 y el router vr113, ya que cada extremo del

enlace está asignado a un área OSPF diferente.

Paso 2.6. Ejecute el comando run show ospf statistics para comprobar los

contadores de errores actuales.





Hello 3303 3105 2 1

DbD 12 7 0 0

LSReq 1 2 0 0

LSUpdate 98 75 0 0

LSAck 70 70 0 0










db summaries : 0

lsreq entries : 0

Receive errors:

104 area mismatches



P - ¿Aparece algún error en el contador de errores?

R - Sí, aparece el error comentado anteriormente (area mismatches) y el número de veces que se ha producido.

Paso 2.7. Renombre de nuevo area 3 a su correcto nombre (Área 1 o Área 2

dependiendo del dispositivo). A continuación, asigne a dicha área el tipo

stub y active los cambios realizados.


lab3@srx-1# rename area 3 to area 1


lab3@srx-1# set area 1 stub


lab3@srx-1# commit

commit complete

Paso 2.8. Ejecute el comando run clear log trace-ospf para limpiar el contenido

del archivo trace definido anteriormente. Espere un momento y entonces

ejecute el comando run show log trace-ospf para ver cualquier nueva

entrada en dicho archivo.


lab3@srx-1# run clear log trace-ospf


lab3@srx-1# run show log trace-ospf

Mar 12 18:49:55 srx-1 clear-log[2018]: logfile cleared

Mar 12 18:49:56.750566 OSPF packet ignored: area stubness mismatch from

172.20.113.10 on intf em4.113 area 0.0.0.1

P - ¿Aparece el problema de adyacencia OSPF en el archivo de errores generado?

R - Como podemos observar en la salida, existe un desajuste en el tipo de área.

Paso 2.9. Ejecute el comando run show ospf statistics para comprobar los

errores contabilizados.





Hello 3592 3342 0 1

DbD 12 7 0 0



LSReq 1 2 0 0

LSUpdate 103 82 0 0

LSAck 77 74 0 0










db summaries : 0

lsreq entries : 0

Receive errors:

143 area mismatches

53 stub area mismatches

P - ¿Aparece algún nuevo tipo de error listado?

R - Sí, aparece el error "stub area mismatches" además del "area mismatches". Esto es debido a la configuración

realizada anteriormente.

Paso 2.10. Vuelva a una configuración anterior previa a la introducción de estos errores.

Compruebe que la adyacencia con su vecino OSPF vuelve a tener un estado

Full entre el router srx-1 y el router virtual vr113 .

[edit]

lab3@srx-1# rollback 3

load complete

[edit]


commit complete


lab3@srx-1> show ospf neighbor


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 31

172.20.113.10 em4.113 Full 192.168.1.2 128 38



5.4 Lab 4: Border Gateway Protocol (BGP)

En este laboratorio se configurará y monitorizará el protocolo BGP (Border Gateway

Protocol). En este laboratorio, se utilizará la línea de comandos (CLI) para configurar y

monitorizar BGP.


em2 (.1)

em1 (.1)

em2 (.2)

em1 (.2)

172.20.66.0/30

172.20.77.0/30

ISP YAS 65515

em3

(.2)

17

2.18

.1.0

/30

(.

1)

(.1) 172.18.2.0/30 (.2) em3

srx-1 srx-2

vr113 vr114

em4.113 (.1)

172.20.113.0/24

em1.113 (.10)

(.1) em4.114

172.20.114.0/24

(.10) em1.114

lo0: 192.168.1.1

lo0: 192.168.1.2

lo0: 192.168.2.1

lo0: 192.168.2.2

AS 64700

ISP XAS 65510

ISP ZAS 65520

Figura 38: Escenario del Lab 4 "BGP"


o Parte 1: Configurar y monitorizar IBGP.

o Parte 2: Exportar rutas agregadas a un peer EBGP.



5.4.1 Parte 1: Configuración y Monitorización de IBGP

En esta parte del laboratorio, configurará y monitorizará el protocolo BGP interno (IBGP).

Primero definirá el número de sistema autónomo (AS) para su dispositivo. A

continuación, establecerá sesiones peering IBGP usando direcciones loopback. Por último,

monitorizará las sesiones peering IBGP establecidas usando los comandos del modo

operaciones de la CLI.

Paso 1.1. Sitúese en el nivel jerárquico [edit routing-options] y defina el número

de AS asignado a su red.

[edit]



lab4@srx-1# set autonomous-system 64700

Paso 1.2. Sitúese en el nivel jerárquico [edit protocols bgp]. Configure un grupo

BGP llamado my-int-group que incluya los tres dispositivos que están

dentro de tu red como vecinos IBGP. Use la dirección loopback asignada a su

dispositivo como la dirección local y las direcciones loopback remotas de los

dispositivos dentro del AS como las direcciones vecinas. Por último, ejecute el

comando commit para activar los cambios.


lab4@srx-1# top edit protocols bgp

[edit protocols bgp]

lab4@srx-1# set group my-int-group local-address 192.168.1.1


lab4@srx-1# set group my-int-group neighbor 192.168.1.2






lab4@srx-1# show

group my-int-group {

local-address 192.168.1.1;

neighbor 192.168.1.2;

neighbor 192.168.2.1;

neighbor 192.168.2.2;

}




lab4@srx-1# commit

[edit protocols]

'bgp'

Error in neighbor 192.168.1.2 of group my-int-group:

peer AS number must be configured for an external peer

error: configuration check-out failed

P - ¿Ha sido satisfactoria la operación commit? ¿Por qué?

R - Como podemos observar, se ha producido un error. Eso es debido a que no se ha especificado que se trata de una

sesión de tipo interna (IBGP).

Paso 1.3. Configure el grupo my-int-group para el tipo de sesión BGP interna. A

continuación, ejecute el comando commit para activar la configuración.


lab4@srx-1# set group my-int-group type internal


lab4@srx-1# commit

commit complete

Paso 1.4. Ejecute el comando run show bgp neighbor para ver la información sobre

los dispositivos BGP vecinos (IBGP).


lab4@srx-1# run show bgp neighbor

Peer: 192.168.1.2 AS 64700 Local: 192.168.1.1 AS 64700

Type: Internal State: Active Flags: <ImportEval>

Last State: Idle Last Event: Start

Last Error: None

Options: <Preference LocalAddress Refresh>

Local Address: 192.168.1.1 Holdtime: 90 Preference: 170

Number of flaps: 0

Peer: 192.168.2.1 AS 64700 Local: 192.168.1.1 AS 64700



Last Error: None



Number of flaps: 0

Peer: 192.168.2.2 AS 64700 Local: 192.168.1.1 AS 64700



Last Error: None



Number of flaps: 0



Paso 1.5. Ejecute el comando run show route advertising-protocol bgp

neighbor, donde neighbor es la dirección loopback de cada vecino IBGP.


lab4@srx-1# run show route advertising-protocol bgp 192.168.1.2





P - ¿Está el dispositivo anunciando rutas BGP a sus vecinos IBGP?

R - La respuesta es no, debido a que rutas BGP recibidas de vecinos IBGP no deben ser anunciadas a los otros

vecinos para evitar bucles.

5.4.2 Parte 2: Configuración y Monitorización de EBGP

En esta parte del laboratorio, configurará y monitorizará el protocolo BGP externo

(EBGP). Primero, establecerá una sesión peering EBGP con el vecino externo. A

continuación, anunciará rutas agregadas a su vecino EBGP. Finalmente, monitorizará la

sesión establecida con su vecino EBGP usando los comandos adecuados.

Paso 2.1. Sitúese en el nivel jerárquico [edit protocols bgp]. Configure una

sesión peering EBGP con los AS conectados (ISP-X o ISP-Z). Nombra el grupo

EBGP asociado my-ext-group. Una vez configurado, active los cambios

usando el comando commit.


lab4@srx-1# set group my-ext-group type external


lab4@srx-1# set group my-ext-group peer-as 65510


lab4@srx-1# set group my-ext-group neighbor 172.18.1.1


lab4@srx-1# show

group my-int-group {

type internal;

local-address 192.168.1.1;

neighbor 192.168.1.2;

neighbor 192.168.2.1;

neighbor 192.168.2.2;

}



group my-ext-group {

type external;

peer-as 65510;

neighbor 172.18.1.1;

}


lab4@srx-1# commit

commit complete

Paso 2.2. Ejecute el comando run show bgp neighbor address para ver los

detalles de la sesión peering EBGP. Sustituye address por la dirección IP

asignada a tu vecino EBGP.


lab4@srx-1# run show bgp neighbor 172.18.1.1

Peer: 172.18.1.1+55762 AS 65510 Local: 172.18.1.2+179 AS 64700

Type: External State: Established Flags: <Sync>

Last State: OpenConfirm Last Event: RecvKeepAlive

Last Error: None

Options: <Preference PeerAS Refresh>

Holdtime: 90 Preference: 170

Number of flaps: 0

Peer ID: 172.18.1.1 Local ID: 192.168.1.1 Active Holdtime: 90

Keepalive Interval: 30 Peer index: 0

BFD: disabled, down

Local Interface: em3.0

NLRI for restart configured on peer: inet-unicast

NLRI advertised by peer: inet-unicast

NLRI for this session: inet-unicast

Peer supports Refresh capability (2)

Stale routes from peer are kept for: 300

Peer does not support Restarter functionality

NLRI that restart is negotiated for: inet-unicast

NLRI of received end-of-rib markers: inet-unicast

NLRI of all end-of-rib markers sent: inet-unicast

Peer supports 4 byte AS extension (peer-as 65510)

Peer does not support Addpath

Table inet.0 Bit: 10000

RIB State: BGP restart is complete

Send state: in sync

Active prefixes: 0

Received prefixes: 0

Accepted prefixes: 0

Suppressed due to damping: 0

Advertised prefixes: 0

Last traffic (seconds): Received 15 Sent 1 Checked 63

Input messages: Total 20 Updates 1 Refreshes 0 Octets 424

Output messages: Total 21 Updates 0 Refreshes 0 Octets 462

Output Queue[0]: 0

P - ¿Cuál es el actual estado de este vecino? ¿Cuál fue su estado previo?

R - Su estado actual es Established. Su estado previo es OpenConfirm.

P - ¿Qué valores son establecidos para el intervalo "keepalive" y el tiempo de "holddown"?



R - El actual intervalo "keepalive" está establecido en 30 segundos y el tiempo de "holddown" es el triple del

intervalo "keepalive" (en nuestro caso, 90 segundos).

P - ¿Cuál es el último evento grabado en esta sesión EBGP?

R - La recepción de un paquete "keepalive" enviado por su vecino (Last Event: RecvKeepAlive).

Paso 2.3. Sitúese en el nivel [edit routing-options] y defina rutas agregadas

adicionales que representen algunas de las redes que forman parte de tu AS.








lab4@srx-1# show aggregate

route 192.168.1.0/30;

route 192.168.2.0/30;

Paso 2.4. Sitúese en el nivel [edit policy-options] y defina una nueva política

llamada adv-aggregates que incluya dos términos. Nombra al primero

match-aggregate-routes. Éste debería aceptar las rutas agregadas.

Nombra al segundo deny-other. Éste debería rechazar todas las otras rutas.


lab4@srx-1# top edit policy-options


lab4@srx-1# edit policy-statement adv-aggregates

[edit policy-options policy-statement adv-aggregates]

lab4@srx-1# set term match-aggregate-routes from protocol aggregate


lab4@srx-1# set term match-aggregate-routes from route-filter 192.168.1.0/30

exact


lab4@srx-1# set term math-aggregate-routes from route-filter 192.168.2.0/30

exact


lab4@srx-1# set term math-aggregate-routes then accept


lab4@srx-1# set term deny-other then reject




lab4@srx-1# show

term match-aggregate-routes {

from {

protocol aggregate;

route-filter 192.168.1.0/30 exact;

route-filter 192.168.2.0/30 exact;

}

then accept;

}

term deny-other {

then reject;

}

Paso 2.5. Sitúese en el nivel [edit protocols bgp] y aplique la política definida

anteriormente como una política exportada para el grupo EBGP llamado my-

ext-group. Active los cambios con el comando commit.


lab4@srx-1# top edit protocols bgp


lab4@srx-1# set group my-ext-group export adv-aggregates


lab4@srx-1# show group my-ext-group

type external;

export adv-aggregates;

peer-as 65510;

neighbor 172.18.1.1;


lab4@srx-1# commit

commit complete

Paso 2.6. Verifique los efectos de la política nueva definida anteriormente y ejecute el

comando run show route advertising-protocol bgp address,

donde address es la dirección IP asignada a tu vecino EBGP.




Prefix Nexthop MED Lclpref AS path

* 192.168.1.0/30 Self I

* 192.168.2.0/30 Self I

P - ¿Anuncia su dispositivo todas los prefijos agregados esperados?

R - Como podemos observar en la salida, ambas rutas agregadas aparecen correctamente.



5.5 Lab 5: IP Tunneling

En este laboratorio se configurará y monitorizará un túnel GRE (Generic Routing

Encapsulation) mediante el uso de la línea de comandos (CLI).


em2 (.1)

em1 (.1)

em2 (.2)

em1 (.2)

172.20.66.0/30

172.20.77.0/30

Internet

em3 (.

2)

172.1

8.1.0

/30

(.1

) (.1) 172.18.2.0/30 (.2) em3

srx-1 srx-2

vr113 vr114

em4.113 (.1)

172.20.113.0/24

em1.113 (.10)

(.1) em4.114

172.20.114.0/24

(.10) em1.114

lo0: 192.168.1.1

lo0: 192.168.1.2

lo0: 192.168.2.1

lo0: 192.168.2.2

OSPF Area 0.0.0.0OSPF Area 0.0.0.1

OSPF Area 0.0.0.2

GRE Tunnel

Figura 39: Escenario del Lab 5 "IP Tunneling"


o Parte 1: Configurar y monitorizar un túnel GRE.

o Parte 2: Usar el túnel GRE configurado para unir dos dominios OSPF remotos.



5.5.1 Parte 1: Configuración y Monitorización de un túnel GRE

En esta parte del laboratorio, configurará y monitorizará un túnel GRE. Usando rutas

estáticas, dirigirá el tráfico hacia subredes remotas a través del túnel GRE formado.

Paso 1.1. Sitúese en el nivel jerárquico [edit interfaces]. A continuación,

deshabilite las interfaces em1 y em2. Finalmente, establezca el mtu de la

interfaz em3 a 1524.

[edit]


[edit interfaces]

lab5@srx-1# set em1 disable

[edit interfaces]

lab5@srx-1# set em2 disable

[edit interfaces]

lab5@srx-1# set em3 mtu 1524

P - ¿Por qué se incrementa el MTU a 1524?

R - Para encapsular un paquete GRE en un paquete IP, se añaden una cabecera GRE y una cabecera IP al paquete

en cuestión, añadiendo, por tanto, 24 bytes adicionales al paquete. Un MTU de 1524 permite al MTU ethernet

por defecto de 1500 sumar las dos cabeceras adicionales.

Paso 1.2. Defina una nueva interfaz GRE y un túnel usando la dirección IP de la interfaz

loopback de su equipo srx-1 como la dirección fuente y la dirección IP de la

interfaz loopback del equipo remoto srx-2 como la dirección destino. Use

unit 0 para la interfaz lógica punto-a-punto.

[edit interfaces]

lab5@srx-1# set gre unit 0 family inet

[edit interfaces]

lab5@srx-1# set gre unit 0 tunnel source 192.168.1.1

[edit interfaces]

lab5@srx-1# set gre unit 0 tunnel destination 192.168.2.1

[edit interfaces]

lab5@srx-1# show gre

unit 0 {

tunnel {

source 192.168.1.1;

destination 192.168.2.1;

}

family inet;

}



Paso 1.3. Active los cambios y ejecute el comando run show interfaces terse

gre para verificar el estado de la nueva interfaz GRE.

[edit interfaces]

lab5@srx-1# commit

commit complete

[edit interfaces]

lab5@srx-1# run show interfaces terse gre


gre up up

gre.0 up up inet

P - ¿Cuál es el estado actual de la interfaz gre?

R - Como podemos observar, el estado que presenta la interfaz es up, tanto en Admin como en Link.

Paso 1.4. Sitúese en el nivel jerárquico [edit routing-options static] y cree las

rutas estáticas necesarias para que exista conectividad con los dispositivos

remotos. Asegúrese de que las rutas estáticas definidas hacia las subredes

asociadas al equipo remoto srx-2 usarán la interfaz GRE definida

anteriormente.

[edit interfaces]

lab5@srx-1# top edit routing-options static

[edit routing-options static]

lab5@srx-1# set route 192.168.1.2/32 next-hop 172.20.113.10


lab5@srx-1# set route 192.168.2.0/30 next-hop gre.0


lab5@srx-1# set route 172.20.114.0/24 next-hop gre.0


lab5@srx-1# set route 192.168.2.1/32 next-hop 172.18.1.1


lab5@srx-1# set route 0/0 next-hop 172.18.1.1


lab5@srx-1# show

route 192.168.1.2/32 next-hop 172.20.113.10;

route 192.168.2.0/30 next-hop gre.0;

route 172.20.114.0/24 next-hop gre.0;

route 192.168.2.1/32 next-hop 172.18.1.1;

route 0.0.0.0/0 next-hop 172.18.1.1;



Paso 1.5. Active los cambios usando el comando commit. A continuación, use la tabla

de enrutamiento para determinar el next-hop asociado a la subred del router

virtual remoto vr114.


lab5@srx-1# commit

commit complete


lab5@srx-1# run show route 172.20.114.0/24



172.20.114.0/24 *[Static/5] 00:18:54

> via gre.0

P - ¿Cuál es el next-hop asociado a la ruta estática hacia la subred del router virtual remoto vr114?

R - Como muestra la salida de arriba, será la interfaz gre.0 creada anteriormente la que se usará como next-hop

hacia la subred del router virtual remoto vr114.

Paso 1.6. Haga un ping para verificar la conectividad al router virtual remoto vr114.

Use como fuente la dirección de su interfaz local em4.


lab5@srx-1# run ping 172.20.114.10 source 172.20.113.1

PING 172.20.114.10 (172.20.114.10): 56 data bytes




^C

--- 172.20.114.10 ping statistics ---



P - ¿Es satisfactorio el ping realizado? ¿Qué indica el ping realizado?

R - Como podemos observar en la salida de arriba, el ping ha sido satisfactorio. Un ping satisfactorio indica que el

túnel GRE creado anteriormente está transportando tráfico en ambas direcciones. Para verificar el correcto

funcionamiento de la interfaz gre.0, podemos ejecutar el comando mostrado a continuación.


lab5@srx-1# run show interfaces gre.0

Logical interface gre.0 (Index 71) (SNMP ifIndex 507)

Flags: Point-To-Point SNMP-Traps 0x4000

IP-Header 192.168.2.1:192.168.1.1:47:df:64:0000000000000000

Encapsulation: GRE-NULL

Gre keepalives configured: Off, Gre keepalives adjacency state: down

Input packets : 3

Output packets: 3

Protocol inet, MTU: 1486

Flags: Sendbcast-pkt-to-re



5.5.2 Parte 2: Configuración de interfaz GRE para participar en OSPF

En esta parte del laboratorio, configurará la interfaz GRE para participar en OSPF,

permitiendo unir los dos dominios OSPF remotos (Área 1 y Área 2) a través del túnel

GRE. A continuación, rehabilitará las interfaces em1 y em2, y se asegurará de que la

interfaz gre.0 servirá como un enlace de backup para el área 0 de OSPF.

Paso 2.1. En primer lugar, realice las configuraciones necesarias para obtener una red

OSPF como muestra el escenario de este laboratorio.

[edit]

lab5@srx-1# edit protocols ospf










lab5@srx-1# show

area 0.0.0.0 {

interface lo0.0;

interface em1.0;

interface em2.0;

}

area 0.0.0.1 {

interface em4.113;

}

Paso 2.2. Active los cambios mediante el comando commit. A continuación, ejecute el

comando run show ospf neighbor para ver qué vecinos OSPF tiene

actualmente el router srx-1 (recuerde que las interfaces em1 y em2 están

deshabilitadas actualmente).


lab5@srx-1# commit

commit complete




172.20.113.10 em4.113 Full 192.168.1.2 128 37



Paso 2.3. Añada la interfaz gre.0 al Área 0 de OSPF.


lab5@srx-1# set area 0 interface gre.0


lab5@srx-1# show

area 0.0.0.0 {

interface lo0.0;

interface em1.0;

interface em2.0;

interface gre.0;

}

area 0.0.0.1 {

interface em4.113;

}

Paso 2.4. Active los cambios mediante el comando commit. A continuación, ejecute el

comando run show ospf neighbor para ver qué vecinos OSPF tiene

ahora el router srx-1.


lab5@srx-1# commit

commit complete




192.168.2.1 gre.0 Full 192.168.2.1 128 39

172.20.113.10 em4.113 Full 192.168.1.2 128 37

P - Basado en la salida generada, ¿cuál es la dirección del nuevo vecino OSPF detectado?

R - Como podemos observar en la salida de arriba, se trata de la dirección de loopback del router remoto srx-2

(también es la dirección de destino del túnel GRE). La dirección es la siguiente: 192.168.2.1.

Paso 2.5. Ejecute el comando show route address, donde address representa la

dirección loopback del dispositivo remoto srx-2.





192.168.2.1/32 *[Static/5] 01:14:28

> to 172.18.1.1 via em3.0

[OSPF/10] 00:15:26, metric 1

> via gre.0



P - ¿De qué forma aprenderá su dispositivo la ruta hacia la dirección especificada? ¿Cuál es

seleccionada como activa y por qué?

R - Como muestra la salida, el router srx-1 aprende la ruta hacia el router remoto srx-2 de dos formas: Ruta

estática (configurada en la primera parte de este laboratorio) y a través del protocolo OSPF. La ruta estática

será seleccionada como activa (lo indica el asterisco *), ya que presenta una preferencia de ruta por defecto (5)

inferior al del protocolo OSPF (10).

Paso 2.6. Ejecute el comando run show ospf neighbors.




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 36

192.168.2.1 gre.0 Full 192.168.2.1 128 32

172.20.113.10 em4.113 Full 192.168.1.2 128 33

P - ¿Cuántos vecinos OSPF tiene actualmente su dispositivo?

R - Como podemos observar, tiene cuatro vecinos actualmente.

Paso 2.7. Añada una métrica de 200 a la interfaz gre.0 para asegurarse que el túnel

actúa como camino de backup cuando las interfaces em1.0 y em2.0 están

operativas. Active los cambios usando el comando commit.


lab5@srx-1# set area 0 interface gre.0 metric 200


lab5@srx-1# show

area 0.0.0.0 {

interface lo0.0;

interface em1.0;

interface em2.0;

interface gre.0 {

metric 200;

}

}

area 0.0.0.1 {

interface em4.113;

}


lab5@srx-1# commit

commit complete



Paso 2.8. Ejecute el comando run show ospf route para confirmar que las rutas

OSPF no están usando actualmente la interface gre.0.


lab5@srx-1# up 2

[edit]





192.168.1.2 Intra AS BR IP 1 em4.113 172.20.113.10

192.168.2.1 Intra Area BR IP 1 em1.0 172.20.77.2

192.168.2.2 Inter AS BR IP 2 em1.0 172.20.77.2




172.20.114.0/24 Inter Network IP 2 em1.0 172.20.77.2




192.168.2.2/32 Inter Network IP 2 em1.0 172.20.77.2

P - ¿Hay alguna ruta OSPF usando la interfaz gre.0?

R - Como podemos observar, no existe ninguna ruta OSPF usando la interfaz gre.0, debido a la métrica más alta

configurada anteriormente.

Paso 2.9. Por último, deshabilite nuevamente las interfaces em1 y em2. Active sus

cambios mediante el comando commit y ejecute el comando run show

ospf route para confirmar que las rutas OSPF remotas son ahora

aprendidas a través de la interfaz gre.0.

[edit]

lab5@srx-1# set interfaces em1 disable

[edit]

lab5@srx-1# set interfaces em2 disable

[edit]

lab5@srx-1# commit

commit complete

[edit]





192.168.1.2 Intra AS BR IP 1 em4.113 172.20.113.10

192.168.2.1 Intra Area BR IP 200 gre.0

192.168.2.2 Inter AS BR IP 201 gre.0


172.20.114.0/24 Inter Network IP 201 gre.0





192.168.2.1/32 Intra Network IP 200 gre.0

192.168.2.2/32 Inter Network IP 201 gre.0

P - ¿Están las rutas OSFP usando la interfaz gre.0?

R - Sí, ya que al ser nuevamente deshabilitadas las interfaces em1 y em2, será ahora la interfaz gre.0 (configurada

como backup) la encargada de transportar el tráfico por las rutas OSPF configuradas anteriormente.



5.6 Lab 6: High Availability

En este laboratorio configurará y monitorizará alguna característica de alta disponibilidad

(high availability) usando la línea de comandos (CLI).


em1

Internet

em3 (.

2)

172.1

8.1.0

/30

(.1

) (.1) 172.18.2.0/30 (.2) em3

172.31.15.1

Internet Host

srx-1 srx-2

(.2)

SwitchUser_A

172.25.100.100/24

User_B

172.25.100.101/24

172.25.100.0/24 172.25.100.0/24

em1

(.3)

VIRTUAL IP ADDRESS

172.25.100.1

Figura 40: Escenario del Lab 6 "High Availability"


o Parte 1: Configurar y monitorizar VRRP (Virtual Router Redundancy Protocol).

NOTA: En cuanto a las partes 2 ("Graceful Restart") y 3 ("BDF"), no se ha considerado oportuno llevar a cabo

su implementación, ya que tan sólo hacen referencia a otras de las tantas características de "high availaability".

Hemos considerado VRRP como la más destacada e importante como para llevar a cabo su implementación.



5.6.1 Parte 1: Configuración y Monitorización de VRRP

En esta parte del laboratorio, configurará y monitorizará VRRP.

Paso 1.1. Configure las interfaces según el diagrama de este laboratorio.

[edit]

lab6@srx-1# set interfaces em1 unit 0 family inet address 172.25.100.2/24

[edit]

lab6@srx-1# set interfaces em3 unit 0 family inet address 172.18.1.2/30

[edit]

lab6@srx-1# show interfaces

em1 {

unit 0 {

family inet {

address 172.25.100.2/24;

}

}

}

em3 {

unit 0 {

family inet {

address 172.18.1.2/30;

}

}

}

Paso 1.2. Realice las configuraciones necesarias para que exista conectividad entre todos

los dispositivos del escenario. A continuación, active los cambios mediante el

comando commit.

[edit]



lab6@srx-1# set static route 0/0 next-hop 172.18.1.1


lab6@srx-1# commit

commit complete



Paso 1.3. Realice algunos ping para comprobar que exista conectividad entre los

usuarios (User_A y User_B) y el host de Internet.

VPCS[2]> ping 172.31.15.1

172.31.15.1 icmp_seq=1 ttl=62 time=3.501 ms





VPCS[3]> ping 172.31.15.1






P - ¿Existe conectividad entre los diferentes PCs?

R - Como podemos observar en la salida, los pings han sido realizados correctamente, con lo cual, existe

conectividad entre los diferentes PCs. Los pings realizados han sido desde el User_A (VPCS[2]) y desde el

User_B (VPCS[3]), ambos hacia el Internet_Host (VPCS[1]).

NOTA: Para la simulación de PCs, se ha utilizado la herramienta VPCS que lleva incorporada GNS3

(explicada en apartados anteriores). Las asignaciones de los PCs son las siguientes:

o VPCS[1] = Internet_Host

o VPCS[2] = User_A

o VPCS[3] = User_B

Paso 1.4. Configure VRRP en las interfaces adecuadas de los routers srx-1 y srx-2.

Asegúrese de asignar prioridades diferentes para que srx-1 actúe como master

y srx-2 actúe como backup, además de la dirección IP virtual. A continuación,

active los cambios mediante el comando commit

% CONFIGURACIÓN EN EL ROUTER SRX-1

[edit]

lab6@srx-1# edit interfaces em1


lab6@srx-1# edit unit 0 family inet address 172.25.100.2/24

[edit interfaces em1 unit 0 family inet address 172.25.100.2/24]

lab6@srx-1# set vrrp-group 10 priority 200


lab6@srx-1# set vrrp-group 10 virtual-address 172.25.100.1


lab6@srx-1# up 3




lab6@srx-1# show

unit 0 {

family inet {

address 172.25.100.2/24 {

vrrp-group 10 {

virtual-address 172.25.100.1;

priority 200;

}

}

}

}


lab6@srx-1# commit

commit complete


[edit]

lab6@srx-2# edit interfaces em1


lab6@srx-2# edit unit 0 family inet address 172.25.100.3/24


lab6@srx-2# set vrrp-group 10 priority 100


lab6@srx-2# set vrrp-group 10 virtual-address 172.25.100.1


lab6@srx-2# up 3


lab6@srx-2# show

unit 0 {

family inet {

address 172.25.100.3/24 {

vrrp-group 10 {


priority 100;

}

}

}

}


lab6@srx-2# commit

commit complete

P - ¿Funciona correctamente el VRRP configurado en ambos routers?

R - En este punto debemos recordar que el comportamiento por defecto en un router Juniper es rechazar todo el

tráfico dirigido a la dirección IP virtual del router configurado como master. Para habilitar esta función, y

poder dirigir tráfico a través de esta IP virtual, debemos configurar el router con el comando "accept-data"

dentro de la configuración de VRRP. Mostramos a continuación dicha configuración en ambos routers:





lab6@srx-1# set vrrp-group 10 accept-data


lab6@srx-1# up 3


lab6@srx-1# show

unit 0 {

family inet {

address 172.25.100.2/24 {

vrrp-group 10 {


priority 200;

accept-data;

}

}

}

}


lab6@srx-1# commit

commit complete



lab6@srx-2# set vrrp-group 10 accept-data


lab6@srx-2# up 3


lab6@srx-2# show

unit 0 {

family inet {

address 172.25.100.3/24 {

vrrp-group 10 {


priority 100;

accept-data;

}

}

}

}


lab6@srx-2# commit

commit complete



Paso 1.5. Por último, comprueba el correcto funcionamiento de VRRP en nuestro

escenario.

[edit]

lab6@srx-1# run show vrrp ?

Possible completions:

<[Enter]> Execute this command

brief Display brief output (default)

detail Display detailed output

extensive Display extensive output

interface Show VRRP interface

logical-system Name of logical system

summary Display summary output

track Show VRRP track interfaces

| Pipe through a command

[edit]

lab6@srx-1# run show vrrp summary

VRRP is not running

P - ¿Funciona correctamente VRRP?

R - En principio, una vez configurado VRRP en los pasos previos, debería funcionar correctamente, ya que los

comandos han sido introducidos sin ningún problema como hemos podido observar. Por el contrario, como

podemos observar en la salida, VRRP no está funcionando en el router srx-1 (tampoco en el router srx-2). (Ver

el apartado "TROUBLESHOOTING LABORATORIOS")



5.7 Lab 7: IPv6

En este laboratorio configurará y monitorizará interfaces con IP versión 6 (IPv6) en

dispositivos con sistema operativo Junos. En este laboratorio, usará la línea de comandos

(CLI) para configurar y monitorizar interfaces, enrutamiento estático y OSPF básico.


OSPF Area 0.0.0.0

em2 (::1) em2 (::2)2001:172:20:66::/64

Internet

em3 (::2)

(:

:1)

(::1) (::2) em3

2001:172:31:15::1

Internet Host

srx-1 srx-2

lo0: 2001:192:168:1::1/128

2001:172:18:1::/64 2001:172:18:2::/64

lo0: 2001:192:168:2::1/128

PARTE 3

em2 (::1) em2 (::2)2001:172:20:66::/64

Internet

em3 (::2)

(:

:1)

(::1) (::2) em3

2001:172:31:15::1

Internet Host

srx-1 srx-2

lo0: 2001:192:168:1::1/128

2001:172:18:1::/64 2001:172:18:2::/64

lo0: 2001:192:168:2::1/128

PARTE 1 y 2



Internet

em3 (.

2)

172.1

8.1.0

/30

(.1

) (.1) 172.18.2.0/30 (.2) em3

srx-1 srx-2

lo0: 192.168.1.1 lo0: 192.168.2.1

GRE Tunnel

GRE Tunnel IPv6 address: 2001:c0ff:ee:100::2/64

GRE Tunnel IPv6 address: 2001:c0ff:ee:100::1/64

PARTE 4

Figura 41: Escenarios del Lab 7 "IPv6"


o Parte 1: Configurar y verificar el funcionamiento básico de interfaces con IPv6.

o Parte 2: Configurar y monitorizar enrutamiento estático con IPv6.

o Parte 3: Configurar y monitorizar OSPF con interfaces IPv6.

o Parte 4: Configurar un túnel GRE para transportar tráfico IPv6 sobre una red IPv4.



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

En esta parte del laboratorio, configurará las interfaces de red sobre su dispositivo

asignado. A continuación, verificará que las interfaces son operativas y que el sistema

añade a su tabla de enrutamiento las correspondientes interfaces configuradas.

Paso 1.1. Configure las interfaces de tu dispositivo asignado (router srx-1). Use la

unidad lógica 0 para todas las interfaces. Recuerde configurar la interfaz

loopback.

[edit]


[edit interfaces]

lab7@srx-1# set lo0 unit 0 family inet6 address 2001:192:168:1::1/128

[edit interfaces]

lab7@srx-1# set em3 unit 0 family inet6 address 2001:172:18:1::2/64

[edit interfaces]

lab7@srx-1# set em2 unit 0 family inet6 address 2001:172:20:66::1/64

Paso 1.2. Muestre la configuración de interfaces y asegúrese de que cumple con lo

mostrado en el diagrama de este laboratorio. A continuación, ejecute el

comando commit-and-quit para activar los cambios y volver al modo

operacional.

[edit interfaces]

lab7@srx-1# show

em2 {

unit 0 {

family inet6 {

address 2001:172:20:66::1/64;

}

}

}

em3 {

unit 0 {

family inet6 {

address 2001:172:18:1::2/64;

}

}

}

lo0 {

unit 0 {

family inet6 {

address 2001:192:168:1::1/128;

}

}

}



[edit interfaces]


commit complete


Paso 1.3. Ejecute el comando show interfaces terse para verificar el estado actual

de las interfaces configuradas recientemente.

lab7@srx-1> show interfaces terse


cbp0 up up

demux0 up up

dsc up up

em0 up up

em1 up down

em2 up up

em2.0 up up inet6 2001:172:20:66::1/64

fe80::a00:27ff:fe8c:70ae/64

em3 up up

em3.0 up up inet6 2001:172:18:1::2/64

fe80::a00:27ff:fea2:f223/64

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:270f:fcb4:4f12

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:270f:fcb4:4f12

lsi up up

mtun up up

pimd up up

pime up up

pip0 up up

pp0 up up

tap up up

P - ¿Cuántas direcciones IPv6 son asociadas con cada una de tus interfaces?

R - Todas las interfaces configuradas tendrán dos direcciones IPv6 asignadas. Por un lado, la dirección IPv6

global que hemos configurado manualmente, y por otro lado, la dirección IPv6 link-local, que será

autoconfigurada por el router (EUI-64).

P - ¿Cómo son creadas en el router las otras direcciones?

R - Las direcciones link-local (conocidas por empezar por FE80) son expresadas en el formato IEEE EUI-64. Lo

que hace es introducir en la dirección MAC de dicha interfaz (entre los primeros 24 bits y los últimos 24 bits)

el valor hexadecimal 0xFFFE, obteniéndose así la dirección link-local de dicha interfaz (además, también se

invierte el valor del séptimo bit empezando por la izquierda de la dirección MAC).

lab7@srx-1> show interfaces em2 | match Hardware

Current address: 08:00:27:8c:70:ae, Hardware address: 08:00:27:8c:70:ae



lab7@srx-1> show interfaces em2 terse


em2 up up

em2.0 up up inet6 2001:172:20:66::1/64

fe80::a00:27ff:fe8c:70ae/64

Paso 1.4. Ejecute el comando show route table inet6 para ver las entradas

actuales en la tabla de enrutamiento IPv6.

lab7@srx-1> show route table inet6

inet6.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)


2001:172:18:1::/64 *[Direct/0] 00:19:47

> via em3.0

2001:172:18:1::2/128

*[Local/0] 00:19:47

Local via em3.0

2001:172:20:66::/64*[Direct/0] 00:19:48

> via em2.0

2001:172:20:66::1/128

*[Local/0] 00:19:48

Local via em2.0

2001:192:168:1::1/128

*[Direct/0] 00:19:47

> via lo0.0

fe80::/64 *[Direct/0] 00:19:48

> via em2.0

[Direct/0] 00:19:47

> via em3.0

fe80::a00:270f:fcb4:4f12/128

*[Direct/0] 00:19:47

> via lo0.0

fe80::a00:27ff:fe8c:70ae/128

*[Local/0] 00:19:48

Local via em2.0

fe80::a00:27ff:fea2:f223/128

*[Local/0] 00:19:47

Local via em3.0

P - ¿Cuántas rutas fueron instaladas para cada una de las interfaces configuradas?

R - Cada interfaz física tendrá cuatro rutas instaladas en la tabla de enrutamiento: dos rutas directas y dos rutas

locales para ambos tipos de direcciones (global y link-local). En cambio, la interfaz loopback solamente tendrá

dos rutas directas: una para la dirección global y otra para la dirección link-local.

P - ¿Hay alguna ruta oculta actualmente?

R - Como podemos observar en la salida, actualmente no existe ninguna ruta oculta (0 hidden).



Paso 1.5. Use el ping para verificar que existe conectividad entre los dispositivos

vecinos. Previamente, asegúrese que los dispositivos vecinos estén

configurados con las direcciones correctas.

lab7@srx-1> 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 ---


round-trip min/avg/max/std-dev = 0.370/0.539/1.312/0.223 ms

lab7@srx-1> 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 ---



P - ¿Fueron satisfactorios los pings?

R - Sí, como podemos observar en la salida de arriba, los pings fueron satisfactorios.

Paso 1.6. Ejecute el comando show ipv6 neighbors.

lab7@srx-1> show ipv6 neighbors

IPv6 Address Linklayer Address State Exp Rtr Secure Interface

2001:172:18:1::1 08:00:27:9d:34:9f stale 847 yes no em3.0

2001:172:20:66::2 08:00:27:b8:c1:79 stale 892 yes no em2.0

5.7.2 Parte 2: Configuración y Monitorización de Enrutamiento

Estático

En esta parte del laboratorio, configurará una ruta estática por defecto IPv6.

Paso 2.1. Realice un ping hacia el host de Internet para ver si existe conectividad.

lab7@srx-1> ping 2001:172:31:15::1

PING6(56=40+8+8 bytes) 2001:192:168:1::1 --> 2001:172:31:15::1

ping: sendmsg: No route to host

ping6: wrote 2001:172:31:15::1 16 chars, ret=-1









^C

--- 2001:172:31:15::1 ping6 statistics ---


P - ¿Qué indica el resultado de los pings?

R - Que actualmente no existe una ruta específica desde el router srx-1 hacia el host de Internet.

P - ¿Qué dirección IP debería su dispositivo usar como next-hop para alcanzar el host de Internet?

R - Como podemos observar en el diagrama de nuestro escenario, la dirección de next-hop que deberá usarse en el

dispositivo srx-1 es 2001:172:18:1::1 (en el dispositivo srx-2 será 2001:172:18:2::1).

Paso 2.2. Defina una ruta estática por defecto. Use la dirección IP identificada en el paso

anterior como el next-hop para la ruta estática por defecto.

[edit]

lab7@srx-1# edit routing-options rib inet6.0

[edit routing-options rib inet6.0]

lab7@srx-1# set static route ::/0 next-hop 2001:172:18:1::1

Paso 2.3. Active la ruta estática añadida en el paso anterior y vuelva al modo

operacional. A continuación, ejecute el comando show route

2001:172:31:15::1.

[edit routing-options rib inet6.0]


commit complete


lab7@srx-1> show route 2001:172:31:15::1



::/0 *[Static/5] 00:00:17

> to 2001:172:18:1::1 via em3.0

P - ¿Existe una ruta válida hacia la dirección IPv6 asociada al host de Internet?

R - Sí, como podemos observar en la salida de arriba.

P - ¿Cuál es la preferencia de ruta de la ruta estática por defecto?

R - Como podemos observar en la salida, la ruta estática por defecto usa una preferencia de ruta de 5, que es el

valor por defecto para las rutas estáticas.

Paso 2.4. Ejecute el comando ping 2001:172:31:15::1 para hacer un ping al host

de Internet.



lab7@srx-1> ping 2001:172:31:15::1

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

16 bytes from 2001:172:31:15::1, icmp_seq=0 hlim=62 time=4.193 ms




^C

--- 2001:172:31:15::1 ping6 statistics ---



P - ¿Se ha realizado el ping satisfactoriamente?

R - Sí, el ping se ha llevado a cabo satisfactoriamente.

5.7.3 Parte 3: Configuración y Monitorización de OSPFv3

En esta parte del laboratorio, configurará y monitorizará una interfaz IPv6 en OSPF.

Configurará una simple Área 0 OSPF. Finalmente, verificará el correcto funcionamiento

de OSPF (OSPFv3 para IPv6).

Paso 3.1. Defina OSPF Area 0 e incluya las interfaces internas que conectan al

dispositivo remoto srx-2. Asegúrese que también incluye la interfaz lo0.

También, recuerde que solamente OSPFv3 soporta IPv6. Ejecute el comando

show para ver el resultado de la configuración. (NOTA: En caso de no existir

ninguna interfaz configurada con una dirección IPv4, configure el router-id).

[edit]





lab7@srx-1# top edit protocols ospf3

[edit]

lab7@srx-1# edit protocols ospf3

[edit protocols ospf3]





lab7@srx-1# show

area 0.0.0.0 {

interface em2.0;



interface lo0.0;

}

P - ¿Cuántas adyacencias con vecinos OSPF deberían formarse?

R - Aunque aparecen dos interfaces, solamente una de ellas es capaz de formar una adyacencia con un vecino

OSPF (en nuestro caso, esa interfaz será la em2.0).

Paso 3.2. Active la configuración usando el comando commit and-quit para volver

al modo operacional. Ejecute el comando show ospf3 neighbor para

verificar la información sobre la adyacencia con vecinos OSPF.



commit complete


lab7@srx-1> show ospf3 neighbor

ID Interface State Pri Dead

2.2.2.2 em2.0 Full 128 37

Neighbor-address fe80::a00:27ff:feb8:c179

P - ¿Qué estado presenta la adyacencia con el vecino OSPF?

R - Como podemos observar en la salida de arriba, el estado es Full.

P - ¿Por qué el ID del vecino se muestra como una dirección IPv4?

R - El router-id de un dispositivo vendrá dado por un número de 32 bit, tanto si estamos trabajando con IPv4

como si estamos con IPv6. Recordad que el router-id lo hemos configurado en un paso anterior.

Paso 3.3. Ejecute el comando show route protocol ospf3 para ver las rutas OSPF

activas en la tabla de enrutamiento del dispositivo.

lab7@srx-1> show route protocol ospf3



2001:192:168:2::1/128

*[OSPF3/10] 00:10:51, metric 1

> to fe80::a00:27ff:feb8:c179 via em2.0

ff02::5/128 *[OSPF3/10] 00:20:25, metric 1

MultiRecv

P - ¿Qué significado tiene la dirección ff02::5/128 que aparece?

R - Esta dirección se utiliza en OSPFv3 como dirección multicast para enviar los paquetes Hello entre dispositivos

configurados con OSPFv3. Es el equivalente a la dirección 224.0.0.5 utilizada en OSPFv2, es decir, en OSPF

para IPv4.



5.7.4 Parte 4: Configuración de un túnel GRE para transportar

tráfico IPv6 sobre una red IPv4

En esta parte del laboratorio, configurará un túnel GRE para transportar tráfico IPv6 sobre

una red IPv4. Tenga en cuenta el escenario correspondiente a esta parte, ya que es

totalmente diferente a las partes anteriores.

Paso 4.1. Configure las direcciones IPv4 de las interfaces loopback y em3 que

aparecen en el escenario de esta parte. Finalmente, usando em3 como next-hop,

configure una ruta estática hacia la loopback del dispositivo remoto srx-2.

[edit]


[edit interfaces]

lab7@srx-1# set lo0 unit 0 family inet address 192.168.1.1/32

[edit interfaces]


[edit interfaces]




Paso 4.2. Muestre los cambios y ejecute el comando commit-and-quit para activarlos

y volver al modo operacional.


lab7@srx-1# top

[edit]

lab7@srx-1# show interfaces

em3 {

unit 0 {

family inet {

address 172.18.1.2/30;

}

}

}

lo0 {

unit 0 {

family inet {

address 192.168.1.1/32;

}

}

}



[edit]

lab7@srx-1# show routing-options

static {

route 192.168.2.1/32 next-hop 172.18.1.1;

}

[edit]


commit complete


lab7@srx-1>

Paso 4.3. En este momento, tiene una red IPv4 básica. Compruebe que existe

conectividad con el dispositivo remoto srx-2 realizando un ping. Asegúrese

que el ping se realiza desde la loopback de su dispositivo.

lab7@srx-1> ping 192.168.2.1 source 192.168.1.1 rapid

PING 192.168.2.1 (192.168.2.1): 56 data bytes

!!!!!





R - Sí, el ping fue satisfactorio, lo que indica que existe conectividad entre ambos dispositivos.

Paso 4.4. Defina una interfaz y túnel GRE usando la dirección IP asignada a su interfaz

loopback como la dirección de fuente y la dirección IP asignada a la interfaz

loopback del dispositivo remoto srx-2 como dirección de destino. Use unit

0 para la interfaz lógica punto-a-punto.



[edit]


[edit interfaces]

lab7@srx-1# set gre unit 0 family inet

[edit interfaces]

lab7@srx-1# set gre unit 0 tunnel source 192.168.1.1

[edit interfaces]

lab7@srx-1# set gre unit 0 tunnel destination 192.168.2.1

[edit interfaces]

lab7@srx-1# show gre

unit 0 {



tunnel {

source 192.168.1.1;

destination 192.168.2.1;

}

family inet;

}

Paso 4.5. Active los cambios y ejecute el comando run show interfaces terse

gre para verificar el estado de la interfaz GRE definida.

[edit interfaces]

lab7@srx-1# commit

commit complete

[edit interfaces]

lab7@srx-1# run show interfaces terse gre


gre up up

gre.0 up up inet

P - ¿Cuál es el estado actual de la interfaz gre.0?

R - Como podemos observar, su estado Admin y Link es up.

Paso 4.6. Configure una dirección IPv6 en su interfaz GRE. Fíjese en el diagrama para

saber qué dirección IPv6 usar. A continuación, active los cambios con el

comando commit.

[edit interfaces]

lab7@srx-1# set gre unit 0 family inet6 address 2001:c0ff:ee:100::1/64

[edit interfaces]

lab7@srx-1# commit

commit complete

Paso 4.7. Realice un ping a la dirección IPv6 de la interfaz GRE del dispositivo remoto

srx-2 para verificar que existe conectividad.

[edit interfaces]

lab7@srx-1# run ping 2001:c0ff:ee:100::2 count 3

PING6(56=40+8+8 bytes) 2001:c0ff:ee:100::1 --> 2001:c0ff:ee:100::2

16 bytes from 2001:c0ff:ee:100::2, icmp_seq=0 hlim=64 time=3.943 ms



--- 2001:c0ff:ee:100::2 ping6 statistics ---





P - ¿Cómo es enviado el tráfico IPv6 a través del túnel?

R - Cuando se realiza un ping a la dirección IPv6 de la interfaz GRE del dispositivo remoto, nuestro dispositivo

encuentra una ruta directa hacia el destino a través de nuestra interfaz GRE. El router, entonces, se da cuenta

de que el tráfico necesita ser tunelado o encapsulado para poder ser transportado sobre la red IPv4. Para ello,

añade una cabecera GRE al paquete IPv4 con dirección de destino igual a la dirección destino del túnel.

Paso 4.8. Ejecute el comando run show route 2001:c0ff:ee:100::2 para

comprobar que el destino IPv6 es, efectivamente, la interfaz GRE.

[edit interfaces]

lab7@srx-1# run show route 2001:c0ff:ee:100::2



2001:c0ff:ee:100::/64

*[Direct/0] 00:23:32

> via gre.0

Paso 4.9. Ejecute el comando run show interfaces gre.0. Fíjese en la línea IP-

Header.

[edit interfaces]

lab7@srx-1# run show interfaces gre.0

Logical interface gre.0 (Index 71) (SNMP ifIndex 506)

Flags: Point-To-Point SNMP-Traps 0x4000

IP-Header 192.168.2.1:192.168.1.1:47:df:64:0000000000000000

Encapsulation: GRE-NULL

Gre keepalives configured: Off, Gre keepalives adjacency state: down

Input packets : 5

Output packets: 5

Protocol inet, MTU: 1476

Flags: Sendbcast-pkt-to-re

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:fccd:abfe

P - ¿Qué indica la línea IP-Header?

R - Esa línea nos dice que para comunicarse con la IPv6 del dispositivo remoto srx-2, el dispositivo srx-1 lo que

hará será añadir una cabecera GRE y lo encapsulará todo en un paquete IPv4 con dirección fuente 192.168.1.1

y dirección destino 192.168.2.1.

P - ¿Qué significa el número 47 en la línea IP-Header?

R - Indica el tipo de protocolo IP usado por GRE.



Paso 4.10. Ejecute el comando run show route address para ver cómo nuestros

paquetes IPv6 encapsulados salen del router, donde address es la dirección

loopback del dispositivo remoto srx-2.

[edit interfaces]




192.168.2.1/32 *[Static/5] 01:04:22

> to 172.18.1.1 via em3.0

P - ¿Qué demuestra la salida?

R - La salida de arriba demuestra que los paquetes IPv6, una vez son encapsulados, usan el túnel IPv4 para

alcanzar su destino.



5.8 Lab 8: IS-IS

En este laboratorio configurará y monitorizará el protocolo de enrutamiento IS-IS

(Intermediate System to Intermediate System). En este laboratorio usará la línea de

comandos (CLI) para configurar, monitorizar y solucionar problemas de IS-IS.


em2 (.1)

em1 (.1)

em2 (.2)

em1 (.2)

172.20.66.0/30

172.20.77.0/30

Internet

em3 (.

2)

172.1

8.1.0

/30

(.1

) (.1) 172.18.2.0/30 (.2) em3

172.31.15.1

Internet Host

srx-1 srx-2

vr113 vr114

em4.113 (.1)

172.20.113.0/24

em1.113 (.10)

(.1) em4.114

172.20.114.0/24

(.10) em1.114

lo0: 192.168.1.1

lo0: 192.168.1.2

lo0: 192.168.2.1

lo0: 192.168.2.2

IS-IS Area 49.0001

IS-IS Area 49.0002

L1/L2 Router L1/L2 Router

L1 Router L1 Router

Figura 42: Escenario del Lab 8 "IS-IS"


o Parte 1: Configurar y monitorizar una red IS-IS multinivel.

o Parte 2: Solucionar problemas básicos en IS-IS.



5.8.1 Parte 1: Configuración y Monitorización de IS-IS

En esta parte del laboratorio, configurará y monitorizará una red IS-IS multinivel. En

primer lugar, definirá un router ID para su dispositivo asignado. A continuación,

configurará su dispositivo para participar en una red IS-IS multinivel y verificará su

comportamiento mediante los comandos del modo operacional de la CLI.

Paso 1.1. Sitúese en el nivel jerárquico [edit routing-options] y defina el router-

ID en su router usando como valor la dirección IP asignada a la interfaz lo0.

[edit]




Paso 1.2. Sitúese en el nivel jerárquico [edit interfaces] y añada la familia ISO y

la dirección NET (Network Entity Title) a la interfaz lo0. Rellene cada octeto

del router-ID con ceros a la izquierda para formar la parte de system-ID de la

dirección NET. Por tanto, si la dirección lo0 del router es 192.168.1.1, la parte

del system-ID de la dirección NET será 1921.6800.1001. El campo N-selector

(SEL) es 00.


lab8@srx-1# top edit interfaces

[edit interfaces]

lab8@srx-1# set lo0 unit 0 family iso address 49.0001.1921.6800.1001.00

[edit interfaces]

lab8@srx-1# show lo0

unit 0 {

family inet {

address 192.168.1.1/32;

}

family iso {

address 49.0001.1921.6800.1001.00;

}

}

Paso 1.3. Añada family iso a las interfaces de tránsito.

[edit interfaces]

lab8@srx-1# set em1 unit 0 family iso



[edit interfaces]


[edit interfaces]


Paso 1.4. Sitúese en el nivel jerárquico [edit protocols isis] y configure los

niveles IS-IS. Haz que las interfaces lo0, em1 y em2 sean del nivel 2 solamente.

[edit interfaces]

lab8@srx-1# top edit protocols isis

[edit protocols isis]

lab8@srx-1# set interface lo0 level 1 disable


lab8@srx-1# set interface em1 level 1 disable


lab8@srx-1# set interface em2 level 1 disable

Paso 1.5. Active la configuración y ejecute el comando run show isis adjacency.


lab8@srx-1# commit

commit complete


lab8@srx-1# run show isis adjacency

Interface System L State Hold (secs) SNPA

em1.0 srx-2 2 Up 20 8:0:27:90:cd:de

em2.0 srx-2 2 Up 26 8:0:27:98:42:7d

P - ¿Qué estado presentan las interfaces en la adyacencia con el vecino?

R - Como podemos observar en la salida de arriba, tanto la interfaz em1.0 como la em2.0 presentan un estado Up.

P - ¿Qué valor es mostrado bajo la columna L (Level)?

R - Para ambas interfaces, el valor es 2, el cual indica que se han establecido adyacencias en el nivel 2.

Paso 1.6. Ejecute el comando run show isis interface para mostrar los detalles

IS-IS de las interfaces.


lab8@srx-1# run show isis interface

IS-IS interface database:

Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric

em1.0 2 0x2 Disabled srx-1.02 10/10



em2.0 2 0x3 Disabled srx-1.03 10/10

lo0.0 0 0x1 Disabled Passive 0/0

P - ¿Qué interfaces son mostradas en la salida?

R - Son mostradas las interfaces em1.0, em2.0 y lo0.0. La interfaz lo0.0 siempre será listada como Passive, ya

que no se podrá formar ninguna adyacencia con ella.

Paso 1.7. Ejecute el comando run show isis database para mostrar los detalles de

la base de datos IS-IS.


lab8@srx-1# run show isis database

IS-IS level 1 link-state database:

LSP ID Sequence Checksum Lifetime Attributes

srx-1.00-00 0x3 0xe6f0 722 L1 L2 Attached

1 LSPs



srx-1.00-00 0x4 0xe561 730 L1 L2

srx-1.02-00 0x2 0xa16c 722 L1 L2

srx-1.03-00 0x2 0x9a72 730 L1 L2

srx-2.00-00 0x4 0x76b8 709 L1 L2

4 LSPs

P - ¿Cuántos LSPs (link-state protocol data units) existen en la base de datos IS-IS?

R - Como podemos observar en la salida, existen un total de 5 LSPs: cuatro en el nivel 2 y uno en el nivel 1.

Paso 1.8. Muestre las rutas anunciadas y recibidas con IS-IS usando el comando run

show isis route.


lab8@srx-1# run show isis route

IS-IS routing table Current version: L1: 5 L2: 8

IPv4/IPv6 Routes

----------------

Prefix L Version Metric Type Interface NH Via

192.168.2.1/32 2 8 10 int em1.0 IPV4 srx-2

em2.0 IPV4 srx-2

Paso 1.9. Ejecute el comando run show route protocol isis para ver la rutas IS-

IS instaladas en la tabla de enrutamiento.


lab8@srx-1# run show route protocol isis





192.168.2.1/32 *[IS-IS/18] 00:29:58, metric 10

> to 172.20.77.2 via em1.0

to 172.20.66.2 via em2.0

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

P - ¿Qué rutas IS-IS aparecen en la tabla de enrutamiento?

R - Solamente aparece la ruta hacia la dirección loopback del router remoto srx-2.

P - ¿Por qué no aparecen en la salida las rutas 172.20.66.0/30 y 172.20.77.0/30?

R - Porque ambas son instaladas en la tabla de enrutamiento como rutas directas. Hay que recordar que las rutas

directas tienen una preferencia de ruta de 0, mientras que las rutas IS-IS internas de 18.

Paso 1.10. Configure su dispositivo con una adyacencia de nivel 1 al router virtual. A

continuación, active los cambios y vuelva al modo operacional.


lab8@srx-1# set interface em4.113 level 2 disable



commit complete


Paso 1.11. Ejecute el comando run show isis adjacency para verificar los detalles

de la adyacencia IS-IS formada.

lab8@srx-1> show isis adjacency


em1.0 srx-2 2 Up 25 8:0:27:90:cd:de

em2.0 srx-2 2 Up 26 8:0:27:98:42:7d

em4.113 vr113 1 Up 25 8:0:27:3:43:b2

P - ¿Cuántas adyacencias IS-IS existen y cuáles son sus estados?

R - Como podemos observar en la salida, existen tres adyacencias y todas presentan un estado Up .

Paso 1.12. Ejecute el comando show isis database para mostrar la actual base de

datos IS-IS.

lab8@srx-1> show isis database



srx-1.00-00 0x7 0x219e 916 L1 L2 Attached



srx-1.04-00 0x1 0x9793 916 L1 L2

vr113.00-00 0x2 0x7091 914 L1 L2

3 LSPs



srx-1.00-00 0x6 0x8c92 546 L1 L2

srx-1.02-00 0x5 0x9b6f 546 L1 L2

srx-1.03-00 0x4 0x9674 546 L1 L2

srx-2.00-00 0x6 0x72ba 686 L1 L2

4 LSPs

P - ¿Cuántos LSPs existen en la base de datos en este momento?

R - Existen un total de 7 LSPs: tres LSPs en la base de datos del nivel 1 y cuatro LSPs en la del nivel 2.

P - ¿Qué comando lista solamente el nivel 2 en la base de datos IS-IS?

R - El comando sería el siguiente: show isis database level 2. Su salida la podemos observar a

continuación.

lab8@srx-1> show isis database level 2



srx-1.00-00 0x7 0x8a93 1104 L1 L2

srx-1.02-00 0x6 0x9970 1146 L1 L2

srx-1.03-00 0x5 0x9475 1146 L1 L2

srx-2.00-00 0x6 0x72ba 461 L1 L2

4 LSPs

5.8.2 Parte 2: Solución de problemas básicos en IS-IS

En esta parte del laboratorio, solucionará algunos problemas básicos en IS-IS. En primer

lugar, modificará la configuración actual de su dispositivo para hacerlo incompatible con

el router virtual conectado a él. A continuación, habilitará traceoptions IS-IS para registrar

la actividad del protocolo. Finalmente, mostrará dichos registros para ver los posibles

errores asociados.

Paso 2.1. En primer lugar, modifique el área del dispositivo asignado srx-1 para que no

coincida con el área del router virtual vr113 (srx-1 pasará a estar en el área

49.0003, mientras que vr113 permanecerá en el área 49.0001). A continuación,

active los cambios usando el comando commit.

[edit]

lab8@srx-1# edit interfaces lo0 unit 0 family iso

[edit interfaces lo0 unit 0 family iso]

lab8@srx-1# rename address 49.0001.1921.6800.1001.00 to address 49.0003.1921.6800.1001.00



[edit interfaces lo0 unit 0 family iso]

lab8@srx-1# up 4

[edit]

lab8@srx-1# show interfaces lo0

unit 0 {

family inet {

address 192.168.1.1/32;

}

family iso {

address 49.0003.1921.6800.1001.00;

}

}

[edit]

lab8@srx-1# commit

commit complete

Paso 2.2. Ejecute el comando run show isis adjacency.

[edit]



em1.0 srx-2 2 Up 23 8:0:27:90:cd:de

em2.0 srx-2 2 Up 22 8:0:27:98:42:7d

P - ¿Cuántas adyacencias IS-IS existen actualmente en el dispositivo srx-1?

R - Como podemos observar en la salida, existen dos adyacencias de nivel 2 con el dispositivo remoto srx-2. La

adyacencia de nivel 1 con el router vr113 ha desaparecido, debido a que ahora mismo pertenecen a áreas

diferentes.

Paso 2.3. Sitúese en el nivel [edit protocols isis] y defina opciones de

seguimiento (traceoptions) para que los errores IS-IS sean escritos en un

archivo llamado trace-isis. Incluya la opción detail con el flag error

para capturar los detalles adicionales en los errores IS-IS. Por último, active los

cambios usando el comando commit.

[edit]

lab8@srx-1# edit protocols isis


lab8@srx-1# set traceoptions file trace-isis


lab8@srx-1# set traceoptions flag error detail


lab8@srx-1# commit

commit complete



Paso 2.4. Ejecute el comando run show log trace-isis para ver lo que se ha

escrito en el archivo de seguimiento trace-isis.


lab8@srx-1# run show log trace-isis Apr 9 16:51:40.936044 local area 49.0003

Apr 9 16:51:40.936114 remote area 49.0001 (3 bytes)

Apr 9 16:51:49.577331 ERROR: IIH from vr113 with no matching areas, interface em4.113

Apr 9 16:51:49.577478 local area 49.0003

Apr 9 16:51:49.577498 remote area 49.0001 (3 bytes)

Apr 9 16:51:57.569447 ERROR: IIH from vr113 with no matching areas, interface em4.113

P - ¿El error generado en el archivo de seguimiento explica el actual problema de adyacencia IS-IS?

R - Basándonos en el contenido del archivo de seguimiento, podemos observar que el actual problema de

adyacencia IS-IS es debido a que los dispositivos srx-1 y vr113 pertenecen a áreas diferentes. Mientras que el

router srx-1 se encuentra en el área 49.003, el router vr113 está en el área 49.001.

Paso 2.5. Sitúese en el nivel [edit interfaces lo0 unit 0] y elimine la dirección

NET incorrecta y establezca la dirección correcta. Configure IS-IS Nivel 1 para

que tenga una autenticación simple con juniper como contraseña.


lab8@srx-1# top edit interfaces lo0 unit 0

[edit interfaces lo0 unit 0]

lab8@srx-1# show

family inet {

address 192.168.1.1/32;

}

family iso {

address 49.0003.1921.6800.1001.00;

}


lab8@srx-1# delete family iso address 49.0003.1921.6800.1001.00


lab8@srx-1# set family iso address 49.0001.1921.6800.1001.00


lab8@srx-1# top edit protocols isis


lab8@srx-1# set level 1 authentication-type simple


lab8@srx-1# set level 1 authentication-key juniper


lab8@srx-1# commit

commit complete



Paso 2.6. Ejecute el comando run clear log trace-isis para limpiar el contenido

del archivo de seguimiento. Espere un minuto y entonces ejecute el comando

run show log trace-isis para ver las nuevas entradas en el archivo.


lab8@srx-1# run show log trace-isis

Apr 9 17:15:16 srx-1 clear-log[1620]: logfile cleared

Apr 9 17:15:17.034835 ERROR: IIH from 1921.6800.1002 on em4.113 without authentication

Apr 9 17:15:17.035110 ERROR: previous error from L1, source 1921.6800.1002 on em4.113





P - ¿El error generado en el archivo de seguimiento explica el actual problema de adyacencia IS-IS?

R - Basándonos en el contenido del archivo de seguimiento, podemos observar que el actual problema de

adyacencia IS-IS es debido a un problema de autenticación. En concreto, el problema está en que el dispositivo

vr113 no ha sido configurado previamente con una autenticación simple cuya contraseña sea "juniper".

Paso 2.7. Elimine la autenticación del dispositivo srx-1 para que se pueda establecer la

adyacencia con el router virtual vr113 sin ningún problema. A continuación,

active los cambios usando el comando commit.


lab8@srx-1# delete level 1 authentication-type simple


lab8@srx-1# commit

commit complete

Paso 2.8. Verifique que las adyacencias IS-IS han vuelto al estado Up entre su

dispositivo srx-1 y el router directamente conectado vr113.




em1.0 srx-2 2 Up 22 8:0:27:90:cd:de

em2.0 srx-2 2 Up 18 8:0:27:98:42:7d

em4.113 vr113 1 Up 24 8:0:27:3:43:b2

P - ¿Ha vuelto la adyacencia IS-IS con el router vr113 al estado de Up?

R - Como podemos observar en la salida de arriba, se ha vuelto a establecer la adyacencia perfectamente entre

ambos dispositivos.



5.9 Troubleshooting Laboratorios

A continuación, y una vez completados los laboratorios correspondientes a la parte de

routing de la certificación JNCIS (Juniper Networks Certified Internet Specialist), pasaremos a

analizar los distintos problemas encontrados en la simulación de dichos laboratorios en

GNS3, así como posibles soluciones de los mismos. La metodología seguida ha sido la

siguiente:

PASO 3 - Implementar acciones correctivas

PASO 1 - Detectar síntomas

PASO 2 - Aislar el problema

Si no se ha solucionado el problema o se ha creado otro problema, deshacer la acción correctiva y empezar de nuevo.

- Documentar la solución- Guardar los cambios

¿Problema solucionado?SÍNO

Figura 43: Troubleshooting Laboratorios

Pasamos pues, a analizar independientemente cada uno de los laboratorios

implementados en apartados anteriores:



Lab.1 - Protocol-Independent Routing:

En este laboratorio se han configurado y monitorizado características de enrutamiento

independientes de protocolos en dispositivos que ejecutan el sistema operativo Junos. Este

laboratorio constaba de tres partes:

o Parte 1: Comprobación del correcto funcionamiento de las interfaces de red.

- Observaciones: Todo ha funcionado correctamente en GNS3.

o Parte 2: Configurar y monitorizar rutas estáticas y agregadas.


o Parte 3: Configurar instancias de enrutamiento y compartir rutas entre ellas usando

grupos de tablas de enrutamiento.


Lab.2 - Load Balancing and Filter-Based Forwarding:

En este laboratorio se han configurado y monitorizado el balanceo de carga y el reenvío

de paquetes basado en filtros (FBF) en dispositivos que ejecutan el sistema operativo

Junos. Este laboratorio constaba de dos partes:

o Parte 1: Configuración y monitorización de los efectos del balanceo de carga.


o Parte 2: Configuración y monitorización del FBF (Filter-Based Forwarding).




Lab.3 - Open Shortest Path First (OSPF):

En este laboratorio se ha configurado y monitorizado el protocolo OSPF (Open Shortest

Path First) en dispositivos que ejecutan el sistema operativo Junos. Este laboratorio

constaba de dos partes:

o Parte 1: Configuración y monitorización de OSPF multiárea.


o Parte 2: Solución de problemas básicos en OSPF.


Lab.4 - Border Gateway Protocol (BGP):

En este laboratorio se ha configurado y monitorizado el protocolo BGP (Border Gateway

Protocol) en dispositivos que ejecutan el sistema operativo Junos. Este laboratorio constaba

de dos partes:

o Parte 1: Configuración y monitorización de IBGP.

- Observaciones: Todo ha funcionado correctamente en GNS3. No obstante, tenemos que ser

conscientes del comportamiento por defecto de BGP en cuanto a publicación de rutas. Por

defecto, solamente las rutas activas serán anunciadas. Las reglas que sigue BGP en cuanto

a publicación de rutas son las siguientes:

1. Dispositivos internos (IBGP) anuncian rutas recibidas desde dispositivos externos

(EBGP) a otros dispositivos internos (IBGP).

2. Dispositivos externos (EBGP) anuncian rutas aprendidas desde dispositivos

internos (IBGP) o externos (EBGP) a otros dispositivos externos (EBGP).

3. Dispositivos internos (IBGP) no anuncian rutas recibidas desde dispositivos

internos (IBGP) a otros dispositivos internos (IBGP).

El objetivo de estas reglas que sigue el protocolo BGP por defecto es evitar bucles de

enrutamiento en redes que utilicen BGP, tanto interno (IBGP) como externo (EBGP).



o Parte 2: Exportación de rutas agregadas a un peer EBGP.

- Observaciones: Todo ha funcionado correctamente en GNS3. Simplemente tenemos que

tener en cuenta que al no tener acceso a los paquetes que deberían cargarse en los

dispositivos previamente, donde hay muchas más rutas, ASs, etc. con lo cual no se pueden

obtener los resultados esperados. Por tanto, tan solo realizamos configuraciones básicas

para comprobar el correcto funcionamiento de IBGP y EBGP.

Lab.5 - IP Tunneling:

En este laboratorio se ha configurado y monitorizado un túnel GRE (Generic Routing

Encapsulation) mediante el uso de la línea de comandos (CLI). Este laboratorio constaba de

dos partes:

o Parte 1: Configuración y monitorización de un túnel GRE.


o Parte 2: Usar el túnel GRE configurado para unir dos dominios OSPF remotos.


Lab.6 - High Availability:

En este laboratorio se ha configurado y monitorizado una característica de alta

disponibilidad (high availability) en dispositivos que ejecutan el sistema operativo Junos.

Este laboratorio constaba de la siguiente parte:

o Parte 1: Configuración y monitorización de VRRP.

- Observaciones: En principio, una vez configurado VRRP, debería funcionar correctamente,

ya que los comandos han sido introducidos y asimilados sin ningún problema en los

distintos dispositivos. Por el contrario, como podemos observar en la salida de abajo, VRRP

no está funcionando en el router srx-1 (tampoco en el router srx-2).



[edit]

lab6@srx-1# run show vrrp ?

Possible completions:

<[Enter]> Execute this command

brief Display brief output (default)

detail Display detailed output

extensive Display extensive output

interface Show VRRP interface

logical-system Name of logical system

summary Display summary output

track Show VRRP track interfaces

| Pipe through a command

[edit]

lab6@srx-1# run show vrrp summary

VRRP is not running

- Posibles causas: En principio, se podría pensar que es debido a que el router master VRRP

de forma predeterminada no responde a ningún tráfico IP hasta que no se habilite la opción

"accept-data", pero incluso configurando dicha opción, VRRP sigue sin funcionar. Por otra

parte, este laboratorio también se ha realizado con otra versión de JUNOS (concretamente,

JunOS Olive 10.4R1.9) para comprobar si el problema estaba en la versión de la oliva

utilizada. El resultado obtenido ha sido el mismo, con lo cual, no es problema de la versión.

Por lo tanto, podemos concluir que actualmente estas olivas utilizadas en GNS3 no son

capaces de emular el comportamiento de esta característica "high availability" de

enrutamiento avanzado.

- Solución: VRRP debería ser configurado directamente sobre routers Juniper físicos reales.

Lab.7 - IPv6:

En este laboratorio se han configurado y monitorizado interfaces con IP versión 6 (IPv6)

en dispositivos que ejecutan el sistema operativo Junos. Este laboratorio constaba de tres

partes:

o Parte 1: Configuración y verificación del funcionamiento básico de interfaces con IPv6.




o Parte 2: Configuración y monitorización de enrutamiento estático con IPv6.


o Parte 3: Configuración y monitorización de OSPF con IPv6.


o Parte 4: Configuración de túnel GRE para transportar tráfico IPv6 sobre una red IPv4.


Lab.8 - IS-IS:

En este laboratorio se ha configurado y monitorizado el protocolo de enrutamiento IS-IS

(Intermediate System to Intermediate System) en dispositivos que ejecutan el sistema

operativo Junos. Este laboratorio constaba de dos partes:

o Parte 1: Configuración y monitorización de una red IS-IS multinivel.


o Parte 2: Solución de problemas básicos en IS-IS.




6 Conclusiones

Teniendo en cuenta los objetivos marcados al comienzo de este Trabajo Fin de Máster,

podemos concluir que se han cumplido todos los objetivos del mismo. Se han conseguido

simular en GNS3 prácticamente todos los apartados de los laboratorios correspondientes

a la parte de enrutamiento de la certificación JNCIS de Juniper. Aquellos que no se han

podido implementar en GNS3, se ha dejado indicado cuáles serían las alternativas

posibles para realizar dichos apartados.

Teniendo en cuenta todo ello, las principales conclusiones obtenidas del presente TFM

serían las siguientes:

La tecnología Juniper está experimentando un espectacular crecimiento a nivel

mundial, sobre todo en Europa, debido entre otras cosas a las características peculiares

que presenta su sistema operativo JUNOS, el cual tiene una gran robustez a la hora de

montarse sobre diferente hardware Juniper, lo que permite que exista una alta

compatibilidad entre dispositivos Juniper en un mismo escenario.

Para conseguir simular redes Juniper en GNS3, previamente tendrán que ser

montadas las máquinas virtuales con el sistema operativo JUNOS (las llamadas

"olivas") en los routers o dispositivos en cuestión que van a ser simulados en GNS3.

Estas "olivas" han sido creadas previamente utilizando el programa VirtualBox.

En cuanto al programa simulador de redes GNS3, ha quedado demostrada su validez

a la hora de simular el comportamiento de redes Juniper. Hasta la fecha, dicho

programa era utilizado principalmente para redes Cisco, siendo Juniper una

tecnología poco amigable a la hora de ser simulada en programas como GNS3.

El switching en GNS3 aún no está desarrollado, con lo que realizar pruebas avanzadas

de capa 2 en GNS3 aún no es posible. No obstante, GNS3 proporciona unos switches



virtuales con las características básicas de conmutación, para poder realizar las tareas

mínimas necesarias que puede llevar a cabo un switch de capa 2.

Los laboratorios correspondientes a la parte de enrutamiento de la certificación JNCIS

de Juniper han podido simularse en GNS3 de forma correcta en prácticamente la

totalidad de sus apartados.

Los protocolos de enrutamiento dinámico avanzado configurados y analizados en los

laboratorios (concretamente, los protocolos OSPF, IS-IS y BGP) han sido aceptados y

simulados correctamente en GNS3 sin ningún tipo de problemas.

Características de enrutamiento avanzado, tales como: Instancias de enrutamiento,

políticas de balanceo de carga, FBF (Filter-Based Forwarding), etc. han sido

configuradas y simuladas correctamente en GNS3 sin ningún tipo de problemas.

La configuración y puesta en marcha de túneles GRE (Generic Routing Encapsulation)

han sido aceptados y simulados correctamente en GNS3.

El programa simulador de redes GNS3 soporta la configuración de interfaces con

IPv6, así como características de enrutamiento avanzado relacionadas con dicho

protocolo (por ejemplo: túneles que transportan tráfico IPv6 sobre una red IPv4).

El protocolo VRRP (Virtual Router Redundancy Protocol) no funciona sobre

escenarios virtuales. Éste y otros problemas que pueden encontrarse en la simulación

de redes, suelen ser resueltos empleando equipos físicos reales.



7 Líneas Futuras

Como ya hemos comentado en apartados anteriores, la tecnología Juniper está tomando

fuerza a nivel mundial, con la consiguiente necesidad de personal altamente cualificado y

preparado para llevar a cabo el soporte de redes que utilicen dicha tecnología. En este

TFM hemos llevado a cabo la simulación de los escenarios correspondientes a la parte de

enrutamiento avanzado de la certificación JNCIS de Juniper, pero está claro que a partir

de aquí se abre un amplio camino para continuar con esta línea de trabajo.

Las principales líneas futuras de trabajo serían las siguientes:

Una vez realizada la parte de enrutamiento de la certificación JNCIS de Juniper sobre

GNS3, realizar la parte de conmutación. Actualmente no se puede, pero GNS3 está

trabajando para poder implementar simulaciones avanzadas de conmutación.

Una vez completados todos los laboratorios del JNCIS, continuar con las simulaciones

de escenarios correspondientes a las siguientes certificaciones de Juniper: JNCIP y

JNCIE.

Crear una red de aprendizaje web para la preparación de certificaciones Juniper, con

sus correspondientes herramientas de aprendizaje (materiales de apoyo, prácticas,

foros, etc.) integradas en dicha plataforma y que sirvan de ayuda al alumno en

cuestión (como el Cisco NetAcad que tiene actualmente Cisco).

Una vez comprobado el correcto funcionamiento de las simulaciones en GNS3,

realizar una comparativa en cuanto a tiempos de respuesta, asimilación de comandos,

convergencia de la red, etc. utilizando equipamiento Juniper físico real.

Enumerar, describir y analizar las principales diferencias que pueden existir entre las

diferentes versiones de JUNOS a la hora de simular redes Juniper en GNS3 (la versión

utilizada en este TFM es JunOS Olive 12.1R1.9).



Realizar una comparativa en cuanto a rendimiento entre Juniper y otra tecnología

(Cisco o Huawei, por ejemplo) simulando escenarios semejantes en GNS3.

Programar una aplicación capaz de transformar los comandos Juniper a otra

tecnología (Cisco, por ejemplo). Es decir, que una vez guardada la configuración de un

dispositivo Juniper en un fichero .txt por ejemplo, esta aplicación sea capaz de

"traducir" esa configuración de Juniper a Cisco, para posteriormente poder ser cargada

directamente en el dispositivo Cisco en cuestión sin ningún tipo de incompatibilidad.



8 Bibliografía

[1] JNCIS-ENT Routing Study Guide, Juniper Networks, Inc., 2012

[2] Junos Intermediate Routing High-Level Lab Guide, Juniper Networks, Inc., 2012

[3] JNCIA-Junos Study Guide—Part 1, Juniper Networks, Inc., 2012

[4] JNCIA-Junos Study Guide—Part 2, Juniper Networks, Inc., 2012

[5] Peter Southwick, Doug Marschke and Harry Reynolds, Junos Enterprise Routing,

Second Edition, O'Reilly Media, Inc., 2011

[6] Junos OS High Availability Configuration Guide, Juniper Networks, Inc., 2012

[7] Chris Welsh, GNS3 Network Simulation Guide, Packt Published Ltd., 2013

[8] Chris Grundemann, Day One: Exploring IPv6, Juniper Networks, Inc., 2011

[9] John J. Amoss and Daniel Minoli, IPv4 to IPv6 Transition, Taylor & Francis Group,

LLC, 2008

[10] How to install Juniper JunOS Olive 12. 1R1. 9 for GNS3 with VirtualBox:

http://vidoz.com.ua/video/DoX-nwlVCF5.html

[11] Connecting GNS3 to Real Networks:

http://www.gns3.net/documentation/gns3/connecting-gns3-to-real-networks/

[12] Connecting hosts to your Topologies:

http://www.gns3.net/documentation/gns3/adding-hosts-to-your-topologies/

[13] How to configure a GRE tunnel in JUNOS:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB12769

http://vidoz.com.ua/video/DoX-nwlVCF5.html

http://www.gns3.net/documentation/gns3/connecting-gns3-to-real-networks/

http://www.gns3.net/documentation/gns3/adding-hosts-to-your-topologies/

https://kb.juniper.net/InfoCenter/index?page=content&id=KB12769

Escenarios de Enrutamiento Dinámico Avanzado en Entornos Virtuales mediante Tecnología Juniper

Technology

Transcript of Escenarios de Enrutamiento Dinámico Avanzado en Entornos Virtuales mediante Tecnología Juniper