Aula 17: GRE Tunnels — criando túneis de rede no Cisco IOS

Bem-vindo à Aula 17 do nosso curso Cisco IOS — Do Zero ao Avançado. Hoje vamos mergulhar em um dos mecanismos mais versáteis e amplamente utilizados na interconexão de redes: os GRE Tunnels (Generic Routing Encapsulation). Se você já precisou conectar duas filiais através da internet mantendo a transparência de protocolos, ou estender uma VLAN sobre uma WAN, ou ainda estabelecer a base para uma VPN segura com IPsec, os túneis GRE são a resposta. Nesta aula, você vai entender a fundo como eles funcionam, como configurá-los do zero e como solucionar os problemas mais comuns que encontramos no dia a dia.

Em nossos projetos na JRT Technology Solutions, utilizamos GRE Tunnels diariamente para integrar datacenters, conectar ambientes legados que dependem de broadcast e multicast, e como fundação para túneis criptografados em cenários de alta disponibilidade. A beleza do GRE está na sua simplicidade: ele encapsula praticamente qualquer protocolo da camada 3 dentro de um pacote IP, criando um enlace virtual ponto a ponto que o IOS trata como uma interface lógica comum. Isso significa que você pode rotear, aplicar ACLs, configurar QoS e até rodar protocolos de roteamento dinâmico sobre ele.

Ao final desta aula, você terá habilidades práticas para projetar, implementar e diagnosticar GRE Tunnels em equipamentos Cisco. Vamos construir dois cenários reais: um túnel simples entre dois roteadores e um túnel com keepalive e roteamento OSPF. Abordaremos a configuração completa de cada lado, a verificação com comandos show e debug, e as armadilhas clássicas que podem transformar uma tarde produtiva em horas de troubleshooting. Prepare seu terminal, seu GNS3 ou EVE-NG, e vamos lá.

O que você vai aprender nesta aula

• Compreender o encapsulamento GRE e sua diferença em relação a outros tipos de túnel (IP-in-IP, IPsec).
• Configurar GRE Tunnels ponto a ponto entre dois roteadores Cisco IOS.
• Atribuir endereçamento IP à interface de túnel e integrá-la à tabela de roteamento.
• Habilitar keepalives para detecção de falhas no túnel.
• Transportar tráfego de roteamento dinâmico (OSPF) sobre o túnel GRE.
• Verificar o estado do túnel com comandos show interfaces tunnel, show ip route e debug tunnel.
• Diagnosticar e corrigir os 4 erros mais comuns em GRE Tunnels.
• Aplicar boas práticas de MTU, MSS e segurança ao implementar túneis em produção.

Pré-requisitos e Ambiente

Antes de iniciar esta aula, certifique-se de que você possui:

• Cisco IOS versão 12.4 ou superior (recomendado 15.x ou IOS-XE) em dois roteadores com conectividade IP entre si.
• Acesso ao modo EXEC privilegiado e modo de configuração global em ambos os roteadores.
• Conhecimento sólido de roteamento IP estático e configuração básica de interfaces (Aulas 5 a 8 do curso).
• Um ambiente de laboratório funcional: GNS3, EVE-NG ou equipamento físico com pelo menos duas interfaces de rede.
• Conceitos de sub-redes e máscaras de tamanho variável (VLSM) frescos na memória.
• Endereços IP públicos (simulados) para as interfaces físicas de saída dos roteadores.

Nosso cenário de laboratório será o seguinte: R1 (matriz) com IP público 200.1.1.1/30 e rede local 192.168.1.0/24; R2 (filial) com IP público 200.2.2.2/30 e rede local 192.168.2.0/24. O túnel GRE interligará as redes locais usando a faixa 10.0.0.0/30. Ambos os roteadores devem ter rota para o IP público do outro — neste laboratório, usaremos rotas estáticas para alcançar a internet simulada.

O que são GRE Tunnels? — Conceitos Fundamentais

O protocolo GRE (Generic Routing Encapsulation), definido originalmente na RFC 1701 e depois atualizado na RFC 2784, é um mecanismo de tunelamento que permite encapsular uma grande variedade de protocolos de rede dentro de pacotes IP. Diferente de um túnel IP-in-IP simples (protocolo IP 4), o GRE utiliza o protocolo IP 47 em seu cabeçalho externo. Isso é uma distinção crítica: muitos firewalls e ACLs são configurados para permitir apenas TCP, UDP e ICMP, e acabam bloqueando o protocolo 47, impedindo o funcionamento do túnel. Na JRT Technology Solutions, sempre reforçamos a verificação do protocolo 47 nas políticas de firewall ao implantar GRE Tunnels.

