Generic Routing Encapsulation (GRE) es un protocolo de túnel desarrollado por Cisco Systems que fue originalmente desarrolado para encapsular y transportar una gran variedad de protocolos de red antiguos como Internetwork Packet Exchange (IPX), Appletalk o NetBIOS sobre una red IP. Fue descrito por primera en 1994 en los RFC1701 y RFC1702 y actualizado en el RFC2784.
¿Qué es un túnel? Es simplemente colocar un paquete dentro de otro paquete para que pueda ser transportado. Esto es lo que se llama encapsulamiento. ¿Cómo se logra ésto? GRE agrega un nueva cabecera o header al paquete original para su transporte y es retirada al llegar a su destino (desencapsulamiento).
- El protocolo pasajero son todos aquellos datos en su paquete original que tienen que ser encapsulados y transportados.
- El protocolo portador es el que encapsula al protocolo pasajero. En este caso específico es GRE.
- El protocolo de transporte es el que verdaderamente se usa para transportar los paquetes - IPv4 ó IPv6.
Esto tiene un costo en cuanto a la cantidad de data que se puede enviar por paquete dado que GRE agrega por lo mínimo 24 bytes al paquete nuevo: 20 son de la nueva cabecera de IP y los 4 restantes de la cabecera de GRE. Ésta puede ser hasta 12 bytes más grande si se utilizan las opciones que están presentes dentro de la cabecera de GRE: Checksum, Key y Sequence Number agregan 4 bytes cada uno si se están utilizando.
Si sabemos que el MTU de Ethernet es 1500 bytes y GRE añade 24 bytes al paquete, entonces la cantidad de data del paquete original que puede ser encapsulada no puede llegar a los 1500 bytes, sino hay que restarle por lo mínimo los 24 bytes utilizados por GRE, con lo que llegamos a un número de 1476 bytes como MTU del protocolo pasajero.
Otras de las características fundamentales de GRE son:
- Soporte para tráfico multicast.
- Soporte para tráfico broadcast.
- Es un protocolo no seguro: no ofrece encriptación, lo que significa que cualquier paquete que sea capturado, puede ser leído.
- Es un protocolo sin estado y no contiene ningún protocolo de control de flujo.
- Protocolo número 47.
Teniendo en cuenta la importancia de la seguridad de la información, es lógico preguntarse por qué un protocolo tan inseguro puede mantenerse aún con vida y ser utilizado en estos días. La respuesta está en sus primeras dos características que son aprovechadas para trabajar con:
- IPsec solo tiene soporte unicast, por lo que sólo funciona de punto a punto. Al combinar GRE + IPsec se pueden tener túneles completamente encriptados punto multipunto tipo hub and spoke o DMVPN.
- Los protocolos de enrutamiento dinámico como los son EIGRP, OSPF y RIP utilizan tráfico broadcast para establecer sus adjecencias, por lo que son perfectamente compatibles con GRE.
Después de haber establecido todos los puntos anteriores, se puede concluir que GRE funciona junto con un protocolo de transporte (IPv4 ó IPv6) para crear túneles punto a punto o punto multipunto. Si analizamos más esta estructura nos damos cuenta de que un túnel GRE se construye sobre IP, con lo que llegamos a los conceptos de una red inferior (underlay network) y una red superior (overlay network). La red inferior es la red física y la superior es una red virtual.
Configuración:
Pasos:
- Crear la interfaz con el comando interface tunnel x (x es us número). Esto crea la interfaz que es una interfaz virtual.
- Asignarle una dirección IP.
- Definir el origen (puede ser una interfaz física o una loopback - recordar que si es una loopback tiene que podérsele llegar).
- Definir el destino.
- Asignar el MTU.
- Definir el tipo de túnel (este paso es opcional porque por defecto es gre ip).
En la captura anterior se puede observar que el destino de la interfaz tunnel0 de R1 es el origen de la interfaz tunnel0 de R2 y viceversa.
Una vez con el túnel funcionando, podemos configurar el tráfico que va a utilizar esta VPN. Esto se puede hacer con enrutamiento estático o con un protocolo de enrutamiento dinámico.
Como se puede observar sólo la red superior fue declarada dentro de OSPF. Hay que tener muchísimo cuidado de mantener tanto la red superior como la subyacente en protocolos diferentes y que no se vean entre ellas, de lo contrario se crea un error de enrutamiento recursivo llevando a la interfaz del túnel entre en loop de levante y caída (flapping) hasta que se separen las redes. La clave está en la salida que describe Midchain parent maintenance ... Como se puede ver en la siguiente captura:
Para revisar si el tráfico está pasando por el túnel, un traceroute nos sirve:
Como se evidencia en las capturas, en el traceroute de la izquierda el tráfico no pasaba por la VPN, es decir, no estaba siendo encapsulado por GRE, mientras que en de la derecha el tráfico sí estaba viajando por la VPN.
Para revisar el estado de la interfaz del túnel podemos ver la salida de show ip interface brief. Ahí podemos ver la dirección ip de todas las interfaces configuradas al igual que su estdo. Sin embargo, con la salida del comado show ip interface tunnel x (x es el número de la interfaz), obtenemos muchísima más información como se ve en el siguiente extracto.
Este trabajo está demostrado en un video de un laboratorio en GNS3 con la siguiente topología..
Como se puede ver, el direcionamiento es el mismo utilizado en todas las capturas anterioeres. Lo único que ha cambiado es el desarrollo de las LANs de R1 y R5 y la red del ISP.
Tanto este documento como el video lo pueden encontrar en mi blog
