IP : Encapsulado de routing genérico (GRE)

Keepalives del túnel GRE

25 Agosto 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (23 Abril 2015) | Comentarios


Contenido


Introducción

Este documento explica qué son las señales de mantenimiento GRE y cómo funcionan. El Keepalives del túnel GRE no se soporta conjuntamente con el comando tunnel protection ipsec profile. Este documento discute este problema.

Nota:  Las Señales de mantenimiento GRE no se soportan así como la protección del túnel IPsec bajo ninguna circunstancias.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Mecanismo de keepalive del túnel GRE

Túneles GRE

Los túneles GRE se diseñan para ser totalmente apátridas. Esto significa que cada punto final del túnel no guarda ninguna información sobre el estado o la Disponibilidad de la punto final remota del túnel. Una consecuencia de esto es que el router local de la punto final del túnel no tiene la capacidad de derribar el Line Protocol de la interfaz de túnel GRE si el extremo remoto del túnel es inalcanzable. La capacidad de marcar una interfaz como abajo cuando el extremo remoto del link no está disponible se utiliza para quitar cualquier ruta (específicamente Static rutas) en la tabla de ruteo que utilice esa interfaz como la interfaz de salida. Específicamente, si el Line Protocol para una interfaz se cambia a abajo, después cualquier Static rutas que señalen que la interfaz está quitada de la tabla de ruteo. Esto permite para la instalación de una Static ruta (flotante) alterna o para que el Routing basado en políticas (PBR) seleccione un Next-Hop alterno o interconecte.

Normalmente, una interfaz de túnel GRE sube tan pronto como se configure y permanece para arriba mientras haya un direccionamiento o una interfaz válido de origen de túnel que están para arriba. El IP Address de destino del túnel debe también ser routable. Esto es verdad incluso si el otro lado del túnel no se ha configurado. Esto significa que sigue habiendo una Static ruta o un reenvío PBR de paquetes vía la interfaz de túnel GRE en efecto aunque los paquetes de túnel GRE no alcanzan el otro extremo del túnel.

Antes de que las Señales de mantenimiento GRE fueran implementadas, había solamente tres razones de un túnel GRE para apagar:

  • No hay ruta a la dirección de destino del túnel.

  • La interfaz que asegura el origen de túnel está abajo.

  • La ruta a la dirección de destino del túnel está a través del túnel sí mismo.

Estas tres reglas (la ruta perdida, interconecta abajo y destino del túnel encaminado erróneamente) son problemas locales al router en los puntos finales del túnel y no cubren los problemas en la red intermedia. Por ejemplo, estas reglas no cubren el caso en el cual los paquetes GRE tunelizados se remiten con éxito, pero se pierden antes de que alcancen el otro extremo del túnel. Esto causa los paquetes de datos que pasan a través del túnel GRE ser “negro agujereado”, aunque una ruta alternativa que utiliza PBR o las Rutas estáticas flotantes vía otra interfaz está potencialmente disponible. El Keepalives en la interfaz de túnel GRE se utiliza para solucionar este problema de la misma forma que el Keepalives se utiliza en las interfaces físicas.

Con el Software Release 12.2(8)T de Cisco IOS�, es posible configurar el Keepalives en una interfaz de túnel GRE de punto a punto. Con este cambio, la interfaz del túnel apaga dinámicamente si el Keepalives falla por cierto período de tiempo. Para entender mejor cómo el Keepalives del túnel GRE trabaja, estas secciones discuten algunos otros mecanismos frecuentes de keepalive.

Mecanismos frecuentes de keepalive

Los mensajes de keepalive son enviados por un dispositivo de red vía una comprobación o un circuito virtual todavía para informar a otro dispositivo de red ese el circuito entre ellos las funciones. El intervalo de keepalive es el período de tiempo entre cada mensaje de keepalive que sea enviado por un dispositivo de red. Las recomprobaciones del keepalive son la cantidad de veces que el dispositivo continúa enviando los paquetes de keepalive sin la respuesta antes de que se derribe la interfaz.

Keepalives de los Ethernetes