A grande vantagem do GRE é sua capacidade de encapsular praticamente qualquer payload: IPv4, IPv6, MPLS, AppleTalk, IPX, e até mesmo quadros Ethernet (no caso do NVGRE, uma variação para virtualização). No escopo do Cisco IOS, o uso mais comum é transportar tráfego IPv4 multicast e broadcast — algo que um túnel IPsec puro não consegue fazer sem auxílio. É exatamente por isso que protocolos de roteamento como OSPF, EIGRP e RIP funcionam perfeitamente sobre GRE Tunnels: o multicast necessário para as adjacências é encapsulado como unicast no pacote externo GRE, atravessando a rede intermediária como se fosse tráfego comum.

Outra característica essencial é que o GRE, por si só, não oferece criptografia. O payload é encapsulado, mas transmitido em texto claro. Se você precisa de confidencialidade, o caminho natural é combinar GRE com IPsec — o chamado GRE over IPsec, que será abordado em uma aula futura. Por ora, foque no GRE puro: ele cria uma interface lógica de túnel, com estado up/down, MTU própria e capacidade de receber endereço IP, exatamente como uma interface física. Isso é poderoso porque abstrai toda a complexidade da rede intermediária (a internet) para os protocolos que rodam sobre o túnel.

Anatomia de um túnel GRE no Cisco IOS

Antes de partir para os comandos, é fundamental entender como o IOS representa um GRE Tunnel internamente. Quando você cria uma interface tunnel, o roteador aloca uma estrutura lógica que possui:

• Tunnel source: o endereço IP local de onde o encapsulamento se origina. Pode ser uma interface física, um loopback ou um IP explícito.
• Tunnel destination: o endereço IP remoto para onde os pacotes GRE são enviados.
• Tunnel mode: o modo padrão é gre ip, que encapsula IPv4 sobre GRE. Existem variantes como gre ipv6, gre multipoint (mGRE) e outras.
• MTU: por padrão, a interface de túnel herda a MTU da interface física de origem, mas com os 24 bytes adicionais do overhead GRE (20 IP externo + 4 GRE), o payload efetivo pode exceder a MTU do enlace físico, causando fragmentação.
• Keepalive: um mecanismo opcional que envia pacotes periódicos pelo túnel para verificar se o destino remoto está alcançável.

Veja o formato do cabeçalho GRE em comparação com um pacote IP normal:

Esse overhead de até 24 bytes (20 IP + 4 GRE) é o motivo pelo qual a MTU do túnel é tão importante. Se suas interfaces físicas têm MTU 1500, o túnel GRE efetivo terá 1476 bytes disponíveis para o payload sem fragmentação. Ignorar isso causa problemas intermitentes que afligem até administradores experientes. Em nossos projetos na JRT Technology Solutions, sempre ajustamos a MTU do túnel para 1400 bytes como margem de segurança quando o túnel atravessa a internet.

Configurando GRE Tunnels — Passo a Passo Completo

Vamos construir o primeiro túnel GRE do nosso laboratório. Nosso cenário: R1 (200.1.1.1) e R2 (200.2.2.2) estão se comunicando via rede WAN simulada (200.1.1.0/30 e 200.2.2.0/30). Já existe roteamento IP funcional entre eles — ou seja, R1 consegue pingar 200.2.2.2 e vice-versa. Sem essa conectividade básica, o túnel não sobe. Vamos garantir isso primeiro.

Laboratório — Topologia:

Passo 1: Conectividade IP entre os endpoints do túnel (pré-requisito). No R1, configure a interface WAN e a rota para alcançar o IP público do R2. No R2, faça o correspondente.

Configuração em R1:

! Acesse o modo privilegiado e entre em configuração global
enable
configure terminal

! Configure a interface WAN com o IP público
interface GigabitEthernet0/0
 description LINK_WAN_R1
 ip address 200.1.1.1 255.255.255.252
 no shutdown
!
! Configure a interface LAN local
interface GigabitEthernet0/1
 description LAN_MATRIZ
 ip address 192.168.1.1 255.255.255.0
 no shutdown
