Dans certaines architecture Hub-Spoke avec DMVPN, on veut bien que le trafic internet des utilisateurs se trouvant dans les sites distants Branch, est routé d’abord au site central HQ à travers le tunnel VPN dans le but d’une inspection approfondie par la pile de securité se trouvant dans le data center pour ensuite l’acheminer vers internet, dans cet exemple, pour s’assurer que tout l’trafic internet et egalement le trafic entre les sites branch ou bien de l’enterprise puisse passer par le site central (ie le Hub), une route EIGRP par défaut est annoncé avec la commande ip summary-address eigrp 1 0.0.0.0 0.0.0.0 au niveau du routeur Hub, en meme temps les routeurs Spokes des sites branchs n’annoncent aucun réseau se trouvant derriere 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 meme temps, une autre exigence dicte que le trafic INTERNET Guest ne doit pas etre routé vers le site central à travers le tunnel VPN. Mais il doit etre achemené directement vers internet à travers la gateway local, c’est a dire le réseau guest localisé derriere le routeur Spoke1 va utiliser ce meme routeur pour naviguer directement sur internet, c’est ce qu’on appelle communemment Direct Internet Access DIA.

Pour mettre en oeuvre 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 rammene à un deuxieme 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 utilisateuses de l’enterprise via le site central.

Pour répondre à ses deux exigencés, 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 sensée etre utiliser pour monter les tunnels est isolée dans la VRF denommé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 denommé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’enterprise passe à travers le tunnel VPN vers le Hub pour ensuite le router vers internet.

Dans les déploiement largé, la mise en place de la fonctionnalité DIA devient complexe comme j’l’ai expliquée dans un post precedent (comparaison entre DMVPN et SD-WAN).

Avec Cisco SD-WAN, je dois reconnaitre l’implementation est simple et intuitive, vous configurer simple policy based routing (Data Policy) au niveau du vManage et elle est lancée et appliquée sur tous les routeurs Branchs.

Write A Comment