Determinar qué afecta a los estados de la interfaz de túnel GRE

Introducción

En este documento se describen las diferentes condiciones que pueden afectar el estado de una interfaz de túnel de encapsulamiento de routing genérico (GRE).

Antecedentes

Los túneles GRE están diseñados para ser completamente independientes del estado. Esto significa que cada extremo del túnel no conserva ninguna información sobre el estado o la disponibilidad del extremo del túnel remoto.

Una consecuencia es que, de forma predeterminada, el router de extremo de túnel local no puede desactivar el protocolo de línea de la interfaz de túnel GRE si el extremo remoto del túnel es inalcanzable.

La capacidad de marcar una interfaz como "inactiva" (en esta situación) se utiliza para eliminar cualquier ruta estática en la tabla de ruteo que utilice esa interfaz como interfaz saliente.

Específicamente, si el protocolo de línea para una interfaz se cambia a "down", las rutas estáticas que indican esa interfaz se eliminan de la tabla de ruteo.

Esto permite la instalación de una ruta estática alternativa (flotante) o de Policy Based Routing (PBR) para seleccionar un salto o interfaz siguiente alternativos.

Además, hay otras aplicaciones que se activan cuando una interfaz cambia de estado; por ejemplo, 'backup interface <b-interface>'.

Cuatro estados de túnel diferentes

Hay cuatro estados posibles en los que existe una interfaz de túnel GRE:

1. Up/up (Encendido/encendido): Esto implica que el túnel es completamente funcional y pasa el tráfico. Está activado administrativamente y su protocolo también está activado.
2. Administrativamente down/down - Esto implica que la interfaz se ha cerrado administrativamente.
3. Up/down - Esto implica que, aunque el túnel esté administrativamente activo, algo hace que el protocolo de línea en la interfaz esté inactivo.
4. Reset/down - Este suele ser un estado transitorio cuando el software reinicia el túnel. Esto suele ocurrir cuando el túnel está mal configurado con un servidor de próximo salto (NHS) que es su propia dirección IP.

Cuando se crea por primera vez una interfaz de túnel y no se le aplica ninguna otra configuración, la interfaz no se cierra de forma predeterminada:

Router#show run interface tunnel 1
Building configuration...

Current configuration : 40 bytes
!
interface Tunnel1
 no ip address
end

En este estado, la interfaz siempre está activa/inactiva:

Router(config-if)#do show ip interface brief 
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         172.16.52.1     YES NVRAM  administratively down down    
GigabitEthernet0/1         10.36.128.49    YES NVRAM  down                  down    
GigabitEthernet0/2         unassigned      YES NVRAM  down                  down    
GigabitEthernet0/3         unassigned      YES NVRAM  down                  down    
Loopback1                  192.168.2.1     YES NVRAM  up                    up      
Tunnel1                    unassigned      YES unset  up                    down

Esto se debe a que la interfaz está habilitada administrativamente, pero como no tiene un origen de túnel o un destino de túnel, el protocolo de línea está inactivo.

Para configurar esta interfaz como up/up, se debe configurar un origen y un destino de túnel válidos:

Router#show run interface tunnel  1
Building configuration...

Current configuration : 113 bytes
!
interface Tunnel1
 ip address 10.1.1.1 255.255.255.0
 tunnel source Loopback1
 tunnel destination 10.0.0.1
end

Router#show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         172.16.52.1     YES NVRAM  up                    up      
GigabitEthernet0/1         10.36.128.49    YES NVRAM  down                  down    
GigabitEthernet0/2         unassigned      YES NVRAM  down                  down    
GigabitEthernet0/3         unassigned      YES NVRAM  down                  down    
Loopback0                  unassigned      YES unset  up                    up      
Loopback1                  192.168.2.1     YES manual up                    up      
Tunnel1                    10.1.1.1         YES manual up                    up      

La secuencia anterior muestra que:

• Un origen de túnel válido consiste en cualquier interfaz que se encuentre en el estado activo/activo y que tenga una dirección IP configurada en ella.
• Por ejemplo, si el origen del túnel se cambió a Loopback0, la interfaz del túnel se desactivaría aunque Loopback0 esté en el estado up/up:
  
  

  Router(config)#interface tunnel 1
  Router(config-if)#tunnel source loopback 0
  Router(config-if)#
  *Sep  6 19:51:31.043: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down

