Dans certaines architectures Hub-Spoke avec DMVPN, on veut bien que le trafic internet des utilisateurs se trouvant dans les sites distants Branch, soit routé d’abord au site central HQ à travers le tunnel VPN dans le but d’une inspection approfondie par la pile de sécurité se trouvant dans le data center pour ensuite l’acheminer vers internet, dans cet exemple, pour s’assurer que tout l’trafic internet mais également le trafic entre les sites branch ou bien de l’entreprise puisse passer par le site central (ie le Hub), une route EIGRP par défaut est annoncée avec la commande ip summary-address eigrp 1 0.0.0.0 0.0.0.0 au niveau du routeur Hub, en même temps les routeurs Spokes des sites branchs n’annoncent aucun réseau se trouvant derrière eux. Par conséquent cette route EIGRP par défaut avec le Hub comme next hop sera utilisée à priori pour tous le trafic des utilisateurs branchs (Trafic INTERNET + Trafic de l’entreprise).
En même temps, une autre exigence dicte que le trafic INTERNET Guest ne doit pas être routé vers le site central à travers le tunnel VPN. Mais il doit être achemené directement vers internet à travers la gateway local, c’est a dire le réseau guest localisé derrière le routeur Spoke1 va utiliser ce même routeur pour naviguer directement sur internet, c’est ce qu’on appelle communément Direct Internet Access DIA.
Pour mettre en œuvre cette solution, deux défis majeurs se posent:
-La route EIGRP par défaut a une distance administrative 90 superieur à celle de la route statique par défaut au niveau des spokes. (Notez bien que chaque spoke doit avoir une route statique par défaut qui pointe directement vers internet dans le but de monter le tunnel GRE avec IPSec).
Conséquence la route par défaut annoncée par le routeur Hub ne sera pas installée dans la table de routage des routeurs Spokes.
Ce qui nous ramène à un deuxième défi qui est le suivant:
On a besoin des deux routes par défaut, pourquoi?
La route statique par défaut qui pointe directement vers l’ISP du site Branch sera utilisée par les utilisateurs GUEST afin d’acheminer leur trafic INTERNET directement.
La route EIGRP par défaut qui point vers le Hub et le tunnel GRE afin d’acheminer le trafic INTERNET des utilisateurs de l’entreprise via le site central.
Pour répondre à ses deux exigences, le concept du VRF (Virtual Routing Forwarding) vient en secours, l’idée est la suivante:
On va mettre le réseau GUEST et l’interface physique connectée à INTERNET du routeur Spoke dans une VRF et on configure ensuite une route statique par défaut dans cette VRF, tandis que la route EIGRP par défaut sera gardée dans la table de routage globale (Global Routing Table).
Au niveau du Spoke1 ça donne la configuration suivante:
ip vrf INTERNET
!
interface Ethernet0/0
description to ISP Internet
ip vrf forwarding INTERNET
ip address 2.2.2.1 255.255.255.0
ip nat outside
!
interface Ethernet0/1
description to Guest network
ip vrf forwarding INTERNET
ip address 192.168.4.1 255.255.255.0
ip nat inside
!
interface Ethernet0/2
description to Corporate network
ip address 192.168.5.1 255.255.255.0
!
ip route vrf INTERNET 0.0.0.0 0.0.0.0 2.2.2.2
Mais un autre challenge va jaillir, si on se content de cette configuration seulement, les tunnels GRE ne vont pas s’établir car la route statique par défaut via l’interface physique E0/0 censée être utilisé pour monter les tunnels est isolée dans la VRF dénommée INTERNET, pendant que le tunnel GRE est configurée avec tunnel source E0/0.
Pour cela on va instruire les routeurs Spokes, dans cet exemple Spoke1 d’utiliser la table de routage VRF dénommée INTERNET afin d’assurer la connectivité avec le Hub à travers le transport internet et ce dans l’objectif de monter le tunnel GRE (échange NHRP et tout ce qui en suit). Ceci est possible avec la commande tunnel vrf au niveau de l’interface Tunnel de chaque spoke.
interface Tunnel1
tunnel vrf INTERNET
Maintenant le trafic du PC Guest Guest-PC1 passe directement vers internet.
Tandis que le trafic internet du PC de l’entreprise passe à travers le tunnel VPN vers le Hub pour ensuite le router vers internet.
Dans les déploiements larges la mise en place de la fonctionnalité DIA devient complexe comme j’l’ai expliquée dans un post précédent (comparaison entre DMVPN et SD-WAN).
Avec Cisco SD-WAN, je dois reconnaitre l’implémentation est simple et intuitive, vous configurer une simple policy based routing (Data Policy) au niveau du vManage et elle est lancée et appliquée sur tous les routeurs Branchs.
