Tuneles GRE

Este artículo forma parte de una serie de varios artículos que tratan los distintos tipos de routing en IPV4 e IPV6 para CCNA R&S, para ir al índice del curso tienes este link:

http://networkkings-es.blogspot.com.es/2013/07/curso-gratuito-ccna-200-120.html

Tuneles GRE:

Hace ya mas de un año que puliqué varios artículos sobre tuneles GRE, pero en estaocasión voy a tomar como base mi primer artículo sobre tuneles GRE, y adaptarlo un poco.

Tuneles GRE BASICO
Tuneles GRE multipunto (AVANZADO)
Tuneles GRE multipunto ejemplo(AVANZADO)
Recursividad en tuneles GRE


Los túneles GRE son una herramienta todoterreno que te puede echar una mano para prácticamente todo, permitiendote saltarte limitaciones de protocolos y tecnologías múltiples y diversas.

El hecho de ser una herramienta tan flexible, que te saca de tantos apuros, hace que el 95% de las veces se hagan "chapuzas" con ellos. Antes de explicar un poco los túneles GRE mi recomendación es, que salvo para circunstancias muy excepcionales intentes evitar los túneles GRE ya que prácticamente siempre va a haber una alternativa mejor diseñada, mas limpia, mejor optimizada, y con un troubleshooting mas sencillo.

¿Que es un tunel GRE?

GRE significa Generic Routing Encapsulation, es una encapsulación para tuneles, por defecto no lleva encriptación, es facil de implementar, funciona bajo IPV4 pero se puede usar direccionamiento de IPV4 e IPV6, y lo mas importante que permite establecer routing dinámico a traves del tunel.

En el fondo resumiendo un poco, lo que hace un tunel GRE es simplemente crear una interfaz virtual entre los dos extremos del tunel, cuando se envían paquetes hacia el otro lado del tunel estos paquetes dentro del tunel tendrán como destino la dirección ip que corresponda, pero para llegar al otro extremo se tendrán que enviar paquetes con destino el otro extremo del tunel. Esto en realidad es tunelizar el tráfico ya que da cara a la red es algo transparente.

¿Como se configura?

router(config)#interface tunnel X
router(config-if)# tunnel source ( ip | interface )
router(config-if)# tunnel destination ( destination_ip )
router(config-if)#ip address x.x.x.x y.y.y.y
router(config-if)# ipv6 address ( ipv6_address ) ( ipv6_mask )

¿ Como funcionan ?

Es un protocolo que funciona a nivel 4 y admite una MTU máxima de 1475 bytes, por tanto si prevees que sobre el tunel tiene que fluir tráfico que no admita fragmentación, y que tenga mas de 1475 bytes lo mejor es ir olvidandose. El que avisa no es traidor.

Ejemplo con routing dinámico:

R4:

interface Loopback1
ip address 4.4.4.4 255.255.255.255
!
interface Loopback2
ip address 1.2.3.4 255.255.255.255
!
interface Tunnel1
ip address 10.0.0.1 255.255.255.252
tunnel source Loopback1
tunnel destination 6.6.6.6
!
interface Ethernet0/0
ip address 192.168.1.1 255.255.255.0
half-duplex
!
router eigrp 100
network 1.2.3.4 0.0.0.0
network 10.0.0.1 0.0.0.0
auto-summary
!
router rip
version 2
network 4.0.0.0
network 192.168.1.0!

R5:

interface Ethernet0/0
ip address 192.168.1.2 255.255.255.0
half-duplex
!
interface Ethernet0/1
ip address 192.168.2.1 255.255.255.0
half-duplex
router rip
version 2
network 192.168.1.0
network 192.168.2.0

R6:

interface Ethernet0/1
ip address 192.168.2.2 255.255.255.0
half-duplex
interface Loopback1
ip address 6.6.6.6 255.255.255.255
!
interface Loopback2
ip address 4.3.2.1 255.255.255.255
!
interface Tunnel1
ip address 10.0.0.2 255.255.255.252
tunnel source Loopback1
tunnel destination 4.4.4.4

router eigrp 100
network 4.3.2.1 0.0.0.0
network 10.0.0.2 0.0.0.0
no auto-summary
!
router rip
version 2
network 6.0.0.0
network 192.168.2.0

En este mismo ejemplo si se enviase un tracert desde la loopback 1 a la loopback 1 del otro extremo veríamos que hay un solo salto, ya que el router intermedio no está viendo pasar el tráfico de loopback a loopbak, el router intermedio solo ve pasar tráfico perteneciente a un tunel, y lo que haya dentro del tunel no le interesa.