IP : Encapsulado de routing genérico (GRE)

Estados de la interfaz de túnel GRE y qué impactos ellos

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe las diversas condiciones que pueden afectar al estado de una interfaz del túnel del Generic Routing Encapsulation (GRE).

Contribuido por Wen Zhang y Atri Basu, ingenieros de Cisco TAC.

Antecedentes

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 del punto final del túnel remoto. Una consecuencia de esto es que, por abandono, el router local del 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 el Routing basado en políticas (PBR) para seleccionar un Next-Hop alterno o interconectar. También hay otras aplicaciones que accionan cuando una interfaz cambia el estado; por ejemplo, “<b-interface> de la Interfaz de respaldo”.

Tres diversos estados de túnel

Hay tres estados posibles en los cuales una interfaz de túnel GRE puede estar:

  1. Up/up - Esto implica que el túnel está completamente - funcional y está pasando el tráfico. Es ambos adminstratively ascendentes y su protocolo está para arriba también.
  2. Abajo/abajo de Adminstratively - Esto implica que la interfaz administrativo se ha apagado.
  3. Arriba/abajo - Esto implica que, aunque el túnel está administrativo para arriba, algo hace el Line Protocol en la interfaz estar abajo.

Cuando una interfaz del túnel primero se crea y no se aplica ninguna otra configuración a ella, la interfaz es ningún cerrado por abandono:

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

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

En este estado, la interfaz es siempre arriba/abaja:

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         14.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 es porque la interfaz administrativo se habilita, pero puesto que no tiene un origen de túnel o un destino del túnel, el Line Protocol está abajo.

Para hacer este up/up de la interfaz, un origen de túnel válido y el destino del túnel deben ser configurados:

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

Current configuration : 113 bytes
!
interface Tunnel1
 ip address 1.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         14.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                    1.1.1.1         YES manual up                    up      

La secuencia anterior muestra eso:

  • Un origen de túnel válido consiste en cualquier interfaz que esté sí mismo en el estado up-up y tenga una dirección IP configurada en él. Por ejemplo, si el origen de túnel fuera cambiado al loopback0, la interfaz del túnel iría abajo aunque el loopback0 está en el estado up-up:

    Router(config-if)#int tun 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 del túnel válido es uno que es routable. Sin embargo, no tiene que ser accesible, que se puede ver de 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 de punto a punto (P2P), que es el valor por defecto. Si se cambiara este túnel a un túnel de múltiples puntos GRE (mGRE), después todo que se requiere para que el túnel esté en un estado ascendente es un origen de túnel válido (un túnel del mGRE puede tener muchos destinos del túnel, para no poder 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 1.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                    1.1.1.1         YES manual up                    up   

En cualquier punta, si la interfaz del túnel adminstratively se apaga, el túnel entra inmediatamente administrativo abajo/estado 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

Normalmente, una interfaz de túnel GRE P2P sube tan pronto como se configure con un direccionamiento de origen de túnel o una interfaz válida que sea ascendente y un IP Address de destino del túnel que sea routable tal y como se muestra en de la sección anterior.

Line Protocol abajo localmente en el router

En circunstancias normales, hay solamente tres razones de un túnel GRE para estar en el estado encendido/apagado:  

  • No hay ruta, que incluye la ruta predeterminado, 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, que da lugar a la repetición.

Estas tres reglas (la ruta perdida, interconecta abajo, y destino del túnel ruteado incorrectamente) son problemas locales al router en los puntos finales del túnel y no cubren los problemas en la red intermedia o las otras funciones relacionadas con el túnel GRE que pudo ser configurado. Este documento describe los escenarios donde otros factores pudieron influenciar el estado del túnel GRE.

Keepalives del túnel GRE

Las reglas básicas 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 el Keepalives de este problema se utiliza de la misma manera en las interfaces físicas.

Con la versión 12.2(8)T del Cisco IOS ® Software, es posible configurar el Keepalives en una interfaz de túnel GRE P2P. 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, satisfaga refieren al Keepalives del túnel GRE.

Nota: El Keepalives del túnel GRE es solamente válido y tiene un efecto sobre los túneles GRE P2P; él es inválido y no tiene ningún efecto sobre los túneles del mGRE.

Interfaces del túnel de múltiples puntos GRE (mGRE)

Para las interfaces de túnel MGRE, puesto que no hay destino del túnel fijo, algunas de las comprobaciones para anteriores los túneles P2P son no corresponde. Aquí están las razones que el Line Protocol de un túnel del mGRE puede estar en un estado inactivo:

  • La interfaz del origen de túnel está en un estado inactivo.
  • Si la característica del control estatal de interfaz se habilita para el Dynamic Multipoint VPN (DMVPN) y ningunos de los servidores de Next Hop (NHSs) no responda, después el Line Protocol se pone en un estado inactivo. Para los detalles en la característica del control estatal de interfaz, vea el control de salud del túnel DMVPN y a la guía de configuración de la recuperación.

Dependencias en el estado de redundancia

Cuando se configura una dirección IP del origen de túnel como una dirección IP de la Redundancia (por ejemplo, un direccionamiento del protocolo del router de la espera en caliente IP virtual (HSRP VIP)), después el estado de la interfaz del túnel sigue al estado de redundancia.

Esto agregó un control adicional, que mantiene tales interfaces del túnel el estado inactivo del Line Protocol hasta los cambios de estado de redundancia al ACTIVE. En este ejemplo, una Redundancia mal configurado de las causas de la configuración predeterminada de la zona ipc a estar en el estado de la NEGOCIACIÓN y mantiene tales interfaces del túnel 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>

Troubleshooting

Además de marcar las razones delineadas previamente, la línea evaluación del túnel del estado para el túnel abajo razona se puede considerar con el comando oculto del túnel x de la interfaz del túnel de la demostración 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 que el túnel abajo razona más explícito para indicar que es debido al estado de redundancia que no es activo. Esto es seguida por el Id. de bug Cisco CSCuq31060.

Información Relacionada



Document ID: 118361