En el medio de broadcast como un Ethernet, el Keepalives es levemente diferente. Puesto que hay muchos posibles vecinos en los Ethernetes, el keepalive no se diseña para determinar si la trayectoria a cualquier un vecino particular en el alambre está disponible. Se diseña solamente para marcar que el sistema local tiene acceso de lectura y escritura al alambre de los Ethernetes sí mismo. El router produce un paquete Ethernet consigo mismo como el MAC Address de origen y destino y código de tipo Ethernet especial de 0x9000. El hardware Ethernet envía este paquete sobre el alambre de los Ethernetes y después recibe inmediatamente esta parte posterior del paquete otra vez. Esto marca el hardware de envío y de recepción en el adaptador Ethernet y la integridad básica del alambre.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-a.gif

Señales de mantenimiento de HDLC

Otro mecanismo de keepalive bien conocido es señales de mantenimiento serial para el HDLC. Las señales de mantenimiento serial se envían hacia adelante y hacia atrás entre dos Routers y el Keepalives se reconocen. Con el uso de los números de secuencia, cada router no pierde de vista los paquetes de keepalive enviados y reconocidos. De esta manera, los routeres remotos miran cada otros Keepalives y pista si se recibe el Keepalives que él envía.

Como un ejemplo de cómo las señales de mantenimiento serial trabajan, el router1 y router2 están conectados directamente vía el Serial0/0 y el Serial2/0 respectivamente. En la salida del router1, el Serial0/0 se apaga adrede. Esto hace el router2 faltar tres Keepalives para ilustrar cómo este incidente hace el router2 apagar el Serial2/0 cuando se falta el Keepalives.

Ésta es salida de muestra del comando debug serial interface para una conexión HDLC cuando se habilita el Keepalives. Cuando la diferencia en los valores en el myseq y los campos del mineseen excede de 3 en el router2, la línea va abajo y se reajusta la interfaz.

Router 1
17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up 
17:21:19.725: Serial0/0: HDLC myseq 1, mineseen 1*, yourseen 2, line up
17:21:29.753: Serial0/0: HDLC myseq 2, mineseen 2*, yourseen 3, line up
17:21:39.773: Serial0/0: HDLC myseq 3, mineseen 3*, yourseen 4, line up
17:21:49.805: Serial0/0: HDLC myseq 4, mineseen 4*, yourseen 5, line up
17:21:59.837: Serial0/0: HDLC myseq 5, mineseen 5*, yourseen 6, line up
17:22:09.865: Serial0/0: HDLC myseq 6, mineseen 6*, yourseen 7, line up
17:22:19.905: Serial0/0: HDLC myseq 7, mineseen 7*, yourseen 8, line up
17:22:29.945: Serial0/0: HDLC myseq 8, mineseen 8*, yourseen 9, line up
Router1 (config-if)#shut
17:22:39.965: Serial0/0: HDLC myseq 9, mineseen 9*, yourseen 10, line up
17:22:42.225: %LINK-5-CHANGED: Interface Serial0/0, changed state 
to administratively down

17:22:43.245: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, 
changed state to down

Router 2
*Sep 24 17:21:04.929: Serial2/0: HDLC myseq 0, mineseen 0, yourseen 0, line up 
*Sep 24 17:21:14.941: Serial2/0: HDLC myseq 1, mineseen 1*, yourseen 1, line up 
*Sep 24 17:21:24.961: Serial2/0: HDLC myseq 2, mineseen 2*, yourseen 2, line up 
*Sep 24 17:21:34.981: Serial2/0: HDLC myseq 3, mineseen 3*, yourseen 3, line up 
*Sep 24 17:21:45.001: Serial2/0: HDLC myseq 4, mineseen 4*, yourseen 4, line up 
*Sep 24 17:21:55.021: Serial2/0: HDLC myseq 5, mineseen 5*, yourseen 5, line up 
*Sep 24 17:22:05.041: Serial2/0: HDLC myseq 6, mineseen 6*, yourseen 6, line up 
*Sep 24 17:22:15.061: Serial2/0: HDLC myseq 7, mineseen 7*, yourseen 7, line up 
*Sep 24 17:22:25.081: Serial2/0: HDLC myseq 8, mineseen 8*, yourseen 8, line up 
*Sep 24 17:22:35.101: Serial2/0: HDLC myseq 9, mineseen 9*, yourseen 9, line up 
*Sep 24 17:22:45.113: Serial2/0: HDLC myseq 10, mineseen 10*, yourseen 10, line up 
*Sep 24 17:22:55.133: Serial2/0: HDLC myseq 11, mineseen 10, yourseen 10, line up 
*Sep 24 17:23:05.153: HD(0): Reset from 0x203758
*Sep 24 17:23:05.153: HD(0): Asserting DTR 
*Sep 24 17:23:05.153: HD(0): Asserting DTR and RTS 
*Sep 24 17:23:05.153: Serial2/0: HDLC myseq 12, mineseen 10, yourseen 10, line up 
*Sep 24 17:23:15.173: HD(0): Reset from 0x203758
*Sep 24 17:23:15.173: HD(0): Asserting DTR 
*Sep 24 17:23:15.173: HD(0): Asserting DTR and RTS 
*Sep 24 17:23:15.173: Serial2/0: HDLC myseq 13, mineseen 10, yourseen 10, line down 
17:23:16.201: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, 
changed state to down
Router2#
17:23:25.193: Serial2/0: HDLC myseq 14, mineseen 10, yourseen 10, line down

