Informe VPN FrameRelay IPSEC GRE 514 658

ESCUELA SUPERIOR POLITÉCNICA DE
CHIMBORAZO
FACULTAD DE INFORMATICA Y ELECTRONICA
ESCUELA DE INGENIERIA ELECTRONICA
MATERIA:
CONMUTACION Y RUTEO II
TEMA:
CONFIGURACIÓN BGP, FRAME RELAY E IPSEC
NOMBRE:
María Eugenia Serrano (514)
Mario Paguay (658)
SEMESTRE:
Octubre 2016 – Marzo 2017
Ingenieria Electronica, Telecomunicaciones y redes
I N F O R M E D E P R Á C T I C A
TEMA: CONFIGURACIÓN BGP, FRAME RELAY E IPSEC
OBJETIVOS
1.1 GENERAL
 Simular el escenario propuesto y analizar el comportamiento y funcionamiento del

protocolo de enrutamiento de puerta de enlace de borde (BGP), junto con la
configuración de Frame Relay, con el uso de IPsec y GRE.
2.2 ESPECÍFÍCOS
 Crear un proceso de enrutamiento dinámico, con el uso del protocolo IGP, para
generar la convergencia de los sistemas autónomos.
 Configurar rutas de datos permanentes virtuales entre las agencias y la matriz, a
través de implementación de frame relay.
 Brindar seguridad a los datos a transmitir como voz y video a través de tunnelling
IPsec y GRE.
 Establecer procesos de enrutamiento de puerta de enlace de borde (BGP), para
generar la publicación de las rutas y lograr una comunicación entre sistemas
autónomos.
MARCO TEÓRICO
FRAME RELAY
Frame Relay proporciona mayor ancho de banda, fiabilidad y resistencia que las líneas
privadas o arrendadas. El uso de un ejemplo de una red de grandes empresas ayuda a
ilustrar los beneficios del uso de una WAN Frame Relay. En el ejemplo mostrado en la
figura, SPAN Engineering Company tiene cinco campus en Norteamérica. Al igual que la
mayoría de las organizaciones, los requisitos de ancho de banda de SPAN son variados.
[1]
Lo primero a considerar es el requisito de ancho de banda de cada sitio. Trabajando

desde la sede, la conexión entre Chicago y New York requiere una velocidad máxima de
256 kb / s. Otros tres sitios necesitan una velocidad máxima de 48 kb / s conectándose a
la sede, mientras que la conexión entre las sucursales de Nueva York y Dallas requiere sólo
12 kb / s. [1]
1
Encapsulación de Frame Relay
Fig1.- Encapsulación Frame Relay
Frame Relay toma los paquetes de datos de un protocolo de capa de red, como IPv4 o
IPv6, los encapsula como la porción de datos de una trama Frame Relay y luego pasa el
marco a la capa física para su entrega en el cable. Para entender cómo funciona esto,
es útil entender cómo se relaciona con los niveles inferiores del modelo OSI. [1]
Frame Relay encapsula los datos para el transporte y los mueve hacia abajo a la capa
física para la entrega, como se muestra en la Figura.
En primer lugar, Frame Relay acepta un paquete de un protocolo de capa de red, como
IPv4. A continuación, lo envuelve con un campo de dirección que contiene el DLCI y una
suma de comprobación. Los campos de indicador se añaden para indicar el comienzo y
el final del marco. Los campos de indicador marcan el inicio y el final del marco y son
siempre los mismos. Las banderas se representan ya sea como el número hexadecimal 7E
o como el número binario 01111110. Después de que el paquete se encapsula, Frame
Relay pasa el marco a la capa física para el transporte. [1]
El enrutador CPE encapsula cada paquete de Capa 3 dentro de un encabezado y un

