Este documento descreve as diferentes condições que podem afetar o estado de uma interface de túnel GRE (Generic Routing Encapsulation).
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>'.
Há quatro estados possíveis nos quais uma interface de túnel GRE pode ser:
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:
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
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
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.
Em circunstâncias normais, há apenas três razões para um túnel GRE estar no estado up/down:
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.
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.
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).
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:
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>
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.