Keepalives del túnel GRE

El mecanismo de keepalive del túnel GRE es levemente diferente que para los Ethernetes o las interfaces seriales. Da la capacidad para que un lado origine y reciba los paquetes de keepalive a y desde un router remoto incluso si el router remoto no soporta las Señales de mantenimiento GRE. Puesto que el GRE es un mecanismo de tunelización del paquete para hacer un túnel el IP dentro del IP, un paquete del túnel IP GRE se puede construir dentro de otro paquete del túnel IP GRE. Para las Señales de mantenimiento GRE, las PRE-estructuras del remitente el paquete de la respuesta de keepalive dentro del paquete de pedidos del keepalive original de modo que las necesidades del extremo remoto solamente de hacer la descapsulación estándar GRE del encabezado IP externo GRE y entonces remiten el Paquete GRE interno IP. Este mecanismo hace la respuesta de keepalive remitir hacia fuera la interfaz física bastante que la interfaz del túnel. Esto significa que el paquete de respuesta del keepalive GRE no es afectado por ninguna funciones de resultados en la interfaz del túnel, tal como “protección del túnel…”, QoS, y así sucesivamente. ).

Nota: Si un ACL entrante en la interfaz de túnel GRE se configura, después el paquete de keepalive del túnel GRE que el dispositivo opuesto envía debe ser permitido. Si no, el túnel GRE del dispositivo opuesto estará abajo. (de la lista de acceso del <number> del permit gre host host <tunnel-source> <tunnel-destination>)

Otro atributo del Keepalives del túnel GRE es que los temporizadores KEEPALIVE en cada lado son independientes y no tienen que hacer juego. El problema con la configuración del Keepalives solamente en un lado del túnel es que solamente el router que hace el Keepalives configurar marca su interfaz del túnel como abajo si expira el temporizador KEEPALIVE. Sigue habiendo la interfaz de túnel GRE en el otro lado, donde el Keepalives no se configura, para arriba incluso si el otro lado del túnel está abajo. El túnel puede sentir bien a un agujero negro para los paquetes dirigidos en el túnel del lado que no tenía Keepalives configurado. En una red grande del túnel GRE del hub-and-spoke, puede ser que sea apropiado configurar solamente las Señales de mantenimiento GRE en el lado radial y no en el lado del eje de conexión. Esto es porque es a menudo más importante para habló para descubrir que el concentrador es inalcanzable y por lo tanto Switch a un trayecto de backup (Respaldo de marcado por ejemplo).

Cómo los keepalives de túnel trabajan

Un túnel GRE es una interfaz lógica en un router Cisco los paquetes de pasajero de ese proporciona una manera de encapsular dentro de un Transport Protocol. Es una arquitectura diseñada para proporcionar los servicios necesarios para implementar un esquema de encapsulación punto a punto.

Estos paquetes ilustran los conceptos del Tunelización IP donde está el Encapsulation Protocol el GRE y el IP es el Transport Protocol. El protocolo pasajero es también IP (aunque puede ser otro protocolo como el DECNet, el IPX o el APPLETALK).

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-b.gif

  • IP es el protocolo de transporte.

  • GRE es el protocolo de encapsulación.

  • IP es el protocolo pasajero.

Para entender mejor cómo los trabajos del mecanismo del keepalive de túnel, consideran esta topología de túnel ejemplo y configuración. Las interfaces físicas del router A y del router B son s1 y el s2 respectivamente y las interfaces del túnel se llaman Tu0. Hay una red de estructura básica IP entre los dos routeres del punto final del túnel GRE.

