O hub duplo, com layout duplo de DMVPN, é ligeiramente mais difícil de configurar, mas proporciona um controle melhor do roteamento através do DMVPN. A ideia é ter um dois DMVPN separado “nuvens”. Cada hub (dois nesse caso) está conectado a uma sub-rede DMVPN ("rede") e os spokes estão conectados nas duas sub-redes DMVPN ("redes"). Como os roteadores spoke estão fazendo o roteamento dos vizinhos com os dois roteadores hub nas duas interfaces de túnel GRE, você pode usar as diferenças de configuração de interface (por exemplo, largura de banda, custo e retardo) para modificar a métrica do Dynamic Routing Protocol e escolher um dos dois hubs quando ambos estiverem conectados.
Nota: O problema acima em geral só é importante quando os roteadores de hub são co-alocados. Quando eles não são co-alocados, o roteamento
dinâmico normal provavelmente prefere o roteador de hub correto, mesmo quando a rede de destino pode ser alcançada por meio de qualquer um dos roteadores de hub.
Você pode usar interfaces de túnel p-pGRE ou mGRE nos roteadores spoke. As relações múltiplas do p-pGRE em um roteador do spoke podem usar o mesmo endereço IP de Um ou Mais Servidores Cisco ICM NT do origem de túnel…, mas as relações múltiplas mGRE em um roteador do spoke devem ter um endereço IP de Um ou Mais Servidores Cisco ICM NT da fonte do túnel exclusivo…. Isso acontece porque, quando o IPSec está iniciando, o primeiro pacote é um pacote ISAKMP que precisa ser associado a um dos túneis mGRE. O pacote ISAKMP apresenta apenas o endereço IP de destino (endereço do peer IPsec remoto) com o qual a associação deve ser estabelecida. Esse endereço é comparado com o endereço de origem do túnel, mas como ambos os túneis têm o mesmo endereço de origem, a primeira interface de túnel mGRE é sempre comparada. Isso significa que os pacotes de dados de multicast recebidos podem estar associados à interface mGRE errada, quebrando qualquer Dynamic Routing Protocol.
Os pacotes GRE não têm esse problema, uma vez que possuem um valor de chave de túnel para diferenciar as duas interfaces mGRE.
Começando nos Cisco IOS Software Releases 12.3(5) e 12.3(7)T, um parâmetro adicional foi introduzido para superar esta limitação: proteção
do túnel….compartilhado. A palavra-chave compartilhada indica que as relações do mutiple mGRE usarão a criptografia IPSec com o mesmo
endereço IP de origem. Se você tem uma versão anterior você pode usar túneis do p-pGRE neste hub dual com layout duplo DMVPN. No caso do túnel p-pGRE, os endereços IP de origem e de destino podem ser usados para correspondência. Para túneis do p-pGRE deste exemplo será usado neste hub dual com layout duplo DMVPN e para não usar o qualificador compartilhado.
Hub duplo - Disposição de DMVPN dupla
As seguintes alterações destacadas são relativas às configurações dinâmicas de concentrador e ponto remoto multiponto ilustradas anteriormente nesse documento. Roteador do hub 1 version 12.3 ! hostname Hub1 !
crypto isakmp policy 1 authentication pre-share
crypto isakmp key cisco47 address 0.0.0.0 0.0.0.0 !
crypto ipsec transform-set trans2 esp-des esp-md5-hmac mode transport
crypto ipsec profile vpnprof set transform-set trans2 ! interface Tunnel0 bandwidth 1000 ip address 10.0.0.1 255.255.255.0 ip mtu 1400 ip nhrp authentication test ip nhrp map multicast dynamic ip nhrp network-id 100000 ip nhrp holdtime 600 no ip split-horizon eigrp 1 delay 1000
tunnel source Ethernet0 tunnel mode gre multipoint tunnel key 100000
tunnel protection ipsec profile vpnprof ! interface Ethernet0 ip address 172.17.0.1 255.255.255.252 ! interface Ethernet1 ip address 192.168.0.1 255.255.255.0 ! router eigrp 1 network 10.0.0.0 0.0.0.255 network 192.168.0.0 0.0.0.255 no auto-summary ! Roteador do hub 2 version 12.3 ! hostname Hub2 !
crypto isakmp policy 1 authentication pre-share
crypto isakmp key cisco47 address 0.0.0.0 0.0.0.0 !
crypto ipsec transform-set trans2 esp-des esp-md5-hmac mode transport
!
crypto ipsec profile vpnprof set transform-set trans2 ! interface Tunnel0 bandwidth 1000 ip address 10.0.1.1 255.255.255.0 ip mtu 1400 ip nhrp authentication test ip nhrp map multicast dynamic
ip nhrp network-id 100001
ip nhrp holdtime 600 no ip split-horizon eigrp 1 delay 1000
tunnel source Ethernet0 tunnel mode gre multipoint
tunnel key 100001
tunnel protection ipsec profile vpnprof ! interface Ethernet0 ip address 172.17.0.5 255.255.255.252 ! interface Ethernet1 ip address 192.168.0.2 255.255.255.0 ! router eigrp 1 network 10.0.1.0 0.0.0.255 network 192.168.0.0 0.0.0.255 no auto-summary !
Neste caso, as configurações de Hub1 e de Hub2 são similares. O principal diferença é que cada um é o hub de um DMVPN diferente. Cada DMVPN usa um diferente:
Sub-rede de IP (10.0.0.0/24, 10.0.0.1/24) Identificação de rede NHRP (100000, 100001) Chave de túnel (100000, 100001)
EIGRP, conforme descrito mais adiante neste documento. roteador spoke1 version 12.3 ! hostname Spoke1 !
crypto isakmp policy 1 authentication pre-share
crypto isakmp key cisco47 address 0.0.0.0 0.0.0.0 !
crypto ipsec transform-set trans2 esp-des esp-md5-hmac mode transport
!
crypto ipsec profile vpnprof set transform-set trans2 ! interface Tunnel0 bandwidth 1000 ip address 10.0.0.11 255.255.255.0 ip mtu 1400 ip nhrp authentication test ip nhrp map 10.0.0.1 172.17.0.1 ip nhrp network-id 100000 ip nhrp holdtime 300 ip nhrp nhs 10.0.0.1 delay 1000
tunnel source Ethernet0
tunnel destination 172.17.0.1 tunnel key 100000
tunnel protection ipsec profile vpnprof ! interface Tunnel1 bandwidth 1000 ip address 10.0.1.11 255.255.255.0 ip mtu 1400 ip nhrp authentication test ip nhrp map 10.0.1.1 172.17.0.5 ip nhrp network-id 100001 ip nhrp holdtime 300 ip nhrp nhs 10.0.1.1 delay 1000
tunnel source Ethernet0
tunnel destination 172.17.0.5 tunnel key 100001
tunnel protection ipsec profile vpnprof !
interface Ethernet0
ip address dhcp hostname Spoke1 ! interface Ethernet1 ip address 192.168.1.1 255.255.255.0 ! router eigrp 1 network 10.0.0.0 0.0.0.255 network 10.0.1.0 0.0.0.255 network 192.168.1.0 0.0.0.255 no auto-summary !
Cada roteador de spoke é configurado com duas interfaces de túnel p-pGRE, uma em cada DMVPN. Os valores de ip address ..., ip nhrp network-id ..., tunnel key ... e tunnel destination ... são usados para diferenciar entre os dois túneis. O Dynamic Routing Protocol, EIGRP, é executado em ambas as sub-redes de túnel p-pGRE e é usado para selecionar uma interface p-pGRE (DMVPN) em vez da outra.
roteador spoke2
version 12.3 !
hostname Spoke2 !
crypto isakmp policy 1 authentication pre-share
crypto isakmp key cisco47 address 0.0.0.0 0.0.0.0 !
crypto ipsec transform-set trans2 esp-des esp-md5-hmac mode transport
!
crypto ipsec profile vpnprof set transform-set trans2 !
interface Tunnel0 bandwidth 1000 ip address 10.0.0.12 255.255.255.0 ip mtu 1400 ip nhrp authentication test ip nhrp map 10.0.0.1 172.17.0.1 ip nhrp network-id 100000 ip nhrp holdtime 300 ip nhrp nhs 10.0.0.1 delay 1000
tunnel source Ethernet0
tunnel destination 172.17.0.1 tunnel key 100000
tunnel protection ipsec profile vpnprof ! interface Tunnel1 bandwidth 1000 ip address 10.0.1.12 255.255.255.0 ip mtu 1400 ip nhrp authentication test ip nhrp map 10.0.1.1 172.17.0.5 ip nhrp network-id 100001 ip nhrp holdtime 300 ip nhrp nhs 10.0.1.1 delay 1000
tunnel source Ethernet0
tunnel destination 172.17.0.5 tunnel key 100001
tunnel protection ipsec profile vpnprof !
interface Ethernet0
ip address dhcp hostname Spoke2 ! interface Ethernet1 ip address 192.168.2.1 255.255.255.0 ! router eigrp 1 network 10.0.0.0 0.0.0.255 network 10.0.1.0 0.0.0.255 network 192.168.2.0 0.0.0.255 no auto-summary ! Roteador do Spoke<n> version 12.3 ! hostname Spoke<n> !
crypto isakmp policy 1 authentication pre-share
crypto isakmp key cisco47 address 0.0.0.0 0.0.0.0 !
crypto ipsec transform-set trans2 esp-des esp-md5-hmac mode transport
!
crypto ipsec profile vpnprof set transform-set trans2 ! interface Tunnel0 bandwidth 1000 ip address 10.0.0.<n+10> 255.255.255.0 ip mtu 1400 ip nhrp authentication test ip nhrp map 10.0.0.1 172.17.0.1 ip nhrp network-id 100000 ip nhrp holdtime 300 ip nhrp nhs 10.0.0.1 delay 1000
tunnel source Ethernet0
tunnel destination 172.17.0.1 tunnel key 100000
tunnel protection ipsec profile vpnprof ! interface Tunnel1 bandwidth 1000 ip address 10.0.1.<n+10> 255.255.255.0 ip mtu 1400 ip nhrp authentication test ip nhrp map 10.0.1.1 172.17.0.5 ip nhrp network-id 100001 ip nhrp holdtime 300 ip nhrp nhs 10.0.1.1
delay 1000
tunnel source Ethernet0
tunnel destination 172.17.0.5 tunnel key 100001
tunnel protection ipsec profile vpnprof !
interface Ethernet0
ip address dhcp hostname Spoke<x> ! interface Ethernet1 ip address 192.168.<n>.1 255.255.255.0 ! router eigrp 1 network 10.0.0.0 0.0.0.255 network 10.0.1.0 0.0.0.255 network 192.168.<n>.0 0.0.0.255 no auto-summary !
Neste momento, deixe-nos olhar as tabelas de roteamento, as tabelas do mapeamento NHRP, e conexões IPSec no Roteadores de Hub1, de Hub2, de Spoke1 e de Spoke2 para ver as condições inicial (imediatamente depois do Roteadores de Spoke1 e de Spoke2 venha acima).
Condições e alterações iniciais
Informação do Hub1 Router
Hub1#show ip route
172.17.0.0/30 is subnetted, 1 subnets
C 172.17.0.0 is directly connected, Ethernet0 10.0.0.0/24 is subnetted, 2 subnets
C 10.0.0.0 is directly connected, Tunnel0
D 10.0.1.0 [90/2611200] via 192.168.0.2, 00:00:46, Ethernet1 C 192.168.0.0/24 is directly connected, Ethernet1
D 192.168.1.0/24 [90/2841600] via 10.0.0.11, 00:00:59, Tunnel0 D 192.168.2.0/24 [90/2841600] via 10.0.0.12, 00:00:34, Tunnel0 Hub1#show ip nhrp
10.0.0.12/32 via 10.0.0.12, Tunnel0 created 23:48:32, expire 00:03:50 Type: dynamic, Flags: authoritative unique registered
NBMA address: 172.16.2.75
10.0.0.11/32 via 10.0.0.11, Tunnel0 created 23:16:46, expire 00:04:45 Type: dynamic, Flags: authoritative unique registered
NBMA address: 172.16.1.24
Hub1#show crypto engine connection active
ID Interface IP-Address State Algorithm Encrypt Decrypt 15 Ethernet0 172.17.63.18 set HMAC_SHA+DES_56_CB 0 0 16 Ethernet0 10.0.0.1 set HMAC_SHA+DES_56_CB 0 0 2038 Tunnel0 10.0.0.1 set HMAC_MD5+DES_56_CB 0 759 2039 Tunnel0 10.0.0.1 set HMAC_MD5+DES_56_CB 726 0 2040 Tunnel0 10.0.0.1 set HMAC_MD5+DES_56_CB 0 37 2041 Tunnel0 10.0.0.1 set HMAC_MD5+DES_56_CB 36 0
Informação do Hub2 Router
Hub2#show ip route
172.17.0.0/30 is subnetted, 1 subnets
C 172.17.0.4 is directly connected, Ethernet0 10.0.0.0/24 is subnetted, 2 subnets
D 10.0.0.0 [90/2611200] via 192.168.0.1, 00:12:22, Ethernet1 C 10.0.1.0 is directly connected, Tunnel0
C 192.168.0.0/24 is directly connected, Ethernet1
D 192.168.1.0/24 [90/2841600] via 10.0.1.11, 00:13:24, Tunnel0 D 192.168.2.0/24 [90/2841600] via 10.0.1.12, 00:12:11, Tunnel0 Hub2#show ip nhrp
10.0.1.12/32 via 10.0.1.12, Tunnel3 created 06:03:24, expire 00:04:39 Type: dynamic, Flags: authoritative unique registered
NBMA address: 172.16.2.75
10.0.1.11/32 via 10.0.1.11, Tunnel3 created 23:06:47, expire 00:04:54 Type: dynamic, Flags: authoritative unique registered
NBMA address: 172.16.1.24
Hub2#show crypto engine connection active
ID Interface IP-Address State Algorithm Encrypt Decrypt 4 Ethernet0 171.17.0.5 set HMAC_SHA+DES_56_CB 0 0 6 Ethernet0 171.17.0.5 set HMAC_SHA+DES_56_CB 0 0 2098 Tunnel0 10.0.1.1 set HMAC_MD5+DES_56_CB 0 722 2099 Tunnel0 10.0.1.1 set HMAC_MD5+DES_56_CB 690 0 2100 Tunnel0 10.0.1.1 set HMAC_MD5+DES_56_CB 0 268 2101 Tunnel0 10.0.1.1 set HMAC_MD5+DES_56_CB 254 0
Spoke1#show ip route
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Tunnel0 C 10.0.1.0 is directly connected, Tunnel1
D 192.168.0.0/24 [90/2841600] via 10.0.1.1, 00:26:30, Tunnel1 [90/2841600] via 10.0.0.1, 00:26:30, Tunnel0 C 192.168.1.0/24 is directly connected, Ethernet1
D 192.168.2.0/24 [90/3097600] via 10.0.1.1, 00:26:29, Tunnel1 [90/3097600] via 10.0.0.1, 00:26:29, Tunnel0 Spoke1#show ip nhrp
10.0.0.1/32 via 10.0.0.1, Tunnel0 created 23:25:46, never expire Type: static, Flags: authoritative
NBMA address: 172.17.0.1
10.0.1.1/32 via 10.0.1.1, Tunnel1 created 23:24:40, never expire Type: static, Flags: authoritative
NBMA address: 172.17.0.5
Spoke1#show crypto engine connection active
ID Interface IP-Address State Algorithm Encrypt Decrypt 16 Ethernet0 172.16.1.24 set HMAC_SHA+DES_56_CB 0 0 18 Ethernet0 172.16.1.24 set HMAC_SHA+DES_56_CB 0 0 2118 Tunnel0 10.0.0.11 set HMAC_MD5+DES_56_CB 0 181 2119 Tunnel0 10.0.0.11 set HMAC_MD5+DES_56_CB 186 0 2120 Tunnel1 10.0.1.11 set HMAC_MD5+DES_56_CB 0 105 2121 Tunnel1 10.0.1.11 set HMAC_MD5+DES_56_CB 110 0
Informação do roteador Spoke2
Spoke2#show ip route
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.2.0 is directly connected, Ethernet0 10.0.0.0/24 is subnetted, 2 subnets
C 10.0.0.0 is directly connected, Tunnel0 C 10.0.1.0 is directly connected, Tunnel1
D 192.168.0.0/24 [90/2841600] via 10.0.1.1, 00:38:04, Tunnel1 [90/2841600] via 10.0.0.1, 00:38:04, Tunnel0 D 192.168.1.0/24 [90/3097600] via 10.0.1.1, 00:38:02, Tunnel1 [90/3097600] via 10.0.0.1, 00:38:02, Tunnel0 C 192.168.2.0/24 is directly connected, Ethernet1
Spoke2#show ip nhrp
10.0.0.1/32 via 10.0.0.1, Tunnel0 created 1d02h, never expire Type: static, Flags: authoritative used
NBMA address: 172.17.0.1
10.0.1.1/32 via 10.0.1.1, Tunnel1 created 1d02h, never expire Type: static, Flags: authoritative used
NBMA address: 172.17.0.5
Spoke2#show crypto engine connection active
ID Interface IP-Address State Algorithm Encrypt Decrypt 8 Ethernet0 172.16.2.75 set HMAC_SHA+DES_56_CB 0 0 9 Ethernet0 172.16.2.75 set HMAC_SHA+DES_56_CB 0 0 2036 Tunnel0 10.0.0.12 set HMAC_MD5+DES_56_CB 0 585 2037 Tunnel0 10.0.0.12 set HMAC_MD5+DES_56_CB 614 0 2038 Tunnel1 10.0.1.12 set HMAC_MD5+DES_56_CB 0 408 2039 Tunnel1 10.0.1.12 set HMAC_MD5+DES_56_CB 424 0
Novamente, existem alguns fatores interessantes a serem observados sobre tabelas de roteamento em Hub1, Hub2, Spoke1 e Spoke2: Os dois roteadores do concentrador possuem rotas de custos iguais para as redes por trás dos roteadores de raio.
Hub1: D 192.168.1.0/24 [90/2841600] via 10.0.0.11, 00:00:59, Tunnel0 D 192.168.2.0/24 [90/2841600] via 10.0.0.12, 00:00:34, Tunnel0 Hub2: D 192.168.1.0/24 [90/2841600] via 10.0.1.11, 00:13:24, Tunnel0 D 192.168.2.0/24 [90/2841600] via 10.0.1.12, 00:12:11, Tunnel0
Isso significa que Hub1 e Hub 2 anunciarão o mesmo custo das redes atrás dos roteadores de spoke para os roteadores na rede atrás dos roteadores de hub. Por exemplo, a tabela de roteamento em um roteador, R2, que esteja conectado diretamente à LAN 192.168.0.0/24 seria assim:
D 192.168.1.0/24 [90/2867200] via 192.168.0.1, 00:51:51, Ethernet1/0/3 [90/2867200] via 192.168.0.2, 00:51:51, Ethernet1/0/3 D 192.168.2.0/24 [90/2867200] via 192.168.0.2, 00:52:43, Ethernet1/0/3 [90/2867200] via 192.168.0.1, 00:52:43, Ethernet1/0/3
Os roteadores spoke possuem rotas de custo equivalentes por meio dos roteadores de hub para a rede por trás dos roteadores de hub. Spoke1: D 192.168.0.0/24 [90/3097600] via 10.0.1.1, 00:26:30, Tunnel1 [90/3097600] via 10.0.0.1, 00:26:30, Tunnel0 Spoke2: D 192.168.0.0/24 [90/3097600] via 10.0.1.1, 00:38:04, Tunnel1 [90/3097600] via 10.0.0.1, 00:38:04, Tunnel0
Se o Roteadores do spoke está fazendo o balanceamento de carga por pacote, a seguir você poderia obter pacotes estragados.
Para evitar o roteamento assimétrico ou o balanceamento de carga por pacote nos enlaces para os dois concentradores, você precisa configurar o Routing Protocol para preferir um caminho do tipo “spoke-to-hub” em ambas as direções. Se você quer Hub1 ser o preliminar e Hub2 a ser o backup, a seguir você pode ajustar o atraso nas interfaces de túnel do hub para ser diferente.
Hub1: interface tunnel0 ... delay 1000 ... Hub2: interface tunnel0 ... delay 1050 ...
Nota: Neste exemplo, 50 foi adicionado ao retardo na interface do túnel no Hub2 porque ele é menor que o retardo na interface Ethernet1 entre
os dois hubs (100). Fazendo isso, o Hub2 continuará a encaminhar pacotes diretamente para os roteadores spoke, mas anunciará uma rota menos desejável que o Hub1 para roteadores atrás de Hub1 e Hub2. Se o atraso foi aumentado por mais de 100, a seguir Hub2 enviaria pacotes para o Roteadores do spoke com Hub1 através da relação de Ethernet1, embora o Roteadores atrás de Hub1 e de Hub2 ainda assim preferiria
corretamente Hub-1 para enviar pacotes ao Roteadores do spoke. Agora as rotas são apresentadas da seguinte forma:
Hub1: D 192.168.1.0/24 [90/2841600] via 10.0.0.11, 00:01:11, Tunnel0 D 192.168.2.0/24 [90/2841600] via 10.0.0.12, 00:01:11, Tunnel0 Hub2: D 192.168.1.0/24 [90/2854400] via 10.0.1.11, 00:00:04, Tunnel0 D 192.168.2.0/24 [90/2854400] via 10.0.1.12, 00:00:04, Tunnel0 R2: D 192.168.1.0/24 [90/2867200] via 192.168.0.1, 00:02:18, Ethernet1/0/3 D 192.168.2.0/24 [90/2867200] via 192.168.0.1, 00:02:18, Ethernet1/0/3
Os dois roteadores de hub têm diferentes custos para as rotas da rede para os roteadores de spoke, portanto, nesse caso, o Hub1 será preferido para encaminhar tráfego para os roteadores de spoke, como se vê em R2. Isto toma da edição descrito na primeira bala acima.
O problema descrito no segundo item acima ainda está lá, mas visto haver duas interfaces de túnel p-pGRE, será possível configurar o retardo ... nas interfaces de túnel separadamente para alterar a métrica do EIGRP para as rotas aprendidas da relação entre o Hubs 1 e 2.
Spoke1:
delay 1000 interface tunnel1 delay 1050 Spoke2: interface tunnel0 delay 1000 interface tunnel1 delay 1050
Agora as rotas são apresentadas da seguinte forma: Spoke1: D 192.168.0.0/24 [90/2841600] via 10.0.0.1, 00:15:44, Tunnel0 D 192.168.2.0/24 [90/3097600] via 10.0.0.1, 00:15:44, Tunnel0 Spoke2: D 192.168.0.0/24 [90/2841600] via 10.0.0.1, 00:13:54, Tunnel0 D 192.168.1.0/24 [90/3097600] via 10.0.0.1, 00:13:54, Tunnel0
A configuração de roteamento acima protegerá contra roteamento assimétrico, enquanto permite o failover para o hub2 caso o hub1 fique inativo. Significa que quando os dois hubs estão ativados, apenas o Hub 1 é usado.
Se você quer usar ambo o Hubs equilibrando o spokes através do Hubs, com proteção de failover e nenhum roteamento assimétrico, a seguir a configuração de roteamento é mais complexa, mas você pode fazê-la ao usar o EIGRP. Para realizar isto, ajuste o atraso… nas interfaces de túnel dos roteadores de hub de volta a ser igual e use então o comando offset-list <acl> out <offset> <interface> no Roteadores do spoke aumentar a métrica EIGRP para rotas anunciou para fora as interfaces do túnel GRE ao hub alternativo. O retardo desigual ... entre as interfaces Tunnel0 e Tunnel1 no spoke ainda é usado; portanto, o roteador spoke preferirá seu roteador de hub principal. As alterações nos roteadores de raio são as seguintes:
roteador spoke1 version 12.3 ! hostname Spoke1 ! ... ! interface Tunnel0 bandwidth 1000 ip address 10.0.0.11 255.255.255.0 ip mtu 1400 ip nhrp authentication test ip nhrp map 10.0.0.1 172.17.0.1 ip nhrp network-id 100000 ip nhrp holdtime 300 ip nhrp nhs 10.0.0.1 delay 1000
tunnel source Ethernet0 tunnel destination 172.17.0.1 tunnel key 100000
tunnel protection ipsec profile vpnprof ! interface Tunnel1 bandwidth 1000 ip address 10.0.1.11 255.255.255.0 ip mtu 1400 ip nhrp authentication test ip nhrp map 10.0.1.1 172.17.0.5 ip nhrp network-id 100001 ip nhrp holdtime 300 ip nhrp nhs 10.0.1.1 delay 1500
tunnel source Ethernet0 tunnel destination 172.17.0.5 tunnel key 100001
tunnel protection ipsec profile vpnprof !
... !
router eigrp 1
offset-list 1 out 12800 Tunnel1
network 10.0.1.0 0.0.0.255 network 192.168.1.0 distribute-list 1 out no auto-summary ! access-list 1 permit 192.168.1.0 ! roteador spoke2 version 12.3 ! hostname Spoke2 ! ... ! interface Tunnel0 bandwidth 1000 ip address 10.0.0.12 255.255.255.0 ip mtu 1400 ip nhrp authentication test ip nhrp map 10.0.0.1 172.17.0.1 ip nhrp network-id 100000 ip nhrp holdtime 300 ip nhrp nhs 10.0.0.1 delay 1500
tunnel source Ethernet0 tunnel destination 172.17.0.1 tunnel key 100000
tunnel protection ipsec profile vpnprof ! interface Tunnel1 bandwidth 1000 ip address 10.0.1.12 255.255.255.0 ip mtu 1400 ip nhrp authentication test ip nhrp map 10.0.1.1 172.17.0.5 ip nhrp network-id 100001 ip nhrp holdtime 300 ip nhrp nhs 10.0.1.1 delay 1000
tunnel source Ethernet0 tunnel destination 172.17.0.5 tunnel key 100001
tunnel protection ipsec profile vpnprof !
... !
router eigrp 1
offset-list 1 out 12800 Tunnel1
network 10.0.0.0 0.0.0.255 network 10.0.1.0 0.0.0.255 network 192.168.2.0 distribute-list 1 out no auto-summary ! access-list 1 permit 192.168.2.0 !
Nota: O valor de deslocamento de 12800 (50*256) foi adicionado à métrica EIGRP porque é menor de 25600 (100*256). É este valor (25600)
que é adicionado à métrica do EIGRP para as rotas aprendidas entre os roteadores do hub. Usando 12800 no comando offset-list, o roteador de hub alternativo enviará pacotes diretamente ao Roteadores do spoke, um pouco do que enviando estes pacotes através dos Ethernet para atravessar o roteador de hub preliminar para aquele spokes. A métrica nas rotas anunciadas pelos roteadores hub ainda será aquela em que o roteador hub principal correto será o preferido. Lembre-se de que metade dos spokes possuem o hub1 como seu roteador primário e a outra metade o hub 2.
Nota: Se o valor do deslocamento de tempo foi aumentado em mais de 25600 (100*256), então os hubs encaminharão os pacotes pela metade
dos roteadores de spoke por outro hub via interface de Ethernet mesmo se os roteadores atrás dos hubs preferirem o hub correto para enviar os pacotes aos roteadores de spoke.
Nota: O comando saída de lista de distribuição 1 também foi adicionado, pois é possível que as rotas conhecidas de um roteador de hub via uma
interface de túnel em um raio possa ser anunciado de volta para o outro hub pelo outro túnel. O comando distribute-list ... assegura que o roteador de concentrador somente possa anunciar suas próprias rotas.
Nota: Se você prefere controlar as propagandas do roteamento nos roteadores de hub um pouco do que no Roteadores do spoke, a seguir os comandos offset-list <acl1> in <value> <interface> e distribute-list <acl2> in podem ser configurados nos roteadores de hub em vez no
spokes. A lista de acesso <acl2> alistaria as rotas de trás todo o spokes e a lista de acesso <acl1> alistaria somente as rotas do spokes de trás onde um outro roteador de hub é ser o hub preliminar.
Com estas mudanças as rotas olham como o seguinte: Hub1: D 192.168.1.0/24 [90/2841600] via 10.0.0.11, 00:12:11, Tunnel2 D 192.168.2.0/24 [90/2854400] via 10.0.0.12, 00:13:24, Tunnel2 Hub2: D 192.168.1.0/24 [90/2854400] via 10.0.1.11, 00:09:58, Tunnel0 D 192.168.2.0/24 [90/2841600] via 10.10.1.12, 00:11:11, Tunnel0 R2: D 192.168.1.0/24 [90/2867200] via 192.168.0.1, 00:13:13, Ethernet1/0/3 D 192.168.2.0/24 [90/2867200] via 192.168.0.2, 00:14:25, Ethernet1/0/3 Spoke1: D 192.168.0.0/24 [90/2841600] via 10.0.0.1, 00:16:12, Tunnel0 Spoke2: D 192.168.0.0/24 [90/2841600] via 10.0.1.1, 00:18:54, Tunnel1
Conclusão
A solução de DMVPN fornece a seguinte funcionalidade para escalar melhor grandes e redes pequenas do IPSec VPN. O DMVPN permite a melhor escamação na malha cheia ou no IPsec VPN da malha parcial.
É especialmente útil quando o tráfego spoke-to-spoke é esporádico (por exemplo, cada spoke não está enviando constantemente dados a cada outro spoke). Permite o algum falou para enviar dados diretamente a todo o outro spoke, como por muito tempo há uma conectividade IP direta entre o spokes.
DMVPN suporta nós IPsec com endereços dinamicamente atribuídos (tais como o cabo, o ISDN, e o DSL).
Isto se aplica a hub-e-spoke e também a redes em malha. É possível que o DMVPN requisite que o link hub-spoke esteja constantemente ativo.
O DMVPN simplifica a adição de nós de VPN.
Para adicionar um novo roteador de spoke, basta configurá-lo e conectá-lo à rede (embora talvez seja necessário adicionar informações de autorização do ISAKMP para o novo spoke no hub). O hub aprenderá dinamicamente sobre o spoke novo e o protocolo de roteamento dinâmico propagará o roteamento ao hub e a todo spokes restante.
O DMVPN reduz o tamanho da configuração necessária em todo o Roteadores no VPN. Esse também é o caso das redes VPN somente hub-and-spoke de GRE+IPsec.
O DMVPN usa o GRE e, portanto, suporta o tráfego de roteamento dinâmico e multicast de IP no VPN.
Isto significa que um protocolo de roteamento dinâmico pode ser usado, e o “Hubs redundante” pode ser apoiado pelo protocolo. São suportados aplicativos multicast também.
O DMVPN oferece suporte ao tunelamento dividido nos spokes.
Informações Relacionadas
White Paper de Tecnologia
© 1992-2015 Cisco Systems Inc. Todos os direitos reservados. Data da Geração do PDF: 19 Setembro 2015