!
! Rota estática para alcançar o IP público do R2 via next-hop da WAN
! Considere que o outro lado da WAN é 200.1.1.2 (provedor) que tem rota para 200.2.2.0
ip route 200.2.2.0 255.255.255.252 200.1.1.2
!

Configuração em R2:

enable
configure terminal

interface GigabitEthernet0/0
 description LINK_WAN_R2
 ip address 200.2.2.2 255.255.255.252
 no shutdown
!
interface GigabitEthernet0/1
 description LAN_FILIAL
 ip address 192.168.2.1 255.255.255.0
 no shutdown
!
ip route 200.1.1.0 255.255.255.252 200.2.2.1
!

Verifique a conectividade: no R1, execute ping 200.2.2.2 source 200.1.1.1. A resposta deve ser bem-sucedida. Se falhar, revise as rotas e o IP do next-hop (aqui assumimos que o IP do provedor no enlace de R1 é 200.1.1.2 e no de R2 é 200.2.2.1 — em laboratório GNS3, você pode conectar diretamente com uma nuvem ou switch e usar /30).

R1# ping 200.2.2.2 source 200.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 200.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Passo 2: Criar a interface de túnel no R1. A interface tunnel é lógica e só aparece no running-config após ser criada. Vamos configurá-la com o IP do túnel, definir a origem e o destino, e ativar o keepalive.

! No R1, crie a interface Tunnel0
R1(config)# interface Tunnel0

! Descrição para documentação (boa prática)
R1(config-if)# description TUNEL_GRE_PARA_R2

! IP da interface de túnel — será o gateway para a rede 10.0.0.0/30
R1(config-if)# ip address 10.0.0.1 255.255.255.252

! Origem do túnel: IP da interface WAN de R1
R1(config-if)# tunnel source 200.1.1.1

! Destino do túnel: IP da interface WAN de R2
R1(config-if)# tunnel destination 200.2.2.2

! Modo do túnel — opcional, pois gre ip é o padrão
R1(config-if)# tunnel mode gre ip

! Ajuste de MTU para evitar fragmentação (recomendado 1400)
R1(config-if)# ip mtu 1400

! Ajuste de MSS para TCP (opcional, mas evita problemas)
R1(config-if)# ip tcp adjust-mss 1360

! Keepalive: envia pacotes a cada 5 segundos, 3 falhas derruba o túnel
R1(config-if)# keepalive 5 3

! Ativar a interface
R1(config-if)# no shutdown
R1(config-if)# end

Passo 3: Criar a interface de túnel no R2 (mesmo processo, invertendo source e destination).

! No R2, crie a interface Tunnel0
R2(config)# interface Tunnel0
R2(config-if)# description TUNEL_GRE_PARA_R1
R2(config-if)# ip address 10.0.0.2 255.255.255.252
R2(config-if)# tunnel source 200.2.2.2
R2(config-if)# tunnel destination 200.1.1.1
R2(config-if)# tunnel mode gre ip
R2(config-if)# ip mtu 1400
R2(config-if)# ip tcp adjust-mss 1360
R2(config-if)# keepalive 5 3
R2(config-if)# no shutdown
R2(config-if)# end

Passo 4: Roteamento sobre o túnel. Agora que as interfaces de túnel estão configuradas e o enlace virtual 10.0.0.0/30 está ativo, precisamos ensinar cada roteador como alcançar a rede local do outro através do túnel. Usaremos rotas estáticas, mas você poderia habilitar OSPF (faremos isso mais adiante).

! Em R1: rota para a rede local da filial via IP do túnel do R2
R1(config)# ip route 192.168.2.0 255.255.255.0 10.0.0.2

! Em R2: rota para a rede local da matriz via IP do túnel do R1
R2(config)# ip route 192.168.1.0 255.255.255.0 10.0.0.1

Passo 5: Teste de conectividade fim-a-fim. A partir de um dispositivo na LAN de R1 (192.168.1.0/24), pingue um dispositivo na LAN de R2 (192.168.2.0/24). Como não temos PCs reais, podemos usar o próprio roteador com ping estendido ou source da interface LAN.

! Em R1, ping para a LAN do R2 usando a interface LAN como source
R1# ping 192.168.2.1 source 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5)

Se você obteve 100% de sucesso, o túnel GRE está funcional. Os pacotes saíram de R1, foram encapsulados em GRE com IP de origem 200.1.1.1 e destino 200.2.2.2, atravessaram a WAN simulada, foram desencapsulados por R2 e entregues à rede 192.168.2.0.

