Um túnel GRE que sobe mas ainda assim não deixa dois sites fazerem Ping um no outro pelo endereço do túnel é um dos chamados de VPN mais comuns na fase inicial. Esta é a ordem que encontra a falha mais rápido — o encapsulamento antes do roteamento, os comandos display exatos para cada etapa, as verificações que só importam depois que a interface já está ativa, e os casos reais de configuração incorreta por trás disso.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
O instinto é começar imediatamente a fazer Ping e rastrear rotas — mas em um túnel GRE, boa parte das falhas de Ping nem chega a esse ponto: os dois lados ainda nem estão falando o mesmo encapsulamento.
Uma interface Up não significa que o túnel está saudável, e uma configuração que parece correta nos dois lados não significa que os dois sites realmente conseguem alcançar o endereço IP da interface Tunnel um do outro. A ordem que encontra a falha mais rápido é: confirmar que os dois lados usam o mesmo encapsulamento, confirmar que o endereçamento do túnel está espelhado e completo, confirmar que existe uma rota entre os dois endereços físicos de origem/destino, e só depois que a interface em si estiver realmente Up, verificar a Chave GRE e a rota para o endereço da interface Tunnel do peer especificamente.
A seguir está a ordem de diagnóstico na qual isto se baseia, tirada do próprio modelo de classificação de falhas de GRE do roteador Huawei AR, as verificações e comandos display para cada etapa, um caso de configuração incorreta documentado, e um conjunto de respostas de perguntas frequentes tiradas do mesmo material de manutenção. Se o túnel por baixo disso for protegido por IPSec, «O túnel VPN IPSec não sobe?» cobre a camada de negociação; se for um desenho dinâmico em estrela em vez de um túnel ponto a ponto fixo, «DSVPN over IPSec entre filiais Huawei e um hub Cisco» cobre diretamente essa variante.
As falhas de Ping em GRE se dividem em três formas: a própria interface Tunnel nunca sobe, ela está Up mas os dois lados ainda não conseguem fazer Ping um no Tunnel IP do outro, ou ela está Up e o Ping funciona mas o link está instável ou lento.
Colocar primeiro o sintoma nesta árvore indica qual das etapas abaixo realmente se aplica — e, de forma mais útil, se você já está diante de um problema de roteamento.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Quase todas as verificações do ramo esquerdo são uma simples incompatibilidade de configuração que precisa coincidir, campo a campo, nos dois lados. O ramo do meio é o que resta quando a própria interface já está saudável, mas os dois endereços Tunnel IP ainda não se alcançam; o ramo direito é um problema de desenho de roteamento, não um erro de configuração do túnel.
Quatro pontos de verificação, cada um com seu próprio comando display — a árvore de falhas acima indica por qual começar.
Se o protocolo de camada de rede da interface Tunnel simplesmente não sobe, não mexa no roteamento ainda — o encapsulamento é a primeira coisa que precisa coincidir.
[Huawei-Tunnel0/0/0] display this
[V200R009C00SPC300]
#
interface Tunnel0/0/0
ip address 172.16.1.1 255.255.255.252
tunnel-protocol gre
source GigabitEthernet1/0/0
destination 1.1.1.2
#
return
// tunnel-protocol gre confirms the actual encapsulation in use
// source/destination on this end must mirror the peer's destination/sourceEncapsulamento e endereçamento corretos ainda assim não farão a interface subir se os dois extremos físicos não conseguirem realmente se alcançar.
<Huawei> display ip routing-table
<Huawei> display fib
// confirm the FIB table agrees with the routing table before assuming
// the tunnel itself is the problem rather than the transport network below itÉ aqui que mora um segundo par de verificações menos óbvio: a Chave GRE, e uma rota especificamente para o endereço da interface Tunnel do peer — não apenas para o seu endereço físico.
Dois sintomas de aparência muito diferente remontam à mesma causa raiz: a rota para o próprio endereço de destino do túnel aponta para o tipo errado de interface de saída.
<Huawei> ping -s packetsize -a source-ip-address host
// increase packetsize until loss appears -- that breakpoint sets the working MTU
[Huawei-Tunnel0/0/0] mtu mtu-value
[Huawei-Tunnel0/0/0] tcp adjust-mss valueDepois que as etapas acima indicarem onde está o problema, essas seis causas explicam a maior parte do que realmente está errado.
SINTOMAO protocolo de camada de rede da interface Tunnel nunca sobe, não importa o quão correto pareça o resto da interface.
CAUSAtunnel-protocol precisa ser idêntico nos dois lados; display this em cada lado é a única forma confiável de ver o que realmente está configurado, porque um tipo de encapsulamento incompatível é, de outra forma, completamente silencioso — sem log, sem mensagem de erro.
SOLUÇÃOReconfigure tunnel-protocol gre no lado que estiver errado; como isso apaga o source e o destination existentes, reinsira-os imediatamente depois.
[Huawei-Tunnel0/0/0] tunnel-protocol gre
[Huawei-Tunnel0/0/0] source GigabitEthernet1/0/0
[Huawei-Tunnel0/0/0] destination 1.1.1.2SINTOMAOs dois lados parecem totalmente configurados, individualmente, mas a interface Tunnel nunca sobe.
CAUSAO par source/destination identifica um único túnel; se o destination deste lado não for o source do peer (e vice-versa), os dois lados estão tecnicamente construindo, cada um, um túnel diferente que nunca se encontra com o outro.
SOLUÇÃOLeia display this nos dois lados lado a lado e confirme explicitamente o espelhamento — não confie apenas que quem configurou o outro lado acertou.
SINTOMAA interface Tunnel está Up nos dois lados, o encapsulamento e o endereçamento estão corretos, mas os dois lados ainda não conseguem fazer Ping um no Tunnel IP do outro.
CAUSAgre key é opcional, mas se qualquer um dos lados a configurar, os dois precisam carregar o mesmo valor — uma Chave definida em um lado e não definida (ou definida de forma diferente) no outro impede que o túnel realmente passe tráfego, mesmo que o estado da interface pareça perfeitamente saudável.
SOLUÇÃOConfigure o mesmo valor de gre key nos dois lados, ou remova-a dos dois — nunca a deixe configurada em apenas um lado.
SINTOMAOs endereços físicos de origem e destino são alcançáveis e a interface está Up, mas um Ping para o Tunnel IP do peer ainda falha.
CAUSAUm túnel estar Up só confirma que a camada física subjacente é alcançável — alcançar o endereço lógico da interface Tunnel do peer é uma questão de roteamento separada, resolvida pelo protocolo de roteamento que roda sobre o túnel, não algo que o próprio estado Up do túnel implique automaticamente.
SOLUÇÃOConfirme que existe uma rota para o Tunnel IP do peer — via um protocolo de roteamento rodando sobre o túnel (o GRE suporta roteamento estático, OSPF, IS-IS, RIP e BGP), ou uma rota estática — antes de assumir que o próprio túnel está quebrado.
SINTOMAO Ping funciona bem, mas a interface Tunnel oscila Up/Down repetidamente, ou o desempenho está inesperadamente ruim, sem mais nada visivelmente errado.
CAUSASe a rota para o próprio endereço de destino do túnel se resolver com a própria interface Tunnel GRE como interface de saída, o túnel depende de si mesmo para se manter Up — uma causa documentada de oscilação. Separadamente, uma rota de destino cuja interface de saída é uma interface VLANIF é uma causa documentada de baixo desempenho.
SOLUÇÃOVerifique com display ip routing-table especificamente a interface de saída do endereço de destino; se for o próprio túnel, replaneje o roteamento subjacente para que o destino seja alcançado por uma interface física real, não o túnel que depende dele.
SINTOMAEm uma implantação GRE over IPSec, o tráfego estava passando pelo túnel, o túnel oscilou para Down e o tráfego migrou para o NAT, e quando o túnel voltou a ficar Up, o tráfego permaneceu no NAT em vez de retornar a ele.
CAUSAEste é um caso real documentado. Uma vez que o tráfego migrou para uma sessão NAT, essa entrada da tabela de sessões NAT tem prioridade maior que a tabela de rotas — então mesmo depois que o túnel GRE volta a ficar Up e a tabela de rotas apontaria corretamente o tráfego para ele, a sessão NAT existente continua prevalecendo.
SOLUÇÃOLimpe a tabela de sessões NAT para que o tráfego se resolva novamente contra a tabela de rotas agora correta e retorne ao túnel; não assuma que "túnel Up" sozinho significa que o tráfego realmente voltou para ele.
<RouterA> system-view
[RouterA] reset nat session all
Warning:The current all NAT sessions will be deleted.
Are you sure to continue?[Y/N]YTiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Em ordem de frequência: incompatibilidade de encapsulamento entre os dois lados; endereço IP, source ou destination não configurados, ou não espelhados entre os dois lados; Chave GRE configurada de forma inconsistente; falta de rota entre os endereços físicos de origem e destino; uma configuração de Keepalive em que os contadores de envio/recebimento não batem; valores de MTU incompatíveis entre os dois lados; e um valor de TCP MSS de interface definido alto o suficiente para que o quadro mais a sobrecarga ultrapasse o MTU.
Duas coisas especificamente: uma incompatibilidade na Chave GRE (configurada em um lado e não no outro, ou configurada com valores diferentes), e uma rota ausente para o próprio endereço da interface Tunnel do peer — a alcançabilidade entre os endereços físicos de origem e destino não gera automaticamente uma rota para o Tunnel IP lógico por cima dela.
Nada necessariamente mudou na configuração do próprio túnel. Verifique se a interface de saída da rota de destino é o próprio túnel — essa é uma causa documentada de oscilação por roteamento recursivo — ou uma interface VLANIF, que é uma causa documentada de baixo desempenho. Ambos são problemas de desenho de rede a serem replanejados, não erros de configuração do túnel a serem corrigidos.
Sim — o GRE suporta roteamento estático, OSPF, IS-IS, RIP e BGP sobre o túnel, e pode carregar protocolos multicast incluindo PIM. Essa é uma razão pela qual o GRE over IPSec existe: um túnel IPSec puro só protege tráfego unicast, então qualquer multicast que precise de criptografia é encapsulado primeiro em GRE, e o IPSec então protege o próprio túnel GRE.
Duas razões comuns: um túnel IPSec sozinho só protege tráfego unicast, então qualquer multicast que também precise de criptografia — chamada de voz, alguns protocolos de roteamento — precisa ser encapsulado em GRE primeiro e entregue ao IPSec depois; e o GRE dá a você uma interface lógica real para rodar um protocolo de roteamento dinâmico, algo que uma política IPSec pura não fornece por si só. Veja «DSVPN over IPSec entre filiais Huawei e um hub Cisco» para um exemplo prático exatamente dessa combinação.
Sim — um MTU configurado na interface Tunnel GRE se aplica ao tráfego encaminhado por esse túnel; qualquer coisa maior que o valor configurado é fragmentada antes de ser enviada. Esse é exatamente o mecanismo em que se baseia o teste ping -s da Etapa 3 acima.
Esta nota se baseia no modelo de classificação de falhas de GRE do roteador Huawei série AR — display this, display ip routing-table, display fib — e nos casos de campo por trás deles, tirados da mesma documentação de manutenção. Ela assume um túnel GRE estático ponto a ponto, não a variante mGRE dinâmica do DSVPN nem uma implantação GRE over IPSec totalmente desenvolvida. Para a negociação IPSec sobreposta a um túnel como este, veja «O túnel VPN IPSec não sobe?»; para o caso multiponto dinâmico, veja «DSVPN over IPSec entre filiais Huawei e um hub Cisco».
Conte-nos se a própria interface Tunnel está Up, junto com a saída de display this dos dois lados, e ajudamos você a interpretá-la.