• Un destino de túnel válido es uno que es enrutable. Sin embargo, no tiene que ser alcanzable, lo que se puede ver en esta prueba de ping:
  
  

  Router#show ip route 10.0.0.1
  % Network not in table
  Router#show ip route | inc 0.0.0.0
  Gateway of last resort is 172.16.52.100 to network 0.0.0.0
  S*    0.0.0.0/0 [1/0] via 172.16.52.100
  Router#ping 10.0.0.1 
  Type escape sequence to abort.
  Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
  .....
  Success rate is 0 percent (0/5)

Hasta el momento, el túnel se ha configurado como túnel GRE punto a punto (P2P), que es el predeterminado.

Si este túnel se cambia a un túnel GRE multipunto (mGRE), todo lo que se requiere para un estado activo es un origen de túnel válido. 

Router#show run interface tunnel 1
Building configuration...

Current configuration : 129 bytes
!
interface Tunnel1
 ip address 10.1.1.1 255.255.255.0
 no ip redirects
 tunnel source Loopback1
 tunnel mode gre multipoint
end

Router#show ip interface brief | include Tunnel
Tunnel1                    10.1.1.1         YES manual up                    up    

En cualquier momento, si la interfaz de túnel se apaga administrativamente, el túnel pasa inmediatamente a un estado administrativamente inactivo/inactivo:

Router#show run interface tunnel 1
Building configuration...

Current configuration : 50 bytes
!
interface Tunnel1
 no ip address
shutdown
end

Router#show ip interface brief | include Tunnel
Tunnel1                    unassigned      YES unset  administratively down down    

Estado del túnel GRE P2P

Una interfaz de túnel GRE P2P suele aparecer tan pronto como se configura con una dirección de origen o interfaz de túnel válida que está activa y una dirección IP de destino de túnel que es enrutable (mostrada anteriormente).

Protocolo de línea caído localmente en el router

En circunstancias normales, solo hay tres razones para que un túnel GRE esté en el estado activo/inactivo:  

• No existe ninguna ruta, que incluya la ruta predeterminada, a la dirección de destino del túnel.
• La interfaz que ancla el origen del túnel está inactiva.
• La ruta a la dirección de destino del túnel pasa a través del propio túnel, lo que resulta en recursión.

Estas tres reglas (missing, ruta, interfaz inactiva y destino de túnel mal ruteado) son problemas locales del router en los extremos del túnel. 

No cubren los problemas en la red interviniente ni otras características relacionadas con el túnel GRE que se pueden configurar. Este documento describe escenarios donde otros factores pueden influir en el estado del túnel GRE.

Keepalives de túnel GRE

Las reglas básicas no cubren el caso en el que los paquetes tunelados GRE se reenvían correctamente pero se pierden antes de llegar al otro extremo del túnel.

Esto hace que se pierdan los paquetes de datos que pasan a través del túnel GRE, aunque una ruta alternativa que utiliza PBR o una ruta estática flotante a través de otra interfaz esté potencialmente disponible.

Los keepalives en la interfaz de túnel GRE se utilizan para resolver este problema de la misma manera que los keepalives se utilizan en las interfaces físicas.

Con Cisco IOS^® Software Release 12.2(8)T, es posible configurar señales de mantenimiento en una interfaz de túnel GRE P2P. Con este cambio, la interfaz de túnel se apaga dinámicamente si las señales de mantenimiento fallan durante un cierto período de tiempo. 

Para entender mejor cómo funcionan los keepalives del túnel GRE, consulte Keepalives del Túnel GRE.

Nota: Las señales de mantenimiento del túnel GRE sólo son válidas y tienen un efecto en los túneles GRE P2P; no son válidos y no tienen ningún efecto en los túneles mGRE.

Túneles GRE con protección de túnel

En las versiones 15.4(3)M/15.4(3)S y posteriores del software Cisco IOS^®, el estado del protocolo de línea de túnel GRE sigue el estado de la Asociación de seguridad (SA) IPsec. Por lo tanto, el protocolo de línea puede permanecer inactivo hasta que la sesión IPSec se haya establecido completamente.