Configuração avançada — Keepalive e redundância em GRE Tunnels

O keepalive é um mecanismo essencial para produção. Sem ele, se o caminho entre os endpoints falhar silenciosamente (ex: uma rota é removida, mas o enlace físico permanece up), a interface de túnel continuará exibindo up/up e o tráfego será descartado de forma obscura. Com keepalive, o IOS envia pacotes GRE especiais a cada intervalo configurado e, após um número de falhas consecutivas, derruba a interface do túnel. Isso é vital para acionar mecanismos de failover em rotas flutuantes ou protocolos de roteamento dinâmico.

Vamos analisar o comando keepalive 5 3:

• 5: intervalo em segundos entre cada pacote keepalive.
• 3: número de falhas consecutivas antes de considerar o túnel down.

Assim, o IOS enviará um keepalive a cada 5 segundos. Se 3 respostas consecutivas não forem recebidas, após aproximadamente 15 segundos a interface transiciona para up/down (ou down/down), removendo quaisquer rotas associadas da tabela de roteamento. Para visualizar o funcionamento, use debug tunnel keepalive:

R1# debug tunnel keepalive
Tunnel Keepalive debugging is on

*Mar  1 00:15:23.451: Tunnel0: sending keepalive to 200.2.2.2 (seq=1)
*Mar  1 00:15:23.455: Tunnel0: received keepalive from 200.2.2.2 (seq=1, rtt=4 ms)
*Mar  1 00:15:28.451: Tunnel0: sending keepalive to 200.2.2.2 (seq=2)
*Mar  1 00:15:28.455: Tunnel0: received keepalive from 200.2.2.2 (seq=2, rtt=4 ms)

Além do keepalive, você pode usar rotas flutuantes para redundância. Imagine que você tem um link backup via MPLS e o túnel GRE é o principal. Com keepalive ativo, quando o túnel cai, a rota estática pela interface tunnel é removida e a rota flutuante com distância administrativa maior assume automaticamente:

! Rota principal via túnel (AD padrão 1 para estática)
ip route 192.168.2.0 255.255.255.0 10.0.0.2

! Rota flutuante de backup via MPLS (AD 200 — só entra se a principal cair)
ip route 192.168.2.0 255.255.255.0 172.16.0.2 200

Em cenários mais complexos na JRT Technology Solutions, combinamos GRE Tunnels com OSPF para failover dinâmico e balanceamento de carga. Falaremos disso na seção de boas práticas.

Verificando a Instalação / Testando a Configuração

Esta seção é obrigatória para garantir que seu túnel GRE está operacional e saudável. Vamos executar uma série de comandos de verificação em ambos os roteadores e analisar as saídas esperadas.

1. Verificando o estado da interface de túnel:

R1# show interfaces tunnel 0

Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Description: TUNEL_GRE_PARA_R2
  Internet address is 10.0.0.1/30
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive set (5 sec), retries 3
  Tunnel source 200.1.1.1, destination 200.2.2.2
  Tunnel Subblocks:
     src-track:
        Tunnel0 source tracking subblock associated with GigabitEthernet0/0
         Set of tunnels with source GigabitEthernet0/0, 1 member (includes iterators), on interface <OK>
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Tunnel transport MTU 1476 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input 00:00:08, output 00:00:08, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     123 packets input, 10234 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     145 packets output, 11456 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out

As linhas críticas aqui são “Tunnel0 is up, line protocol is up” (ambos devem estar up), Tunnel source e Tunnel destination corretos, e Keepalive set (5 sec), retries 3. Se a linha de protocolo estiver down, verifique a rota para o destino do túnel e se o firewall permite protocolo 47.

2. Verificando a tabela de roteamento:

R1# show ip route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.0.0.0/30 is directly connected, Tunnel0
L        10.0.0.1/32 is directly connected, Tunnel0
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, GigabitEthernet0/1
L        192.168.1.1/32 is directly connected, GigabitEthernet0/1
      200.1.1.0/30 is subnetted, 1 subnets
C        200.1.1.0/30 is directly connected, GigabitEthernet0/0
L        200.1.1.1/32 is directly connected, GigabitEthernet0/0
S     192.168.2.0/24 [1/0] via 10.0.0.2
S     200.2.2.0/30 [1/0] via 200.1.1.2

Observe a rota estática S 192.168.2.0/24 [1/0] via 10.0.0.2. Isso confirma que o tráfego para a filial está sendo encaminhado pelo túnel.