remolque de Frame Relay antes de enviarlo a través del VC. El encabezado y el remolque
están definidos por la especificación de los Servicios Portadores de Enlace de Acceso
para Frame Relay (LAPF), ITU Q.922-A, el encabezado Frame Relay (campo de dirección)
contiene específicamente lo siguiente:
DLCI - El DLCI de 10 bits es uno de los campos más importantes en el encabezado Frame
Relay. Este valor representa la conexión virtual entre el dispositivo DTE y el conmutador.
Cada conexión virtual que está multiplexada en el canal físico está representada por un
DLCI único. Los valores DLCI sólo tienen significado local, lo que significa que son únicos
en el canal físico en el que residen. Por lo tanto, los dispositivos en extremos opuestos de
una conexión pueden utilizar diferentes valores DLCI para referirse a la misma conexión
virtual. [1]
2
C / R - El bit que sigue al byte DLCI más significativo en el campo Dirección. El bit C / R no
está definido actualmente.
Dirección extendida (EA) - Si el valor del campo EA es 1, se determina que el byte actual
es el último octeto DLCI. Aunque las implementaciones de Frame Relay actuales utilizan
un DLCI de dos octetos, esta capacidad permite DLCIs más largos en el futuro. El octavo
bit de cada byte del campo Address indica el EA. [1]
Control de congestión - Consiste en tres bits de notificación de congestión de Frame

Relay. Estos tres bits se denominan específicamente Notificación de congestión explícita
hacia delante (FECN), Notificación de congestión explícita hacia atrás (BECN) y Desechar
bits elegibles.
La capa física es típicamente EIA / TIA-232, 449 o 530, V.35 o X.21. La trama Frame Relay
es un subconjunto del tipo de trama HDLC; Por lo tanto, está delimitado con campos de
bandera. El indicador de 1 byte utiliza el patrón de bits 01111110. El FCS determina si se
produjeron errores en el campo de dirección de Capa 2 durante la transmisión. El FCS se
calcula antes de la transmisión por el nodo emisor, y el resultado se inserta en el campo
FCS. En el extremo distante, se calcula un segundo valor FCS y se compara con el FCS en
el cuadro. Si los resultados son los mismos, se procesa la trama. Si hay una diferencia, el
marco se descarta. Frame Relay no notifica a la fuente cuando un marco se descarta. El
control de errores se deja a las capas superiores del modelo OSI. [1]
IPSEC
IPsec (abreviatura de Internet Protocol security) es un conjunto de protocolos cuya

función es asegurar las comunicaciones sobre el Protocolo de Internet (IP) autenticando
y/o cifrando cada paquete IP en un flujo de datos. IPsec también incluye protocolos para
el establecimiento de claves de cifrado. [2]
Los protocolos de IPsec actúan en la capa de red, la capa 3 del modelo OSI.Otros
protocolos de seguridad para Internet de uso extendido, como SSL, TLS y SSH operan de la
capa de transporte (capas OSI 4 a 7) hacia arriba. Esto hace que IPsec sea más flexible,
ya que puede ser utilizado para proteger protocolos de la capa 4, incluyendo TCP y UDP,
los protocolos de capa de transporte más usados. IPsec tiene una ventaja sobre SSL y
otros métodos que operan en capas superiores. Para que una aplicación pueda usar
IPsec no hay que hacer ningún cambio, mientras que para usar SSL y otros protocolos de
niveles superiores, las aplicaciones tienen que modificar su código. [2]
IPsec está implementado por un conjunto de protocolos criptográficos para asegurar el

flujo de paquetes, garantizar la autenticación mutua y establecer parámetros
criptográficos. [2]
La arquitectura de seguridad IP utiliza el concepto de asociación de seguridad (SA)

como base para construir funciones de seguridad en IP. Una asociación de seguridad es
simplemente el paquete de algoritmos y parámetros (tales como las claves) que se está
usando para cifrar y autenticar un flujo particular en una dirección. Por lo tanto, en el
tráfico normal bidireccional, los flujos son asegurados por un par de asociaciones de
3
seguridad. La decisión final de los algoritmos de cifrado y autenticación (de una lista
definida) le corresponde al administrador de IPsec. [2]
Para decidir qué protección se va a proporcionar a un paquete saliente, IPsec utiliza el

índice de parámetro de seguridad (SPI), un índice a la base de datos de asociaciones de
seguridad (SADB), junto con la dirección de destino de la cabecera del paquete, que
juntos identifican de forma única una asociación de seguridad para dicho paquete. Para
un paquete entrante se realiza un procedimiento similar; en este caso IPsec coge las
claves de verificación y descifrado de la base de datos de asociaciones de seguridad. [2]
En el caso de multicast, se proporciona una asociación de seguridad al grupo, y se

