el 02-07-2021 07:35 PM
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).
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:
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:
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:
Para que la configuración del túnel funcione correctamente y haya tráfico encapsulado, es necesario que haya comunicación entre las interfaces de R1 y la de R2 que sirven como origen y destino del túnel GRE (red subjayente y su dependencia). De lo contrario, el túnel no se formará.
Pasos:
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 for IP midchain out of Tunnel0... 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
Gracias por compartir el contenido @juantovarm
Se agradece la informacion, super claro.
Muchas gracias por esa información.
Muy buena informacion, Gracias!!
Excelente información. Sumamente especifica y fácil de comprender. Muy útil para ponerlo en práctica.
Muchisimas gracias @juantovarm me ha servido de mucho.
excelente aporte
¡Conecte con otros expertos de Cisco y del mundo! Encuentre soluciones a sus problemas técnicos o comerciales, y aprenda compartiendo experiencias.
Queremos que su experiencia sea grata, le compartimos algunos links que le ayudarán a familiarizarse con la Comunidad de Cisco:
Navegue y encuentre contenido personalizado de la comunidad