O protocolo GRE é definido pela RFC 2784, e é um protocolo de tunelamento desenvolvido pela Cisco, em conjunto com a Juniper (sim, eles trabalham juntos ocasionalmente 😉 ). Antes de avançarmos no protocolo, propriamente dito, é importante que entendamos o que significa o “tunelamento” de um protocolo em outro ou, de forma mais leiga, o que seria a criação de um “túnel” em uma rede de dados. Um túnel em uma rede de dados, é meramente o encapsulamento de um protocolo (ex: IP) em outro (como o GRE), ou seja, pegamos o protocolo que desejamos enviar via túnel e adicionamos ao mesmo o cabeçalho do protocolo de tunelamento (como o GRE). O cabeçalho do GRE pode ser observado abaixo:
Na prática, podemos pensar em um túnel como uma forma de atalho. Na engenharia civil, é exatamente esta a função de um. Na engenharia de redes, não é diferente. Uma das razões para criarmos túneis virtuais é encurtarmos o caminho entre 2 ou mais pontos, ao menos sob o ponto de vista de roteamento. Existem outras razões para a criação de túneis virtuais em redes de dados, como por exemplo, a segregação – e consequente proteção – dos dados que trafegam pelos túneis. Estes túneis seguros são usados para a criação de VPNs, por exemplo. Lembrando que já falamos um pouco sobre VPNs no post “http://blog.ccna.com.br/2008/10/28/dmvpn/“. A figura abaixo ilustra a aplicação de túneis em uma rede:
Quando o túnel virtual é fechado entre as duas pontas (ex. entre a filial 1 e a matriz), em termos de roteamento, encurtamos virtualmente o caminho entre os 2 pontos (Filial1 e Matriz), já que antes tínhamos 3 saltos de uma rede para outra, e agora, temos apenas 1. Isso é particularmente interessante para a aplicação de protocolos de roteamento, por exemplo. Antes do fechamento dos túneis, não havia como rodar um protocolo de roteamento diretamente entre as localidades da empresa (Matriz e Filiais), já que temos os roteadores do ISP no meio do caminho, e não controlamos eles. Quando fechamos túneis como os ilustrados na figura acima, “enganamos” os roteadores, que passam a enxergar os roteadores remotos como se estivessem diretamente conectados…! Interessante, não?
Existem muitos protocolos definidos para a criação de túneis, dentre os quais, temos:
- Cisco GRE (Generic Routing Encapsulation)
- L2TP (Layer 2 Tunneling Protocol)
- Microsoft PPTP (Point-to-Point Tunneling Protocol)
- Cisco Layer 2 Forwarding (L2F)
Este post foca no GRE, que é comumente utilizado com outros protocolos de tunelamento (como o L2TP ou o PPTP) para a criação de túneis seguros. O GRE utilizado sozinho é capaz de criar túneis, porém, não criptografa os dados que atravessam estes túneis. A vantagem do GRE é que ele suporta não apenas o encapsulamento de pacotes IP, mas também de IPv6 e de tráfego multicast. Existem algumas limitações conhecidas de se utilizar tunelamento GRE. Uma delas é que a interface túnel é uma interface virtual, e permanece UP mesmo que o lado remoto esteja com problemas. Isso pode ser um problema, especialmente se você planeja utilizar Policy-based Routing (PBR). Este tipo de limitação pode ser contornada se habilitarmos o PBR para realizar o monitoramento do ponto remoto, entretanto. Existem diversas formas de realizar isso, mas não é o foco deste post 😉 . Outra limitação que aparece ao se utilizar túneis diz respeito à fragmentação dos pacotes. Como o GRE encapsula o pacote IP com um novo cabeçalho, o MTU de 1500 bytes em uma rede Ethernet, por exemplo, acaba sendo ultrapassado neste processo. Se o pacote estiver com o bit “DF” (don’t fragment) ativado, podemos ter problemas. O ideal é configurar o MTU das interfaces túnel com um MTU pelo menos 24 bytes MENOR que o MTU máximo suportado pela interface (no caso de uma interface Ethernet, seria algo em torno de 1476 bytes). Finalmente, não podemos nos esquecer que deve existir uma rota operacional para a ponta destino do túnel (veja abaixo nas configs exemplo).
GRE + Protocolos de roteamento
Como já foi mencionado, GRE permite que os roteadores em cada ponta do túnel virtual criado executem protocolos de roteamento. No exemplo abaixo, ativaremos o EIGRP:
As configs são bastante simples:
A) Primeiramente, criamos o túnel entre os routers A e B:
Router A
conf t interface tunnel 1 ip address 192.168.1.1 255.255.255.252 tunnel destination 12.1.2.2 tunnel source 12.1.1.2 ip route 12.1.2.2 255.255.255.255 12.1.1.1
Router B
conf t interface tunnel 1 ip address 192.168.1.2 255.255.255.252 tunnel destination 12.1.1.2 tunnel source 12.1.2.2 ip route 12.1.1.2 255.255.255.255 12.1.2.1
B) Na sequência, ativamos o EIGRP:
Router A
conf t router eigrp 20 network 192.168.1.0 network 20.1.1.0 no auto-summary
Router B
conf t router eigrp 20 network 192.168.1.0 network 30.1.1.0 no auto-summary
Obviamente, GRE pode ser testado sem problemas usando o Dynamips / Dynagen / GNS3. Testem!
Fontes consultadas:
http://enetworktutor.com/tutorials/tutorial_9_eigrp_over_gre_tunnel.html
http://www.faqs.org/rfcs/rfc2784.html
Espero que tenham gostado! Este foi meu último post de 2008. Me despeço de vocês por este ano, desejo-lhes Boas Festas e uma excelente virada, e nos encontramos de novo em Janeiro de 2009! O próximo post será sobre aceleração WAN, seguindo a tendência das tecnologias que devem “pegar” em 2009!
Um abraço!!
Marco Filippetti
12 comentários
Pular para o formulário de comentário
Marco, excelente post. Estive implementando por esses dias um túnel GRE com IPSec.
Feliz Natal e um ótimo 2000 “INOVE” para todos nós.
😀
Marco, ótimo Post, uma vez que é uma tecnologia muito interessante, assim como VPNs.
Feliz Natal e um ótimo 2009 para todos !!!
Parabens Marco,
Feliz Natal e Feliz Ano Novo a vc e a toda galera do Blog.
Um forte abraço.
ótimo post. valeu
Assunto que eu esperava.
Vlw
Parabéns pelo post Marco !
Assunto excelente!!!
Feliz Ano Novo a todos!!
Muito interessante.
Feliz ano novo a todos!
Nossa Marco… agora sim!!!! GRE não é mais um problema de entendimento para mim!!! Muito obrigado pela resposta a minha dúvida!! Ficou show o POST!!!
Ótimo artigo , parabéns Filippetti. Gostei da configuração no Cisco é bem simples de se fazer. Feliz 2009!!!
Filippetti,
Estava vendo seu post, que por sinal otima configuração, mas me surgiu uma duvida.
No roteador A ao inves de network 20.1.1.0 não deveria ser 30.1.1.0 no EIGRP ?
Foi invertido ou realmente desta maneira funciona ? Eu mesmo coloquei da maneira que está no post no PacketTracert e não funcionava a rede 20 e nem a 30, ai quando eu inverti a configuração funcionou.
Abraços
Simples e útil, desmistificou algumas dúvidas aqui.
Obrigado.
Post manero!