Enrutamiento dinámico y virtualización 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í]

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

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.
Protocolosde EnrutamientoDinámico
IGPs
(Interior Gateway Protocols)
VectorDistancia
RIP EIGRP
Estado de Enlace
OSPF IS-IS
EGPs
(Exterior Gateway Protocols)
VectorCamino
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)em3
(.1)
172.18.1.0/30
(.2)em
3
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)em3
(.1)
172.18.1.0/30
(.2)em
3
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
Entering configuration mode
[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
em
3
(.2)
172.18.1.0/30
(.1)
(.1)
172.18.2.0/30
(.2)em
3
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
Exiting configuration mode
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
Interface Admin Link Proto Local Remote
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# set aggregate route 172.20.64.0/18
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.
lab1@srx-1# run show route 172.20.64.1
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.
lab1@srx-1# commit and-quit
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
P - ¿Fue satisfactorio el ping?
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.
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
em
3
(.2)
172.18.1.0/30
(.1)
(.1)
172.18.2.0/30
(.2)em
3
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"
Para completar este laboratorio, llevaremos a cabo las siguientes tareas:
o Parte 1: Configurar y monitorizar los efectos del balanceo de carga.
o Parte 2: Configurar y monitorizar FBF (Filter-Based Forwarding).

Enrutamiento dinámico y virtualización Juniper

Enrutamiento dinámico y virtualización Juniper

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (13)

En vedette

En vedette (20)

Similaire à Enrutamiento dinámico y virtualización Juniper

Similaire à Enrutamiento dinámico y virtualización Juniper (20)

Dernier

Dernier (13)

Enrutamiento dinámico y virtualización Juniper