Túneis L2 sobre redes públicas usando GRE + AToM

Resolvi criar este post em cima de algumas experiências que eu já tive, por achar a tecnologia, em si, muito interessante. Muitos não sabem, mas é possível combinar túneis GRE (L3) com VPNs L2 (L2VPN) para alcançar resultados bastante interessantes. Montei o lab em cima do GNS3, e vou disponibilizar todo o material (configurações, cenário e IOS) para que vocês repliquem o mesmo em vossas casas 😉

O objetivo é fazer com que dois CPEs (roteadores, PCs ou mesmo switches) consigam se enxergar via camada 2 – como se estivessem diretamente conectados – mesmo estando a milhares de kilômetros de distância e, fisicamente, atravessando redes sobre as quais não temos qualquer controle (como a Internet). Abaixo, o cenário montado no GNS3.

No caso, a “nuvem” Internet é representada por um roteador no GNS3 (chamado “Internet”). Para os CPEs foram usados roteadores Cisco 3600, e para os PEs e o roteador “Internet”, Cisco 7200. O motivo é que não consegui fazer o AToM (Any Transport over MPLS) funcionar nos 3600. AToM é a tecnologia usada para a emulação de enlaces L2 sobre redes MPLS, e para que isso funcione, é preciso ativar MPLS entre os roteadores PE1 e PE2.

O problema é que temos a Internet no meio do caminho. Para contornar isso, criamos um túnel GRE fazendo com que os roteadores PE1 e PE2 “achem” que estão diretamente conectados. Ativamos, então, AToM neste túnel GRE. O legal desta solução é que não é necessário ativar MPLS nas interfaces que se conectam com o mundo exterior (com a Internet, no exemplo). Apenas nas interfaces túnel. Não vou me extender no assunto pois este já foi tratado em um post anterior, sobre VPNs L2.

Para alcançar o resultado, nos CPEs, em si, nenhuma configuração especial se faz necessária. A única coisa que fiz foi colocar IPs em suas interfaces (192.168.0.1, na F0/0 do CPE1, e 192.168.0.2 na F0/1 do CPE2). Mas para o cenário funcionar, sequer isso seria necessário, já que podemos constatar que a coisa está funcionando via CDP, que como vocês sabem, é um protocolo exclusivamente L2:

CPE1#sh cdp nei

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
CPE2             Fas 0/0            163        R S I      3660      Fas 0/1

Como temos IPs configurados nas duas pontas, a saída do comando “show arp” também mostra que o cenário está funcionando à contento:

CPE1#sh arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.0.1             -   cc08.195c.0000  ARPA   FastEthernet0/0
Internet  192.168.0.2            24   cc09.195c.0001  ARPA   FastEthernet0/0

E, claro, temos o PING:

CPE1#ping 192.168.0.2 
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/48/128 ms

Se ao invés de roteadores fossem conectados switches como CPEs, poderíamos fechar um trunk entre ambos, mesmo que um estivesse fisicamente no Brasil, e outro no Japão, por exemplo. É claro que existem os problemas com delay, QoS, jitter, etc desta solução, e isso não tem jeito, já que não temos controle sobre os pacotes que caem na Internet (ou em qualquer rede de dados pública). Mas, de qualquer forma, não deixa de ser uma solução interessante, e que pode ser útil em vários cenários do mundo real.

Os arquivos de configuração, .net e os IOS usados nesta demonstração encontram-se disponíveis para download no link abaixo:

http://www.4shared.com/file/1rQdDdbR/Lab_L2VPN.html

Bom lab!!!

Marco.