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

Popularity: 4% [?]