Determine o que afeta os estados da interface do túnel GRE

Introdução

Este documento descreve as diferentes condições que podem afetar o estado de uma interface de túnel GRE (Generic Routing Encapsulation).

Informações de Apoio

Os túneis GRE são projetados para serem completamente stateless. Isso significa que cada endpoint de túnel não mantém nenhuma informação sobre o estado ou a disponibilidade do endpoint de túnel remoto.

Uma consequência é que, por padrão, o roteador de ponto final de túnel local não pode desativar o protocolo de linha da interface de túnel GRE se a extremidade remota do túnel estiver inalcançável.

A capacidade de marcar uma interface como "inativa" (nessa situação) é usada para remover quaisquer rotas estáticas na tabela de roteamento que usam essa interface como a interface de saída.

Especificamente, se o protocolo de linha de uma interface for alterado para "inativo", todas as rotas estáticas que indicam que a interface foi removida da tabela de roteamento.

Isso permite a instalação de uma rota estática alternativa (flutuante) ou de Roteamento Baseado em Políticas (PBR - Policy Based Routing) para selecionar um próximo salto alternativo ou uma interface.

Além disso, há outros aplicativos que são acionados quando uma interface muda de estado; por exemplo, 'backup interface <b-interface>'.

Quatro estados de túnel diferentes

Há quatro estados possíveis em que uma interface de túnel GRE existe:

1. Up/up - Isso significa que o túnel está totalmente funcional e transmite tráfego. Ele está administrativamente ativo e seu protocolo também.
2. Administratively down/down - Significa que a interface foi administrativamente desativada.
3. Ativo/inativo - Isso implica que, mesmo que o túnel esteja administrativamente ativo, algo faz com que o protocolo de linha na interface esteja inativo.
4. Reset/down (Redefinir/inativar): geralmente, este é um estado transitório quando o túnel é redefinido pelo software. Isso geralmente acontece quando o túnel está configurado incorretamente com um NHS (Next Hop Server, servidor de próximo salto) que é seu próprio endereço IP.

Quando uma interface de túnel é criada pela primeira vez e nenhuma outra configuração é aplicada a ela, a interface não é fechada por padrão:

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

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

Nesse estado, a interface está sempre ativa/inativa:

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

Isso ocorre porque a interface está habilitada administrativamente, mas como não tem uma origem de túnel ou um destino de túnel, o protocolo de linha está inativo.

Para tornar essa interface up/up, uma origem e um destino de túnel válidos devem ser configurados:

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      

A sequência anterior mostra que:

• Uma origem de túnel válida consiste em qualquer interface que esteja no estado up/up e tenha um endereço IP configurado nela.
• Por exemplo, se a origem do túnel fosse alterada para Loopback0, a interface do túnel ficaria inativa mesmo que Loopback0 estivesse no 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

• Um destino de túnel válido é aquele que é roteável. No entanto, ele não precisa estar acessível, o que pode ser visto neste teste 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)

Até agora, o túnel foi configurado como um túnel GRE ponto a ponto (P2P), que é o padrão.

Se esse túnel fosse alterado para um túnel GRE multiponto (mGRE), tudo o que é necessário para um estado ativado seria uma origem de túnel válida. 

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    

Em qualquer ponto, se a interface do túnel for administrativamente desativada, o túnel imediatamente entrará em um estado administrativamente desativado/desativado:

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 de túnel GRE P2P

Uma interface de túnel GRE P2P geralmente é ativada assim que é configurada com um endereço de origem de túnel válido ou uma interface que está ativa e um endereço IP de destino de túnel que é roteável (mostrado anteriormente).

Protocolo de linha desativado localmente no roteador

Em circunstâncias normais, há apenas três razões para um túnel GRE estar no estado up/down:  

• Não há rota, que inclui a rota padrão, para o endereço destino do túnel.
• A interface que ancora a origem do túnel está inoperante.
• A rota para o endereço destino do túnel é através do próprio túnel, o que resulta em recursão.

