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:
- Up/up - Isso significa que o túnel está totalmente funcional e transmite tráfego. Ele está administrativamente ativo e seu protocolo também.
- Administratively down/down - Significa que a interface foi administrativamente desativada.
- 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.
- 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.
Observação: 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 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.
Essas três regras (missing, rota, interface inoperante e destino de túnel roteado incorretamente) 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:
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