Esto se confirmó con el ID de bug de Cisco CSCum34057 (intento inicial con el ID de bug de Cisco CSCuj29996 y luego se retiró con el ID de bug de Cisco CSCuj9287).

Interfaces de túnel GRE multipunto (mGRE)

Para las interfaces de túnel mGRE, algunas de las comprobaciones anteriores para túneles P2P no son aplicables (porque no hay un destino de túnel fijo).

Estas son las razones por las que un protocolo de línea de túnel mGRE puede estar en un estado inactivo:

• La interfaz de origen del túnel está en estado inactivo.
• Si la función de control de estado de la interfaz está activada para la VPN multipunto dinámica (DMVPN) y no responde ningún NHS, el protocolo de línea se pondrá en estado inactivo.
• Para obtener más información sobre la función de control de estado de la interfaz, consulte la Guía de configuración de la supervisión y recuperación del estado del túnel DMVPN.

Dependencias en el estado de redundancia

Cuando una dirección IP de origen de túnel se configura como una dirección IP de redundancia (por ejemplo, una dirección IP virtual de protocolo de router con espera en caliente (HSRP VIP)), el estado de la interfaz de túnel realiza un seguimiento del estado de redundancia.

Esto agrega otra verificación que mantiene tales interfaces de túnel en el estado de inactividad del protocolo de línea hasta que el estado de redundancia cambia a ACTIVO.

En este ejemplo, una configuración ipc zone default mal configurada hace que la redundancia se encuentre en el estado NEGOTIATION y mantiene tales interfaces de túnel en un estado inactivo:

Router#show redundancy state
       my state = 3  -NEGOTIATION 
     peer state = 1  -DISABLED 
           Mode = Simplex
        Unit ID = 0

     Maintenance Mode = Disabled
    Manual Swact = disabled (system is simplex (no peer unit))
 Communications = Down      Reason: Simplex mode

   client count = 16
 client_notification_TMR = 60000 milliseconds
           RF debug mask = 0x0   

Router#show interface tunnel100
Tunnel100 is up, line protocol is down 
  Hardware is Tunnel
  Internet address is 172.16.1.100/24
  MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 10.122.162.254 (GigabitEthernet0/1)
   Tunnel Subblocks:
      src-track:
         Tunnel100 source tracking subblock associated with GigabitEthernet0/1
          Set of tunnels with source GigabitEthernet0/1, 2 members (includes
          iterators), on interface <OK>
  Tunnel protocol/transport multi-GRE/IP
<SNIP>

Troubleshoot

Además de los motivos previamente descritos, la evaluación del estado de línea del túnel para el motivo de caída del túnel se puede ver con el comando show tunnel interface tunnel x hidden:

Router#show tunnel interface tunnel 100
Tunnel100
   Mode:multi-GRE/IP, Destination UNKNOWN, Source GigabitEthernet0/1
   Application ID 1: unspecified
   Tunnel Subblocks:
      src-track:
         Tunnel100 source tracking subblock associated with GigabitEthernet0/1
          Set of tunnels with source GigabitEthernet0/1, 2 members (includes
          iterators), on interface <OK>
   Linestate - current down
   Internal linestate - current down, evaluated down - interface not up
   Tunnel Source Flags: Local   
   Transport IPv4 Header DF bit cleared
   OCE: IP tunnel decap 
   Provider: interface Tu100, prot 47   
     Performs protocol check [47] 
     Performs Address save check 
     Protocol Handler: GRE: key 0x64, opt 0x2000
       ptype: ipv4 [ipv4 dispatcher: drop] 
       ptype: ipv6 [ipv6 dispatcher: drop] 
       ptype: mpls [mpls dispatcher: drop] 
       ptype: otv [mpls dispatcher: drop] 
       ptype: generic [mpls dispatcher: drop] 

Nota: Hay una mejora abierta para hacer que el motivo de caída del túnel sea más explícito para indicar que se debe al estado de redundancia porque no está activo. El seguimiento de esto se realiza mediante el identificador de bug de Cisco CSCuq31060.

Información Relacionada

• RFC 1701, encapsulación de router genérico (GRE)
• RFC 2890, extensiones de clave y número de secuencia a GRE
• keepalive de túnel de encapsulación de routing genérico (GRE)
• Fragmentación de IP y PMTUD
• Soporte Técnico y Documentación - Cisco Systems