Un Endpoint dans Cisco ACI se compose d'une adresse MAC et de zéro ou plusieurs adresses IP.
Dans un réseau traditionnel, trois tables sont utilisées pour maintenir les adresses réseau des Hosts :
- Une table d'adresses MAC pour le forwarding Layer 2
- Une Routing Information Base (RIB) pour le forwarding Layer 3
- Une table ARP pour la combinaison des adresses IP et MAC
Cisco ACI a remplacé la table d'adresses MAC et la table ARP par une seule table appelée la table Endpoints. Ce changement implique que Cisco ACI apprend ces informations de manière différente par rapport à un réseau traditionnel. Cisco ACI apprend les adresses MAC et IP en matériel en examinant l'adresse MAC source et l'adresse IP source dans le plan de données (Data Plane), au lieu de se baser sur le protocole ARP pour obtenir l'adresse MAC du prochain saut pour les adresses IP. Cette approche réduit le besoin en ressources pour traiter et générer le trafic ARP. Elle permet également de détecter le déplacement des adresses IP et MAC sans avoir besoin d'attendre un GARP tant qu'un certain trafic est envoyé depuis le nouvel hôte. Bien que Cisco ACI utilise la table des Endpoints au lieu des tables MAC et ARP, il utilise toujours la RIB et la table ARP (pour L3Out, routage vers l'exterieur de la Fabric).
Cisco ACI Layer 2 Forwarding
Le Hardware Proxy ou Spine Proxy pour le trafic Layer 2 unknown unicast est l'option par défaut. Si l'adresse MAC de destination ne figure pas dans Endpoint Table du leaf ingress, le paquet est envoyé au Spine Proxy. Ce comportement de transfert utilise la base de données COOP sur les switches spine pour acheminer le trafic unknown unicast vers le leaf de destination, sans avoir recours à un comportement de flood-and-learn, tant que l'adresse MAC est connue dans la base de données COOP du switch spine.
Dans le cas de l'option Layer 2 unknown unicast flooding, c'est-à-dire si le Hardware Proxy est désactivé dans le Bridge Domain, La table Endpoint du leaf et la base de données COOP du spine sont toujours peuplées avec les informations MAC-to-VTEP. Cependant, le transfert n'utilise pas la base de données COOP des switches spine. Les paquets Layer 2 unknown unicast sont inondés dans le domaine de pont.
Si l'option flooding ARP est activé, le trafic ARP sera inondé dans le Bridge Domain selon le traitement classique de l'ARP dans les réseaux traditionnels. Si cette option est désactivée, le leaf ingress utilise le trafic unicast pour envoyer le trafic ARP au leaf de destination ou au proxy spine Il est à noter que ces options s'appliquent uniquement si le routage unicast (Unicast Routing) est activé dans le Bridge Domain. Si le routage unicast est désactivé, le trafic ARP est toujours inondé dans Bridge Domain.
Ensuite, nous verrons comment un paquet Layer 2 circule à travers la fabric, comment l'ARP est résolu, et comment les différents modes de Bridge Domain influencent le flux des données.
Si l'adresse MAC de destination est connue d'un leaf ingress, le paquet est transféré vers le port local si le Endpoint se trouve sur le leaf local.
Si l'adresse MAC de destination est connue d'un leaf ingress et que le point d'extrémité ne se trouve pas sur le leaf local, le paquet est transféré directement vers le leaf distant.
Prenons un exemple où le trafic circule entre deux Endpoints dans le même EPG (Endpoint Group) qui est dans le même Bridge Domain Layer 2, les adresses MAC des deux Endpoints sont connues. Par exemple:
EP-1 est connu comme étant local au switch leaf-1 et EP-2 est connu comme un Endpoint distant pour ce switch.
EP-1 est connu comme un Endpoint distant pour Leaf-2 tandis que EP2 est connu comme local pour ce switch.
Lorsque le trafic de EP-1 vers EP-2, Leaf-1 encapsule le paquet avec l'adresse source PTEP ou VTEP Physical/Virtual Tunnel Endpoint de Leaf 1 et l'adresse de destination du VTEP/PTEP de Leaf-2. Leaf-2 va décapsuler le paquet et l'envoyer au port connecté à EP-2. Le meme procédé s'applique lorsque le trafic est envoyé par EP-2 vers EP-1. Leaf-2 encapsule le paquet avec l'adresse source VTEP/PTEP de Leaf-2 et l'adresse de destination VTEP/PTEP de Leaf-1.
Si l'adresse MAC de destination n'est pas connue du leaf ingress, alors il y a deux options.
Si le Bridge Domain est en mode Layer 2 Unknown Unicast Flood, le paquet est inondé dans ce Bridge Domain. Par exemple, Leaf-1 ne sait pas où se trouve l'adresse MAC de EP-2, il va donc inonder le paquet à tous les Endpoints dans le Bridge Domain. Lorsqu'un paquet est inondé dans un BD, les paquets sont encapsulés avec une IP spécifique multicast appelé Group IP Outer (GIPo) et envoyé au Spine au lieu du VTEP des leafs. Chaque Bridge Domain se voit attribuer par l'APIC un GIPo interne à cette fin. Le SPINE joue le rôle du Root pour l’arbre multicast, ce qui aide à une bonne gestion des trames et éviter les problèmes de boucles.
Si vous utilisez un Bridge Domain pour le niveau 2 uniquement avec l'option Unicast Routing désactivée, il est recommandé de mettre le Bridge Domain en mode flood. Sinon, Il y'a le risque que le spine drop les trames (par exemple, les hosts inactifs ou silent hosts).
Si un Bridge Domain est en mode Layer 2 Unknown Unicast hardware-proxy, le paquet est envoyé au proxy spine. Ensuite, il y a deux options possibles.
Leaf 1 ne sait pas où se trouve l'adresse MAC de EP-2; il va donc encapsuler le paquet avec une adresse MAC anycast du spine comme destination pour le proxy spine. Si la base de données COOP sur le spine contient des informations sur l'adresse MAC de EP2, le spine transfère le paquet au leaf distant.
Si l'adresse MAC d'un Endpoint n'est pas présente dans la base de données COOP du spine (par exemple un host inactif ), le spine drop le paquet.
Cisco ACI Forwarding of ARP Packets
Lorsque le routage unicast est désactivé dans un Bridge Domain, indépendamment du mode ARP Flooding, les requêtes ARP avec une adresse MAC broadcast seront toujours inondées.
Il existe trois scénarios possibles pour le traitement des trames ARP dans un Bridge Domain avec le routage unicast activé.
Si le mode flooding ARP est activé, le comportement est généralement le même que dans un Bridge Domaine de niveau 2 avec le routage unicast DESACTIVE. Les requêtes ARP en diffusion sont toujours inondées dans le Bridge Domain. Le mode Layer 2 Unknown Unicast n'impacte pas le flooding ARP.
Si le mode flooding ARP est désactivé et que le switch leaf ingress connaît l'adresse IP en tant que Endpoint local ou distant, la requête ARP sera envoyée uniquement au Endpoint au lieu d'être inondée dans le Bridge Domain. Si c'est un Endpoint distant qui se trouve sur un autre leaf. Le paquet sera donc encapsulé dans le VXLAN et envoyé au leaf egress. Ensuite, le leaf egress l'enverra uniquement au Endpoint qui possède l'adresse IP cible ARP.
Si le mode flooding ARP est désactivé et que le leaf ingress ne connaît pas l'adresse IP cible (Endpoint distant) ARP, une requête ARP sera envoyée à l'IP anycast proxy du spine au lieu d'être inondée. Dans ce cas il y a deux Scenarios.
Si le spine possède l'entrée du Endpoint distant dans la base de données COOP, il enverra une ARP au switch leaf egress (similaire au scénario précédent).
Si le spine ne possède pas l'entrée du Endpoint disant dans la base de données COOP, il drop la requête ARP et enverra immédiatement un paquet interne au switch leaf. Le switch leaf générera ensuite une nouvelle requête ARP avec comme adresse IP source, la SVI (gateway pervasive) du bridge domain et inondera la requête ARP à tous les switches leaf de ce Bridge Domain, et La prochaine requête ARP pour le meme Endpoint sera envoyée uniquement au leaf egress approprié (appris lors de l'étape précédente). Ce processus est appelé ARP glean ou Silent Host Tracking.