duplica para todos los receptores autorizados del grupo. Puede haber más de una
asociación de seguridad para un grupo, utilizando diferentes SPIs, y por ello permitiendo
múltiples niveles y conjuntos de seguridad dentro de un grupo. De hecho, cada remitente
puede tener múltiples asociaciones de seguridad, permitiendo autenticación, ya que un
receptor sólo puede saber que alguien que conoce las claves ha enviado los datos. Hay
que observar que el estándar pertinente no describe cómo se elige y duplica la
asociación a través del grupo; se asume que un interesado responsable habrá hecho la
elección. [2]
Modos de funcionamiento
Modo transporte
En modo transporte, sólo la carga útil (los datos que se transfieren) del paquete IP es
cifrada y/o autenticada. El enrutamiento permanece intacto, ya que no se modifica ni se
cifra la cabecera IP; sin embargo, cuando se utiliza la cabecera de autenticación (AH),
las direcciones IP no pueden ser traducidas, ya que eso invalidaría el hash. Las capas de
transporte y aplicación están siempre aseguradas por un hash, de forma que no pueden
ser modificadas de ninguna manera (por ejemplo traduciendo los números de puerto TCP
y UDP). El modo transporte se utiliza para comunicaciones ordenador a ordenador. [2]
Una forma de encapsular mensajes IPsec para atravesar NAT ha sido definida por RFCs
que describen el mecanismo de NAT-T
El propósito de este modo es establecer una comunicación segura punto a punto, entre
dos hosts y sobre un canal inseguro.
Modo tunel
En el modo túnel, todo el paquete IP (datos más cabeceras del mensaje) es cifrado y/o
autenticado. Debe ser entonces encapsulado en un nuevo paquete IP para que
funcione el enrutamiento. El modo túnel se utiliza para comunicaciones red a red (túneles
seguros entre routers, p.e. para VPNs) o comunicaciones ordenador a red u ordenador a
ordenador sobre Internet. El propósito de este modo es establecer una comunicación
segura entre dos redes remotas sobre un canal inseguro. [2]
4
Cabecera IPsec AH (authentication only)
AH está dirigido a garantizar integridad sin conexión y autenticación de los datos de

origen de los datagramas IP. Para ello, calcula un Hash Message Authentication Code
(HMAC) a través de algún algoritmo hash operando sobre una clave secreta, el
contenido del paquete IP y las partes inmutables del datagrama. Este proceso restringe la
posibilidad de emplear NAT, que puede ser implementada con NAT transversal. Por otro
lado, AH puede proteger opcionalmente contra ataques de repetición utilizando la
técnica de ventana deslizante y descartando paquetes viejos. AH protege la carga útil IP
y todos los campos de la cabecera de un datagrama IP excepto los campos mutantes,
es decir, aquellos que pueden ser alterados en el tránsito. En IPv4, los campos de la
cabecera IP mutantes (y por lo tanto no autenticados) incluyen TOS, Flags, Offset de
fragmentos, TTL y suma de verificación de la cabecera. AH opera directamente por
encima de IP, utilizando el protocolo IP número 51. Un cabecera AH mide 32 bits, he aquí
un diagrama de cómo se organizan:
* next hdr Identifica cuál es el siguiente protocolo, es decir, cual es el protocolo que
será autentificado, cuál es el payload.
 AH len El tamaño del paquete AH.
 RESERVED Reservado para futuras aplicaciones. Debe estar a 0
 Security parameters index (SPI) Indica los parametros de seguridad, que en

combinación con los parámetros IP, identifican la asociación de seguridad del
paquete
 Sequence Number Es un número creciente usado para prevenir ataques por

repetición. El número está incluido en los datos encriptados, así que cualquier
alteración será detectada
 Authentication Data Contiene el valor de identificación de integridad. Puede

contener relleno.Se calcula sobre el paquete entero, incluidas la mayoría de las
cabeceras. El que recibe calcula otra vez el hash, y si este no coincide, el
paquete se tira. [2]
AH en Modo Transporte
La manera más fácil de entender el modo transporte es que protege el intercambio

