DMVPN PDF

VPN IPSec multipoint dynamiques (utilisation de GRE
multipoint/NHRP pour tendre les VPN IPsec)

Contenu
Introduction
Informations gnrales
La solution DMVPN
Dmarrage automatique du cryptage IPsec
Cration dynamique de tunnel pour les liaisons Spoke-to-Hub
Cration dynamique de tunnel pour les trafics Spoke-to-Spoke
Prise en charge des protocoles de routage dynamiques
Commutation rapide de Cisco Express Forwarding pour mGRE
Utilisation du routage dynamique sur les VPN protgs par IPsec
Configuration de base
Exemples des tableaux de routage sur les routeurs en toile
Rduction de la taille de la configuration du routeur concentrateur
Prise en charge des adresses dynamiques sur les rayons
Rseau en toile multipoint dynamique
VPN IPSec multipoint dynamique
RIP
EIGRP
OSPF
Conditions initiales
Conditions aprs la cration d'une liaison dynamique entre Spoke1 et Spoke2
VPN IPSec multipoint dynamique avec doubles concentrateurs
Double concentrateur - Affichage simple DMVPN
Conditions initiales et modifications
Double concentrateur - Double affichage DMVPN
Conclusion
Informations connexes
Introduction
Ce document discute des VPN IPsec multipoint dynamique (DMVPN) et pourquoi une socit pourrait vouloir concevoir ou migrer leur rseau
pour se servir de cette nouvelle solution VPN IPsec dans le logiciel Cisco IOS.
Informations gnrales
Les socits peuvent avoir besoin d'interconnecter beaucoup de sites un site principal, et peut-tre galement entre eux, travers Internet tout
en cryptant le trafic pour le protger. Par exemple, des magasins qui doivent se connecter au sige social de la socit pour la gestion des stocks
et les commandes peuvent galement avoir besoin de se connecter d'autres magasins de la socit pour vrifier la disponibilit des produits.
Dans le pass, la seule faon d'tablir la connexion tait d'employer un rseau double couche tel que l'ISDN ou le Frame Relay pour
interconnecter tout. L'installation et l'investissement pour ces liaisons cbles pour le trafic IP interne peuvent tre longs et coteux. Si tous les
sites (site principal compris) ont dj un accs Internet relativement bon march, alors cet accs Internet peut galement tre utilis pour la
communication IP interne entre les magasins et le sige social l'aide des tunnels IPsec pour assurer la confidentialit et l'intgrit des donnes.
Pour que les socits tablissent de grands rseaux d'IPsec interconnectant leurs sites travers Internet, vous devez tre capable de faire voluer
le rseau d'IPsec. IPsec crypte le trafic entre deux points de terminaison (homologues), et le cryptage est fait par les deux points de terminaison
l'aide d'un secret partag. Puisque ce secret est partag seulement entre ces deux points de terminaison, les rseaux crypts sont en soi une
collection de liaisons point point. Pour cette raison, IPsec est intrinsquement un rseau tunnel point point. La mthode la plus faisable pour
faire voluer un grand rseau point point est de l'organiser en un rseau en toile ou en un rseau maill complet (partiel). Dans la plupart des
rseaux, la majorit du trafic IP se fait entre les rayons et le concentrateur, et trs peu entre les rayons, ainsi la conception de rseau toile est
souvent le meilleur choix. Cette conception s'accorde galement avec des rseaux Frame relay plus anciens puisqu'il tait beaucoup trop cher de
payer des liaisons entre tous les sites dans ces rseaux.
En utilisant Internet comme l'interconnexion entre le concentrateur et les rayons, les rayons ont galement l'accs direct entre eux sans frais
supplmentaires, mais il a t trs difficile, voire impossible, d'installer et/ou grer un rseau maill complet (partiel). Les rseaux maills
complets ou partiels sont souvent souhaitables parce qu'il peut y avoir des conomies de cots si le trafic de routage spoke-to-spoke peut se faire,
au lieu de passer par le concentrateur. Le trafic spoke-to-spoke traversant le concentrateur utilise ses ressources et peut provoquer des dlais,
particulirement en utilisant le cryptage IPsec, puisque le concentrateur devra dcrypter les paquets des rayons envoyeurs, puis recrypter le trafic
pour l'envoyer au rayon receveur. Un autre exemple o le trafic de routage direct spoke-to-spoke serait utile est le cas o deux rayons sont dans
la mme ville et le concentrateur se trouve l'autre bout du pays.
Alors que les rseaux en toile IPsec taient dploys et se dveloppaient en taille, il est devenu plus souhaitable de les faire router des paquets
d'IP aussi dynamiquement que possible. Dans anciens rseaux en toile Frame Relay, ceci a t accompli en excutant un protocole de routage
dynamique comme OSPF ou EIGRP sur des liaisons Frame Relay. C'tait utile pour annoncer dynamiquement l'accessibilit des rseaux en
toile et prendre en charge galement la redondance dans le rseau de routage IP. Si le rseau perdait un routeur concentrateur, un routeur de
concentrateur de secours pouvait automatiquement lui succder pour maintenir la connectivit rseau aux rseaux en toile.
Il y a un problme fondamental avec les tunnels IPsec et les protocoles de routage dynamique. Les protocoles de routage dynamiques se basent
sur l'utilisation de Multicast IP ou de paquets de diffusion, mais IPsec ne prend pas en charge le cryptage de multicast ou des paquets de
diffusion. La mthode actuelle pour rsoudre ce problme est d'utiliser les tunnels d'encapsulation de routage gnrique (GRE) en combination
avec le chiffrement IPsec.
Les tunnels GRE prennent en charge le transport du Multicast IP et des paquets de diffusion l'autre extrmit du tunnel GRE. Le paquet de
tunnel GRE est un paquet de monodiffusion IP. Ainsi, le paquet GRE peut tre crypt l'aide d'IPsec. Dans ce scnario, GRE effectue le travail
de tunnel et IPsec se charge de la partie cryptage pour supporter le rseau VPN. Lorsque des tunnels GRE sont configurs, les adresses IP pour
les points de terminaison du tunnel (source du tunnel, destination du tunnel) doivent tre connues de l'autre point de terminaison et doit tre
routable par Internet. Ceci signifie que le concentrateur et tous les routeurs en toile dans ce rseau doivent avoir des adresses IP non-prives
statiques.
Pour de petites connexions de site Internet, il est courant que l'adresse IP externe d'un rayon change chaque fois qu'il se connecte Internet
parce que leur fournisseur d'accs Internet (ISP) fournit dynamiquement l'adresse d'interface externe (par l'intermdiaire du protocole DHCP
(Dynamic Host Configuration Protocol)) chaque fois que le rayon est en ligne (Ligne d'abonn numrique dbit asymtrique (ADSL) et
services de cble). Cette allocation dynamique de l'adresse externe du routeur permet l'ISP d'largir l'utilisation de leur espace d'adresse
Internet, puisque tous les utilisateurs ne seront pas en ligne en mme temps. Il peut tre considrablement plus cher de payer le fournisseur pour
allouer une adresse statique au routeur en toile. L'excution d'un protocole de routage dynamique sur un VPN IPSec requiert l'utilisation de
tunnels GRE, mais vous perdez la possibilit d'avoir des rayons avec des adresses IP dynamiquement allous sur leurs interfaces physiques
extrieures.
Les restrictions ci-dessus et quelques autres sont rcapitules aux quatre points suivants :
IPsec emploie une liste de contrle d'accs (ACL) pour dfinir quelles donnes doivent tre chiffres. Ainsi, chaque fois que un nouveau
(sous-)rseau est ajout derrire un rayon ou le concentrateur, le client doit modifier l'ACL sur le concentrateur et sur les routeurs en toile.
Si le fournisseur d'accs gre le routeur, alors le client doit informer le fournisseur d'accs afin que l'ACL IPsec soit modifi de sorte que
le nouveau trafic de routage soit crypt.
Avec de grands rseaux en toile, la taille de la configuration sur le routeur concentrateur peut devenir trs grande jusqu' devenir
inutilisable. Par exemple, un routeur concentrateur aurait besoin de jusqu' 3 900 lignes de configuration pour prendre en charge 300
routeurs en toile. C'est tellement grand qu'il serait difficile d'afficher la configuration et de rechercher la section de la configuration qui
se rapporte un problme actuel qui est en cours de dbogage. galement, cette configuration de taille peut tre trop grande pour la
NVRAM et devrait tre enregistre en mmoire flash.
GRE + IPsec doivent connatre l'adresse d'homologue du point de terminaison. Les adresses IP des rayons sont connectes directement
Internet par l'intermdiaire de leur propre FAI, et elles sont souvent installes de sorte que leurs adresse d'interface externe n'est pas fixe.
Les adresses IP peuvent changer chaque fois que le site se met en ligne (par l'intermdiaire du DHCP).
Si les rayons doivent parler directement entre eux via VPN IPSec, alors le rseau en toile doit devenir un rseau maill global. Comme il
n'est pas possible de savoir quel rayon aura besoin de parler directement avec un autre, un rseau maill global est ncessaire, mme si
chaque rayon n'aura peut-tre pas besoin de parler directement avec tous les autres rayons. En outre, il n'est pas faisable de configurer
IPsec sur un petit routeur en toile de sorte qu'il ait une connexion directe avec tous les autres routeurs en toile dans le rseau ; ainsi les
routeurs en toile peuvent avoir besoin d'tre des routeurs plus puissants.
La solution DMVPN
La solution de routage DMVPN emploie le multipoint GRE (mGRE) et le protocole de rsolution de sauts successifs (NHRP), avec IPsec et
quelques nouvelles amliorations, pour rsoudre les problmes de routage ci-dessus d'une manire volutive.
Dmarrage automatique du cryptage IPsec

Quand la solution DMVPN n'est pas utilise, le tunnel de cryptage IPsec n'est pas lanc jusqu' ce qu'il y ait du trafic de donnes qui requiert
l'utilisation de ce tunnel IPsec. Il peut falloir entre 1 et 10 secondes pour terminer le dmarrage du tunnel IPsec et le trafic de donnes est stopp
pendant ce temps. En utilisant GRE avec IPsec, la configuration de tunnel GRE inclut dj l'adresse de l'homologue de tunnel GRE ( destination
du tunnel) , qui est galement l'adresse d'homologue IPsec. Chacune des deux adresses est prconfigure.
Si vous utilisez le Tunnel Endpoint Discovery (TED) et des cartes de chiffrement dynamique sur le routeur concentrateur, alors vous pouvez
viter de devoir prconfigurer les adresses d'homologue IPsec sur le concentrateur, mais un probe and response de TED doit tre envoy et reu
avant que la ngociation ISAKMP puisse commencer. Ceci ne devrait pas tre ncessaire puisque, en utilisant GRE, les adresses d'origine et de
destination d'homologue sont dj connues. Elles sont en configuration ou rsolues avec le NHRP (pour les tunnels GRE multipoints).
Avec la solution de routage DMVPN, IPsec est dclench immdiatement pour les tunnels GRE point par point et multipoints. En outre, il n'est
pas ncessaire de configurer un ACL de cryptage, puisque ceux-ci seront automatiquement drivs des adresses d'origine et de destination du
tunnel GRE. Les commandes suivantes sont utilises pour dfinir les paramtres de cryptage IPsec. Notez qu'il n'y a aucune commande set peer
... ou match address ... requise parce que ces informations sont drives directement des mappages du tunnel GRE ou du NHRP associs.
crypto ipsec profile <profile-name>

set transform-set <transform-name>
La commande suivante associe une interface du tunnel au profil IPSec.
interface tunnel<number>
...
tunnel protection ipsec profile <profile-name>
Cration dynamique de tunnel pour les liaisons Spoke-to-Hub

Aucune information GRE ou IPsec sur un rayon n'est configure sur le routeur concentrateur dans le rseau DMVPN. Le tunnel GRE du routeur
en toile est configur (par l'intermdiaire des commandes de NHRP) avec des informations concernant le routeur concentrateur. Quand le
routeur en toile dmarre, il lance automatiquement le tunnel IPsec avec le routeur concentrateur comme dcrit ci-dessus. Il emploie alors le
NHRP pour informer le routeur concentrateur de son adresse IP d'interface physique actuelle. Ceci est utile pour trois raisons :
Si le routeur en toile fait attribuer son adresse IP d'interface physique dynamiquement (comme avec l'ADSL ou le modem cble), alors le
routeur concentrateur ne peut pas tre configur avec ces informations puisque chaque fois que le routeur en toile se recharge il obtiendra
une nouvelle adresse IP d'interface physique.
La configuration du routeur concentrateur se raccourcit et est simplifie puisqu'elle n'a pas besoin d'informations GRE ou IPsec
concernant les routeurs partenaire. Toutes ces informations sont apprises dynamiquement via NHRP.
Quand vous ajoutez un nouveau routeur en toile au rseau DMVPN, vous n'avez pas besoin de modifier la configuration sur le
concentrateur ou sur les routeurs en toile actuels. Le nouveau routeur en toile est configur avec les informations du concentrateur, et
quand il dmarre, il s'inscrit dynamiquement au routeur concentrateur. Le protocole de routage dynamique propage les informations de
routage pour ce rayon au concentrateur. Le concentrateur propage ces nouvelles informations de routage aux autres rayons. Il propage
galement les informations de routage des autres rayons ce rayon.
Cration dynamique de tunnel pour les trafics Spoke-to-Spoke

Comme indiqu plus tt, actuellement dans un rseau maill, tous les tunnels point point IPsec (ou IPsec+GRE) doivent tre configurs sur tous
les routeurs, mme si certains/la plupart de ces tunnels ne sont pas ncessaires tout moment. Avec la solution DMVPN, un routeur est le
concentrateur, et tous les autres routeurs (rayons) sont configurs avec des tunnels vers le concentrateur. Les tunnels de rayon--concentrateur
sont continuellement en ligne, et les rayons n'ont pas besoin de la configuration pour les tunnels directs aux autres rayons. Au lieu de cela, quand
un rayon veut transmettre un paquet un autre rayon (tel que le sous-rseau derrire un autre rayon), elle emploie NHRP pour dterminer
dynamiquement l'adresse de destination requise du rayon cible. Le routeur concentrateur agit en tant que serveur NHRP et traite cette demande
pour le rayon source. Les deux rayons crent alors dynamiquement un tunnel IPsec entre eux (par l'intermdiaire de l'interface simple mGRE) et
des donnes peuvent tre directement transfres. Ce tunnel dynamique de rayon rayon sera automatiquement dmoli aprs une priode
d'inactivit (configurable).
Prise en charge des protocoles de routage dynamiques

La solution DMVPN est base sur les tunnels GRE qui prennent en charge des paquets de multicast/diffusion IP de transmission tunnel. Ainsi, la
solution DMVPN prend en charge galement les protocoles de routage dynamiques s'excutant au-dessus des tunnels IPsec+mGRE.
Prcdemment, le NHRP vous obligeait configurer explicitement le mappage diffusion/multicast pour que les adresses IP du tunnel de
destination pour prendre en charge la transmission tunnel GRE des paquets IP multicast et de diffusion. Par exemple, au niveau du concentrateur
vous auriez besoin de la ligne de configuration ip nhrp map multicast <spoke-n-addr> pour chaque rayon. Avec la solution DMVPN, les
adresses des rayons ne sont pas connues l'avance et cette configuration n'est donc pas possible. Au lieu de cela, NHRP peut tre configur pour
ajouter automatiquement chaque rayon la liste de destination multicast sur le concentrateur avec la commande ip nhrp map multicast
dynamic. Avec cette commande, quand les routeurs en toile enregistrent leur mappage de NHRP de monodiffusion avec le serveur NHRP
(concentrateur), NHRP crera galement un mappage diffusion/multicast pour ce rayon. Ceci limine le besoin de connatre les adresses des
rayons l'avance.
Commutation rapide de Cisco Express Forwarding pour mGRE

Actuellement, le trafic dans une interface de mGRE est commut par processus, ce qui entrane des performances mdiocres. La solution
DMVPN ajoute la commutation de Cisco Express Forwarding pour le trafic mGRE, ce qui entrane des performances bien meilleures. Il n'y a
aucune commande de configuration ncessaire pour activer cette fonctionnalit. Si la commutation de Cisco Express Forwarding est autorise sur
l'interface de tunnel GRE et sur les interfaces physiques sortantes/entrantes, alors les paquets du tunnel GRE multipoints seront commuts par
Cisco Express Forwarding.
Utilisation du routage dynamique sur les VPN protgs par IPsec
Cette section dcrit la situation actuelle (antrieure la solution DMVPN). IPsec est mis en application sur les routeurs Cisco par l'intermdiaire
d'un ensemble de commandes qui dfinissent le cryptage, puis une commande crypto map <map-name> applique sur l'interface externe du
routeur. En raison de cette conception et du fait qu'il n'y a actuellement aucune norme pour l'usage d'IPsec pour crypter des paquets IP
multicast/diffusion, les paquets du protocole de routage IP ne peuvent pas tre transfrs par le tunnel IPsec et aucune modification du
routage ne peut tre dynamiquement propage de l'autre ct du tunnel IPsec.
Remarque: Tous les protocoles de routage dynamiques except le BGP utilisent des paquets IP de diffusion ou de multicast. Les tunnels GRE
sont utiliss en combinaison avec IPsec pour rsoudre ce problme de routage.
Les tunnels GRE sont mis en application sur les routeurs Cisco l'aide d'une interface de tunnel virtuel ( interface tunnel<#>). Le protocole de
transmission tunnel GRE est conu pour prendre en charge les paquets IP multicast/diffusion pour qu'un protocole de routage dynamique puisse
tre excut sur un tunnel GRE. Les paquets de tunnel GRE sont des paquets de monodiffusion IP qui encapsulent le paquet IP
multicast/monodiffusion original. Vous pouvez alors utiliser IPsec pour crypter le paquet du tunnel GRE. Vous pouvez galement excuter IPsec
en mode transport et conomiser 20 octets puisque GRE a dj encapsul le paquet des donnes originales. Vous n'avez donc pas besoin qu'IPsec
encapsule le paquet IP GRE dans un autre en-tte IP.
En excutant IPsec en mode de transport, il y a une restriction qui fait que les adresses IP d'origine et de destination du paquet chiffrer doivent
correspondre aux adresses d'homologue IPsec (le routeur lui-mme). Dans ce cas, ceci signifie juste que le point de destination du tunnel GRE et
des adresses de l'homologue IPsec doivent tre identiques. Ce n'est pas un problme puisque les mmes routeurs sont la fois les points de
destination d'IPsec et du tunnel GRE. En combinant des tunnels GRE avec le cryptage IPsec, vous pouvez utiliser un protocole de routage
dynamique IP pour mettre jour les tables de routage aux deux extrmits du tunnel crypt. Les entres de la table de routage IP pour les rseaux
qui ont t appris via le tunnel crypt auront l'autre extrmit du tunnel (adresse IP de l'interface de tunnel GRE) comme prochain saut d'IP.
Ainsi, si les rseaux changent d'un ct ou de l'autre du tunnel, alors l'autre ct apprendra dynamiquement la modification et la connectivit
continuera sans aucune modification de configuration des routeurs.
Configuration de base
Ce qui suit est une configuration standard IPsec+GRE point point. Aprs cela y a une srie d'exemples de configuration o des caractristiques
spcifiques de la solution DMVPN sont ajoutes dans les tapes pour montrer les diffrentes fonctionnalits de DMVPN. Chaque exemple met
profit les exemples prcdents pour montrer comment utiliser la solution DMVPN dans des conceptions de rseaux de plus en plus complexes.
Cette succession d'exemples peut tre utilise comme modle pour migrer un VPN IPsec+GRE actuel vers un DMVPN. Vous pouvez arrter le
transfert n'importe quel point si cet exemple de configuration particulier correspond vos exigences en termes de conception de rseaux.
Concentrateur et rayon IPsec + GRE (n = 1,2,3,)
Routeur concentrateur
version 12.3
!
hostname Hub
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco47 address 0.0.0.0
!
crypto ipsec transform-set trans2 esp-des esp-md5-hmac
mode transport
!
crypto map vpnmap1 local-address Ethernet0
crypto map vpnmap1 10 ipsec-isakmp
set peer 172.16.1.1

set transform-set trans2
match address 101
set peer 172.16.2.1
match address 102
. . .
crypto map vpnmap1 <10*n> ipsec-isakmp
set peer 172.16.<n>.1
match address <n+100>
!
interface Tunnel1
bandwidth 1000
ip address 10.0.0.1 255.255.255.252
ip mtu 1400
delay 1000
tunnel source Ethernet0
tunnel destination 172.16.1.1
!
interface Tunnel2
bandwidth 1000
ip address 10.0.0.5 255.255.255.252
ip mtu 1400
delay 1000
!
. . .
!
interface Tunnel<n>
bandwidth 1000
ip address 10.0.0.<4n-3> 255.255.255.252
ip mtu 1400
delay 1000
tunnel destination 172.16.<n>.1
!
interface Ethernet0
ip address 172.17.0.1 255.255.255.0
crypto map vpnmap1
!
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
!
access-list 101 permit gre host 172.17.0.1 host 172.16.1.1
...
access-list <n+100> permit gre host 172.17.0.1 host 172.16.<n>.1
Routeur Spoke1
version 12.3
!
hostname Spoke1
!
!
mode transport
!
set peer 172.17.0.1
match address 101
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.2 255.255.255.252
ip mtu 1400
delay 1000
!
interface Ethernet0
ip address 172.16.1.1 255.255.255.252
crypto map vpnmap1
!
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 192.168.1.0 0.0.0.255
no auto-summary
!
Routeur Spoke2
version 12.3
!
hostname Spoke2
!
!
mode transport
!
set peer 172.17.0.1
match address 101
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.6 255.255.255.252
ip mtu 1400
delay 1000
!
interface Ethernet0
ip address 172.16.2.1 255.255.255.252
crypto map vpnmap1
!
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 192.168.2.0 0.0.0.255
no auto-summary
!
Routeur Spoke<n>
version 12.3
!
hostname Spoke<n>
!
!
mode transport
!
set peer 172.17.0.1
match address 101
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.<4n-2> 255.255.255.252
ip mtu 1400
delay 1000
!
interface Ethernet0
ip address 172.16.<n>.1 255.255.255.252
crypto map vpnmap1
!
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 192.168.<n>.0 0.0.0.255
no auto-summary
!
access-list 101 permit gre host 172.16.<n>.1 host 172.17.0.1
Dans la configuration ci-dessus, les listes de contrle d'accs sont utilises pour dfinir quel trafic sera crypt. Sur le concentrateur et les routeurs
en toile, cette ACL doit seulement correspondre aux paquets IP du tunnel GRE. Peu importe comment les rseaux sont modifi l'une ou
l'autre extrmit, les paquets IP de tunnel GRE ne seront pas modifis, donc cet ACL n'a pas besoin d'tre modifi.
Remarque: En utilisant des versions du logiciel Cisco IOS antrieures la 12.2(13)T, vous devez appliquer la commande de configuration
crypto map vpnmap1 aux interfaces de tunnel GRE (Tunnel<x>) et l'interface physique (Ethernet0). Avec Cisco IOS version 12.2(13)T et
ultrieures, vous appliquez seulement la commande de configuration crypto map vpnmap1 l'interface physique (Ethernet0).
Exemples des tableaux de routage sur les routeurs en toile

Tableau de routage sur le routeur concentrateur
172.17.0.0/24 is subnetted, 1 subnets
C
172.17.0.0 is directly connected, Ethernet0
10.0.0.0/30 is subnetted, <n> subnets
C
10.0.0.0 is directly connected, Tunnel1
C
...
C
10.0.0.<4n-4> is directly connected, Tunnel<n>
C
192.168.0.0/24 is directly connected, Ethernet1
D
192.168.1.0/24 [90/2841600] via 10.0.0.2, 18:28:19, Tunnel1
D
192.168.2.0/24 [90/2841600] via 10.0.0.6, 2d05h, Tunnel2
...
D
192.168.<n>.0/24 [90/2841600] via 10.0.0.<4n-2>, 2d05h, Tunnel<n>
Tableau de routage sur le routeur Spoke1

C
C
D
10.0.0.4 [90/2841600] via 10.0.0.1, 23:00:58, Tunnel0
...
D
10.0.0.<4n-4> [90/2841600] via 10.0.0.1, 23:00:58, Tunnel0
D
192.168.0.0/24 [90/2841600] via 10.0.0.1, 23:00:58, Tunnel0
C
192.168.1.0/24 is directly connected, Loopback0
D
192.168.2.0/24 [90/3097600] via 10.0.0.1, 23:00:58, Tunnel0
...
D
192.168.<n>.0/24 [90/3097600] via 10.0.0.1, 23:00:58, Tunnel0
Tableau de routage sur le routeur Spoke<n>

C
172.16.<n>.0 is directly connected, Ethernet0
D
10.0.0.0 [90/2841600] via 10.0.0.1, 22:01:21, Tunnel0
D
10.0.0.4 [90/2841600] via 10.0.0.1, 22:01:21, Tunnel0
...
C
10.0.0.<4n-4> is directly connected, Tunnel0
D
192.168.0.0/24 [90/2841600] via 10.0.0.1, 22:01:21, Tunnel0
D
192.168.1.0/24 [90/3097600] via 10.0.0.1, 22:01:21, Tunnel0
D
192.168.2.0/24 [90/3097600] via 10.0.0.1, 22:01:21, Tunnel0
...
C
192.168.<n>.0/24 is directly connected, Ethernet0
Ceci est une configuration fonctionnelle de base qui est utilise comme point de dpart pour la comparaison avec des configurations plus
complexes possibles en utilisant la solution DMVPN. La premire modification rduira la taille de la configuration sur le routeur concentrateur.
Ce n'est pas important avec un nombre restreint de routeurs en toile, mais cela le devient quand il y a plus de 50 100 routeurs en toile.
Rduction de la taille de la configuration du routeur concentrateur
Dans l'exemple suivant, la configuration est modifie d'une faon minimale sur le routeur concentrateur et passe de plusieurs interfaces de tunnel
GRE point point, une interface de tunnel GRE multipoint. C'est une premire tape dans la solution DMVPN.
Il y a un seul bloc de lignes de configuration sur le routeur concentrateur pour dfinir les caractristiques la carte de cryptage pour chaque routeur
en toile. Ce bloc de configuration dfinit l'ACL de cryptage et l'interface de tunnel GRE pour ce routeur en toile. Ces caractristiques sont en
grande partie identiques pour tous les rayons, except pour les adresses IP (homologue dfini, destination du tunnel).
En regardant la configuration du routeur concentrateur ci-dessus, vous voyez qu'il y a au moins 13 lignes de configuration par routeur en toile ;
quatre pour la carte de cryptage, un pour l'ACL de cryptage, et huit pour l'interface de tunnel GRE. Le nombre total de lignes de configuration,
s'il y avait 300 routeurs en toile, est 3 900 lignes. Vous avez besoin galement de 300 (/30) sous-rseaux pour adresser chaque liaison de tunnel.
Il est trs difficile de grer une configuration de cette taille et bien plus difficile lors du dpannage du rseau priv virtuel. Pour rduire cette
valeur, vous pourriez utiliser des cartes de cryptage dynamique, qui rduiraient la valeur ci-dessus 1 200, laissant 2 700 lignes dans un rseau de
300 rayons.
Remarque: En utilisant des cartes de cryptage dynamique, le tunnel de cryptage IPsec doit tre lanc par le routeur en toile. Vous pouvez
galement utiliser ip unnumbered <interface> pour rduire le nombre de sous-rseaux requis pour les tunnels GRE, mais ceci peut rendre le
dpannage plus difficile plus tard.
Avec la solution DMVPN, vous pouvez configurer une seule interface de tunnel GRE multipoint et un seul profil IPSec sur le routeur
concentrateur pour prendre en charge tous les routeurs en toile. Ceci permet la taille de la configuration sur le routeur concentrateur de rester
identique, quel que soit le nombre de routeurs en toile ajouts au rseau VPN.
La solution DMVPN introduit les nouvelles commandes suivantes :
crypto ipsec profile <name>

<ipsec parameters>
tunnel protection ipsec profile <name>
ip nhrp map multicast dynamic
La commande crypto ipsec profile <name> est utilise comme une carte de cryptage dynamique, et elle est conue spcifiquement pour les
interfaces de tunnel. Cette commande est utilise pour dfinir les paramtres pour le cryptage IPsec sur les tunnels VPN de rayon concentrateur
et de rayon rayon. Le seul paramtre qui est requis sous le profil est le jeu de transformations. L'adresse d'homologue IPsec et la clause match
address ... pour le proxy IPsec sont automatiquement drives des mappages NHRP pour le tunnel GRE.
La commande tunnel protection ipsec profile <name> est configure sous l'interface de tunnel GRE et est utilise pour associer l'interface de
tunnel GRE avec le profil IPSec. En outre, la commande tunnel protection ipsec profile <name> peut galement tre utilise avec un tunnel
GRE point point. Dans ce cas elle drivera les informations d'homologue et de proxy IPsec de la configuration tunnel sourceet tunnel
destination. Ceci simplifie la configuration puisque l'homologue IPsec et l'ACL de cryptage ne sont plus ncessaires.
Remarque: La commande tunnel protectionspcifie que le cryptage IPsec sera fait aprs que l'encapsulation GRE ait t ajoute au paquet.
Ces deux premires nouvelles commandes sont semblables la configuration d'une carte de cryptage et l'attribution de la carte de cryptage
une interface en utilisant la commande crypto map <name>. La grande diffrence est que, avec les nouvelles commandes, vous n'avez pas
besoin de spcifier l'adresse d'homologue IPsec ou une ACL pour correspondre aux paquets crypter. Ces paramtres sont automatiquement
dtermins partir des mappages NHRP pour l'interface de tunnel mGRE.
Remarque: En utilisant la commande tunnel protectionsur l'interface du tunnel, une commande crypto map ... n'est pas configure sur
l'interface sortante physique.
La dernire nouvelle commande, ip nhrp map multicast dynamic, permet au NHRP d'ajouter automatiquement des routeurs en toile aux
mappages NHRP multicast quand ces routeurs en toile lancent le tunnel mGRE+IPsec et enregistrent leurs mappages de monodiffusion NHRP.
Ceci est ncessaire pour permettre des protocoles de routage dynamiques de fonctionner sur des tunnels mGRE+IPsec entre le concentrateur et
les rayons. Si cette commande n'tait pas disponible, alors le routeur concentrateur devrait avoir une ligne distincte de configuration pour un
mappage multicast pour chaque rayon.
Remarque: Avec cette configuration, les routeurs en toile doivent lancer la connexion en tunnel mGRE+IPsec, puisque le routeur concentrateur
n'est configur avec aucune information sur les rayons. Mais ce n'est pas un problme parce qu'avec DMVPN le tunnel mGRE+IPsec est
automatiquement lanc quand le routeur en toile dmarre, et il reste toujours en ligne.
Remarque: Les exemples suivants montrent des interfaces de tunnel GRE point point sur les routeurs en toile et des lignes de configuration
NHRP ajoutes sur le concentrateur et sur les routeurs en toile pour prendre en charge le tunnel mGRE sur le routeur concentrateur. Les
modifications de la configuration sont les suivantes.
Routeur concentrateur (vieux)
crypto map vpnmap1 10 IPsec-isakmp
set peer 172.16.1.1

match address 101
set peer 172.16.2.1
match address 102
. . .
crypto map vpnmap1 <10n> IPsec-isakmp
set peer 172.16.<n>.1
match address <n+100>
!
interface Tunnel1
bandwidth 1000
ip address 10.0.0.1 255.255.255.252
ip mtu 1400
delay 1000
!
interface Tunnel2
bandwidth 1000
ip address 10.0.0.5 255.255.255.252
ip mtu 1400
delay 1000
!
. . .
!
interface Tunnel<n>
bandwidth 1000
ip address 10.0.0.<4n-1> 255.255.255.252
ip mtu 1400
delay 1000
tunnel destination 172.16.<n>.1
!
interface Ethernet0
ip address 172.17.0.1 255.255.255.0
crypto map vpnmap1
!
. . .
access-list <n+100> permit gre host 172.17.0.1 host 172.16.<n>.1
Routeur concentrateur (nouveau)

crypto ipsec profile vpnprof
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.1 255.255.255.0
ip mtu 1400
ip nhrp authentication test
ip nhrp network-id 100000
ip nhrp holdtime 600
no ip split-horizon eigrp 1
delay 1000
tunnel mode gre multipoint
tunnel key 100000
tunnel protection ipsec profile vpnprof
!
interface Ethernet0
ip address 172.17.0.1 255.255.255.0
Routeur Spoke<n> (vieux)

set peer 172.17.0.1
match address 101
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.<4n-2> 255.255.255.252
ip mtu 1400
delay 1000
!
interface Ethernet0
ip address 172.16.<n>.1 255.255.255.252
crypto map vpnmap1
!
. . .
!
!
Routeur Spoke<n> (nouveau)

set peer 172.17.0.1
match address 101
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.<n+1> 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
ip nhrp nhs 10.0.0.1
delay 1000
tunnel key 100000
!
interface Ethernet0
ip address 172.16.<n>.1 255.255.255.252
crypto map vpnmap1
!
. . .
!
!
Sur les routeurs en toile, le masque de sous-rseau a t modifi, et les commandes NHRP ont t ajoutes sous l'interface du tunnel. Les
commandes NHRP sont ncessaires puisque le routeur concentrateur emploie maintenant NHRP pour mapper l'adresse IP d'interface du tunnel
de rayon l'adresse IP d'interface physique de rayon.
ip address 10.0.0.<n+1> 255.255.255.0

ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
...
tunnel key 100000
Le sous-rseau est maintenant /24 au lieu de /30. Ainsi tous les noeuds sont dans le mme sous-rseau, au lieu d'tre dans des sous-rseaux
diffrents. Les rayons envoient toujours le trafic de rayon rayon par l'intermdiaire du concentrateur puisqu'ils utilisent une interface de tunnel
GRE point point. Les commandes ip nhrp authentication, ip nhrp network-id ... et tunnel keysont utilises pour mapper les paquets de
tunnel et les paquets NHRP l'interface de tunnel GRE multipoint et au rseau NHRP corrects quand ils sont reus sur le concentrateur. Les
commandes ip nhrp mapet ip nhrp nhs sont utilises par NHRP sur le rayon pour annoncer le mappage NHRP des rayons (10.0.0.<n+1> -->
172.16.<n>.1) au concentrateur. L'adresse 10.0.0.<n+1> est rcupre de la commande ip address ... sur l'interface de tunnel et l'adresse
172.16.<n>.1 est rcupre de la commande tunnel destination ... sur l'interface du tunnel.
Dans un cas o il y a 300 routeurs en toile, cette modification ramnerait le nombre de lignes de configuration sur le concentrateur de 3 900
lignes 16 lignes (une rduction de 3 884 lignes). La configuration sur chaque routeur en toile augmenterait de 6 lignes.
Prise en charge des adresses dynamiques sur les rayons

Sur un routeur Cisco, chaque homologue IPsec doit tre configur avec l'adresse IP de l'autre homologue IPsec avant que le tunnel IPsec puisse
tre lanc. Faire ceci pose problme si un routeur en toile a une adresse dynamique sur son interface physique, ce qui est rpandu pour les
routeurs qui sont connects par DSL ou cble.
TED permet un homologue IPsec de trouver un autre homologue IPsec en envoyant un paquet spcial d'Internet Security Association and Key
Management Protocol (ISAKMP) l'adresse IP de destination du paquet des donnes originales qui ont d tre chiffres. L'hypothse est que ce
paquet traversera le rseau intervenant le long du mme chemin que celui pris par le paquet de tunnel IPsec. Ce paquet sera pris par l'homologue
IPsec l'autre bout, qui rpondra au premier homologue. Les deux routeurs ngocieront alors ISAKMP et les Security Associations (SA) IPsec et
amneront le tunnel IPsec. Ceci fonctionnera seulement si les paquets de donnes chiffrer ont des adresses IP routables.
TED peut tre utilis en combination avec les tunnels GRE comme configur dans la section prcdente. Ceci a t test et fonctionne, bien qu'il
ait y eu une bogue dans les versions antrieures du logiciel Cisco IOS o TED a forc tout le trafic IP entre les deux homologues IPsec chiffrer,
pas seulement les paquets de tunnel GRE. La solution DMVPN fournit ceci et des fonctionnalits supplmentaires sans que les htes doivent
utiliser des adresses IP routables par Internet et sans devoir envoyer des paquets probe and response. Avec une lgre modification, la
configuration de la dernire section peut tre utilise pour prendre en charge des routeurs en toile avec des adresses IP dynamiques sur leurs
interfaces physiques extrieures.
Routeur concentrateur (aucune modification)
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.1 255.255.255.0
ip mtu 1400
delay 1000
tunnel key 100000
!
interface Ethernet0
ip address 172.17.0.1 255.255.255.0
Routeur Spoke<n> (vieux)

set peer 172.17.0.1
match address 101
!
...
!
Routeur Spoke<n> (nouveau)

set peer 172.17.0.1
set security-association level per-host
match address 101
!
...
!
access-list 101 permit gre any host 172.17.0.1
La fonctionnalit qui est utilise dans la nouvelle configuration en toile est la suivante.
Quand l'interface de tunnel GRE est lance, elle commencera envoyer des paquets d'enregistrement NHRP au routeur concentrateur. Ces
paquets d'enregistrement NHRP dclencheront IPsec. Sur le routeur en toile, les commandes set peer <peer-address> et match ip accesslist <ACL> sont configures. L'ACL spcifie GRE comme protocole, n'importe laquelle pour la source, et l'adresse IP du concentrateur
pour la destination.
Remarque: Il est important de noter que n'importe laquelle est utilise comme source dans l'ACL, et ceci doit tre le cas puisque l'adresse
IP du routeur en toile est dynamique et, en consquence, non connue avant que l'interface physique soit en activit. Un sous-rseau IP
peut tre utilis pour la source dans l'ACL si l'adresse dynamique d'interface du rayon sera restreinte une adresse dans ce sous-rseau.
La commande set security-association level per-host est utilise de sorte que la source IP dans le proxy IPsec des rayons soit juste
l'adresse actuelle d'interface physique des rayons (/32), plutt que n'importe laquelle dans l'ACL. Si n'importe laquelle dans
l'ACL tait utilise comme source dans le proxy IPsec, cela exclurait n'importe quel autre routeur en toile d'installer galement un tunnel
IPsec+GRE avec ce concentrateur. C'est parce que le proxy IPsec rsultant sur le concentrateur serait quivalent permit gre host
172.17.0.1 any. Ceci signifierait que tous les paquets de tunnel GRE destins n'importe quel rayon seraient chiffrs et envoys au
premier rayon qui a tabli un tunnel avec le concentrateur, puisque son proxy IPsec ajuste les paquets GRE pour chaque rayon.
Une fois que le tunnel IPsec est install, un paquet d'enregistrement NHRP va du routeur en toile au serveur de prochain saut (NHS)
configur. NHS est le routeur concentrateur de ce rseau en toile. Le paquet d'enregistrement NHRP fournit les informations pour que le
routeur concentrateur cre un mappage NHRP pour ce routeur en toile. Avec ce mappage, le routeur concentrateur peut alors transfrer
des paquets de donnes IP de monodiffusion ce routeur en toile sur un tunnel mGRE+IPsec. En outre, le concentrateur ajoute le routeur
en toile sa liste de mappage multicast NHRP. Le concentrateur commencera alors envoyer des paquets de routage IP multicast
dynamiques (si un protocole de routage dynamique est configur). Le rayon deviendra alors un protocole de routage voisin du
concentrateur, et ils s'changeront des mises jour de routage.
Concentrateur et rayon IPsec + mGRE
version 12.3
!
hostname Hub
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.1 255.255.255.0
ip mtu 1400
delay 1000
tunnel key 100000
!
interface Ethernet0
ip address 172.17.0.1 255.255.255.0
!
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
!
Notez que dans la configuration de concentrateur ci-dessus, les adresses IP des routeurs en toile ne sont pas configures. L'interface physique
externe du rayon et le mappage aux adresses IP de l'interface du tunnel du rayon sont apprises dynamiquement par le concentrateur par
l'intermdiaire de NHRP. Ceci permet l'adresse IP de l'interface physique externe du rayon d'tre attribue dynamiquement.
Routeur Spoke1
version 12.3
!
hostname Spoke1
!
crypto isakmp key cisco47 address 0.0.0.0 0.0.0.0
!
mode transport
!
set peer 172.17.0.1
match address 101
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.2 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
delay 1000
tunnel key 100000
!
interface Ethernet0
ip address dhcp hostname Spoke1
crypto map vpnmap1
!
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 192.168.1.0 0.0.0.255
no auto-summary
!
access-list 101 permit gre 172.16.1.0 0.0.0.255 host 172.17.0.1
Routeur Spoke2
version 12.3
!
hostname Spoke2
!
!
mode transport
!
set peer 172.17.0.1
match address 101
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.3 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
delay 1000
tunnel key 100000
!
interface Ethernet0
crypto map vpnmap1
!
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 192.168.1.0 0.0.0.255
no auto-summary
!
Les principales choses noter au sujet des configurations en toile sont :

L'adresse IP de l'interface physique externe (ethernet0) est dynamique via DHCP.
Crypto ACL (101) spcifie un sous-rseau comme source pour le proxy IPsec.
La commande suivante dans la carte de cryptage IPsec spcifie que l'association de scurit se fera par hte.
Tous les tunnels font partie du mme sous-rseau, puisque tous se connectent par l'intermdiaire de la mme interface multipoint GRE sur
le routeur concentrateur.
ip address 10.0.0.2 255.255.255.0
La combinaison de ces trois commandes rend inutile la configuration de l'adresse IP externe de l'interface physique du rayon. Le proxy IPsec qui
est utilis sera bas sur l'hte plutt que sur le sous-rseau.
La configuration sur les routeurs en toile possde l'adresse IP configure du routeur concentrateur, puisqu'elle doit lancer le tunnel IPsec+GRE.
Notez la similarit entre les configurations Spoke1 et Spoke2. Non seulement ces deux-l sont semblables, mais toutes les configurations de
routeur en toile seront semblables. Dans la plupart des cas, tous les rayons ont besoin simplement d'adresses IP uniques sur leurs interfaces, et le
reste de leurs configurations sera identique. Ceci permet de configurer et dployer beaucoup de routeurs en toile rapidement.
Les donnes NHRP sur le concentrateur et le rayon ressemblent cela.
Hub#show ip nhrp
10.0.0.2/32 via 10.0.0.2, Tunnel0 created 01:25:18, expire 00:03:51
Type: dynamic, Flags: authoritative unique registered
NBMA address: 172.16.1.4
...
10.0.0.<n>/32 via 10.0.0.<n>, Tunnel0 created 00:06:00, expire 00:04:25
NBMA address: 172.16.<n>.41
Routeur Spoke1
Spoke1#sho ip nhrp
10.0.0.1/32 via 10.0.0.1, Tunnel0 created 4d08h, never expire
Type: static, Flags: authoritative
Rseau en toile multipoint dynamique

La configuration sur les routeurs en toile ci-dessus ne se fonde pas sur des fonctionnalits de la solution DMVPN. Les routeurs en toile peuvent
donc excuter des versions du logiciel Cisco IOS antrieures la 12.2(13)T. La configuration sur le routeur concentrateur se fonde sur des
fonctionnalits DMVPN. Elle doit donc excuter Cisco IOS version 12.2(13)T ou ultrieure. Ceci vous permet de la souplesse pour dcider
quand vous devez mettre jour vos routeurs en toile qui sont dj dploys. Si vos routeurs en toile excutent galement Cisco IOS version
12.2(13)T ou ultrieures, alors vous pouvez simplifier la configuration en toile comme suit.
Routeur Spoke<n> (avant Cisco IOS 12.2(13)T)

set peer 172.17.0.1
match address 101
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.<n+1> 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
delay 1000
tunnel key 100000
!
interface Ethernet0
ip address dhcp hostname Spoke<n>
crypto map vpnmap1
!
. . .
!
access-list 101 permit gre any host 172.17.0.1
Routeur Spoke<n> (aprs Cisco IOS 12.2(13)T)

!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.<n+1> 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
delay 1000
tunnel key 100000
!
interface Ethernet0
!
Notez que nous avons fait ce qui suit :

1. Nous avons supprim la commande crypto map vpnmap1 10 ipsec-isakmp et l'avons remplace par crypto ipsec profile vpnprof.
2. Nous avons supprim la commande crypto map vpnmap1 des interfaces Ethernet0 et avons mis la commande tunnel protection ipsec
profile vpnprof sur l'interface Tunnel0.
3. Nous avons supprim l'ACL de cryptage, access-list 101 permit gre any host 172.17.0.1.
Dans ce cas les adresses et les proxys d'homologue IPsec sont automatiquement drivs de la configuration tunnel sourceet tunnel
destination. Les homologues et les proxys sont comme suit (comme dans le rsultat de la commande de show crypto ipsec sa) :
...
local ident (addr/mask/prot/port):
(172.16.1.24/255.255.255.255/47/0)
remote ident (addr/mask/prot/port):
(172.17.0.1/255.255.255.255/47/0)
...
local crypto endpt.: 172.17.1.24, remote crypto endpt.:172.17.0.1
...
En rsum, les configurations compltes suivantes incluent toutes les modifications apportes ce point de la Configuration de base
(concentrateur et rayon IPsec+GRE).
version 12.3
!
hostname Hub
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.1 255.255.255.0
ip mtu 1400
delay 1000
tunnel key 100000
!
interface Ethernet0
ip address 172.17.0.1 255.255.255.0
!
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
!
Il n'y a aucun changement dans la configuration de concentrateur.

Routeur Spoke1
version 12.3
!
hostname Spoke1
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.2 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
delay 1000
tunnel key 100000
!
interface Ethernet0
!
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 192.168.1.0 0.0.0.255
no auto-summary
!
Routeur Spoke2
version 12.3
!
hostname Spoke2
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.3 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
delay 1000
tunnel key 100000
!
interface Ethernet0
!
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 192.168.2.0 0.0.0.255
no auto-summary
!
VPN IPSec multipoint dynamique

Les concepts et la configuration dans cette section montrent les pleines fonctionnalits de DMVPN. NHRP fournit la fonctionnalit pour que les
routeurs en toile apprennent dynamiquement l'adresse extrieure d'interface physique des autres routeurs en toile dans le rseau VPN. Ceci
signifie qu'un routeur en toile aura assez d'informations pour construire dynamiquement un tunnel IPsec+mGRE directement d'autres routeurs
en toile. C'est avantageux puisque, si ce trafic de donnes de rayon--rayon tait envoy par l'intermdiaire du routeur concentrateur, alors il
devrait tre crypt/dcrypt, multipliant par deux le dlai et la charge sur le routeur concentrateur. Afin d'utiliser cette fonctionnalit, les routeurs
en toile doivent tre basculs de GRE point point (p-pGRE) vers des interfaces du tunnel GRE multipoints (mGRE). Ils doivent galement
apprendre (les sous) rseaux qui sont disponibles derrire les autres rayons avec un prochain saut d'IP de l'adresse IP du tunnel de l'autre routeur
en toile. Les routeurs en toile apprennent ces (sous) rseaux par l'intermdiaire du protocole de routage IP dynamique s'excutant au-dessus du
tunnel IPsec+mGRE avec le concentrateur.
Le protocole de routage IP dynamique excut sur le routeur concentrateur peut tre configur pour reflter les routes apprises d'un rayon vers la
mme interface de tous les autres rayons, mais le prochain saut d'IP sur ces routes sera habituellement le routeur concentrateur et non le routeur
en toile partir duquel le concentrateur a appris la route.
Remarque: Le protocole de routage dynamique fonctionne seulement sur les liaisons du concentrateur et des rayons, il ne s'excute pas sur les
liaisons dynamiques de rayon rayon.
Les protocoles de routage dynamique (RIP, OSPF et EIGRP) doivent tre configurs sur le routeur concentrateur pour annoncer les routes vers
l'interface de tunnel mGRE et pour dfinir le prochain saut d'IP au routeur en toile d'origine pour des routes apprises d'un rayon lorsque la
route est annonce vers les autres rayons.
Ce qui suit sont des conditions requises pour les configurations du protocole de routage.
RIP
Vous devez dsactiver le dcoupage de l'horizon sur l'interface de tunnel mGRE sur le concentrateur, autrement, RIP n'annoncera pas les routes
apprises par l'intermdiaire de l'interface mGRE vers cette mme interface.
no ip split-horizon
Aucune autre modification n'est ncessaire. Le routage RIP utilisera automatiquement le prochain saut d'IP initial sur les routes qu'il annonce
vers la mme interface o il a appris ces routes.
EIGRP
Vous devez dsactiver le dcoupage de l'horizon sur l'interface de tunnel mGRE sur le concentrateur, autrement, EIGRP n'annoncera pas les
routes apprises par l'intermdiaire de l'interface mGRE vers cette mme interface.
no ip split-horizon eigrp <as>
Le routage EIGRP dfinira, par dfaut, le prochain saut d'IP pour tre le routeur concentrateur pour des routes qu'il annonce, mme lorsqu'il
annonce ces routes vers la mme interface o il les a apprises. Donc, dans ce cas, vous avez besoin de la commande de configuration suivante
pour demander EIGRP d'utiliser le prochain saut initial d'IP en annonant ces routes.
no ip next-hop-self eigrp <as>
Remarque: La commande no ip next-hop-self eigrp <as> sera disponible partir de la version 12.3(2) de Cisco IOS. Pour des versions de
Cisco IOS entre 12.2(13)T et 12.3(2) vous devez faire ce qui suit :
Si des tunnels dynamiques de rayon rayon ne sont pas voulus, alors la commande ci-dessus n'est pas ncessaire.
Si des tunnels dynamiques de rayon rayon sont voulus, alors vous devez utiliser la commutation de processus sur l'interface de tunnel sur
les routeurs en toile.
Autrement, vous devrez utiliser un protocole de routage diffrent au-dessus de DMVPN.
OSPF
Puisque OSPF est un protocole de routage d'tat de liaison, il n'y a aucun problme de dcoupage de l'horizon. Normalement, pour des interfaces
multipoints, vous configurez le type de rseau OSPF pour tre point multipoint, mais ceci fait qu'OSPF ajoute des routes hte la table de
routage sur les routeurs en toile. Ces routes hte font que les paquets destins aux rseaux derrire d'autres routeurs en toile sont transfrs par
l'intermdiaire du concentrateur, plutt que transfrs directement l'autre rayon. Pour venir bout de ce problme, configurez le type de rseau
OSPF diffuser en utilisant la commande.
ip ospf network broadcast
Vous devez galement vous assurer que le routeur concentrateur sera le routeur dsign (DR) pour le rseau IPsec+mGRE. Ceci est fait en
dfinissant la priorit OSPF plus de 1 sur le concentrateur et 0 sur les rayons.
Hub : ip ospf priority 2
Rai : ip ospf priority 0
Simple concentrateur DMVPN
version 12.3
!
hostname Hub
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.1 255.255.255.0
ip mtu 1400
ip ospf priority 2
delay 1000
tunnel key 100000
!
interface Ethernet0
ip address 172.17.0.1 255.255.255.0
!
interface Ethernet1
ip address 192.168.0.1 255.255.255.0
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 192.168.0.0 0.0.0.255 area 0
!
La seule modification dans la configuration du concentrateur est que OSPF est le protocole de routage au lieu de EIGRP. Notez que le type de
rseau OSPF est dfini sur diffusion et la priorit est dfinie sur 2. Dfinir le type de rseau OSPF sur diffusion fera qu'OSPF installe des routes
pour des rseaux derrire les routeurs en toile avec une adresse du prochain saut d'IP correspondant l'adresse de tunnel GRE pour ce routeur
en toile.
Routeur Spoke1
version 12.3
!
hostname Spoke1
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.2 255.255.255.0
ip mtu 1400
ip nhrp map multicast 172.17.0.1
ip nhrp map 10.0.0.1 172.17.0.1
ip ospf priority 0
delay 1000
tunnel key 100000
!
interface Ethernet0
!
interface Ethernet1
ip address 192.168.1.1 255.255.255.0
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 192.168.1.0 0.0.0.255 area 0
!
La configuration sur les routeurs en toile est maintenant trs semblable la configuration sur le concentrateur. Les diffrences sont les
suivantes :
La priorit OSPF est fixe 0. Les routeurs en toile ne sont pas autoriss devenir DR pour le rseau d'accs multiple sans diffusion
(NBMA) de mGRE. Seul le routeur concentrateur a des connexions statiques directes vers tous les routeurs en toile. Le DR doit avoir
accs tous les membres du rseau NBMA.
Il y a des mappages de monodiffusion et de multicast NHRP configurs pour le routeur concentrateur.

ip nhrp map 10.0.0.1 172.17.0.1
Dans la configuration prcdente, la commande ip nhrp map multicast ... n'tait pas ncessaire puisque le tunnel GRE tait point point.
Dans ce cas, des paquets multicast seront automatiquement encapsuls via le tunnel la seule destination possible. Cette commande est
ncessaire parce que le tunnel GRE des rayons est maintenant multipoint et il y a plus d'une destination possible.
Quand le routeur en toile est en ligne, il doit lancer la connexion en tunnel avec le concentrateur, puisque le routeur concentrateur est
configur avec aucune information sur les routeurs en toile, et les routeurs en toile peuvent avoir des adresses IP attribues
dynamiquement. Les routeurs en toile sont galement configurs avec le concentrateur en tant que leur NHRP NHS.
Avec la commande ci-dessus, le routeur en toile enverra des paquets d'enregistrement NHRP via le tunnel mGRE+IPsec au routeur
concentrateur intervalles rguliers. Ces paquets d'enregistrement fournissent les informations de mappage NHRP de rayon qui sont
ncessaires au routeur concentrateur pour acheminer nouveau les paquets en tunnel vers les routeurs en toile.
Routeur Spoke2
version 12.3
!
hostname Spoke2
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.3 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
ip ospf priority 0
delay 1000
tunnel key 100000
!
interface Ethernet0
!
interface Ethernet1
ip address 192.168.3.1 255.255.255.0
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 192.168.2.0 0.0.0.255 area 0
!
Routeur Spoke<n>
version 12.3
!
hostname Spoke<n>
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.<n+1> 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
ip ospf priority 0
delay 1000
tunnel key 100000
!
interface Ethernet0
!
interface Ethernet1
ip address 192.168.<n>.1 255.255.255.0
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 192.168.<n>.0 0.0.0.255 area 0
!
Notez que les configurations de tous les routeurs en toile sont trs semblables. Les seules diffrences sont les adresses IP sur les interfaces
locales. Ceci est utile pour le dploiement d'un grand nombre de routeurs en toile. Tous les routeurs en toile peuvent tre configurs de manire
identique, et seules les adresses d'interface des IP locales doivent tre ajoutes.
ce moment, jetez un coup d'il aux tables de routage et aux tables de mappage NHRP sur le concentrateur, les Routeurs Spoke1 et Spoke2
pour consulter les conditions initiales (juste aprs l'arrive en ligne des routeurs Spoke1 et Spoke2) et les conditions aprs que Spoke1 et Spoke2
aient cr une liaison dynamique entre eux.
Conditions initiales
Informations du routeur concentrateur
Hub#show ip route
C
C
C
O
192.168.1.0/24 [110/2] via 10.0.0.2, 00:19:53, Tunnel0
O
192.168.2.0/24 [110/2] via 10.0.0.3, 00:19:53, Tunnel0
Hub#show ip nhrp
10.0.0.2/32 via 10.0.0.2, Tunnel0 created 00:57:27, expire
00:04:13
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 07:11:25, expire
00:04:33
Hub#show crypto engine connection active
ID Interface
IP-Address
State Algorithm
Encrypt Decrypt
204 Ethernet0
172.17.0.1
set HMAC_SHA+DES_56_CB
0
0
205 Ethernet0
172.17.0.1
0
0
2628 Tunnel0
10.0.0.1
set HMAC_MD5
0
402
2629 Tunnel0
10.0.0.1
set HMAC_MD5
357
0
2630 Tunnel0
10.0.0.1
set HMAC_MD5
0
427
2631 Tunnel0
10.0.0.1
set HMAC_MD5
308
0
Informations du routeur Spoke1

Spoke1#show ip route
C
C
O
192.168.0.0/24 [110/2] via 10.0.0.1, 00:31:46, Tunnel0
C
O
192.168.2.0/24 [110/2] via 10.0.0.3, 00:31:46, Tunnel0
Spoke1#show ip nhrp
10.0.0.1/32 via 10.0.0.1, Tunnel0 created 01:42:00, never expire
Type: static, Flags: authoritative used
Spoke1#show crypto engine connection active
ID Interface
IP-Address
State Algorithm
Encrypt Decrypt
2 Ethernet0
172.16.1.24
0
0
2064 Tunnel0
10.0.0.2
set HMAC_MD5
0
244
2065 Tunnel0
10.0.0.2
set HMAC_MD5
276
0

C
C
O
192.168.0.0/24 [110/2] via 10.0.0.1, 00:38:52, Tunnel0
O
192.168.1.0/24 [110/2] via 10.0.0.2, 00:38:52, Tunnel0
C
Spoke2#show ip nhrp
ID Interface
IP-Address
State Algorithm
Encrypt Decrypt
17 Ethernet0
172.16.2.75
0
0
2070 Tunnel0
10.0.0.3
set HMAC_MD5
0
279
2071 Tunnel0
10.0.0.3
set HMAC_MD5
316
0
A ce moment nous effectuons un ping de 192.168.1.2 192.168.2.3. Ces adresses sont pour des htes derrire les routeurs Spoke1 et Spoke2,
respectivement. La squence d'oprations suivante a lieu pour construire le tunnel direct mGRE+IPsec de rayon rayon.
1. Le routeur Spoke1 reoit le paquet ping avec la destination 192.168.2.3. Il consulte cette destination dans la table de routage et dcouvre
qu'il doit transfrer ce paquet de l'interface Tunnel0 vers le prochain saut IP, 10.0.0.3.
2. Le routeur Spoke1 vrifie la table de mappage NHRP pour la destination 10.0.0.3 et dcouvre qu'il n'y a pas d'entre. Le routeur Spoke1
cre un paquet de requte de rsolution NHRP et l'envoie NHS (le routeur concentrateur).
3. Le routeur concentrateur vrifie sa table de mappage NHRP pour la destination 10.0.0.3 et dcouvre qu'elle mappe l'adresse 172.16.2.75.
Le routeur concentrateur cre un paquet de rponse de rsolution NHRP et l'envoie au routeur Spoke1.
4. Le routeur Spoke1 reoit la rponse de rsolution NHRP, et il entre le mappage 10.0.0.3 >172.16.2.75 dans sa table de mappage NHRP.
L'ajout du mappage NHRP dclenche IPsec qui dmarre un tunnel IPsec avec l'homologue 172.16.2.75.
5. Le routeur Spoke1 lance ISAKMP avec 172.16.2.75 et ngocie les SA ISAKMP et IPsec. Le proxy IPsec est driv de la commande
tunnel source <address> et du mappage NHRP de Tunnel0.
local ident (addr/mask/prot/port): (172.16.1.24/255.255.255.255/47/0)

remote ident (addr/mask/prot/port): (172.16.2.75/255.255.255.255/47/0)
6. Une fois que le tunnel IPsec est construit, tous les autres paquets de donnes vers le sous-rseau 192.168.2.0/24 sont envoys directement
Spoke2.
7. Aprs qu'un paquet destin 192.168.2.3 ait t transfr l'hte, cet hte enverra un paquet de retour 192.168.1.2. Quand le routeur
Spoke2 reoit ce paquet destin 192.168.1.2, il recherche cette destination dans la table de routage et dcouvre qu'il doit transfrer ce
paquet de l'interface Tunnel0 au prochain saut d'IP, 10.0.0.2.
8. Le routeur Spoke2 vrifie la table de mappage NHRP pour la destination 10.0.0.2 et dcouvre qu'il n'y a pas d'entre. Le routeur Spoke2
cre un paquet de requte de rsolution NHRP et l'envoie NHS (le routeur concentrateur).
9. Le routeur concentrateur vrifie sa table de mappage NHRP pour la destination 10.0.0.2 et dcouvre qu'elle mappe l'adresse 172.16.1.24.
Le routeur concentrateur cre un paquet de rponse de rsolution NHRP et l'envoie au routeur Spoke2.
10. Le routeur Spoke2 reoit la rponse de rsolution NHRP, et il entre le mappage 10.0.0.2 > 172.16.1.24 dans sa table de mappage NHRP.
L'ajout du mappage NHRP dclenche IPsec qui dmarre un tunnel IPsec avec l'homologue 172.16.1.24, mais il y a dj un tunnel IPsec
avec l'homologue 172.16.1.24 donc rien d'autre ne doit tre fait.
11. Spoke1 et Spoke2 peuvent maintenant transfrer des paquets directement entre eux. Quand le mappage NHRP n'a pas t utilis pour
transfrer des paquets pendant la dure de conservation, le mappage NHRP sera supprim. La suppression de l'entre de mappage NHRP
dclenchera IPsec qui supprimera les SA IPsec pour ce lien direct.
Conditions aprs la cration d'une liaison dynamique entre Spoke1 et Spoke2

Spoke1#show ip nhrp
Type: dynamic, Flags: router unique used
ID Interface
IP-Address
State Algorithm
Encrypt Decrypt
2 Ethernet0
172.16.1.24
0
0
3 Ethernet0
172.16.1.24
0
0
2064 Tunnel0
10.0.0.2
set HMAC_MD5
0
375
2065 Tunnel0
10.0.0.2
set HMAC_MD5
426
0
2066 Tunnel0
10.0.0.2
set HMAC_MD5
0
20
2067 Tunnel0
10.0.0.2
set HMAC_MD5
19
0

Spoke2#show ip nhrp
Type: dynamic, Flags: router unique used
ID Interface
IP-Address
State Algorithm
Encrypt Decrypt
17 Ethernet0
172.16.2.75
0
0
18 Ethernet0
172.16.2.75
0
0
2070 Tunnel0
10.0.0.3
set HMAC_MD5
0
407
2071 Tunnel0
10.0.0.3
set HMAC_MD5
460
0
2072 Tunnel0
10.0.0.3
set HMAC_MD5
0
19
2073 Tunnel0
10.0.0.3
set HMAC_MD5
20
0
A partir du rsultat ci-dessus, vous pouvez voir que Spoke1 et Spoke2 ont des mappages NHRP l'un pour l'autre partir du routeur
concentrateur, et ils ont construit et ont utilis un tunnel mGRE+IPsec. Les mappages NHRP expireront aprs cinq minutes (valeur actuelle de la
dure de conservation NHRP = 300 secondes). Si les mappages NHRP sont utiliss dans la dernire minute avant l'expiration, alors une requte
et une rponse de rsolution NHRP seront envoyes pour ractualiser l'entre avant qu'elle ne soit supprime. Autrement, le mappage NHRP
sera supprim et cela dclenchera IPsec qui effacera les SA IPsec.
VPN IPSec multipoint dynamique avec doubles concentrateurs
Avec quelques lignes de configuration supplmentaires sur les routeurs en toile, vous pouvez installer des routeurs concentrateurs doubles (ou
multiples), pour la redondance. Il y a deux faons de configurer les DMVPN double concentrateur.
Un rseau simple DMVPN avec chaque rayon utilisant une simple interface de tunnel GRE multipoint et pointant vers deux concentrateurs
diffrents en tant que serveur de prochain saut (NHS).
Les routeurs concentrateurs auront seulement une simple interface de tunnel GRE multipoints.
Les rseaux DMVPN doubles avec chaque rayon ayant deux interfaces de tunnel GRE (point point ou multipoint) et chaque tunnel GRE
connect un routeur concentrateur diffrent.
Encore une fois, les routeurs concentrateurs auront seulement une simple interface de tunnel GRE multipoints.
Les exemples suivants examineront la configuration de ces deux scnarios diffrents pour les DMVPN double concentrateurs. Dans les deux cas,
les diffrences mises en valeur sont relatives la configuration du concentrateur simple DMVPN.

Il est assez facile d'installer le double concentrateur avec un affichage simple DMVPN, mais il ne vous permet pas de contrler autant le routage
travers DMVPN que le double concentrateur avec double affichage DMVPN. L'ide est dans ce cas d'avoir un DMVPN simple fonctionnant
avec tous les concentrateurs (deux dans ce cas) et tous les rayons connects ce sous-rseau unique ( entit ). Les mappages statiques NHRP
des rayons aux concentrateurs dfinissent les liaisons IPsec+mGRE statiques sur desquelles le protocole de routage dynamique s'excutera. Le
protocole de routage dynamique ne s'excutera pas sur des liaisons IPsec+mGRE dynamiques entre les rayons. Puisque les routeurs en toile
routent les voisins avec les routeurs concentrateurs sur la mme interface de tunnel mGRE, vous ne pouvez pas utiliser des diffrences de liaisons
ou d'interfaces (comme la mtrique, le cot, le dlai, ou la bande passante) pour modifier les mtriques du protocole de routage dynamique pour
privilgier un concentrateur par rapport un autre lorsqu'ils sont tous les deux connects. Si cette prfrence est ncessaire, alors des techniques
internes la configuration du protocole de routage doivent tre utilises. Pour cette raison, il peut tre plus judicieux d'utiliser EIGRP ou RIP
plutt que OSPF en tant que protocole de routage dynamique.
Remarque: Habituellement, le problme ci-dessus constitue un problme seulement si les routeurs concentrateurs sont hbergs conjointement.
Quand ils ne sont pas hbergs conjointement, le routage dynamique normal finira vraisemblablement par prfrer le routeur concentrateur
correct, mme si le rseau de destination peut tre atteint par l'intermdiaire de l'un ou l'autre routeur concentrateur.
version 12.3
!
hostname Hub1
!
!
mode transport
!

!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.1 255.255.255.0
ip mtu 1400
ip ospf priority 2
delay 1000
tunnel key 100000
!
interface Ethernet0
ip address 172.17.0.1 255.255.255.0
!
interface Ethernet1
ip address 192.168.0.1 255.255.255.0
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 1
network 192.168.0.0 0.0.0.255 area 0
!
Routeur Hub2
version 12.3
!
hostname Hub2
!
!
mode transport
!
!
interface Tunnel0
bandwidth 900
ip address 10.0.0.2 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
ip ospf priority 1
delay 1000
tunnel key 100000
!
interface Ethernet0
ip address 172.17.0.5 255.255.255.0
!
interface Ethernet1
ip address 192.168.0.2 255.255.255.0
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 1
network 192.168.0.0 0.0.0.255 area 0
!
La seule modification de la configuration Hub1 consiste modifier OSPF pour utiliser deux zones. La zone 0 est utilise pour le rseau derrire
les deux concentrateurs, et la zone 1 est utilise pour le rseau DMVPN et les rseaux derrire les routeurs en toile. OSPF pourrait utiliser une
seule zone, mais deux zones ont t utilises ici pour expliquer la configuration pour plusieurs zones OSPF.
La configuration pour Hub2 est fondamentalement identique que la configuration Hub1 avec les modifications d'adresse IP appropries. La
principale diffrence est que Hub2 est galement un rayon (ou client) de Hub1, faisant de Hub1 le concentrateur principal et de Hub2 le
concentrateur secondaire. Ceci est fait de sorte que Hub2 soit un voisin OSPF de Hub1 sur le tunnel mGRE. Puisque Hub1 est le DR OSPF, il
doit avoir une connexion directe avec tous les autres routeurs OSPF sur l'interface mGRE (rseau NBMA). Sans lien direct entre Hub1 et Hub2,
Hub2 ne participerait pas au routage OSPF lorsque Hub1 est galement en ligne. Quand Hub1 sera hors ligne, Hub2 sera le DR OSPF pour
DMVPN (rseau NBMA). Quand Hub1 revient en ligne, il succdera Hub2 pour redevenir le DR OSPF pour DMVPN.
Les routeurs derrire Hub1 et Hub2 utiliseront Hub1 pour envoyer des paquets aux rseaux en toile car bande passante pour l'interface de tunnel
GRE est dfinie 1 000 Kb/sec contre 900 Kb/sec sur Hub2. En revanche, les routeurs en toile enverront des paquets pour les rseaux derrire
les routeurs concentrateurs Hub1 et Hub2, puisqu'il y a seulement une interface simple de tunnel mGRE sur chaque routeur en toile et il y
aura deux itinraires au cot gal. Si l'quilibrage de charge par paquet est utilis, ceci peut entraner des paquets en panne.
Routeur Spoke1
version 12.3
!
hostname Spoke1
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.11 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
ip nhrp map 10.0.0.2 172.17.0.5
ip ospf priority 0
delay 1000
tunnel key 100000
!
interface Ethernet0
!
interface Ethernet1
ip address 192.168.1.1 255.255.255.0
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 1
network 192.168.1.0 0.0.0.255 area 1
!
Les diffrences de configuration sur les routeurs en toile sont les suivantes :
En nouvelle configuration, le rayon est configur avec des mappages statiques NHRP pour Hub2 et Hub2 est ajout en tant que serveur de
prochain saut.
Original :

ip nhrp map 10.0.0.1 172.17.0.1
Nouveau :

ip nhrp map 10.0.0.1 172.17.0.1
ip nhrp map 10.0.0.2 172.17.0.5

Les zones OSPF sur les routeurs en toile ont t modifies en zone 1.
Souvenez-vous qu'en dfinissant le mappage statique NHRP et NHS sur un routeur en toile pour un concentrateur, vous allez excuter le
protocole de routage dynamique sur ce tunnel. Ceci dfinit le routage du concentrateur et du rayon ou le rseau voisin. Notez que Hub2 est un
concentrateur pour tous les rayons, et il est galement un rayon pour Hub1. Ceci rend facile la conception, la configuration, et la modification des
rseaux en toile multicouche quand vous utilisez la solution DMVPN.
Routeur Spoke2
version 12.3
!
hostname Spoke2
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.12 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
ip nhrp map 10.0.0.2 172.17.0.5
ip ospf priority 0
delay 1000
tunnel key 100000
!
interface Ethernet0
!
interface Ethernet1
ip address 192.168.2.1 255.255.255.0
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 192.168.2.0 0.0.0.255 area 0
!
Routeur Spoke<n>
version 12.3
!
hostname Spoke<n>
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.<n+10> 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1

ip nhrp map 10.0.0.2 172.17.0.5
ip ospf priority 0
delay 1000
tunnel key 100000
!
interface Ethernet0
ip address dhcp hostname Spoke<x>
!
interface Ethernet1
ip address 192.168.<n>.1 255.255.255.0
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 192.168.<n>.0 0.0.0.255 area 0
!
ce moment, vous pouvez jeter un coup d'il aux tables de routage, aux tables de mappage NHRP, et aux connexions IPsec sur les routeurs
Hub1, Hub2, Spoke1 et Spoke2 pour consulter les conditions initiales (juste aprs l'arrive en ligne des routeurs Spoke1 et Spoke2).

Informations du routeur Hub1
Hub1#show ip route
C
C
C
O
192.168.1.0/24 [110/2] via 10.0.0.11, 00:02:17, Tunnel0
O
192.168.2.0/24 [110/2] via 10.0.0.12, 00:02:17, Tunnel0
Hub1#show ip nhrp
10.0.0.2/32 via 10.0.0.2, Tunnel0 created 1w3d, expire 00:03:15
Hub1#show crypto engine connection active
ID Interface
IP-Address
State Algorithm
Encrypt Decrypt
4 Ethernet0
172.17.0.1
0
0
5 Ethernet0
172.17.0.1
0
0
6 Ethernet0
172.17.0.1
0
0
3532 Tunnel0
10.0.0.1
set HMAC_MD5+DES_56_CB
0
232
3533 Tunnel0
10.0.0.1
212
0
3534 Tunnel0
10.0.0.1
0
18
3535 Tunnel0
10.0.0.1
17
0
3536 Tunnel0
10.0.0.1
0
7
3537 Tunnel0
10.0.0.1
7
0

Hub2#show ip route
C
C
C
O
192.168.1.0/24 [110/2] via 10.0.0.11, 00:29:15, Tunnel0
O
192.168.2.0/24 [110/2] via 10.0.0.12, 00:29:15, Tunnel0
Hub2#show ip nhrp
10.0.0.1/32 via 10.0.0.1, Tunnel0 created 1w3d, never expire

ID Interface
IP-Address
State Algorithm
Encrypt Decrypt
4 Ethernet0
171.17.0.5
0
0
5 Ethernet0
171.17.0.5
0
0
6 Ethernet0
171.17.0.5
0
0
3520 Tunnel0
10.0.0.2
0
351
3521 Tunnel0
10.0.0.2
set HMAC_MD5+DES_56_CB 326
0
3522 Tunnel0
10.0.0.2
0
311
3523 Tunnel0
10.0.0.2
set HMAC_MD5+DES_56_CB 339
0
3524 Tunnel0
10.0.0.2
0
25
3525 Tunnel0
10.0.0.2
22
0

C
C
O IA 192.168.0.0/24 [110/11] via 10.0.0.1, 00:39:31, Tunnel0
[110/11] via 10.0.0.2, 00:39:31, Tunnel0
C
O
192.168.2.0/24 [110/2] via 10.0.0.12, 00:37:58, Tunnel0
Spoke1#show ip nhrp
ID Interface
IP-Address
State Algorithm
Encrypt Decrypt
1 Ethernet0
172.16.1.24
0
0
2 Ethernet0
172.16.1.24
0
0
2010 Tunnel0
10.0.0.11
0
171
2011 Tunnel0
10.0.0.11
185
0
2012 Tunnel0
10.0.0.11
0
12
2013 Tunnel0
10.0.0.11
13
0

C
C
O IA 192.168.0.0/24 [110/11] via 10.0.0.1, 00:57:56, Tunnel0
[110/11] via 10.0.0.2, 00:57:56, Tunnel0
O
192.168.1.0/24 [110/2] via 10.0.0.11, 00:56:14, Tunnel0
C
Spoke2#show ip nhrp
ID Interface
IP-Address
State Algorithm
Encrypt Decrypt
2 Ethernet0
172.16.2.75
0
0
3 Ethernet0
172.16.2.75
0
0
3712 Tunnel0
10.0.0.12
0
302
3713 Tunnel0
10.0.0.12
331
0
3716 Tunnel0
10.0.0.12
0
216
3717 Tunnel0
10.0.0.12
236
0
Il y a quelques problmes intressants noter au sujet des tables de routage sur Hub1, Hub2, Spoke1 et Spoke2 :
Les deux routeurs concentrateurs ont des itinraires au cot gal vers les rseaux derrire les routeurs en toile.
Hub1 :
O
O
Hub2 :
192.168.1.0/24 [110/2] via 10.0.0.11, 00:02:17, Tunnel0

192.168.2.0/24 [110/2] via 10.0.0.12, 00:02:17, Tunnel0
O
O
192.168.1.0/24 [110/2] via 10.0.0.11, 00:29:15, Tunnel0

192.168.2.0/24 [110/2] via 10.0.0.12, 00:29:15, Tunnel0
Ceci signifie que Hub1 et Hub2 annonceront le mme cot pour les rseaux derrire les routeurs en toile aux routeurs dans le rseau
derrire les routeurs concentrateur. Par exemple, la table de routage sur un routeur, R2, qui est connect directement au LAN
192.168.0.0/24 ressemblerait ce qui suit :
R2 :
O
O
IA 192.168.1.0/24 [110/12] via 192.168.0.1, 00:00:26, Ethernet1/0/3

[110/12] via 192.168.0.2, 00:00:27, Ethernet1/0/3O
IA 192.168.2.0/24 [110/12] via 192.168.0.1, 00:00:27, Ethernet1/0/3
[110/12] via 192.168.0.2, 00:00:27, Ethernet1/0/3
Les routeurs en toile ont des itinraires au cot gal vers les deux routeurs concentrateurs du rseau derrire les routeurs concentrateurs.
Spoke1 :
O
IA 192.168.0.0/24 [110/11] via 10.0.0.1, 00:39:31, Tunnel0

[110/11] via 10.0.0.2, 00:39:31, Tunnel0
Spoke2 :
O
IA 192.168.0.0/24 [110/11] via 10.0.0.1, 00:57:56, Tunnel0

[110/11] via 10.0.0.2, 00:57:56, Tunnel0
Si les routeurs en toile font l'quilibrage de charge par paquet, alors vous pourriez obtenir des paquets en panne.
Pour viter de faire du routage asymtrique ou de l'quilibrage de charge par-paquet travers les liaisons vers les deux concentrateurs, vous
devez configurer le protocole de routage pour privilgier un chemin de rayon concentrateur dans les deux directions. Si vous voulez que Hub1
soit le routeur primaire et Hub2 le routeur de secours, alors vous pouvez dfinir des cot OSPF diffrents sur les interfaces du tunnel de
concentrateur.
Hub1 :
interface tunnel0
...
ip ospf cost 10
...
Hub2 :
interface tunnel0
...
ip ospf cost 20
...
Maintenant les routes ressemblent ce qui suit :

Hub1 :
O
O
192.168.1.0/24 [110/11] via 10.0.0.11, 00:00:28, Tunnel0

192.168.2.0/24 [110/11] via 10.0.0.12, 00:00:28, Tunnel0
Hub2 :
O
O
192.168.1.0/24 [110/21] via 10.0.0.11, 00:00:52, Tunnel0

192.168.2.0/24 [110/21] via 10.0.0.12, 00:00:52, Tunnel0
O
O
IA 192.168.1.0/24 [110/31] via 192.168.0.1, 00:01:06, Ethernet1/0/3

IA 192.168.2.0/24 [110/31] via 192.168.0.1, 00:01:06, Ethernet1/0/3
R2 :
Les deux routeurs concentrateurs ont maintenant diffrents cots sur les routes pour les rseaux derrire les routeurs en toile. Ceci signifie que
Hub1 sera privilgi pour transfrer le trafic aux routeurs en toile, comme on peut le voir sur le routeur R2. Ceci rsoudra le problme de
routage asymtrique dcrit dans la premire puce ci-dessus.
Le routage asymtrique dans l'autre direction, comme dcrit dans la deuxime puce ci-dessus, est toujours l. En utilisant le routage OSPF
comme protocole de routage dynamique, vous pouvez rgler ce problme avec une solution de contournement l'aide de la commande
distancesous router ospf 1 sur les rayons pour privilgier des routes apprises par l'intermdiaire de Hub1 par rapport des routes apprises par
l'intermdiaire de Hub2.
Spoke1 :
router ospf 1
distance 111 10.0.0.2 0.0.0.0 1
access-list 1 permit any
Spoke2 :
router ospf 1
distance 111 10.0.0.2 0.0.0.0 1
access-list 1 permit any

Spoke1 :
O
192.168.0.0/24 [110/11] via 10.0.0.1, 00:00:06, Tunnel0
Spoke2 :
O
192.168.1.0/24 [110/11] via 10.0.0.1, 00:00:10, Tunnel0
La configuration de routage ci-dessus protgera contre le routage asymtrique, tout en permettant en mme temps le basculement vers Hub2 si
Hub1 est inactif. Cela signifie que quand les deux concentrateurs sont actifs, seul Hub1 est utilis. Si vous voulez utiliser les deux concentrateurs
en quilibrant les rayons travers les concentrateurs, avec la protection de basculement et sans routage asymtrique, alors la configuration peut
devenir complexe, particulirement en utilisant OSPF. Pour cette raison, le double concentrateur suivant avec double affichage DMVPN peut tre
un meilleur choix.

Il est lgrement plus difficile d'installer le double concentrateur avec double affichage DMVPN, mais il vous donne un meilleur contrle du
routage travers DMVPN. L'ide est d'avoir des deux nuages DMVPN distincts. Chaque concentrateur (deux dans ce cas) est connect un
sous-rseau DMVPN ( nuage ) et les rayons sont connects aux deux sous-rseaux DMVPN ( nuages ). Puisque les routeurs en toile routent
les voisins avec les deux routeurs concentrateurs sur les mmes interfaces de tunnel GRE, vous pouvez utiliser des diffrences de configuration
d'interface (telles que la bande passante, le cot et le dlai) pour modifier les mtriques du protocole de routage dynamique pour privilgier un
concentrateur par rapport l'autre concentrateur quand ils sont tous les deux connects.
Remarque: Habituellement, le problme ci-dessus est seulement appropri si les routeurs concentrateurs sont hbergs conjointement. Quand ils
ne sont pas hbergs conjointement, le routage dynamique normal finira vraisemblablement par prfrer le routeur concentrateur correct, mme si
le rseau de destination peut tre atteint par l'intermdiaire de l'un ou l'autre routeur concentrateur.
Vous pouvez utiliser des interfaces de tunnel p-pGRE ou mGRE sur les routeurs en toile. Diffrentes interfaces p-pGRE sur un routeur en toile
peuvent utiliser la mme adresse IP tunnel source, mais les diffrentes interfaces mGRE sur un routeur en toile doivent avoir une adresse IP
tunnel sourceunique. C'est parce que quand IPsec se lance, le premier paquet est un paquet ISAKMP qui a besoin d'tre associ un des
tunnels mGRE. Le paquet ISAKMP a seulement l'adresse IP de destination (adresse d'homologue IPsec distant) avec laquelle faire cette
association. Cette adresse est mise en correspondance avec l'adresse tunnel source, mais puisque les deux tunnels ont la mme adresse tunnel
source, la premire interface de tunnel mGRE correspond toujours. Ceci signifie que des paquets de donnes multicast entrants peuvent tre
associs la mauvaise interface mGRE, interrompant tout protocole de routage dynamique.
Les paquets GRE eux-mmes n'ont pas ce problme puisqu'ils ont la valeur tunnel keypour se diffrencier entre les deux interfaces mGRE.
partir des versions 12.3(5) et 12.3(7)T du logiciel Cisco IOS, un paramtre supplmentaire a t introduit pour surmonter cette limitation : tunnel
protection.partag. Le mot cl shared indique que plusieurs interfaces mGRE utiliseront le cryptage IPSec avec la mme adresse IP source. Si
vous avez une version antrieure, vous pouvez utiliser des tunnels p-pGRE dans ce double concentrateur avec le double affichage DMVPN. Dans
le cas de tunnel p-pGRE, les adresses IP tunnel sourceet tunnel destinationpeuvent tre utiliss pour la mise en correspondance. Pour cet
exemple, les tunnels p-pGRE seront utiliss dans ce double concentrateur avec le double affichage DMVPN et sans utiliser le qualificatif shared.
Les modifications suivantes mises en valeur sont relatives aux configurations de rseau toil multipoints dynamique illustres plus tt dans ce
document.
Routeur Hub1
version 12.3
!
hostname Hub1
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.1 255.255.255.0
ip mtu 1400
delay 1000
tunnel key 100000
!
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
!
Routeur Hub2
version 12.3
!
hostname Hub2
!

!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.1.1 255.255.255.0
ip mtu 1400
delay 1000
tunnel key 100001
!
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
!
Dans ce cas, les configurations Hub1 et Hub2 sont similaires. La principale diffrence est que chacun est le concentrateur d'un DMVPN
diffrent. Chaque DMVPN utilise un diffrent :
Sous-rseau IP (10.0.0.0/24, 10.0.0.1/24)
ID rseau NHRP (100000, 100001)
Cl tunnel (100000, 100001)
Le protocole de routage dynamique a t bascul de OSPF EIGRP, puisqu'il est plus facile d'installer et de grer un rseau NBMA en utilisant
le EIGRP, comme dcrit plus loin dans ce document.
Routeur Spoke1
version 12.3
!
hostname Spoke1
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.11 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
delay 1000
tunnel key 100000
!
interface Tunnel1
bandwidth 1000
ip address 10.0.1.11 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.1.1 172.17.0.5
delay 1000
tunnel key 100001
!
interface Ethernet0
!
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
!
Chacun des routeurs en toile est configur avec deux interfaces de tunnel p-pGRE, une dans chacun des deux DMVPN. Les valeurs ip address
..., ip nhrp network-id ..., tunnel key ... et tunnel destination ... sont utilises pour faire la diffrence entre les deux tunnels. Le protocole de
routage dynamique, EIGRP, est excut au-dessus des sous-rseaux de tunnel p-pGRE et est utilis pour privilgier une interface p-pGRE
(DMVPN) par rapport l'autre.
Routeur Spoke2
version 12.3
!
hostname Spoke2
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.12 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
delay 1000
tunnel key 100000
!
interface Tunnel1
bandwidth 1000
ip address 10.0.1.12 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.1.1 172.17.0.5
delay 1000
tunnel key 100001
!
interface Ethernet0
!
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
!
Routeur Spoke<n>
version 12.3
!
hostname Spoke<n>
!
!
mode transport
!
!
interface Tunnel0
bandwidth 1000
ip address 10.0.0.<n+10> 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.0.1 172.17.0.1
delay 1000
tunnel key 100000
!
interface Tunnel1
bandwidth 1000
ip address 10.0.1.<n+10> 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.1.1 172.17.0.5
delay 1000
tunnel key 100001
!
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
!
ce moment, jetons un coup d'il aux tables de routage, aux tables de mappage NHRP, et aux connexions IPsec sur les routeurs Hub1, Hub2,
Spoke1 et Spoke2 pour consulter les conditions initiales (juste aprs l'arrive en ligne des routeurs Spoke1 et Spoke2).

Hub1#show ip route
C
C
D
10.0.1.0 [90/2611200] via 192.168.0.2, 00:00:46, Ethernet1
C
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
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

Hub2#show ip route
C
D
10.0.0.0 [90/2611200] via 192.168.0.1, 00:12:22, Ethernet1
C
C
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
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

C
C
C
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
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
ID Interface
IP-Address
State Algorithm
Encrypt
16 Ethernet0
172.16.1.24
set
HMAC_SHA+DES_56_CB
0
18 Ethernet0
172.16.1.24
set
HMAC_SHA+DES_56_CB
0
2118 Tunnel0
10.0.0.11
set
HMAC_MD5+DES_56_CB
0
2119 Tunnel0
10.0.0.11
set
HMAC_MD5+DES_56_CB
186
2120 Tunnel1
10.0.1.11
set
HMAC_MD5+DES_56_CB
0
2121 Tunnel1
10.0.1.11
set
HMAC_MD5+DES_56_CB
110

C
C
C
Decrypt
0
0
181
0
105
0
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
Spoke2#show ip nhrp
ID Interface
IP-Address
State Algorithm
Encrypt
8 Ethernet0
172.16.2.75
set
HMAC_SHA+DES_56_CB
0
9 Ethernet0
172.16.2.75
set
HMAC_SHA+DES_56_CB
0
2036 Tunnel0
10.0.0.12
set
HMAC_MD5+DES_56_CB
0
2037 Tunnel0
10.0.0.12
set
HMAC_MD5+DES_56_CB
614
2038 Tunnel1
10.0.1.12
set
HMAC_MD5+DES_56_CB
0
2039 Tunnel1
10.0.1.12
set
HMAC_MD5+DES_56_CB
424
Decrypt
0
0
585
0
408
0
Encore une fois, il y a quelques lments intressants noter au sujet des tables de routage sur Hub1, Hub2, Spoke1 et Spoke2 :
Les deux routeurs concentrateurs ont des itinraires au cot gal vers les rseaux derrire les routeurs en toile.
Hub1 :
D
D
192.168.1.0/24 [90/2841600] via 10.0.0.11, 00:00:59, Tunnel0

192.168.2.0/24 [90/2841600] via 10.0.0.12, 00:00:34, Tunnel0
Hub2 :
D
D
192.168.1.0/24 [90/2841600] via 10.0.1.11, 00:13:24, Tunnel0

192.168.2.0/24 [90/2841600] via 10.0.1.12, 00:12:11, Tunnel0
Ceci signifie que Hub1 et Hub2 annonceront le mme cot pour les rseaux derrire les routeurs en toile aux routeurs dans le rseau
derrire les routeurs concentrateur. Par exemple, la table de routage sur un routeur, R2, qui est connect directement au LAN
192.168.0.0/24 ressemblerait ce qui suit :
R2 :
D
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
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
Les routeurs en toile ont des itinraires au cot gal vers les deux routeurs concentrateurs du rseau derrire les routeurs concentrateurs.
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
Si les routeurs en toile font l'quilibrage de charge par paquet, alors vous pourriez obtenir des paquets en panne.
Pour viter de faire du routage asymtrique ou de l'quilibrage de charge par-paquet travers les liaisons vers les deux concentrateurs, vous
devez configurer le protocole de routage pour privilgier un chemin de rayon concentrateur dans les deux directions. Si vous voulez que Hub1
soit le routeur primaire et Hub2 le routeur de secours, alors vous pouvez dfinir des dlais diffrents sur les interfaces du tunnel de concentrateur.
Hub1 :
interface tunnel0
...
delay 1000
...
Hub2 :
interface tunnel0
...
delay 1050
...
Remarque: Dans cet exemple, 50 t ajout au dlai sur l'interface du tunnel sur Hub2 parce qu'il est plus petit que le dlai sur l'interface
Ethernet1 entre les deux concentrateurs (100). En faisant cela, Hub2 transfrera toujours des paquets directement aux routeurs en toile, mais il
annoncera un itinraire moins souhaitable que Hub1 aux routeurs derrire Hub1 et Hub2. Si le dlai tait augment de plus de 100, alors Hub2
transfrerait des paquets pour les routeurs en toile par Hub1 par l'intermdiaire de l'interface Ethernet1, mme si les routeurs derrire Hub1 et
Hub2 privilgieraient nanmoins toujours Hub1 pour envoyer des paquets aux routeurs en toile.
Hub1 :
D
D
192.168.1.0/24 [90/2841600] via 10.0.0.11, 00:01:11, Tunnel0

192.168.2.0/24 [90/2841600] via 10.0.0.12, 00:01:11, Tunnel0
Hub2 :
D
D
192.168.1.0/24 [90/2854400] via 10.0.1.11, 00:00:04, Tunnel0

192.168.2.0/24 [90/2854400] via 10.0.1.12, 00:00:04, Tunnel0
D
D
192.168.1.0/24 [90/2867200] via 192.168.0.1, 00:02:18, Ethernet1/0/3

192.168.2.0/24 [90/2867200] via 192.168.0.1, 00:02:18, Ethernet1/0/3
R2 :
Les deux routeurs concentrateurs ont diffrents cots pour les routes de rseau derrire les routeurs en toile, ainsi, dans ce cas, Hub1 sera
privilgi pour transfrer du trafic aux routeurs en toile, comme on peut le voir sur R2. Ceci rgle le problme dcrit dans la premire puce cidessus.
Le problme dcrit dans la deuxime puce ci-dessus est toujours l, mais puisque vous avez deux interfaces du tunnel p-pGRE, vous pouvez
dfinir le dlaisur les interfaces du tunnel sparment pour modifier la mtrique EIGRP pour les routes apprises par Hub1 plutt que Hub2.
Spoke1 :
interface tunnel0
delay 1000
interface tunnel1
delay 1050
Spoke2 :
interface tunnel0
delay 1000
interface tunnel1
delay 1050

Spoke1 :
D
D
192.168.0.0/24 [90/2841600] via 10.0.0.1, 00:15:44, Tunnel0

192.168.2.0/24 [90/3097600] via 10.0.0.1, 00:15:44, Tunnel0
Spoke2 :
D
D
192.168.0.0/24 [90/2841600] via 10.0.0.1, 00:13:54, Tunnel0

192.168.1.0/24 [90/3097600] via 10.0.0.1, 00:13:54, Tunnel0
La configuration de routage ci-dessus protgera contre le routage asymtrique, tout en permettant en mme temps le basculement vers Hub2 si
Hub1 est inactif. Cela signifie que quand les deux concentrateurs sont actifs, seul Hub1 est utilis.
Si vous voulez utiliser les deux concentrateurs en quilibrant les rayons travers les concentrateurs, avec la protection de basculement et sans
routage asymtrique, alors la configuration est plus complexe, mais vous pouvez y arriver en utilisant EIGRP. Pour accomplir ceci, dfinissez le
delaysur les interfaces de tunnel des routeurs concentrateurs pour qu'ils soient de nouveau gaux, puis utilisez la commande offset-list <acl>
out <offset> <interface> sur les routeurs en toile pour augmenter la mtrique EIGRP pour les routes annonces sur les interfaces de tunnel
GRE vers le concentrateur de secours. Le delay ... ingal entre les interfaces Tunnel0 et Tunnel1 sur le rayon est encore utilis. Le routeur en
toile privilgiera donc son routeur concentrateur principal. Les modifications sur les routeurs en toile sont les suivantes.
Routeur 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 map 10.0.0.1 172.17.0.1
delay 1000
tunnel key 100000
!
interface Tunnel1
bandwidth 1000
ip address 10.0.1.11 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.1.1 172.17.0.5
delay 1500
tunnel key 100001
!
...
!
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.1.0
distribute-list 1 out
no auto-summary
!
access-list 1 permit 192.168.1.0
!
Routeur 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 map 10.0.0.1 172.17.0.1
delay 1500
tunnel key 100000
!
interface Tunnel1
bandwidth 1000
ip address 10.0.1.12 255.255.255.0
ip mtu 1400
ip nhrp map 10.0.1.1 172.17.0.5
delay 1000
tunnel key 100001
!
...
!
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
!
Remarque: La valeur de compensation de 12 800 (50*256) a t ajoute la mtrique EIGRP parce qu'elle est plus petite que 25 600 (100*256).
Cette valeur (25 600), est ce qui est ajout la mtrique EIGRP pour les routes apprise entre les routeurs concentrateurs. En utilisant 12 800 dans
la commande offset-list, le routeur concentrateur de secours transfrera des paquets directement aux routeurs en toile, plutt que par Ethernet
par l'intermdiaire du routeur concentrateur principal pour ces rayons. La mtrique sur les routes annonces par les routeurs concentrateurs sera
toujours telle que le routeur concentrateur principal correct sera privilgi. Souvenez-vous que la moiti des rayons ont Hub1 en tant que routeur
primaire, et que l'autre moiti ont Hub2 en tant que routeur primaire.
Remarque: Si la valeur de compensation tait augmente de plus de 25 600 (100*256), alors les concentrateurs transfreraient des paquets pour
la moiti des routeurs en toile par l'autre concentrateur par l'intermdiaire de l'interface Ethernet1, mme si les routeurs derrire les
concentrateurs privilgieraient toujours le concentrateur correct pour envoyer des paquets aux routeurs en toile.
Remarque: La commande distribute-list 1 out a galement t ajoute puisqu'il est possible que les routes apprise par l'intermdiaire d'un
routeur concentrateur via une interface du tunnel sur un rayon puissent tre annonces de nouveau l'autre concentrateur par l'intermdiaire de
l'autre tunnel. La commande distribute-lists'assure que le routeur en toile peut seulement annoncer ses propres routes.
Remarque: Si vous prfrez contrler les annonces de routage sur les routeurs concentrateur plutt que sur les routeurs en toile, alors les
commandes offset-list <acl1> in <value> <interface> et distribute-list <acl2> in peuvent tre configures sur les routeurs concentrateurs au
lieu de sur les rayons. La liste d'accs <acl2> listerait les routes par derrire tous les rayons et la liste d'accs <acl1> listerait seulement les routes
par derrire les rayons o un autre routeur concentrateur doit tre le concentrateur principal.
Avec ces modifications, les routes ressemblent ce qui suit :
Hub1 :
D
D
192.168.1.0/24 [90/2841600] via 10.0.0.11, 00:12:11, Tunnel2

192.168.2.0/24 [90/2854400] via 10.0.0.12, 00:13:24, Tunnel2
Hub2 :
D
D
192.168.1.0/24 [90/2854400] via 10.0.1.11, 00:09:58, Tunnel0

192.168.2.0/24 [90/2841600] via 10.10.1.12, 00:11:11, Tunnel0
D
D
192.168.1.0/24 [90/2867200] via 192.168.0.1, 00:13:13, Ethernet1/0/3

192.168.2.0/24 [90/2867200] via 192.168.0.2, 00:14:25, Ethernet1/0/3
R2 :
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
Conclusion
La solution DMVPN fournit la fonctionnalit suivante pour mieux faire voluer de grands et petits rseaux VPN IPSec.
DMVPN permet une meilleure volutivit dans les VPN IPsec maillage global ou partiel.
C'est particulirement utile lorsque le trafic de rayon rayon est sporadique (par exemple, chaque rayon n'envoie pas constamment des
donnes chaque autre rayon). Ceci permet tout rayon d'envoyer des donnes directement n'importe quel autre rayon, tant qu'il y a une
connectivit IP directe entre les rayons.
DMVPN prend en charge les noeuds IPsec avec des adresses attribues dynamiquement (telles que cble, ISDN et DSL).
Ceci s'applique aux rseaux en toile aussi bien qu'aux rseaux maills. DMVPN peut exiger que la liaison en toile soit constamment
active.
DMVPN simplifie l'ajout de noeuds VPN.
En ajoutant un nouveau routeur en toile, vous devez seulement configurer le routeur en toile et le brancher au rseau (cependant, vous
pouvez devoir ajouter des informations d'autorisation ISAKMP pour le nouveau rayon du concentrateur). Le concentrateur se renseignera
dynamiquement sur le nouveau rayon et le protocole de routage dynamique propagera le routage au concentrateur et tous autres rayons.
DMVPN rduit la taille de la configuration requise sur tous les Routeurs dans le VPN.
C'est galement le cas pour les rseaux VPN en toile uniquement GRE+IPsec.
DMVPN utilise GRE et prend en charge, en consquence, le multicast IP et le trafic de routage dynamique travers le VPN.
Ceci signifie qu'un protocole de routage dynamique peut tre utilis, et des concentrateurs redondants peuvent tre pris en charge par le
protocole de routage. Les applications multidiffusion sont galement prises en charge.
DMVPN prend en charge la transmission tunnel partage aux rayons.
Informations connexes
Livre blanc Technologies
1992-2010 Cisco Systems Inc. Tous droits rservs.

Date du fichier PDF gnr: 19 octobre 2014
http://www.cisco.com/cisco/web/support/CA/fr/109/1095/1095298_dmvpn.html

DMVPN PDF

Transféré par

Droits d'auteur :

Formats disponibles

DMVPN PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DMVPN PDF

Transféré par

Droits d'auteur :

Formats disponibles

VPN IPSec multipoint dynamiques (utilisation de GRE

multipoint/NHRP pour tendre les VPN IPsec)

Dmarrage automatique du cryptage IPsec

crypto ipsec profile <profile-name>

La commande suivante associe une interface du tunnel au profil IPSec.

Cration dynamique de tunnel pour les liaisons Spoke-to-Hub

Cration dynamique de tunnel pour les trafics Spoke-to-Spoke

Prise en charge des protocoles de routage dynamiques

Commutation rapide de Cisco Express Forwarding pour mGRE

Utilisation du routage dynamique sur les VPN protgs par IPsec

set peer 172.16.1.1

Exemples des tableaux de routage sur les routeurs en toile

Tableau de routage sur le routeur Spoke1

Tableau de routage sur le routeur Spoke<n>

Rduction de la taille de la configuration du routeur concentrateur

crypto ipsec profile <name>

set transform-set trans2

Routeur concentrateur (nouveau)

Routeur Spoke<n> (vieux)

Routeur Spoke<n> (nouveau)

ip address 10.0.0.<n+1> 255.255.255.0

Prise en charge des adresses dynamiques sur les rayons

Routeur Spoke<n> (vieux)

Routeur Spoke<n> (nouveau)

Les principales choses noter au sujet des configurations en toile sont :

Rseau en toile multipoint dynamique

Routeur Spoke<n> (avant Cisco IOS 12.2(13)T)

Routeur Spoke<n> (aprs Cisco IOS 12.2(13)T)

Notez que nous avons fait ce qui suit :

Il n'y a aucun changement dans la configuration de concentrateur.

VPN IPSec multipoint dynamique

no ip split-horizon eigrp <as>

no ip next-hop-self eigrp <as>

ip ospf network broadcast

ip nhrp map multicast 172.17.0.1

Informations du routeur Spoke1

Informations du routeur Spoke2

local ident (addr/mask/prot/port): (172.16.1.24/255.255.255.255/47/0)

Conditions aprs la cration d'une liaison dynamique entre Spoke1 et Spoke2

Informations du routeur Spoke2

VPN IPSec multipoint dynamique avec doubles concentrateurs

Double concentrateur - Affichage simple DMVPN

crypto ipsec profile vpnprof

ip nhrp map multicast 172.17.0.1

ip nhrp map multicast 172.17.0.1

ip nhrp map 10.0.0.2 172.17.0.5

ip nhrp map multicast 172.17.0.5

Conditions initiales et modifications

Informations du routeur Hub2

Type: dynamic, Flags: authoritative unique registered

Informations du routeur Spoke1

Informations du routeur Spoke2

192.168.1.0/24 [110/2] via 10.0.0.11, 00:02:17, Tunnel0

192.168.1.0/24 [110/2] via 10.0.0.11, 00:29:15, Tunnel0

IA 192.168.1.0/24 [110/12] via 192.168.0.1, 00:00:26, Ethernet1/0/3

IA 192.168.0.0/24 [110/11] via 10.0.0.1, 00:39:31, Tunnel0

IA 192.168.0.0/24 [110/11] via 10.0.0.1, 00:57:56, Tunnel0

Maintenant les routes ressemblent ce qui suit :

192.168.1.0/24 [110/11] via 10.0.0.11, 00:00:28, Tunnel0