Éste es un ejemplo de un paquete de keepalive que origine del router A y es destinado para el router B. La respuesta de keepalive que el router B vuelve al router A está ya dentro del encabezado IP interno. Los decapsulates del router B simplemente el paquete de keepalive y lo envían se retiran la interfaz física (s2). Procesa el paquete del keepalive GRE apenas como cualquier otro paquete de datos IP GRE.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-1.gif

Esta salida muestra los comandos que usted utiliza para configurar el Keepalives en los túneles GRE.

Router# configure terminal
Router(config)#interface tunnel0
Router(config-if)#keepalive 5 4          

!--- The syntax of this command is keepalive [seconds [retries]].



!--- Keepalives are sent every 5 seconds and 4 retries.
!--- Keepalives must be missed before the tunnel is shut down.
!--- The default values are 10 seconds for the interval and 3 retries.

Nota: El Keepalives del túnel GRE se soporta solamente en los túneles GRE de punto a punto. Los keepalives de túnel son configurables en los túneles de múltiples puntos GRE (mGRE) pero no tienen ningún efecto.

Esta tabla muestra la configuración del router A y al router B con el keepalive de túnel configurado en ambo Routers.

Router A del nombre de host Router-B del nombre de host
interface loopback 0
  ip address 129.9.9.9 255.255.255.255
interface tunnel 0
  ip address 1.1.1.1 255.255.255.240
  tunnel source loopback0
  tunnel destination 128.8.8.8
  keepalive 5 4
interface loopback 0
  ip address 128.8.8.8 255.255.255.255
interface tunnel 0
  ip address 1.1.1.2 255.255.255.240
  tunnel source loopback0
  tunnel destination 129.9.9.9
  keepalive 5 4 

Cuando usted habilita el Keepalives en el punto final del túnel del router A, el router en cada <period> intervalo construye el encabezado IP y el encabezado GRE internos con un Tipo de protocolo (PT) de 0. Entonces manda ese paquete su interfaz del túnel, con la cual da lugar a la encapsulación del paquete con el encabezado IP externo y de un encabezado GRE el PT = el IP. El router A incrementa el contador del keepalive de túnel por uno. Con la suposición que hay una manera de alcanzar el punto final del túnel del otro extremo y el Line Protocol del túnel no está abajo de debido a otras razones, el paquete llega en el router B. Después se corresponde con contra el tunnel0, llega a ser decapsulated, y se remite al IP de destino que es el IP Address del origen de túnel en la llegada de A. Upon del router en el router A, el paquete se convierte en decapsulated y el control de los resultados PT en 0. Esto significa que esto es un paquete de keepalive. El contador del keepalive de túnel entonces se reajusta a 0 y se desecha el paquete.

En el caso cuando el router B es inalcanzable, el router A continúa construyendo y enviando los paquetes de keepalive así como el tráfico normal. Si no se vuelve el Keepalives, el Line Protocol del túnel permanece para arriba mientras el contador del keepalive de túnel sea menos que el número de <retries>. Si esa condición no es verdad, después la próxima vez que el router A intenta enviar un keepalive al router B, se derriba el Line Protocol.

En el estado encendido/apagado, el túnel no remite ni procesa ningún tráfico de datos. Sin embargo, continúa enviando los paquetes de keepalive. En la recepción de una respuesta de keepalive, con la implicación que el punto final del túnel es otra vez accesible, el contador del keepalive de túnel se reajusta a 0 y el Line Protocol en el túnel sube.

Nota: Si es debido a un descenso del keepalive el túnel va al estado encendido/apagado, habilita el túnel del debug y hace el debug del keepalive de túnel.

Esta tabla muestra la salida de muestra del keepalive de túnel del debug en el router A:

Router A del nombre de host
debug tunnel keepalive
        Tunnel keepalive debugging is on
        *Mar  1 01:19:16.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=15
        *Mar  1 01:19:21.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=16
        *Mar  1 01:19:26.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=17

Este diagrama muestra un escenario de ejemplo de qué sucede cuando el router A envía un keepalive GRE al router B:

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-2.gif

Este diagrama muestra un escenario de ejemplo de qué sucede cuando el router B envía un keepalive GRE al router A:

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-3.gif

IPSec y Señales de mantenimiento GRE

Túneles GRE con el IPSec

Los túneles GRE se combinan a veces con el IPSec porque el IPSec no soporta los paquetes del Multicast IP. Esto evita que los Dynamic Routing Protocol se ejecuten con éxito sobre una red del IPSec VPN. Puesto que los túneles GRE soportan el Multicast IP, un Dynamic Routing Protocol se puede funcionar con sobre un túnel GRE. Entonces, usted puede cifrar los paquetes de la unidifusión IP GRE por el IPSec.