de información entre dos usuarios finales. La protección puede ser autentificación o
encriptación (o las dos), pero no se hace usando un tunel (para eso está el modo túnel).
No es una vpn, es una simple conexión segura entre dos usuarios finales. [2]
En AH en Modo Transporte, el paquete IP es modificado ligeramente para incluir una

nueva cabecera AH entre la cabecera IP y la información transmitida (TCP, UDP, etc) y
después se requiere un proceso “de arrastre” que interconecta las distintas cabeceras
entre ellas. [2]
5
Este proceso “de arrastre” se necesita para que el paquete original IP sea reconstituido
cuando llegue a su destino; cuando las cabeceras IPsec han sido validadas en el
receptor, se despojan las cabeceras IPsec y la carga a transmitir (TCP, UDP, etc) es
guardada nuevamente en la cabecera IP.
Cuando el paquete llega a su siguiente destino y pasa el test de autenticidad, la

cabecera AH es quitada y el campo proto=AH es reemplazado con el siguiente protocolo
de la carga transmitida (TCP, UDP, etc). Esto pone al datagrama es su estado original, y
puede ser enviado al proceso original. [2]
GRE
El GRE (Generic Routing Encapsulation) es un protocolo para el establecimiento de

túneles a través de Internet. Está definido en la RFC 1701 y en la RFC 1702, pudiendo
transportar hasta 20 protocolos del nivel de red (nivel 3 del modelo OSI) distintos. [3]
Características
 Permite emplear protocolos de encaminamiento especializados que obtengan el

camino óptimo entre los extremos de la comunicación.
 Soporta la secuencialidad de paquetes y la creación de túneles sobre redes de
alta velocidad.
 Permite establecer políticas de encaminamiento y seguridad.
Aunque IPsec proporciona un método seguro para el túnel de datos a través de una red
IP, tiene limitaciones. IPsec no admite la difusión IP o la multidifusión IP, lo que impide el
uso de protocolos que dependen de estas características, como los protocolos de
enrutamiento. IPsec también no admite el uso de tráfico multiprotocolo.
Generic Route Encapsulation (GRE) es un protocolo que puede utilizarse para "transportar"
otros protocolos de pasajeros, como la difusión IP o la multidifusión IP, así como los
protocolos no IP.
Figura 1.1 GRE como protocolo de IP de la empresa de transporte
El uso de túneles GRE junto con IPsec proporciona la capacidad de ejecutar un

protocolo de enrutamiento, multidifusión IP (IPmc) o tráfico multiprotocolo a través de la
red entre las cabeceras y sucursales.
GRE también permite el direccionamiento privado. Sin un protocolo de túnel en

ejecución, todas las estaciones finales deben estar dirigidas con direcciones IP
6
registradas. Al encapsular el paquete IP en un protocolo de tuneling, se puede utilizar el

espacio de direcciones privadas.
Con la solución p2p GRE over IPsec, todo el tráfico entre sitios se encapsula en un
paquete p2p GRE antes del proceso de encriptación, simplificando la lista de control de
acceso utilizada en las sentencias de mapas criptográficos. Los enunciados de mapa
criptográfico sólo necesitan una línea que permita GRE (Protocolo IP 47).
PLANTEAMIENTO DEL PROBLEMA

Simular la topología que se muestra en la Figura 1 en GNS3
Elementos:
- Router Cisco c7200
Figura 2: Topología propuesta
En la infraestructura de comunicaciones de la empresa XYZ, LACNIC les ha asignado ASNs

a cada una de las redes corporativas de la Matriz, Agencia 1 y Agencia 2, como se
muestra en la figura 1.
La interconexión de las redes se lo hace a través de un proveedor de servicios que
dispone de una red Frame Relay como se indica en la figura, la topología utilizada para
esta conexión es HUB&SPOKE Full Mesh punto a punto, para lo cual el proveedor le asigna
a la empresa la dirección IP 150.10.10.0/28.
En cada Sistema Autónomo está indicado el IGP a configurar y el esquema de
direccionamiento IPv4 a utilizar.
Para garantizar seguridad en el establecimiento de las sesiones eBGP y en la transferencia
de las actualizaciones BGP se propone utilizar un esquema de Redes Privadas Virtuales
que deberán ser implementadas sobre la conexión Frame Relay.
La tecnología de VPN a implementar es IPSEC & GRE.
DESARROLLO
1. Implementamos la topología en GNS3 utilizando los elementos necesarios y