Estas três regras (missing, rota, interface inativa e destino de túnel mal roteado) são problemas locais do roteador nos pontos finais do túnel. 

Eles não cobrem problemas na rede de intervenção ou outros recursos relacionados ao túnel GRE que podem ser configurados. Este documento descreve cenários onde outros fatores podem influenciar o estado do túnel GRE.

Keepalives de túnel GRE

As regras básicas não cobrem o caso em que os pacotes em túnel GRE são encaminhados com êxito e ainda são perdidos antes de chegarem à outra extremidade do túnel.

Isso faz com que os pacotes de dados que passam pelo túnel GRE sejam perdidos, mesmo que uma rota alternativa que use PBR ou uma rota estática flutuante através de outra interface esteja potencialmente disponível.

Os keepalives na interface do túnel GRE são usados para resolver esse problema da mesma forma que os keepalives são usados nas interfaces físicas.

Com o Cisco IOS^® Software Release 12.2(8)T, é possível configurar keepalives em uma interface de túnel GRE P2P. Com essa alteração, a interface do túnel é desativada dinamicamente se os keepalives falharem por um determinado período. 

Para entender melhor como as manutenções de atividades de túnel GRE funcionam, consulte Manutenções de atividades de túnel GRE.

Observação: as manutenções de atividades de túnel GRE são válidas apenas e têm efeito nos túneis GRE P2P; elas não são válidas e não têm efeito nos túneis mGRE.

Túneis GRE com proteção de túnel

No Cisco IOS^® Software Releases 15.4(3)M/15.4(3)S e posteriores, o estado do protocolo de linha de túnel GRE segue o estado da Associação de Segurança (SA) IPsec. Portanto, o protocolo de linha pode permanecer inativo até que a sessão IPsec seja totalmente estabelecida.

Isso foi confirmado com o bug da Cisco ID CSCum34057 (tentativa inicial com o bug da Cisco ID CSCuj29996 e depois foi retirado com o bug da Cisco ID CSCuj99287).

Interfaces de túnel multiponto GRE (mGRE)

Para interfaces de túnel mGRE, algumas das verificações anteriores para túneis P2P não são aplicáveis (porque não há nenhum destino de túnel fixo).

Aqui estão os motivos pelos quais um protocolo de linha de túnel mGRE pode estar em um estado inativo:

• A interface origem do túnel está em um estado inativo.
• Se o recurso Controle de estado da interface estiver habilitado para DMVPN (Dynamic Multipoint VPN) e nenhum NHS responder, o protocolo de linha será colocado em um estado inativo.
• Para obter detalhes sobre o recurso Controle de estado da interface, consulte o Guia de monitoramento de integridade e configuração de recuperação de túnel DMVPN.

Dependências do Estado de Redundância

Quando um endereço IP origem do túnel é configurado como um endereço IP de redundância (por exemplo, um endereço IP virtual do protocolo de roteador de hot standby (HSRP VIP)), o estado da interface do túnel rastreia o estado de redundância.

Isso adiciona outra verificação que mantém essas interfaces de túnel no estado inativo do protocolo de linha até que o estado de redundância mude para ATIVO.

Neste exemplo, uma configuração ipc zone default mal configurada faz com que a redundância esteja no estado NEGOTIATION e mantém essas interfaces de túnel em um estado down:

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

Além dos motivos descritos anteriormente, a avaliação do estado da linha do túnel para a razão de inatividade do túnel pode ser vista com o 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] 

Observação: há um aprimoramento aberto para tornar a razão de inatividade do túnel mais explícita, a fim de indicar que ela se deve ao estado de redundância porque não está ativa. Isso é rastreado pelo bug da Cisco ID CSCuq31060.

Informações Relacionadas

• RFC 1701, Encapsulamento de roteador genérico (GRE)
• RFC 2890, extensões de números de sequência e chave para GRE
• Manutenção de atividade do túnel do Generic Routing Encapsulation (GRE)
• Fragmentação de IP e PMTUD
• Suporte Técnico e Documentação - Cisco Systems