3. Testando conectividade através do túnel (ping estendido):

R1# ping 10.0.0.2 repeat 20 size 1400

Type escape sequence to abort.
Sending 20, 1400-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20), round-trip min/avg/max = 2/3/6 ms

O uso de pacotes grandes (1400 bytes) com sucesso comprova que a MTU está ajustada e não há fragmentação problemática.

4. Verificando estatísticas do túnel e possíveis erros:

R1# show interfaces tunnel 0 stats

Tunnel0
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor        123      10234        145      11456
             Route cache          0          0          0          0
       Distributed cache          0          0          0          0
                   Total        123      10234        145      11456

Se os contadores de input e output estiverem incrementando, o túnel está processando tráfego. Zeros persistentes indicam que nenhum pacote está sendo roteado pelo túnel — revise as rotas.

Erros Comuns e Como Resolver

Em nossa experiência na JRT Technology Solutions, 90% dos problemas com GRE Tunnels se concentram em quatro categorias. Vamos detalhar cada uma com causa, sintoma e solução.

• Erro 1: Interface Tunnel up, line protocol down.
  Causa: O roteador não consegue alcançar o tunnel destination ou o caminho bloqueia o protocolo IP 47 (GRE).
  Sintoma: A interface aparece “Tunnel0 is up, line protocol is down”. Nenhum ping funciona através do túnel.
  Solução: Verifique se há rota válida para o tunnel destination: show ip route <destination>. Teste com ping <destination> source <source>. Se o ping falhar, corrija o roteamento. Se o ping funciona mas o túnel não sobe, investigue ACLs ou firewalls no caminho — eles devem permitir o protocolo IP 47 (GRE), não apenas TCP/UDP. Em Linux/iptables, a regra seria iptables -A INPUT -p 47 -j ACCEPT. Em Cisco ASA/FTD, libere o serviço GRE ou inspecione o protocolo 47.
• Erro 2: Túnel sobe, mas tráfego não passa (ping falha entre redes locais).
  Causa: Roteamento ausente ou incorreto para as redes remotas; ou o roteador não está usando a interface do túnel como next-hop.
  Sintoma: O ping entre os IPs do túnel (10.0.0.1 para 10.0.0.2) funciona, mas o ping de 192.168.1.0 para 192.168.2.0 falha.
  Solução: Execute show ip route em ambos os roteadores e confirme que existem rotas para as redes remotas via IP do túnel. Se estiver usando OSPF, verifique se a interface do túnel está na mesma área e sem passive-interface. Uma armadilha comum: se o túnel foi configurado após o OSPF, pode ser necessário reiniciar o processo OSPF ou aguardar a renovação dos hellos. Use debug ip ospf hello para ver se os pacotes estão saindo pelo túnel.
• Erro 3: Fragmentação e problemas de MTU — ping funciona com pacotes pequenos, mas falha com grandes.
  Causa: A MTU do payload excede o path MTU disponível, e os roteadores intermediários podem descartar pacotes que excedam a MTU da interface física sem enviar ICMP “fragmentation needed” (muitos ISPs bloqueiam ICMP).
  Sintoma: ping 10.0.0.2 size 1500 falha, mas ping 10.0.0.2 size 1400 funciona. Conexões TCP ficam lentas ou travam (MSS mismatch).
  Solução: Reduza a MTU do túnel com ip mtu 1400 e ajuste o MSS com ip tcp adjust-mss 1360. A fórmula: MSS = MTU – 40 (20 IP + 20 TCP). Para túnel GRE com overhead de 24 bytes sobre enlace de 1500: 1500 – 24 = 1476 de payload; 1476 – 40 = 1436 de MSS. Mas ao atravessar a internet, use valores conservadores (MTU 1400, MSS 1360). Em cenários com PPPoE, a MTU física pode ser 1492 — subtraia o overhead GRE disso.
• Erro 4: Keepalive derruba o túnel intermitentemente em links com latência alta.
  Causa: O intervalo de keepalive é muito curto para links com latência elevada (ex: satélite, 4G) e o número de retries é insuficiente.
  Sintoma: O túnel fica oscilando entre up e down, gerando mensagens “%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing” ou “%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down” repetidamente.
  Solução: Ajuste o keepalive para valores maiores: keepalive 10 5 (10 segundos, 5 falhas = ~50 segundos de tolerância). Se houver mensagem de recursive routing, isso indica que a rota para o tunnel destination está sendo aprendida através do próprio túnel — um loop de roteamento. Resolva usando uma rota estática específica para o destination via interface física, com distância administrativa menor, ou use tunnel source de uma interface loopback e garanta que a rota para o loopback remoto jamais passe pelo túnel.