asignamos las direcciones a todos los enrutadores tal como se muestra en la Figura 2
de manera que se utilicen las direcciones .1 y .2 en cada enlace.
7
Figura 3: Topología implementada
2. Aplicamos OSPF como protocolo de enrutamiento con número de proceso 10, con
número de área 0 para el AS 1500.
Figura 4: Visualización de configuración de OSPF en R2
3. Aplicamos EIGRP como protocolo de enrutamiento para el AS 2500.
Figura 5: Visualización de configuración de EIGRP en R10
8
4. Aplicamos IS-IS como protocolo de enrutamiento para el AS 5000.
Figura 6: Visualización de configuración de IS-IS en R10
5. Configuramos las DLCI en la nube Frame Relay de manera que cada una sea
diferente tanto en origen como destino.
Figura 7: Configuración de DLCIs en la nube Frame Relay
9
6. Configuramos las interfaces conectadas a la nube Frame Relay añadiendo la

encapsulación frame relay respectiva y después creando las sub interfaces tal como
se especifica en la topología con su dirección IP y su DLCI respectiva
Figura 8: Configuración interfaces frame relay en R4
7. Configuramos BGP en todo el AS 1500 pero no se declara en R4 los vecinos ni las

redes que corresponden a la nube frame relay.
Figura 11: Configuración de BGP en R4
10


10. Establecemos la VPN en R4 con su seguridad respectiva, primero mediante IPSEC.

Para esto como primer paso se establece una sesión de ISAKMP la misma con la
encriptación 3des, el algoritmo MD5 y la publicación de la autenticación mediante
autentication pre-share. Toda esta configuración deberá ser la misma en los peers
adyacentes.
Figura 14: Configuración de ISAKMP Policy
11. Determinamos la clave de autenticación que en este caso es “cisco” y hacia el peer
al cual va dirigido, en este caso será la dirección 150.10.10.2 hacia R5 y 150.10.10.10
hacia R9 perteneciente a la sub interfaz de frame relay dirigida a R5, además se
configuramos lo que será la transformación de encriptaciones mediante crypto ipsec
transform-set <nombre> esp-3des esp-md5-hmac, con esto logramos que tenga
compatibilidad con otros métodos de encriptación.
11
Figura 15: Configuración de clave y transformación
12. Creamos una interfaz Tunnel que será útil para la implementación de GRE. Asignamos
una dirección diferente a la de la interfaz física, en este caso será 10.10.12.1 y será
dirigida hacia la dirección 150.10.10.2 perteneciente a R5. A si mismo se crea otra
interfaz Tunnel3 la cual será 10.10.13.1 y será dirigida hacia la dirección 150.10.10.10
perteneciente a R9
Figura 16: Creación de la interfaz Tunnel2
Figura 17: Creación de la interfaz Tunnel3
13. Configuramos access-lists para determinar que tráfico de GRE pasara encriptado por
la interfaz Tunnel2 y la interfaz Tunnel3 que son las direcciones del AS 1500 hacia las
del AS 2500 en un caso y el AS 3000 en el otro.
Figura 18: Creación de access-lists
14. Creamos el crypto map que se trata de especificar tanto el par al que está
conectado, la transformación y las redes de ambas access-lists. Un crypto map
servirá para el AS 2500 y el otro al AS 3000 con ID diferentes.
Figura 19: Configuración crypto map 20 en R4
12
Figura 20: Configuración crypto map 30 en R4
15. Aplicamos el crypto map a las interfaces tanto físicas y las interfaces tunnel, la de ID
20 en este caso se aplicará en la interfaz s1/0.2 y la interfaz Tunnel2, mientras que la
de ID 30 se aplicará en la interfaz s1/0.3 y la interfaz Tunnel3.
Figura 21: Aplicación de crypto map 20 en las interfaces de R4
Figura 22: Aplicación de crypto map 30 en las interfaces de R4
16. Realizamos las configuraciones desde el paso 10 al 16 tanto en R5 y en R9 tomando

