help.jpgPessoal, desculpem-me por criar um post apenas para passar este recado, mas é a melhor forma de TODOS ficarem cientes do que vou dizer de forma rápida. Criei o blog há pouco mais de um ano com o intuito de tentar democratizar informações e conhecimentos de forma relativamente simples e rápida. Percebendo a necessidade e o anseio de alguns leitores por ainda mais informações, integrei ao blog um fórum que já conta com 1300 discussões e mais de 10200 comentários em mais de 24 categorias.

Peço ENCARECIDAMENTE que utilizem este recurso para tentarem resolver suas questões. Este blog tornou-se uma comunidade, onde muitos estão dispostos a ajudar ao próximo, compartilhando seu conhecimento. Dentre os que ajudam constantemente, temos os colabs do blog, eu, profissionais tarimbados e experientes, professores, e inúmeros leitores interessados em aprender e ensinar. Assim sendo, peço que EVITEM ao máximo me enviar e-mails diretamente com questões. Peço isso simplesmente porque não tenho tempo de responder a questões individuais… se eu tivesse, certamente o faria. Até o dia de hoje, me esforcei ao máximo para, assim que chego em casa do trabalho, sentar-me em frente ao computador e procurar responder ao maior número de e-mails possível. Hoje, percebi que isso não é mais viável! Meu INBOX estava atolado com mais de 30 e-mails com questões, e optei por ignorar a maioria, infelizmente.

Do contrário, tenho que abrir mão de minha vida pessoal por completo, e certamente não tenho esta intenção ;-)

Portanto, mais uma vez, peço que utilizem o fórum. Certamente alguém irá ajudá-lo (e muito provavelmente de forma melhor do que eu poderia ;-) )!

A partir de hoje, dificilmente responderei a e-mails individuais. Este blog existe para isso. É a melhor forma de contato que eu consigo imaginar. Concordam… ou não ;-) ?

Um abraço!

Marco.

Popularity: 1% [?]

Comments Comments Off

Imprima este post Imprima este post

Leia também:

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:

gre_header.jpg

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:

gre_topo.gif

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:

tutorial_9_eigrp_over_gre_tunnel_2.gif

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% [?]

Comments 12 Comentários »

Imprima este post Imprima este post

Leia também: