Uma interface de túnel GRE travada em estado Down é uma lista de verificação curta e mecânica, não um mistério — modo de encapsulamento, endereçamento de origem/destino, chave GRE, a rota até a outra ponta, e a configuração de keepalive, verificados nessa ordem. Esta é a sequência de diagnóstico, os comandos exatos para cada verificação, e o teste prático de tamanho de ping que encontra um teto silencioso de MTU/fragmentação antes que ele derrube um túnel sob carga.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
Sete itens de configuração decidem se uma interface de túnel GRE sobe — e a falha quase sempre se resume exatamente a um deles.
Uma interface de túnel GRE reportando Down é um dos trabalhos de solução de problemas mais mecânicos em roteamento — o modelo de classificação de falhas por trás disso lista sete itens específicos a verificar, em ordem: modo de encapsulamento, endereçamento IP, atribuição de origem/destino, chave GRE, a rota subjacente até o destino, configuração de keepalive, e dimensionamento de MTU/MSS. Quase todo chamado de "o túnel simplesmente não sobe" se resolve em um item dessa lista.
Isso é deliberadamente diferente de um túnel que já está Up mas não deixa o tráfego passar corretamente — isso é um problema de roteamento ou de detalhe de encapsulamento em um túnel que já existe, e cobrimos isso separadamente em nossa nota sobre um túnel VPN ativo mas com falha no ping. O que se segue aqui é o que verificar antes mesmo de a interface do túnel reportar Up, além do método prático de campo — testar com diferentes tamanhos de ping — para encontrar um teto de MTU/fragmentação que uma simples leitura de configuração nunca revelará.
Os problemas de GRE se dividem como a maioria dos problemas de túnel: a interface nunca sobe, ou sobe e algo a jusante ainda está errado.
Colocar primeiro o sintoma nesta árvore indica se você está diante de um problema de estabelecimento — esta nota — ou de um problema de roteamento/encapsulamento em um túnel que já existe, o que pertence a um caminho de diagnóstico completamente diferente.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Tudo no ramo esquerdo é lido diretamente da própria configuração e contadores da interface do túnel — display this, display ip routing-table, display keepalive packets count. Uma vez que a interface reporta Up, um diagnóstico diferente se aplica, e isso pertence ao território da nota complementar, não desta.
Quatro verificações na ordem de que a própria interface do túnel depende, mais o teste de campo para o único modo de falha que uma leitura de configuração não consegue detectar.
display this na interface do túnel captura a maior parte do que realmente impede um túnel GRE de subir.
[HUAWEI-Tunnel0] display this
#
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel-protocol gre
source 10GE0/0/0
destination 1.1.1.2
#
return
// confirm the peer's source/destination are the exact mirror of these two linesO endereço de destino do túnel precisa ser alcançável através de uma rota que não seja o próprio túnel — esta é a armadilha de roteamento recursivo mais comum.
<Huawei> display ip routing-table
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.2/32 Static 60 0 20.1.1.2 GigabitEthernet0/0/1
// outbound interface is the physical uplink, not Tunnel0 -- this is correct
<Huawei> display ip interface brief
Interface IP Address/Mask Physical Protocol
Tunnel0 172.16.1.1/30 up upO Keepalive do GRE só informa sobre a direção em que foi habilitado — um túnel pode parecer morto de um lado e bem do outro.
# This platform's Tunnel interface
interface Tunnel1
tunnel-protocol gre
keepalive period 10 // Cisco's minimum configurable period is 10s
source 2.2.2.2
destination 1.1.1.1
# Cisco's Tunnel interface (defaults to GRE already)
interface Tunnel1
keepalive 10 3
tunnel source Loopback0
tunnel destination 2.2.2.2
<Huawei> display keepalive packets count
Keepalive sent: 120 Reply received: 118
// sent greater than reply received -> packets lost toward the peer or on the way backEste é um teste prático, não uma verificação de configuração — execute-o sempre que o túnel subir bem mas cair sob tráfego real, ou não se manter estável sob carga.
<Huawei> ping -s 1400 -a 172.16.1.1 172.16.1.2
Request time out
<Huawei> ping -s 1350 -a 172.16.1.1 172.16.1.2
Reply from 172.16.1.2: bytes=1350 time=2 ms
// breakpoint found between 1350 and 1400 -- set the tunnel MTU at or below it
[HUAWEI-Tunnel0] mtu 1350
[HUAWEI-GigabitEthernet0/0/1] tcp adjust-mss 1300
// leave headroom under the tunnel MTU for GRE + IP + TCP header overheadDepois que as verificações acima indicarem onde está o problema, estas cinco causas cobrem a maior parte do que realmente está errado.
SINTOMAdisplay this na interface Tunnel mostra o que parece ser uma configuração completa em ambas as pontas, mas o estado da interface permanece Down.
CAUSAO destino deste lado tem que ser a origem do par, e vice-versa, e o tunnel-protocol de ambas as pontas tem que coincidir exatamente — basta um único campo configurado com o endereço errado, ou um protocolo deixado em um modo diferente, e isso não produz nenhum erro específico em lugar algum.
SOLUÇÃOLeia display this lado a lado em ambas as interfaces de túnel e confirme que origem/destino são espelhos exatos e que tunnel-protocol gre coincide em ambas as pontas.
interface Tunnel0
ip address 172.16.1.1 255.255.255.252
tunnel-protocol gre
source 10GE0/0/0
destination 1.1.1.2
// peer's tunnel interface must show source 1.1.1.2 / destination (this end's source)SINTOMATudo na configuração do túnel parece correto, mas a interface nunca chega a Up e não há nada nos logs apontando o motivo.
CAUSAgre key é um simples valor compartilhado que ambas as pontas devem configurar de forma idêntica; uma incompatibilidade faz com que a ponta receptora descarte silenciosamente os pacotes encapsulados em GRE da ponta remota, como se nunca tivessem chegado.
SOLUÇÃOConfirme que exatamente o mesmo valor de gre key está configurado em ambas as interfaces de túnel — não há tolerância para correspondência parcial.
SINTOMAA interface do túnel sobe, depois cai, depois volta — repetidamente — sem nenhum problema óbvio de link ou hardware.
CAUSAOu não existe nenhuma rota até o endereço de destino do túnel, ou a rota existente aponta de volta para a própria interface do túnel (um loop de roteamento), ou um protocolo de roteamento dinâmico rodando sobre o túnel está reanunciando inadvertidamente a própria rota do destino de volta através dele.
SOLUÇÃOConfirme com display ip routing-table que a interface de saída da rota de destino é a interface física ou lógica correta, não o túnel; quando necessário, fixe-a com uma rota estática /32 de prioridade mais alta.
SINTOMAUma ponta declara o túnel down; a outra ponta não mostra nenhum problema.
CAUSAO Keepalive do GRE só monitora a direção para a qual está configurado — o Keepalive deste lado não exige nem reflete nada sobre o próprio estado de Keepalive do par, então uma configuração unilateral produz um sintoma unilateral e confuso.
SOLUÇÃOHabilite o Keepalive com o mesmo período/número de tentativas em ambas as pontas se quiser monitorar ambas as direções, e leia display keepalive packets count em cada ponta separadamente em vez de assumir que a visão de uma ponta descreve todo o quadro.
SINTOMAA própria interface do túnel reporta Up e o Keepalive está saudável, mas o tráfego real — especialmente TCP — degrada ou trava intermitentemente conforme os tamanhos de pacote crescem.
CAUSAA própria sobrecarga de encapsulamento do GRE empurra o tamanho de carga útil efetivo para abaixo do MTU da interface física; quando o MTU do túnel configurado (e o tcp adjust-mss) não consideram essa sobrecarga, pacotes maiores são silenciosamente fragmentados, descartados ou somem dependendo do caminho, e nada disso aparece como um evento de túnel caído.
SOLUÇÃOExecute o teste de varredura de tamanho ping -s / -a para encontrar o ponto de quebra real, depois configure o mtu do túnel e o tcp adjust-mss da interface em valores que deixem margem para a sobrecarga do GRE.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Sim — é aplicado ao tráfego encaminhado através do túnel. Qualquer pacote maior que o MTU do túnel configurado é fragmentado antes de ser encapsulado, então esse é exatamente o valor a ajustar depois que o teste de tamanho de ping encontrar seu ponto de quebra real.
A interface Tunnel da Cisco já usa encapsulamento GRE por padrão, então tunnel-protocol geralmente não é a incompatibilidade. O que costuma confundir: o período mínimo configurável de Keepalive na Cisco costuma ser de 10 segundos, maior que o padrão de 5 segundos desta plataforma — configure ambas as pontas com o mesmo valor explícito em vez de deixar os padrões, e lembre-se de que o suporte a Keepalive no par não tem relação com o funcionamento do Keepalive do seu próprio lado.
Em hardware Cisco mais antigo, o tráfego da interface Tunnel pode ser encaminhado por CPU em vez de por hardware; sob carga pesada, o processo de CPU que o trata (visível em show processes cpu como um processo consumindo uma parcela desproporcional) pode privar os próprios pacotes de Keepalive, e falhas de Keepalive derrubam o túnel. Remover o Keepalive em ambas as pontas como uma etapa de diagnóstico — não como correção permanente — confirmará isso: se o túnel permanecer estável com o Keepalive desligado, o volume de tráfego, não uma falha real de link, foi a causa.
Esta nota trata inteiramente da falha da própria interface do túnel em chegar a Up — protocolo, endereçamento, chave, rota e keepalive. Um túnel que reporta Up mas não deixa o ping passar corretamente é um problema a jusante — geralmente uma incompatibilidade de roteamento ou de detalhe de encapsulamento em um túnel que tecnicamente já existe — e esse é um caminho de diagnóstico completamente diferente, coberto em nossa nota complementar sobre um túnel VPN ativo mas com falha no ping.
Isso quase sempre é o caso de MTU/fragmentação, não um problema de rota ou Keepalive — pequenos pacotes de controle e tráfego de teste de baixo volume podem atravessar o túnel bem, enquanto o tráfego real maior esbarra na sobrecarga de encapsulamento do GRE e começa a fragmentar ou se perder. Execute o teste de varredura de tamanho de ping em condições que se aproximem do tamanho do tráfego real, não apenas um ping de tamanho padrão.
Na prática, qualquer um deles — o GRE é agnóstico quanto ao protocolo na camada de túnel, então OSPF, IS-IS, BGP e RIP funcionam todos sobre uma interface de túnel GRE exatamente como funcionariam sobre uma física, junto com os protocolos multicast comuns. O próprio túnel não entende nem filtra o que carrega dentro.
Esta nota se baseia no modelo de classificação de falhas de GRE do roteador Huawei série AR e seus comandos display this / display ip routing-table / display keepalive packets count, além dos casos de campo e notas multifabricante por trás deles. Se o seu equipamento for de outro fabricante, os comandos exatos mudam, mas a lista de verificação subjacente — modo de protocolo, endereçamento, chave, rota, direção do keepalive, MTU — se aplica diretamente. Não cobre em profundidade o GRE rodando dentro de um túnel IPSec, nem os limites de desempenho do encaminhamento multicast sobre GRE.
Conte-nos qual das sete verificações — protocolo, endereço, chave, rota, keepalive, ou MTU — você já descartou, junto com sua saída de display this, e ajudamos você a interpretar o resto.