en cuenta los aspectos ya descritos con anterioridad.
13
Figura 23: Configuración de IPSEC and GRE de R5 hacia R4
14
17. Verificamos conectividad entre los túneles respectivos.
Figura 27: Verificación de conectividad de las interfaces Tunnel de R4 y R5
15
18. Establecemos las vecindades EBGP y redes conectadas a la nube frame relay para
que pueda existir conectividad a través de toda la topología, pero las que se
definirán serán las vecindades y redes que se asignaron a las interfaces Tunnel de
cada uno de los enrutadores.
Figura 30: Establecimiento de EBGP en redes externas en R4
19. Verificamos que se hayan aprehendido todas las rutas de BGP externas en los
diferentes AS.
16
Figura 33: Verificación de Rutas aprendidas por R1
Como se puede observar en las figuras 26, R1 perteneciente al AS 1500 ha aprendido

todas las rutas de 192.168.X.X del AS 2500 y las rutas 172.16.X.X del AS 3000
comprobando así que conoce a todos los enrutadores de la topología.
Como se puede observar en las figuras 27, R7 perteneciente al AS 2500 ha aprendido

todas las rutas de 200.10.X.X del AS 1500 y las rutas 172.16.X.X del AS 3000
Como se puede observar en las figuras 28, R12 perteneciente al AS 3000 ha

aprendido todas las rutas de 200.10.X.X del AS 1500 y las rutas 192.168.X.X del AS 2500
20. Verificamos que se esté ejecutando el proceso de ISAKMP perteneciente a IPSEC

mediante el comando show crypto isakmp peers en los enrutadores R4, R5 y R9
17
Figura 36: Verificación del proceso ISAKMP en R4
Como se puede observar en las figuras 29, 30 y 31, cada enrutador ha establecido un
proceso de ISAKMP identificando a sus peers respectivos de interface físicas, los
cuales a su vez fueron encapsulados en GRE con interfaces Tunnel respectivamente
por lo que el establecimiento de VPN a través de una Nube Frame Relay con IPSEC
and GRE se ha realizado satisfactoriamente
CONCLUSIONES
 Frame Relay nos permite realizar conexión punto a punto, a pesar de tener menos
interfaces físicas, todo esto gracias a la creación de diferentes interfaces virtuales
encapsuladas en una interfaz real.
 Mediante el uso de IPSEC, podemos establecer rutas y transmitir información de
manera segura ya que requiere autenticación de extremo a extremo con una
clave determinada por diseñador de red y que va encriptado por diferentes
algoritmos según se desee
 GRE se plantea como una solución a la hora de implementar IPSEC y cuando sea
necesaria la utilización de algoritmos de enrutamiento, en este ejercicio GRE
permitió que se puedan comunicar los diferentes sistemas autónomos mediante
BGP.
RECOMENDACIONES
 Se recomienda establecer solamente IBGPs antes de configurar IPSEC y GRE, pues
es primordial primero establecer las seguridades respectivas de la VPN y
posteriormente que sean publicadas las vecindades EBGP.
 Es importante definir todas las operaciones de ISAKMP tales como claves,
encriptaciones y transformaciones para después aplicarlas en un mapa de
encriptación necesario para su aplicación en las respectivas interfaces.
 Es necesario comprobar que los túneles funciones correctamente antes de aplicar
las seguridades de IPSEC sobre la interfaz ya que puede presentarse confusión al
determinar errores en caso de existirlos.
18
BIBLIOGRAFIA
[1] Black, U. D. (1998). TCP/IP and Related Protocols: IPv4, Frame Relay, and ATM.
McGraw-Hill School Education Group.
[2] Doraswamy, N., & Harkins, D. (2003). IPSec: the new security standard for the
Internet, intranets, and virtual private networks. Prentice Hall Professional.
[3] Worster, T., Rekhter, Y., & Rosen, E. (2005). Encapsulating MPLS in IP or Generic
Routing Encapsulation (GRE) (No. RFC 4023).
19

Informe VPN FrameRelay IPSEC GRE 514 658

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Informe VPN FrameRelay IPSEC GRE 514 658

Cargado por

Copyright:

Formatos disponibles

ESCUELA SUPERIOR POLITÉCNICA DE

FACULTAD DE INFORMATICA Y ELECTRONICA