Hay dos maneras diferentes que el IPSec puede cifrar los Paquetes GRE. Una manera está con el uso de un crypto-mapa y la otra es utilizar la protección del túnel. Ambos métodos especifican que la encripción de IPSec está realizada después de la adición de la encapsulación GRE. Cuando se utiliza un crypto-mapa, se aplica a la interfaz física saliente para los paquetes de túnel GRE. Cuando se utiliza la protección del túnel, se configura en la interfaz de túnel GRE. El comando tunnel protection estaba disponible en el Cisco IOS Software Release 12.2(13)T.

Nota: Las Señales de mantenimiento GRE no son compatibles con la protección del túnel.

Este diagrama muestra los paquetes encriptados que entran en a un router vía una interfaz de túnel GRE. El router tiene un crypto-mapa aplicado en la interfaz física. Una vez que se desencriptan los paquetes y desencapsulado, continúan encendido a su destino IP como texto claro.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-4.gif

Este diagrama muestra qué sucede cuando usted configura la protección del túnel en la interfaz de túnel GRE. Los paquetes entran en al router cifrado vía la interfaz del túnel y son desencriptados y de-capsulated antes de que continúen hacia su destino como texto claro.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-5.gif

Hay dos diferencias fundamentales entre cuando usted utiliza un crypto-mapa y cuando usted utiliza la protección del túnel:

  • El crypto-mapa del IPSec se ata a la interfaz física y se marca mientras que los paquetes se remiten hacia fuera la interfaz física.

    Nota: El túnel GRE tiene GRE encapsuló ya el paquete por esta punta.

  • La protección del túnel ata la funcionalidad de encripción al túnel GRE y se marca después de que el paquete sea GRE encapsulado pero antes de que el paquete se da a la interfaz física.

Problemas con el Keepalives cuando usted combina el IPSec y el GRE

Un problema ocurre si una correspondencia de criptografía se utiliza (configurado en la interfaz física) en un lado de un túnel IPsec GRE y protección del túnel se configura en el otro lado. La protección del túnel se configura en la interfaz del túnel solamente (no la comprobación). Los este tipos de configuración se pudieron hacer en un diseño del hub and spoke. La protección del túnel se configura en el router de eje de conexión para reducir los tamaños de la configuración y una correspondencia de criptografía estática se utiliza en cada spoke. Cuando usted configura el keepalive del túnel GRE en el spoke en este escenario, el keepalive falla. Esto es porque el keepalive de vuelta del CONCENTRADOR atraviesa la interfaz física que no tiene ningún crypto-mapa configurado. Por lo tanto, el keepalive de vuelta no consigue cifrado y el router de recepción (que envió originalmente el paquete de keepalive) cae la respuesta de keepalive porque no era IPSec protegido (cifrado).

Este diagrama muestra un ejemplo del problema:

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-9.gif

Usted puede evitar este problema y puede haber una ventaja si el keepalive GRE se configura en el router donde se configura la protección del túnel. Esta punta se ilustra en este diagrama:

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-10.gif

Si el concentrador utiliza las correspondencias cifradas dinámicas y el router radial utiliza la protección del túnel, después usted puede configurar las Señales de mantenimiento GRE en el router radial así que usted puede accionar una Interfaz de respaldo para marcar el concentrador si la interfaz del túnel apaga en el spoke.

Aunque siga habiendo la interfaz de túnel GRE en el concentrador para arriba, pierden al vecino de ruteo y las rutas a través del túnel y la ruta alternativa puede ser establecida. En el spoke, el hecho de que fuera la interfaz del túnel abajo puede accionarla para criar una interfaz del dialer y una devolución de llamada al concentrador (o a otro router en el concentrador), después establece una nueva conexión.

Si ambo el configuran Routers con los mapas de criptografía, los keepalives de túnel pueden conseguir a través en las ambas direcciones y las interfaces de túnel GRE pueden apagar en cualquiera o las ambas direcciones, y accionan una conexión de respaldo que se hará. Ésta es la mayoría de la opción flexible.

Si configuran a ambo Routers con la protección del túnel entonces los keeaplives del túnel GRE no se pueden utilizar en cualquier dirección. En este caso usted debe utilizar el Routing Protocol o el otro mecanismo, tal como el Service Assurance Agent, para descubrir que el túnel no es funcional.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 64565