Cómo funcionan las señales de mantenimiento GRE
Contenido
Introducción
Este documento proporciona una descripción general de cómo funcionan los keepalives GRE (Generic Routing Encapsulation).
Prerequisites
Requirements
Quienes lean este documento deben tener conocimiento de los siguientes temas:
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
-
Cisco 7505 Router
-
Software Cisco IOS® que admite GRE sobre IPSec
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Convenciones
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Antecedentes
La función de señal de mantenimiento GRE habilita el comando de interfaz keepalive para los túneles y le permite configurar señales de mantenimiento para los túneles GRE punto a punto. Puede configurar keepalive con el comando keepalive y opcionalmente con su nueva extensión.
Los túneles GRE proporcionan un método para encapsular paquetes arbitrarios dentro de un protocolo de transporte. También ofrecen una arquitectura diseñada para proporcionar los servicios necesarios para implementar cualquier esquema de encapsulación punto a punto estándar. Estas son algunas de las ventajas de los túneles GRE:
-
Los túneles GRE proporcionan redes locales multiprotocolo a través de una estructura básica de protocolo único.
-
Los túneles GRE proporcionan soluciones temporales para las redes que contienen protocolos con recuentos de saltos limitados.
-
Los túneles GRE conectan subredes discontinuas.
-
Los túneles GRE permiten VPN en las WAN.
Sin embargo, en la implementación actual de túneles GRE, un túnel configurado no tiene la capacidad de desactivar el protocolo de línea de ninguno de los extremos de túnel, si el extremo lejano es inalcanzable. Por lo tanto, el tráfico enviado desde el túnel está en espera negra y no puede seguir trayectos alternativos porque el túnel siempre permanece activo.
Esta situación se aplica a los túneles que dependen de rutas estáticas o de protocolos de ruteo que agregan rutas para encontrar una ruta al destino del túnel. También es cierto en situaciones en las que los datos del plano de control siguen una ruta diferente a la del plano de datos.
El Mecanismo Keepalive del Túnel
Esta sección proporciona una descripción funcional del mecanismo de keepalive del túnel con la ayuda de un ejemplo. Esta sección también enumera los elementos de software que esta función modifica y analiza el impacto en la memoria y el rendimiento.
Descripción funcional
El mecanismo de señal de mantenimiento del túnel habilita, extiende e implementa un comando específico de la interfaz para las interfaces de túnel y ofrece la capacidad de desactivar el protocolo de línea de un túnel. Para obtener más información, vea la sección Comandos y configuración.
El mecanismo de señal de mantenimiento del túnel también aborda estos requisitos adicionales:
-
El mecanismo de señal de mantenimiento del túnel funciona incluso si el extremo del túnel lejano no admite señales de mantenimiento.
-
El mecanismo de señal de mantenimiento del túnel origina señales de mantenimiento.
-
El mecanismo de señal de mantenimiento del túnel procesa señales de mantenimiento.
-
El mecanismo de señal de mantenimiento del túnel responde a los paquetes keepalive del extremo lejano, incluso cuando el protocolo de línea del túnel está inactivo.
Este es un ejemplo de cómo funciona el mecanismo keepalive del túnel (consulte la Figura 1):
Figura 1: Ejemplo del Mecanismo de señal de mantenimiento del túnel 
Resultado
interface tunnel 0 interface tunnel 0 ip address 1.1.1.1 255.255.255.240 ip address 1.1.1.2 255.255.255.240 tunnel source 128.8.8.8 tunnel source 129.9.9.9 tunnel destination 129.9.9.9 tunnel destination 128.8.8.8 keepalive 5 4 keepalive 5 4 interface loopback 0 interface loopback 0 ip address 128.8.8.8 255.255.255.255 ip address 129.9.9.9 255.255.255.255
Un paquete keepalive que se origina de A a B
---outer IP header---' ---inner IP header---'
=============================================================
|IP | IP src | IP dst | GRE | IP | IP src | IP dst | GRE |
| |128.8.8.8|129.9.9.9|PT=IP| |129.9.9.9|128.8.8.8| PT=0|
=============================================================
----' ---'
GRE header GRE header
Cuando habilita keepalives en el extremo de túnel del Router A, el router en cada intervalo construye el encabezado IP interno. Al final del encabezado, el router también agrega un encabezado GRE con un tipo de protocolo (PT) de 0 y ninguna otra carga útil. Luego, el router envía ese paquete a través del túnel, lo que da como resultado su encapsulación con el encabezado IP externo, y un encabezado GRE con el PT de IP. El contador de señal de mantenimiento del túnel aumenta en uno. Si hay una manera de alcanzar el extremo lejano del túnel y el protocolo de línea del túnel no está inactivo debido a otras razones, el paquete llega al router B. Luego se compara con el túnel 0, se desencapsula y se reenvía a la IP de destino, que es el origen del túnel, el router A. Al llegar al router A, el paquete se desencapsula nuevamente y se verifica el PT. Si el resultado de la verificación PT es 0, significa que éste es un paquete keepalive. En tal caso, el contador de señal de mantenimiento del túnel se restablece en 0 y el paquete se descarta.
En caso de que el Router B no sea accesible, el Router A continúa construyendo y enviando los paquetes keepalive junto con el tráfico normal. Si el protocolo de línea está inactivo, las señales de mantenimiento no vuelven al Router A. Por lo tanto, el contador de señal de mantenimiento sigue aumentando. El protocolo de línea de túnel permanece activo sólo mientras el contador de señal de mantenimiento del túnel permanezca en cero o sea inferior a un valor configurado. Si esa condición no es cierta, la próxima vez que intente enviar una señal de mantenimiento al Router B, se desactiva el protocolo de línea, tan pronto como el contador de señal de mantenimiento alcance el valor de keepalive configurado. En el estado activo/inactivo, el túnel no reenvía ni procesa ningún tráfico aparte de los paquetes keepalive. Para que esto funcione sólo para paquetes keepalive, el túnel debe ser compatible con el reenvío y la recepción. Por lo tanto, el algoritmo de búsqueda de túnel debe ser exitoso en todos los casos y debe descartar solamente los paquetes de datos si el protocolo de línea está inactivo. Cuando se recibe un paquete keepalive, implica que el extremo del túnel se vuelve a alcanzar. El contador de señal de mantenimiento del túnel se restablece a 0 y el protocolo de línea vuelve a funcionar.
Impacto en la Memoria y en el Rendimiento
La función prácticamente no genera demanda adicional en la memoria del sistema del router y se espera que el rendimiento no se vea afectado por su adición. Los paquetes "keepalive" se tratan como paquetes normales, por lo que es posible que se puedan descartar en condiciones de tráfico elevado. Por ahora, puede cambiar el número de reintentos para solucionar este problema. Si esto resulta ser inadecuado en algún momento, puede colocar los paquetes keepalive generados localmente en una cola de alta prioridad para la transmisión. A continuación, puede establecer el valor TOS en los encabezados IP en un valor más adecuado, que no sea el valor predeterminado o configurado.
Consideraciones de empaquetado
La función se incluye en el código de túnel IP básico y en el subsistema GRE. Por lo tanto, debe estar disponible con un paquete IP básico que tenga el túnel y los subsistemas GRE.
Comandos y configuración
Esta sección aborda el comando keepalive habilitado y extendido por esta función solamente bajo el ID de bug de Cisco CSCuk26449. Otros comandos se documentan en las respectivas Guías de Configuración y Referencias de Comandos de Cisco IOS. El comando [no] keepalive <period> <retries> se habilita y amplía con un segundo parámetro y está disponible en la versión 12.2(8)T y posteriores del software del IOS de Cisco. También se ha portado con el ID de bug Cisco CSCuk29980 y CSCuk29983 a las versiones 12.1E y 12.2S del software del IOS de Cisco.
Como keepalive es un comando de configuración de interfaz que habilita keepalives en la interfaz de túnel, actualmente sólo se soportan keepalives para el modo GRE/IP. El segundo parámetro del comando ( reintentos) es visible y sólo está disponible para las interfaces de túnel. Los valores del primer parámetro pueden oscilar entre 1 y 32767. Cuando el valor es 0, equivale a "sin keepalive". Este parámetro tiene un valor predeterminado de 10. Los valores para el segundo parámetro pueden oscilar entre 1 y 255, e indica el número de señales de mantenimiento que se envían pero no se devuelven, después de lo cual la interfaz de túnel desactiva el protocolo de línea. Las señales de mantenimiento en las interfaces de túnel están desactivadas de forma predeterminada.
Formatos de pantalla y salida de ejemplo
Esta sección proporciona resultados de ejemplo.
cisco-7505#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
cisco-7505(config)#interface tunnel 1
cisco-7505(config-if)#?
access-expression Build a bridge boolean access expression
……………
keepalive Enable keepalive <=====
……………
timeout Define timeout values for this interface
cisco-7505(config-if)#keepalive ? <=====
<0-32767> Keepalive period (default 10 seconds)
cisco-7505(config-if)#keepalive 5 ? <=====
<1-255> Keepalive retries (default 3 times)
cisco-7505(config-if)#keepalive 5 4 <=====
cisco-7505(config-if)#end
cisco-7505#show interfaces tunnel 1
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.1.1.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255
Encapsulation TUNNEL, loopback not set
Keepalive set (5 sec), retries 4 <=====
Tunnel source 9.2.2.1, destination 6.6.6.2
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Tunnel TOS 0xF, Tunnel TTL 128
Checksumming of packets disabled, fast tunneling enabled
Last input never, output 00:57:05, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/0, 1 drops; input queue 0/75, 0 drops
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
3 packets output, 1860 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Comentarios