L’interface Ethernet0 est ici l’interface interne (coté LAN, statique) du site central, et Ethernet1 l’interface externe (coté WAN, dhcp).
ip nat inside indique au routeur que les paquets entrant par cette interface et sortant par l’interface noté ip nat outside devront être NATés (translation d’adresse IP). Dans le cadre d’un déploiement ADSL, l’interface ’nat outside’ sera Dialern.
router ospf 1
passive-interface Ethernet0
network 10.0.0.0 0.0.0.255 area 0
network 192.168.0.0 0.0.0.255 area 0OSPF doit fonctionner au travers du tunnel pour permettre d’échanger des routes et faire connaitre les réseaux LAN du hub et des différents spokes. Ces routes seront propagées sur la totalité des routeurs participants au tunnel multipoint GRE.
- Tunnels IPsec et échanges OSPF
Par default, OSFP va envoyer et recevoir des mises à jour de routes via toutes les interfaces concernées par les réseaux participants (network 10.0.0.0 0.0.0.255 et network 192.168.0.0 0.0.0.255). En revanche, comme il n’y a aucun routeur OSPF coté LAN (network 192.168.0.0 0.0.0.255), cette interface est marquée passive-interface Ethernet0 pour éviter un multicast inutile des échanges OSPF sur le réseau interne.
router rip
version 2
passive-interface default
no passive-interface Ethernet1
network 172.22.0.0
network 172.23.0.0
no auto-summaryRIP va en revanche fonctionner hors du tunnel, et uniquement en envoyant des updates sur son interface WAN (passive-interface default et no passive-interface Ethernet1). Le process de routage RIP va permettre d’annoncer le réseau de l’interface Loopback0 sur le réseau ARI. Il n’a évidemment aucune utilité si le déploiement à lieu en ADSL, puique l’extrémité du tunnel mGRE coté hub est dans ce cas une IP fixe (et que de toutes façons, le provider n’a aucune raison d’écouter et de propager des annonces RIP venant de ses clients...).
ip nat inside source list 101 interface Ethernet1 overload
access-list 101 deny ip 192.168.0.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 101 permit ip 192.168.0.0 0.0.0.255 anyLes paquets IP sortant par l’interface physique Ethernet1 et qui corresponent à l’access-list 101 seront NATés. Les autres (l’ESP à destination des spokes en l’occurence) ne le seront pas.
- Configuration des annexes (spokes)
Les annexes ont quasiment la même configuration que le hub (en général, aux adresses IP près).
Les principales différences sont détaillées ci-dessous.
Les configurations complètes des deux annexes sont données en fin d’article.
- Interfaces
Les spokes n’ont pas d’interface de Loopback. Les autres interfaces ont des configurations similaires.
- Interface Tunnel0
La source du tunnel (tunnel source) est directement l’interface WAN (Ethernet1) dans le cas des spokes. Par ailleurs, la priorité OSPF est mise à 0 (pour éviter qu’un spoke soit élu gestionnaire des routes (DR) pour la zone), un next hop server et une entrée NHRP (le hub, dans les deux cas) sont définies statiquement.
- RIPv2
Inutile (voire dangereux) de démarrer un process RIPv2 sur les spokes : ils n’ont absolument pas besoin d’annoncer leur LAN sur le réseau. OSPF se charge de le faire en direction des autres participants au réseau DMVPN.
- Tests et vérifications
- Hub
Une fois les configurations appliquées, quelques commandes permettent de s’assurer que le réseau DMVPN est correctement configuré (les résultats des commandes ont été élagués pour être plus lisibles).
cpe-mairie#show ip route
...
Gateway of last resort is 172.23.211.1 to network 0.0.0.0
172.23.0.0/24 is subnetted, 1 subnets
C 172.23.211.0 is directly connected, Ethernet1
172.22.0.0/32 is subnetted, 1 subnets
C 172.22.0.1 is directly connected, Loopback0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Tunnel0
C 192.168.0.0/24 is directly connected, Ethernet0
O 192.168.1.0/24 [110/110] via 10.0.0.2, 00:27:08, Tunnel0
O 192.168.2.0/24 [110/110] via 10.0.0.3, 00:27:08, Tunnel0
S* 0.0.0.0/0 [254/0] via 172.23.211.1On remarque ici (site central, Hub) que les routes des spokes sont bien reçues en OSPF. Cela permet de confirmer en une seule opération non seulement qu’OSPF fonctionne, mais aussi que mGRE, IPsec et NHRP font correctement leur travail puisque sans ces derniers, il n’y a aucune chance que les routes OSPF arrivent sur le Hub.
Pour plus de détail, il est possible de vérifier chaque composant.
Sur le Hub, la consulation de la table NHRP permet de s’assurer que les interfaces Tunnel des spokes ont bien annoncé leur adresse physique :
cpe-mairie#show ip nhrp
10.0.0.2/32 via 10.0.0.2, Tunnel0 created 00:43:34, expire 00:09:44
Type: dynamic, Flags: authoritative unique registered used
NBMA address: 172.23.211.3
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:28:18, expire 00:09:44
Type: dynamic, Flags: authoritative unique registered used
NBMA address: 172.23.211.2 show crypto ipsec sa permet de vérifier que les SA IPsec sont bien actives :
cpe-mairie#sh crypto ipsec sa
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 172.22.0.1
protected vrf: (none)
local ident (addr/mask/prot/port): (172.22.0.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.23.211.2/255.255.255.255/47/0)
current_peer 172.23.211.2 port 500
local crypto endpt.: 172.22.0.1, remote crypto endpt.: 172.23.211.2
inbound esp sas:
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
Status: ACTIVE
outbound esp sas:
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
Status: ACTIVE
protected vrf: (none)
local ident (addr/mask/prot/port): (172.22.0.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.23.211.3/255.255.255.255/47/0)
current_peer 172.23.211.3 port 500
local crypto endpt.: 172.22.0.1, remote crypto endpt.: 172.23.211.3
inbound esp sas:
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
Status: ACTIVE
outbound esp sas:
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
Status: ACTIVEDans notre cas, on voit biens les deux SA (une pour chaque ’sens’ de communication entre les deux extrémités du tunnel), et ce, avec l’annexe 1 et l’annexe 2 (qui ont recu respectivement 172.23.211.3 et 172.23.211.2 en DHCP).
- Spokes
Coté Spokes, on peut aussi effectuer ces mêmes vérifications :
cpe-annexe1#show ip route
Gateway of last resort is 172.23.211.1 to network 0.0.0.0
172.23.0.0/24 is subnetted, 1 subnets
C 172.23.211.0 is directly connected, Ethernet1
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Tunnel0
O 192.168.0.0/24 [110/110] via 10.0.0.1, 00:29:14, Tunnel0
C 192.168.1.0/24 is directly connected, Ethernet0
O 192.168.2.0/24 [110/110] via 10.0.0.3, 00:29:14, Tunnel0
S* 0.0.0.0/0 [254/0] via 172.23.211.1Les routes sont correctes : une route par défaut via le réseau ARI (vers lequel seront translatés les flux à destination de l’internet) et deux routes reçues en OSPF pour les réseaux distants (le Hub et le deuxième Spoke). Ces deux dernières routes non seulement indiquent le Tunnel0 comme interface de sortie, mais annoncent aussi le bon next-hop (en particulier pour le Spoke).
