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:
- 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.
- Administrativamente down/down - Esto implica que la interfaz se ha cerrado administrativamente.
- 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.
- 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.
Nota: Un túnel mGRE puede tener muchos destinos de túnel, por lo que no se puede utilizar para controlar el estado de la interfaz de túnel.
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 de túnel GRE sólo son válidas y tienen un efecto en los túneles GRE P2P; no son válidas 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