Contenido

Introducción

Antecedentes

Cuatro estados de túnel diferentes

Estado del túnel GRE P2P

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

Keepalives de túnel GRE

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

Interfaces de túnel GRE multipunto (mGRE)

Dependencias en el estado de redundancia

Troubleshoot

Información Relacionada

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 de esto es que, de forma predeterminada, el router de extremo de túnel local no tiene la capacidad de 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 cuando el extremo remoto del link no está disponible se utiliza para quitar cualquier ruta (específicamente rutas estáticas) en la tabla de ruteo que utiliza 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 señalan 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. También 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 una interfaz de túnel GRE puede ser:

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 esté en el estado activo/activo y que tenga una dirección IP configurada en él. 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 ahora, el túnel se ha configurado como túnel GRE punto a punto (P2P), que es el predeterminado. Si se cambia este túnel a un túnel GRE multipunto (mGRE), todo lo que se necesita para que el túnel esté en estado activo es un origen de túnel válido (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 del 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 como se muestra en la sección anterior.

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, route, interface down, y misrouted tunnel destination) son problemas locales del router en los puntos finales del túnel y no cubren problemas en la red interviniente u 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 los paquetes de datos que pasan a través del túnel GRE sean "agujeros negros", 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 determinado período de tiempo. Para entender mejor cómo funcionan las señales de mantenimiento de túnel GRE, consulte Señales de Mantenimiento de 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 Cisco IOS Software Releases 15.4(3)M/15.4(3)S y versiones posteriores, el estado del protocolo de línea de túnel GRE puede seguir el estado de IPsec Security Association (SA), por lo que 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 Cisco CSCum34057 (intento inicial con el ID de bug Cisco CSCuj29996 y luego se retiró con el ID de bug Cisco CSCuj9287).

Interfaces de túnel GRE multipunto (mGRE)

Para las interfaces de túnel mGRE, dado que no hay un destino de túnel fijo, algunas de las comprobaciones anteriores para túneles P2P no son aplicables. Estas son las razones por las que un protocolo de línea de túnel mGRE puede estar en 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 ninguno de los NHS responde, el protocolo de línea se pone 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 agregó una verificación adicional, que mantiene a estas 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, como se muestra aquí:

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 el motivo de caída del túnel 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