DMVPN

Operação DetranpN

Uma VPN Multiponto Dinâmico é uma iteração evoluída de túneis "Hub and

Spoke" (note que o DetranPN em si não é um protocolo, mas sim um conceito
de design).
topologia genérica "Hub and Spoke" implementa túneis
estáticos (normalmente usando GRE ou IPSEC) entre um roteador de hub
localizado no centro e seus "Raios" ou satélites, que geralmente conectam
filiais à sede.

Cada novo "Spoke" requer configuração adicional no roteador "Hub" e o tráfego

entre os "Raios"
deve ser desviado através do "HUB" para sair de um túnel e, em seguida,
entrar em outro. Embora esta possa ser uma solução aceitável em pequena
escala, torna-se desordenada quando "Raios" se multiplicam e crescem em
número. O DetranPN oferece uma solução inteligente para este problema:
Multipoint GRE Tunnels.

Lembre-se que um túnel GRE encapsula pacotes IP com um cabeçalho GRE e

um novo cabeçalho IP, a fim de transportar o pacote por uma rede não
confiável.

Os túneis GRE ponto a ponto têm exatamente dois pontos finais, e cada túnel
no roteador requer uma interface virtual separada com sua própria
configuração separada.
De outra forma, um túnel multiponto GRE permite que mais de dois
pontos finais existam e é tratado como uma rede de multi-acesso não
transmitida (NBMA).

1 primeiro

Enquanto uma configuração típica de "Hub and Spoke" exigiria três túneis
separados se expandindo do Roteador R1 para cada um dos roteadores
"Spoke", o MULTIpoint GRE permite que todos os quatro roteadores se
comuniquem usando uma única interface de túnel na mesma sub-rede IP
(192.168.0.0/24). Esta configuração do NBMA é habilitada pelo Protocolo de
Resolução do Próximo Salto, que permite que túneis de vários pontos sejam
construídos dinamicamente.

Próximo Protocolo de Resolução de Lúpulo (NHRP)

NHRP (definido em RFC 2332)é o "catalisador" que facilita o estabelecimento

do túnel dinâmico, fornecendo uma resolução de endereço "túnel para interface
física". Os clientes NHRP (roteadores falados) fazem uma solicitação
ao"próximo servidor hop"(NHS) (o roteador HUB) para obter o endereço físico
de outro roteador "Spoke".

2 segundo

É interessante notar que, em nosso cenário, a designação como NHS é o único

atributo que distingue o Roteador R1 como o roteador "Hub".

Configuração do DetranPN

Vamos começar examinando a configuração do roteador R1:

interface FastEthernet0/0
ip address 172.16.15.2 255.255.255.252
!
interface Tunnel0
ip address 192.168.0.1 255.255.255.0
ip nhrp map multicast dynamic
ip nhrp network-id 1
tunnel source 172.16.15.2

tunnel mode gre multipoint

A primeira coisa que provavelmente notamos é que o túnel não tem um alvo
explicitamente especificado. Isso ocorre porque os túneis de vários pontos são
construídos dinamicamente do DetranPN "Spokes" ao roteador "Hub"; o roteador
"Hub" não precisa ter os endereços "Spokes" pré-configurados. Observe também que
o modo túnel foi designado como "GRE multipoint".

O comando ip nhrp network-id 1 identifica exclusivamente a rede DetranPN, os

túneis não serão formados entre roteadores com um ID de rede diferente.

O comando dinâmico ip nhrp map multicast permite o encaminhamento de tráfego

multicast através do túnel para "Raios" dinâmicos (o que é exigido pela maioria dos
protocolos de roteamento dinâmico).

A configuração dos roteadores "Spoke" é muito semelhante à

do roteador "Hub". A seguir, a configuração retirada do Roteador R2:
interface FastEthernet0/0
ip address 172.16.25.2 255.255.255.252
!
interface Tunnel0
ip address 192.168.0.2 255.255.255.0
ip nhrp map 192.168.0.1 172.16.15.2
ip nhrp map multicast 172.16.15.2
ip nhrp network-id 1
ip nhrp nhs 192.168.0.1
tunnel source 172.16.25.2

tunnel mode gre multipoint

