Un Bridge Domain dans Cisco ACI fabric fonctionne un peu comme le domaine de broadcast dans un réseau traditionnel, mais avec une flexibilité accrue. Contrairement à un VLAN traditionnel, où l’ID du VLAN doit être unique dans tout le réseau, dans ACI, l’ID du VLAN doit seulement être unique au niveau du Leaf switch. Cela signifie que le même ID VLAN peut être utilisé dans différents Bridge Domains à condition qu’ils soient sur des Leaf switches distincts.
À l’intérieur d’un Bridge Domain, vous pouvez avoir plusieurs subnets. Mais gardez à l’esprit que chaque subnet reste confiné à son Bridge Domain. Les subnets ne sont pas seulement isolés car Ils peuvent être routés et même partagés avec d’autres VRFs ou tenants, facilitant la communication et le partage des ressources au sein de l’architecture ACI.
Lorsque vous configurez votre Bridge Domain, plusieurs options clés doivent être prises en compte pour affiner son fonctionnement. Ces options incluent la décision d’utiliser ou non le hardware proxy ou le Layer 2 unknown unicast flooding, d’activer ou de désactiver le ARP flooding et le unicast routing, de définir un ou plusieurs subnets, et d’adopter des mécanismes pour contrôler l’apprentissage des endpoints. Chaque choix impacte la manière dont les données circulent à travers votre réseau.
Les principales options de configuration du Bridge Domain qui devraient être considérées lors du tuning du comportement du Bridge Domain sont les suivantes :
L’utilisation du mode Hardware-Proxy :
Cisco ACI offre une solution élégante pour optimiser la gestion du trafic et réduire le flooding inutile au sein de la fabric. Avec l’activation de l’option Hardware Proxy dans les paramètres L2 Unknown Unicast, Cisco ACI prend une approche ciblée face aux trames Unknown Unicast. Plutôt que de les diffuser à l’ensemble des ports où le Bridge Domain est configuré, la trame est redirigée intelligemment vers un des Spines de la fabric (Proxy Spine).
Voici comment cela fonctionne : si une trame Unknown Unicast, portant soit une adresse MAC expirée, soit provenant d’un silent host, arrive, elle est immédiatement acheminée vers le proxy Spine. Ce Spine consulte ensuite sa table COOP pour déterminer si l’adresse MAC est connue. Si c’est le cas, la trame est routée avec vers sa destination finale. Si l’adresse est introuvable, la trame est simplement écartée.
L’utilisation du mode Flood :
Lorsque vous configurez votre Bridge Domain en mode L2 Unknown Unicast Flood, vous optez pour une diffusion de la trame à tous les ports qui font partie de ce même Bridge Domain. Cette méthode signifie que le processus de forwarding ne se sert pas de la table COOP des SPINEs pour diriger le trafic.
Pour éviter les problèmes tels que les boucles de réseau, qui peuvent rapidement devenir un casse-tête, les trames L2 Unknown Unicast ne sont pas juste balancées à l’aveuglette. Elles sont intelligemment dirigées vers une adresse IP Multicast spécifique, connue sous le nom de GIPo, qui est liée d’office au Bridge Domain dès sa création.
Dans cette configuration, le SPINE joue le rôle du Root pour l’arbre multicast, ce qui aide à une distribution ordonnée des trames et diminue le risque de congestion ou de boucles au sein de votre architecture réseau.
Il y a un petit conseil à ne pas négliger lorsque vous travaillez en mode L2 Unknown Unicast Flood : assurez-vous d’activer l’option « Clear Remote MAC Entries ». Cela peut sembler être un détail technique, mais son effet est direct et significatif. Par cette action, vous commandez au système de purger les adresses MAC des endpoints qui ne sont plus actifs dans les leafs distant une fois cette adresse MAC est purgée dans le Leaf local. Et le plus beau dans tout ça ? Cela se fait instantanément, sans attendre l’expiration d’un quelconque délai.
ARP Flooding :
Si le flooding ARP est activé dans la fabric, le trafic ARP est diffusé suivant le traitement ARP habituel des réseaux traditionnels. Cette fonctionnalité est cruciale lorsque vous avez besoin de requêtes Gratuitous ARP (GARP) pour mettre à jour les caches ARP des machines ou des routeurs. Plus spécifiquement, le flooding ARP est requis lorsque certains endpoints doivent atteindre l’adresse IP virtuelle d’un serveur parce que leur cache ARP est obsolète.
Des exemples où le flooding ARP est nécessaire incluent les déploiements ou deux Endpoints partageant la même adresse IP mais utilisant potentiellement différentes adresses MAC. Cela peut concerner :
- Les pare-feux et les Load Balancer en mode routé déployés en HA
- Les serveurs en cluster, où l’adresse IP peut passer d’un serveur à l’autre, entraînant un changement d’adresse MAC.
Quand le flooding ARP est désactivé dans la fabric Cisco ACI, cela signifie que la méthode de distribution des requêtes ARP change. Au lieu de diffuser la requête ARP à tous les ports du bridge domain, la fabric utilise l’unicast pour cibler directement l’adresse IP recherchée (Target IP) par la requête ARP. Voici comment cela fonctionne :
- Interception de la requête ARP : Lorsqu’un switch Leaf reçoit une requête ARP, au lieu de la diffuser, il intercepte la requête pour déterminer l’adresse IP cible (Target IP).
- Routage L3 : Une fois l’adresse IP cible identifiée, le switch effectue un routage de couche 3 pour déterminer le chemin optimal pour atteindre le switch Leaf qui héberge l’adresse IP cible. Le paquet ARP est ensuite envoyé directement à ce switch Leaf.
Importance de l’option Unicast Routing : Cette méthode de gestion ARP n’est efficace que si l’option Unicast Routing est activée sur le bridge domain. Si cette option est désactivée, le système revient par défaut au flooding ARP pour garantir que les requêtes ARP peuvent atteindre toutes les destinations possibles au sein du bridge domain.
ARP Gleaning
Cisco ACI dispose de plusieurs mécanismes pour détecter les silent hosts, c’est-à-dire lorsqu’un switch leaf ACI n’a pas encore appris un endpoint local. Pour le trafic niveau 2 vers une MAC inconnue, vous pouvez utiliser l’option L2 Unknown Unicast en mode Flood, tandis que pour les requêtes ARP avec une MAC de destination en broadcast, vous pouvez utiliser l’option de flooding ARP sous le bridge domain pour contrôler le comportement du flooding.
De plus, Cisco ACI utilise le ARP gleaning pour envoyer des requêtes ARP afin de résoudre l’adresse IP d’un silent host.
Avec le ARP gleaning, si le spine n’a pas d’informations sur l’emplacement de la destination de la requête ARP (l’IP cible n’est pas dans la table COOP), l’ACI génère une requête ARP qui provient de l’adresse IP du SVI (gateway pervasive) du bridge domain. Cette requête ARP est envoyée à toutes les interfaces d’accès des leafs faisant partie du bridge domain.
Le ARP gleaning est également déclenché pour le trafic routé (L3), indépendamment de la configuration, comme le flooding ARP, tant que le trafic est acheminé vers une IP inconnue.
Le ARP gleaning est aussi déclenché pour le trafic de couche 2 si le hardware proxy est choisi comme mode de diffusion pour une requête ARP. Par exemple, lorsqu’un endpoint A envoie une diffusion ARP à un endpoint B dans le même bridge domain configuré en Hardware Proxy et l’arp flooding est désactivé, l’ARP sera envoyé au proxy spine. Si l’IP cible est inconnue, le spine déclenchera un ARP gleaning pour cette IP cible.
Le ARP gleaning se déclenche lorsque:
- Une adresse IP est utilisée pour le routage (requêtes ARP avec le flooding ARP désactivé, ou trafic inter-subnet avec l’IP du BD comme passerelle).
- L’Unicast Routing est activé.
- La création d’une ip dans le bridge domain.
Paramètres Niveau 3 du Bridge Domain
Pour faciliter le routage inter-EPG (End Point Group) de couche 3 au sein de la fabric Cisco ACI, vous pouvez exploiter les paramètres L3 du bridge domain.
L’option hardware-proxy est particulièrement avantageuse lorsque vous activez le routage unicast et définissez un sous-réseau sur le bridge domain.
L’intérêt ici est que, avec le hardware-proxy activé, si une adresse MAC devient obsolète dans le spine proxy, le trafic destiné à cette adresse MAC est rejeté. Pour que Cisco ACI maintienne une base de données d’endpoints à jour, il doit effectuer une résolution d’adresse ARP des adresses IP des endpoints et rafraîchir la table d’adresses MAC.
Lorsque vous lui associer un IP, le bridge domain utilise ARP pour résoudre les endpoints avant l’expiration de leur timer dans la policy retention d’endpoints. Ainsi, il n’est pas nécessaire d’ajuster la politique de rétention d’endpoints en fonction du délai d’expiration du cache ARP des hôtes.
Cela permet également au bridge domain d’effectuer du ARP gleaning pour les silents hosts.
La figure suivante illustre les paramètres de couche 3 du bridge domain.
L’onglet « L3 Configurations » dans bridge domain vous permet de définir les paramètres de base suivants pour affiner le routage et la gestion des sous-réseaux au sein de votre fabric Cisco ACI :
- Routage Unicast (Unicast Routing) : Lorsque ce paramètre est activé et qu’une adresse de sous-réseau est configurée, la fabric assure la fonction de passerelle par défaut au sein du bridge domain et achemine le trafic. Activer le routage unicast permet également à la table d’endpoints sur les switches leaf d’apprendre la correspondance IP-TEP (Tunnel Endpoint) pour ce bridge domain. L’apprentissage des adresses IP n’est pas dépendant de la configuration d’un sous-réseau sous le bridge domain.
- Adresse de Sous-réseau (Subnet Address) : Cette option permet de configurer les adresses IP SVI (Switched Virtual Interface) pour le bridge domain, agissant comme des passerelles par défaut. Lorsque vous définissez un sous-réseau/gateway pervasive, il est déployé de manière omniprésente sur tous les switches leaf associés au bridge domain des endpoints, permettant à chaque switch leaf de fournir une fonction de passerelle pour les endpoints. Même en l’absence d’endpoints, la passerelle sera déployée tant que le bridge domain est actif. Les options pour un sous-réseau sous un bridge domain sont les suivantes :
- Advertised Externally : Le sous-réseau peut être exporté hors de la fabric ACI via une connexion L3Out.
- Shared between VRFs : Le sous-réseau peut être partagé et exporté vers plusieurs VRFs au sein du même tenant ou entre différents tenant dans le cadre d’un service partagé. Un exemple de service partagé est une connexion routée vers un EPG situé dans un autre VRF d’un tenant différent, permettant ainsi le passage du trafic dans les deux sens entre les VRFs.
Pensez également activer l’option « Limit Local IP Learning to BD/EPG Subnet » (ou mieux encore, utiliser l’option « Enforce Subnet Check » à l’échelle global de la fabric) disponible dans la configuration générale du bridge domain, pour contrôler le l’apprentissage des endpoints dans le bridge domain. Cela est similaire à RPF (Reverse path Forwarding, lorsque cette option est sélectionnée, la fabric n’apprendra pas les adresses IP d’un sous-réseau autre que celui configuré sur le bridge domain/EPG.
L’ Unicast Routing est activé par défaut et est nécessaire lorsque vous configurez une passerelle par défaut pour un bridge domain au sein de la fabric ACI. Si vous configurez la passerelle par défaut à l’extérieur de la fabric (par exemple, sur un pare-feu), vous devriez désactiver le routage unicast, ce qui active également implicitement le flooding ARP.
Flood in Encapsulation
L’option « Flood in Encapsulation » dans ACI est une fonctionnalité de gestion du trafic qui permet de limiter le flooding à une seule encapsulation (vlan ou vxlan) dans un bridge domain.
Par défaut, les bridge domains sont configurés pour diffuser le trafic multidestination (ou Unknown unicast avec le flooding de couche 2 inconnu sélectionné) dans le bridge domain. Cependant, en configurant « Flood in Encapsulation », vous pouvez restreindre ce flooding au sein du bridge Domain à l’encapsulation spécifique d’où provient le trafic.
Cette fonction est particulièrement utile pour fusionner plusieurs domaines niveau 2 existants en un seul bridge domain, en limitant le domaine de flooding au VLAN d’origine du trafic.
Avec « Flood in Encapsulation », les paquets sont diffusés vers tous les EPGs ayant la même encapsulation VLAN provenant du même Vlan Pool. Cela est particulièrement utile pour contrôler le trafic dans des environnements complexes et pour s’assurer que le trafic est dirigé de manière efficace et sécurisée.
Il est important de noter que cette fonctionnalité doit être utilisée avec discernement, car elle a des exigences spécifiques et n’est pas compatible avec certaines configurations, comme la microsegmentation ou le multicast IPv4 et IPv6. De plus, elle nécessite des switches leaf de type -EX ou ultérieur et une configuration unique des adresses MAC au sein d’un même bridge domain.
En résumé, « Flood in Encapsulation » est une fonctionnalité avancée de Cisco ACI qui offre une granularité supplémentaire dans la gestion du trafic de réseau, permettant une distribution plus précise et contrôlée du trafic dans les bridge domains.
Les Bonnes pratiques du Bridge Domain :
- Pour les endpoints directement connectés aux switches leaf Cisco ACI : Il est conseillé d’activer le routage unicast, d’ajouter un sous-réseau dans le bridge domain et de configurer le mode hardware-proxy pour le Layer 2 unknown unicast. Cette configuration assure une gestion efficace du trafic et une meilleure résolution des adresses.
- Pour les bridge domains connectés à des réseaux Layer 2 existants : Il est recommandé de configurer le flooding pour le Layer 2 unknown unicast et de sélectionner l’option Clear Remote MAC Entries. Cette configuration aide à maintenir la propreté de la base de données MAC et à éviter les problèmes de connectivité.
- Utilisation du flooding ARP : En raison des diverses implémentations de teaming et de la présence potentielle d’adresses IP flottantes, le flooding ARP est souvent nécessaire. Il assure que les requêtes ARP atteignent tous les endpoints nécessaires pour la résolution d’adresses.
- Utilisation de Flood in Encapsulation : Si vous devez fusionner plusieurs domaines Layer 2 dans un seul bridge domain, envisagez d’utiliser l’option Flood in Encapsulation. Cette configuration limite le flooding au sein du bridge domain à une seule encapsulation, optimisant ainsi la distribution du trafic et réduisant le risque de congestion.
Si vous envisagez de migrer vers une solution Cisco ACI mais que vous n’êtes pas sûr de la manière de procéder, n’hésitez pas à nous contacter sur contact@mhd-experts.com. Notre équipe d’experts est à votre disposition pour vous accompagner à chaque étape de votre transition vers Cisco ACI, en vous fournissant des conseils personnalisés, une planification stratégique et un soutien technique pour garantir une migration réussie et optimisée. Profitez de notre expertise pour simplifier votre passage à une infrastructure réseau plus agile et innovante. Contactez-nous dès maintenant pour démarrer votre voyage vers la transformation ACI.