ESCUELA DE INGENIERIA ELECTRONICA

TEMA: CONFIGURACIÓN BGP, FRAME RELAY E IPSEC

 Simular el escenario propuesto y analizar el comportamiento y funcionamiento del

Lo primero a considerar es el requisito de ancho de banda de cada sitio. Trabajando

Encapsulación de Frame Relay

Fig1.- Encapsulación Frame Relay

El enrutador CPE encapsula cada paquete de Capa 3 dentro de un encabezado y un

Control de congestión - Consiste en tres bits de notificación de congestión de Frame

IPsec (abreviatura de Internet Protocol security) es un conjunto de protocolos cuya

IPsec está implementado por un conjunto de protocolos criptográficos para asegurar el

La arquitectura de seguridad IP utiliza el concepto de asociación de seguridad (SA)

Para decidir qué protección se va a proporcionar a un paquete saliente, IPsec utiliza el

En el caso de multicast, se proporciona una asociación de seguridad al grupo, y se

Cabecera IPsec AH (authentication only)

AH está dirigido a garantizar integridad sin conexión y autenticación de los datos de

 AH len El tamaño del paquete AH.

 RESERVED Reservado para futuras aplicaciones. Debe estar a 0

 Security parameters index (SPI) Indica los parametros de seguridad, que en

 Sequence Number Es un número creciente usado para prevenir ataques por

 Authentication Data Contiene el valor de identificación de integridad. Puede

La manera más fácil de entender el modo transporte es que protege el intercambio

En AH en Modo Transporte, el paquete IP es modificado ligeramente para incluir una

Cuando el paquete llega a su siguiente destino y pasa el test de autenticidad, la

El GRE (Generic Routing Encapsulation) es un protocolo para el establecimiento de

 Permite emplear protocolos de encaminamiento especializados que obtengan el

Figura 1.1 GRE como protocolo de IP de la empresa de transporte

El uso de túneles GRE junto con IPsec proporciona la capacidad de ejecutar un

GRE también permite el direccionamiento privado. Sin un protocolo de túnel en

registradas. Al encapsular el paquete IP en un protocolo de tuneling, se puede utilizar el

PLANTEAMIENTO DEL PROBLEMA

Figura 2: Topología propuesta

En la infraestructura de comunicaciones de la empresa XYZ, LACNIC les ha asignado ASNs

1. Implementamos la topología en GNS3 utilizando los elementos necesarios y

Figura 3: Topología implementada

Figura 4: Visualización de configuración de OSPF en R2

3. Aplicamos EIGRP como protocolo de enrutamiento para el AS 2500.

Figura 5: Visualización de configuración de EIGRP en R10

4. Aplicamos IS-IS como protocolo de enrutamiento para el AS 5000.

Figura 6: Visualización de configuración de IS-IS en R10

Figura 7: Configuración de DLCIs en la nube Frame Relay

6. Configuramos las interfaces conectadas a la nube Frame Relay añadiendo la

Figura 8: Configuración interfaces frame relay en R4

Figura 9: Configuración interfaces frame relay en R5

Figura 10: Configuración interfaces frame relay en R9

7. Configuramos BGP en todo el AS 1500 pero no se declara en R4 los vecinos ni las

Figura 11: Configuración de BGP en R4

8. Configuramos BGP en todo el AS 2500 pero no se declara en R5 los vecinos ni las

Figura 12: Configuración de BGP en R5

9. Configuramos BGP en todo el AS 3000 pero no se declara en R9 los vecinos ni las

Figura 13: Configuración de BGP en R9

10. Establecemos la VPN en R4 con su seguridad respectiva, primero mediante IPSEC.

Figura 14: Configuración de ISAKMP Policy

Figura 15: Configuración de clave y transformación

Figura 16: Creación de la interfaz Tunnel2

Figura 17: Creación de la interfaz Tunnel3

Figura 18: Creación de access-lists

Figura 19: Configuración crypto map 20 en R4

Figura 20: Configuración crypto map 30 en R4

Figura 21: Aplicación de crypto map 20 en las interfaces de R4

Figura 22: Aplicación de crypto map 30 en las interfaces de R4

16. Realizamos las configuraciones desde el paso 10 al 16 tanto en R5 y en R9 tomando