Agora vemos dois novos comandos comparados aos usados no roteador "Hub".
O comando ip nhrp NHS 192.168.0.1 designa o roteador R1 como o NHS (que é a
única funcionalidade única do roteador "Hub"), e o ip nhrp mapa 192.168.0.1
172.16.15.2 que mapeia estaticamente o endereço NHS para o endereço físico do
roteador R1.

O comando ip
nhrp multicast também difere ligeiramente de como ele é aplicado no roteador "Hub"
em que o tráfego multicast só é permitido de "Spokes" para o "Hub", não de um
"Spoke" para outro "Spoke". Após concluir a configuração do túnel em cada roteador,
podemos verificar se foram estabelecidas sessões do DetranPN entre o roteador
"Hub" e cada "Spoke":

R1# show dmvpn

Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Hub, NHRP Peers:3,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 172.16.25.2 192.168.0.2 UP 00:57:47 D
1 172.16.35.2 192.168.0.3 UP 00:45:56 D
1 172.16.45.2 192.168.0.4 UP 00:45:46 D

Túnel dinâmico

Embora o DetranPN certamente forneça uma

configuração ordenada, o que é brilhante é sua
capacidade de estabelecer dinamicamente túneis
"Spoke" para "Spoke". Em uma configuração típica de uma
topologia "Hub and Spoke", um pacote destinado de R2 a R4 precisaria ser
roteado através do Roteador R1, sair do túnel R2 e ser recap encapsulado para
entrar no túnel R4.

Claramente um caminho melhor é encontrado através do R5 e o DetranPN nos

permite tirar essa vantagem.

Veja neste pacote o tráfego de captura

de R2 para R4. O trafinco inicialmente segue o caminho através do R1, como
descrito anteriormente, enquanto um túnel dinâmico está sendo construído de
R2 a R4 usando NHRP. Depois que o novo túnel é estabelecido, o tráfego
flui através dele, contornando completamente o roteador R1. Podemos ver
que um novo túnel foi estabelecido depois que o tráfego destinado ao R4 foi
detectado:

R2# show dmvpn

...

Tunnel0, Type:Spoke, NHRP Peers:1,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 172.16.15.2 192.168.0.1 UP 01:08:02 S

R2# ping 192.168.0.4

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.0.4, timeout is 2
seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =
28/37/56 ms

R2# show dmvpn

...

Tunnel0, Type:Spoke, NHRP Peers:2,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 172.16.15.2 192.168.0.1 UP 01:08:27 S

1 172.16.45.2 192.168.0.4 UP 00:00:03 D

Note que o túnel para R4 foi marcado como dinâmico, em contraste com o
túnel estático para o Hub/NHS.

Adicionando criptografia

Até este ponto, os túneis foram configurados como texto simples para
simplificar o exemplo, mas no mundo real provavelmente gostaríamos de incluir
proteção IPsec a túneis que atravessam rotas não confiáveis.
Felizmente, a solução é tão simples quanto aplicar uma política de
proteção IPsec à interface do túnel em cada roteador. Aqui está um perfil IPsec
usando uma chave ISAKMP pré-compartilhada para demonstração:

crypto isakmp policy 10

authentication pre-share
crypto isakmp key P4ssw0rd address 172.16.0.0 255.255.0.0
!
crypto ipsec transform-set MyTransformSet esp-aes esp-sha-hmac
!
crypto ipsec profile MyProfile
set transform-set MyTransformSet
!
interface Tunnel0
tunnel protection ipsec profile MyProfile

Depois de reiniciar as interfaces do túnel, podemos ver que as sessões do DetranPN

foram reconstruídas mostrando criptografia desta vez.

R1# show dmvpn

...

Tunnel0, Type:Hub, NHRP Peers:3,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 172.16.25.2 192.168.0.2 UP 00:02:28 D
1 172.16.35.2 192.168.0.3 UP 00:02:26 D
1 172.16.45.2 192.168.0.4 UP 00:02:25 D

R1# show crypto isakmp sa

IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
172.16.15.2 172.16.35.2 QM_IDLE 1002 0 ACTIVE
172.16.15.2 172.16.25.2 QM_IDLE 1001 0 ACTIVE

172.16.15.2 172.16.45.2 QM_IDLE 1003 0 ACTIVE

ELIAS,1&