Dans les articles précédents, nous avons présenté la logique derrière le fonctionnement du réseau multicast underlay pour VXLAN, et nous avons vu comment cela peut être configuré sur certains commutateurs Cisco Nexus.
Maintenant, cette solution avec du multicast fonctionne, cependant, il y a certains problèmes dont vous devez être conscients.
Dans cette article, nous allons mettre en évidence les faiblesses de la solution multicast dont nous avons parlé dans nos articles précédents,et nous expliquerons comment déployer un réseau multicast plus robuste et plus approprié en utilisant un point de rendez-vous anycast, ou anycast RP.
Il est important de noter ici que ces problèmes concernent davantage la manière dont le multicast est déployé plutôt que le fonctionnement de VXLAN lui-même.
Pour cette raison, il est nécessaire d’avoir une bonne compréhension du multicast,
y compris des éléments comme le PIM Sparse Mode, les points de rendez-vous,
ainsi que l’adressage IP anycast.
Voici la topologie que nous avons utilisée dans notre déploiement d’un réseau de base multicast pour VXLAN.
Faiblesses du réseau Multicast underlay
Lorsque vous utilisez le multicast pour le réseau underlay du VXLAN, il est préférable d’utiliser le sparse mode plutôt que le dense mode pour diverses raisons.
Sans entrer dans trop de détails, le sparse mode est plus évolutif, plus efficace, impose une charge réseau réduite,et il est donc idéal pour les déploiements de centres de données et de clouds à hautes performances et haut débit.
Le mode dense est à proscrire pour ce type de réseau.
🧠 Pour comprendre :
Le multicast peut fonctionner selon deux modes principaux :
-
PIM Dense Mode (DM) → mode « inondation puis retrait »
-
Tout le trafic multicast est envoyé partout au départ.
-
Puis les routeurs qui n’en ont pas besoin disent « je n’en veux pas ».
-
Cela génère beaucoup de trafic inutile, de charge réseau et de latence.
-
-
PIM Sparse Mode (SM) → mode « sur demande »
-
Le trafic multicast n’est envoyé que là où il est demandé.
-
C’est beaucoup plus efficace et scalable, surtout dans les grands réseaux.
-
Le PIM sparse mode utilise ce que l’on appelle un point de rendez-vous ou RP (Rendezvous Point).
C’est un dispositif désigné sur le réseau qui agit comme un point de contact commun pour les récepteurs et les sources multicast.
Dans le cas de VXLAN, les dispositifs de type leaf, ou VTEP, sont ces sources et récepteurs multicast.
Ce sont les VTEP qui communiquent à l’aide du multicast.
Un RP aide à gérer efficacement les adhésions aux groupes multicast et le routage multicast en servant de racine à ce que l’on appelle un arbre partagé,ou arbre RP, vers lequel les sources multicast envoient leur trafic,et auquel les récepteurs se joignent pour recevoir dans le groupe multicast.
Le RP est une partie essentielle du fonctionnement du multicast en PIM Sparse mode.
Ainsi, la première faiblesse de notre solution multicast initiale est que nous n’avons qu’un seul RP.
C’est un point unique de défaillance !
Pour la configuration multicast, le RP est configuré manuellement,et aussi chaque équipement de l'infra underlay est configuré manuellement pour pointer vers ce RP.
C’est problématique, car ce RP, constitue un point unique de défaillance.
Et s’il tombe en panne, vous devez alors reconfigurer manuellement tous les dispositifs du réseau de base pour pointer vers un autre appareil comme nouveau RP.
Et si vous n’avez pas de RP actif dans votre réseau, le multicast ne fonctionnera pas,
ce qui est un gros problème pour VXLAN.
Solutions au problème de redondance
Il existe plusieurs solutions qui peuvent nous fournir une redondance dynamique pour le RP.
Il y a quelques protocoles de découverte de RP qui peuvent automatiquement et dynamiquement détecter un RP de secours en cas de défaillance du RP original.
Par exemple, vous pouvez utiliser la solution propriétaire Auto-RP de Cisco, ou vous pouvez utiliser le protocole Bootstrap PIM (BSR), Ce dernier est une norme standard prise en charge par plusieurs fournisseurs.
Ces deux protocoles fournissent cette découverte dynamique et une sauvegarde automatique des RPs en cas de panne.
Cependant, bien que ces solutions soient bonnes, elles ne sont pas adéquates pour une utilisation dans un centre de données ou une infrastructure cloud, car leurs processus de convergence sont trop lents, ce qui entraînerait des interruptions inacceptables. Ces solutions sont donc écartées.
L’approche la plus appropriée pour VXLAN lorsqu’on utilise le multicast est d’utiliser la solution Anycast RP.
Solution Anycast RP
Anycast RP est une technique utilisée dans le PIM sparse mode pour fournir de la redondance et de la répartition de charge pour le point de rendez-vous.
Dans cette configuration, plusieurs RPs sont configurés avec la même adresse IP. Cette adresse est appelée adresse IP anycast, attribuée aux RPs.
Ces RPs sont généralement répartis à différents endroits au sein du réseau. Lorsqu’une source multicast envoie ses données à l’adresse RP anycast, le protocole de routage sous-jacent, comme EIGRP, OSPF ou tout autre protocole utilisé, redirige le trafic vers le RP le plus proche.
“Le plus proche” signifie simplement le RP ayant la plus petite distance ou métrique de protocole de routage par rapport à la source.
De la même manière, les récepteurs multicast rejoignent également le groupe multicast via le RP le plus proche.
Si un RP tombe en panne, le protocole de routage redirige dynamiquement le trafic vers l’autre RP opérationnel presque instantanément, assurant ainsi une disponibilité continue et une meilleure fiabilité.
Cette configuration améliore la scalabilité et la tolérance aux pannes dans les grands réseaux multicast, ce qui est nécessaire dans les topologies VXLAN en Datacenter et des environnements cloud.
Mais il y a un autre problème à tout cela.
Jusqu’à présent, dans les architectures présentés, nous n’avons qu’un seul lien montant (uplink) depuis chaque Leaf, mais typiquement, dans de tels réseaux, vous aurez deux ou plusieurs liens montants vers deux ou plusieurs commutateurs Spine .
Cela signifie que pour un commutateur leaf particulier, l’un ou l’autre lien peut être utilisé.
Alors, comment un VTEP choisit-il quel lien utiliser pour envoyer le trafic multicast ?
Eh bien, dans un tel cas, les commutateurs leaf utilisent un algorithme de hachage pour choisir quel lien utiliser.
Cet algorithme est conçu pour distribuer plus équitablement le trafic multicast, mais cela signifie que nous pouvons finir par envoyer du trafic multicast via l’un ou l’autre lien, et qu’un lien peut être “plus proche” (en termes de métrique de routage) d’un RP différent.
Cela peut entraîner des incohérences dans les arbres RP et le routage multicast.
Il y a une dernière étape pour résoudre ce problème dans notre solution de réseau underlay multicast.
Nous devons donner aux multiples RPs un moyen de partager leurs informations,
afin que même si cela se produit, ils puissent toujours synchroniser leurs informations entre eux.
Ainsi, si certains leafs rejoignent un RP et d’autres un autre RP, on doit mettre en place un moyen pour que ces RPs se synchronisent entre eux.
De cette manière, si un RP tombe en panne, l’autre aura déjà toutes les informations à jour pour tous les groupes multicast.
Il existe plusieurs façons de mettre en place cette synchronisation.
L’une consiste à utiliser PIM lui-même. Les RPs peuvent être configurés pour échanger des messages PIM entre tous les commutateurs spine configurés comme RPs, de sorte qu’ils puissent tous connaître les sources multicast et tous les récepteurs multicast.
Alternativement, vous pouvez utiliser ce que l’on appelle le Multicast Source Discovery Protocol (MSDP).
Les deux sont des solutions valables pour VXLAN.
Ainsi, si vous souhaitez créer un réseau multicast underlay robuste, fiable et redondant pour une topologie VXLAN, la meilleure solution est de déployer le PIM sparse mode avec plusieurs RPs utilisant des adresses IP anycast,afin d’éliminer le point unique de défaillance (SPOF) introduit par un seul RP.
Vous pouvez ensuite utiliser PIM ou MSDP pour assurer la synchronisation entre ces RPs.
Tout cela peut être fait pour minimiser les temps d’arrêt en cas de panne et pour résoudre les incohérences introduites par les liens montants redondants sur les VTEPs.