Optimisation de chemin : FHRP Isolation

Introduction

Dans le cas d’une infrastructure multi data centers, une question d’architecture se pose souvent :

Doit-on relier les data centers au niveau 2, ou bien au niveau 3 ? Autrement dit faut-il étendre ses VLANs entre plusieurs data centers ?

Les bonnes pratiques voudraient qu’on segmente le niveau 2 à un seul data center, ne serait-ce que pour éviter de diffuser du broadcast sur les liens inter-sites, limiter le domaine spanning-tree et éviter de propager un incident de niveau 2 (boucle réseau par exemple) à un autre data center.

Mais dans la réalité, une multitude de contraintes poussent à utiliser (souvent par facilité) un niveau 2 étendu. Nous pouvons citer entre autre :

• Les clusters applicatifs étendus qui ont besoin d’une connectivité L2
•  Les machines virtuelles qui doivent pouvoir être déplacées d’un DC à l’autre de manière transparente
•  Un déménagement physique de machine entre 2 data centers qui nécessite une transition à cheval sur deux DC
•  etc

Le problème :

Une architecture avec un réseau de niveau 2 étendu pose des problèmes d’optimisation de chemins.

Prenons en exemple le scénario suivant :

Deux data centers A et B hébergent des machines virtuelles sur deux VLANs (100 et 200 par exemple) , étendus sur nos 2 DC. Les machines virtuelles doivent pouvoir être déplacées d’un DC à un autre sans reconfiguration IP (par exemple avec VMware vMotion). Les équipement utilisés pour le routage et le switching sont des Cisco Nexus et les deux data centers sont reliés par deux liens agrégés en virtual port-channel (vPC)

Exemple de VLANs étendus

La question qui peut se poser : où positionner la passerelle par défaut pour nos machines ? On pourrait très bien imaginer une passerelle différente dans chaque data centers, mais l’objectif est de pouvoir déplacer une VM sans avoir à modifier sa passerelle par défaut.

Positionnons donc nos passerelles sur le site A pour nos deux vlans, que se passe-t-il quand une machine du site B sur le VLAN 100 dialogue avec une machine du vlan 200 sur le même site :

Trajet non optimal

Le trafic qui pourrait être local à notre site B va traverser 2 fois le lien inter data centers ce qui n’est pas souhaitable pour deux raisons principales :

• la bande passante de ce lien est limitée
• une latence souvent non négligeable est ajoutée

La solution : vPC et FHRP Isolation

Pour palier à ce problème, il existe une technique appelée « FHRP Isolation ». FHRP, qui signifie First Hop Redundancy Protocol, est un terme désignant les protocoles de redondance de passerelle tels que HSRP ou VRRP. L’exemple utilisé dans la suite de l’article s’appuie sur HSRP, mais cela fonctionnerait également avec VRRP.

L’idée est de filtrer les messages HSRP entre les deux sites et ainsi avoir sur chaque site un routeur actif. Allié aux fonctionnalités du vPC, le trafic routé sera toujours traité par un routeur local au site.

Mise en pratique :

Nous commençons par créer une access-list pour filtrer le trafic HSRP :

ip access HSRP_Filtering
 10 deny udp any 224.0.0.2/32 eq 1985
 20 permit ip any any

On applique cette access-list sur les interfaces physiques (ou le port-channel si l’on fait du vPC) reliant les deux sites :

interface po1
ip port access-group HSRP_Filtering in

Routage par les équipements locaux

Cette configuration va permettre à chacun des routeurs de ne voir que les annonces de l’autre routeur du même site. On aura donc un routeur « HSRP active » sur chaque site, et grâce au vPC les 4 routeurs seront capables de router les paquets qui utilisent l’adresse virtuelle HSRP comme passerelle.

Le protocole HSRP spécifie que le routeur actif envoie régulièrement des paquets gratuitous ARP pour mettre à jour la CAM (la table d’adresse MAC) des switches.

Cela ne pose pas de problème ici car, pour chaque switch qui cumule la fonction de router HSRP, cette adresse est locale, et donc ne sera pas apprise dans la table MAC, par contre cela génère de nombreux logs du type :

Source address of packet received from 0000.0c07.ac01 on Vlan100(port-channel1) is duplicate of local virtual ip, x.x.x.x

Pour éviter cela, il faut ajouter sur les interfaces IP (par exemple l’interface Vlan100 ici) :

no ip arp gratuitous hsrp duplicate

Attention, cette configuration ne fonctionne que si les fibres inter-site arrivent sur l’équipement qui porte l’HSRP, sans équipement L2 intermédiaire.

Dans le cas contraire, par exemple si on sépare la partie switching et la partie routage sur deux équipements, il va se produire un bagotement dans la CAM car le switch verra la même adresse MAC sur deux ports différents (celui vers le routeur local et celui vers l’autre site)

Problème de localisation de la vMAC

Conclusion :

L’isolation HSRP permet de palier en partie au problème de chemins que posent les extensions de niveau 2 entre différents data centers. Cependant, il ne s’agit que du chemin pour le trafic de serveur à serveur, ou pour le sens serveur vers client.

Pour le sens client vers serveur, on ne maitrise pas sur quel data center arrive le client, il faut utiliser d’autres techniques, comme LISP ou du DNS « intelligent » (GSLB). Mais ceci est un tout autre sujet, qui fera sans doute l’objet d’un prochain article.