Contents

Introduction

Informações de Apoio

Quatro estados de túnel diferentes

Estado de túnel GRE P2P

Protocolo de linha desativado localmente no roteador

Keepalives de túnel GRE

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

Interfaces de túnel multiponto GRE (mGRE)

Dependências do Estado de Redundância

Troubleshoot

Informações Relacionadas

Introduction

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 disso é que, por padrão, o roteador de ponto final de túnel local não tem a capacidade de desativar o protocolo de linha da interface de túnel GRE se a extremidade remota do túnel estiver inacessível. A capacidade de marcar uma interface como inativa quando a extremidade remota do link não está disponível é usada para remover quaisquer rotas (especificamente rotas estáticas) na tabela de roteamento que usa 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 apontam essa interface serão removidas 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. Também 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 nos quais uma interface de túnel GRE pode ser:

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): esse é geralmente 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 que o túnel esteja em um estado ativado seria uma origem de túnel válida (um túnel mGRE pode ter muitos destinos de túnel, de modo que não pode ser usado para controlar o estado da interface do 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

Em qualquer ponto, se a interface do túnel for administrativamente desativada, o túnel imediatamente entra 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 como mostrado na seção anterior.

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 e 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, mas 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 "black holed", 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 de túnel será desativada dinamicamente se os keepalives falharem por um determinado período. Para entender melhor como os keepalives de túnel GRE funcionam, consulte Keepalives de Túnel GRE.

Note: As manutenções de atividades de túnel GRE são válidas apenas e têm efeito em túneis GRE P2P; eles não são válidos e não têm nenhum efeito nos túneis mGRE.

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

Nos Cisco IOS Software Releases 15.4(3)M/15.4(3)S e posteriores, o estado do protocolo de linha de túnel GRE pode seguir o estado da Associação de Segurança (SA) IPsec, de modo que 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, como não há nenhum destino de túnel fixo, algumas das verificações anteriores para túneis P2P não são aplicáveis. 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 dos NHSs 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 adicionou uma verificação adicional, 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>

Troubleshoot

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 como mostrado aqui:

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]

Note: 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