Boas Práticas e Dicas Avançadas para GRE Tunnels

Ao longo de dezenas de implementações na JRT Technology Solutions, consolidamos um conjunto de práticas que fazem a diferença entre um túnel que funciona “no laboratório” e um que sobrevive em produção por anos. A primeira delas: sempre use uma interface loopback como tunnel source. Interfaces físicas podem cair, mudar de IP ou sofrer flaps. Uma loopback é estável, nunca cai (a menos que você a desligue) e permite que você implemente redundância com protocolos de roteamento dinâmico anunciando a loopback. Configure:

! Em cada roteador
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Tunnel0
 tunnel source Loopback0
 ! ... demais configurações

Isso desacopla o túnel da interface física. Se você tiver dois links WAN e OSPF anunciando a loopback, o tráfego GRE pode automaticamente migrar de um link para outro sem que o túnel perceba.

A segunda prática: utilize OSPF sobre o túnel em vez de rotas estáticas sempre que houver múltiplas redes atrás dos roteadores. O GRE transporta multicast nativamente, então o OSPF forma adjacência como se estivesse em um enlace local. Exemplo:

! Em R1
router ospf 1
 network 10.0.0.0 0.0.0.3 area 0
 network 192.168.1.0 0.0.0.255 area 0

! Em R2
router ospf 1
 network 10.0.0.0 0.0.0.3 area 0
 network 192.168.2.0 0.0.0.255 area 0

A adjacência se estabelece automaticamente. Você pode verificar com show ip ospf neighbor — deverá ver o vizinho na interface Tunnel0.

Terceira prática: proteja o túnel contra loops de roteamento com rotas estáticas de baixa AD para o tunnel destination. Se você tem OSPF rodando sobre o túnel e também anunciando as redes WAN, pode ocorrer de o roteador aprender o IP do tunnel destination via túnel — isso cria um loop (recursive routing). Para prevenir:

! Rota específica para o destination via next-hop físico com AD baixa (1 é padrão)
ip route 200.2.2.2 255.255.255.255 200.1.1.2
! Garanta que essa rota não seja sobrescrita pelo OSPF (AD 110 > 1, então a estática prevalece)

Quarta prática: monitore o túnel com SNMP ou syslog. Habilite snmp-server enable traps tunnel para receber notificações de quedas e recuperações. Para syslog, mensagens como %LINEPROTO-5-UPDOWN já são geradas por padrão, mas você pode ajustar o logging para níveis mais detalhados com logging trap informational.

Resumo da Aula 17

Nesta aula densa e prática, você dominou os GRE Tunnels no Cisco IOS — desde os fundamentos teóricos do encapsulamento até a configuração completa, verificação e troubleshooting avançado. Começamos entendendo a anatomia de um pacote GRE, o overhead de 24 bytes e a importância crucial do protocolo IP 47. Em seguida, construímos passo a passo um túnel funcional entre dois roteadores, configuramos keepalives, ajustamos MTU e MSS, e estabelecemos roteamento estático entre as LANs remotas.

Você aprendeu a verificar o estado do túnel com uma sequência de comandos show e a interpretar as saídas para diagnósticos precisos. Na seção de erros comuns, cobrimos as quatro falhas mais frequentes que vemos em campo — line protocol down, roteamento ausente, problemas de fragmentação e recursive routing — com causas, sintomas e soluções completas. Finalizamos com boas práticas reais do dia a dia: uso de loopbacks, OSPF sobre GRE, prevenção de loops e monitoramento proativo.

Tabela de referência rápida:

Na próxima aula (Aula 18), daremos um passo adiante no mundo dos túneis seguros: vamos combinar GRE com IPsec para criar VPNs criptografadas, flexíveis e compatíveis com protocolos de roteamento. Você aprenderá a configurar perfis criptográficos, transform-sets e a integrar tudo em uma solução de túnel segura e escalável — o famoso GRE over IPsec. Até lá, pratique os cenários desta aula em seu laboratório. Se precisar de ajuda com implementações reais ou treinamento avançado, a equipe da JRT Technology Solutions está pronta para apoiar seu crescimento com serviços de consultoria, implementação e suporte especializado em Cisco IOS.