ACI ARP deluge!

[Jimena Saez]

ACI a longtemps été présenté comme un système dans lequel les demandes ARP sont minimisées, mais j’ai récemment fait quelques tests lors de l’exploration de la fonctionnalité ARP Gleaning (voir BRKACI-3101 si vous ne savez pas ce qu’est ARP Gleaning) et j'ai constaté que dans le cas de demandes ARP pour des adresses IP inexistantes, ACI multiplie par 4 le nombre d'ARP envoyées et ajoute un "ARP" supplémentaire contenant des "balises VLAN" susceptibles de fuir sur les réseaux des clients et qui peuvent causer potentiellement des dégâts considérables.

Voici ma configuration:

J'ai quatre serveurs (serveurs Web) dans le même Bridge Domain et le même EPG. Le flux ARP est désactivé sur le BD et l'adresse IP du sous-réseau du BD de 192.168.92.1 sert de passerelle par défaut pour chaque hôte.

1. Le serveur Web VM1 est un VM sur un hôte ESXi connecté à Leaf101 (192.168.92.11)
2. Le serveur Web VM2 est un VM sur un hôte ESXi connecté à Leaf102 (192.168.92.12)
3. Le serveur Web BM est un hôte Bare Metal directement associé à Leaf102 (192.168.92.10)

• Scénario #1: Attaché comme accès (802.1P)
• Scénario #2: Attaché comme accès (non étiqueté)
• Scénario #3: Attaché comme coffre

4. Le serveur Web L2EP est un hôte connecté à un commutateur qui se connecte simultanément via un VPC à Leaf101 et à Leaf102 (192.168.92.200)

• ACI exécute la version 3.2 (1m)
• Les commutateurs Leaf sont N9K-C9396PX

Une image aide toujours.

ARP Gleaning Test Setup [Edited thanks to KELLEYD]

Configuration du test de nettoyage ARP [Édité grâce à KELLEYD]

Maintenant, comme je l'ai dit, il s'agissait d'une petite expérience pour démontrer le fonctionnement d'ARP Gleaning. J'ai donc envoyé un seul ping depuis chacun des quatre postes de travail ci-dessus à une adresse IP inexistante (192.168.92.99). Dans chaque cas, ce ping unique a généré 3 demandes ARP dès l'hôte d'origine (Lubuntu) et j'ai exécuté des captures Wireshark sur les quatre postes de travail. J'ai inclus mes résultats bruts ci-dessous.

Les constatations étaient exactement les mêmes pour les trois scénarios énumérés ci-dessus (où l'hôte Bare Metal était attaché d'abord en tant qu'Access (802.1P), puis en tant qu'Access (non étiqueté), puis en tant que Trunk)

• Lorsqu'une demande ARP pour une adresse IP inconnue est envoyée par un poste de travail, ACI génère des demandes ARP pour cette adresse IP inconnue provenant de l'adresse de passerelle ACI (192.168.92.1).

1. Pour les hôtes connectés via VPC, 4 demandes ARP sont reçues pour chaque demande ARP envoyée. Facteur de multiplication = 4
2. Pour les hôtes et les ordinateurs virtuels directement connectés, une demande ARP est reçue de la passerelle IP pour chaque demande ARP envoyée.
3. Pour les hôtes ou les commutateurs directement connectés, une demande ARP supplémentaire est reçue de l'hôte d'origine, mais encapsulée avec une balise VLAN qui représente le VLAN Canonical du port auquel l'hôte / le commutateur est connecté.

• Ce résultat est très inquiétant. Cela signifie que si par exemple un port était configuré pour le VLAN 2092, mais que le VLAN canonique pour ce port était 45, le périphérique / commutateur connecté à ce port recevrait une diffusion ARP non seulement sur le VLAN 2092, mais également sur le VLAN 45. Si un commutateur connecté avait déjà un VLAN 45 représentant un autre groupe de serveurs, le trafic fuirait du VLAN 2092 vers le VLAN 45 et si ce VLAN 45 possédait un périphérique correspondant à l'adresse IP inconnue, il pourrait être soumis à une déluge de demandes ARP.
• Sur la base de ce résultat, je soupçonne que les demandes ARP encapsulées avec une balise 802.1Q correspondant au VLAN canonique sont également envoyées aux hôtes ESXi et aux VPC, mais je n’ai pas eu le temps de le faire.

Ces résultats soulèvent quelques questions:

• Pourquoi ACI envoie TOUTES les trames encapsulées dans le VLAN canonique en dehors de la structure?
• Comment puis-je empêcher ACI d'envoyer des trames ARP potentiellement nuisibles - mes résultats prouvent qu'il n'est pas suffisant de désactiver les inondations ARP sur le domaine du pont
• Pourquoi ACI envoie-t-il quatre trames ARP Gleaning sur une liaison VPC pour chaque demande ARP envoyée par un hôte?
• Pourquoi ACI envoie-t-il le paquet ARP Gleaning en arrière de l'interface sur laquelle l'ARP d'origine a été reçu?

Est-ce que quelqu'un a des réponses?

Voici mes résultats bruts

 

Scénario 1: l'hôte BM connecté en tant qu'accès (802.1P)

Test n ° 1: Envoyez 3xARPs pour une adresse IP inconnue (sur le même sous-réseau) à partir de la VM attachée à la feuille 101

Résultat:

VM attachée à la feuille 101 - celle qui envoie les ARP voit:

• Requêtes 3xARP du même (192.168.92.11) PLUS
• Requêtes 3xARP à partir de l'adresse IP par défaut de GW (ARP Gleaning at work)

VM attaché à la feuille 102 voit:

• Requêtes 3xARP à partir de l'adresse IP par défaut de GW (ARP Gleaning at work)

BMH Attaché à la feuille 102 voit:

• Requêtes 3xARP du GW IP PLUS par défaut
• Requêtes 3xARP provenant de la VM source (192.16892.11) - indiquant que les ARP sont saturés, même si la saturation ARP est désactivée
  • Curieusement, les ARP de la VM source sont étiquetés avec l'ID de VLAN 45, qui est l'ID de VLAN canonique pour le BMH attaché à la feuille 102.

L'hôte recevant du trafic via VPC connecté à Leaf101 + 102 affiche:

• 12 demandes ARP provenant de l'adresse IP par défaut (ARP Gleaning on Steroids)

Test n ° 2: Envoyez 3xARPs pour une adresse IP inconnue (sur le même sous-réseau) à partir de la VM attachée à la feuille 102

Résultat:

VM attachée à la feuille 102 - Celui qui envoie les ARP voit:

• Requêtes 3xARP du même (192.168.92.12) PLUS
• Requêtes 3xARP à partir de l'adresse IP par défaut de GW (ARP Gleaning at work)

La VM attachée à la feuille 101 voit:

• Requêtes 3xARP à partir de l'adresse IP par défaut de GW (ARP Gleaning at work)

BMH Attaché à la feuille 102 voit:

• Requêtes 3xARP du GW IP PLUS par défaut
• Requêtes 3xARP émanant de la VM source (192.168.92.12) - indiquant que les ARP sont saturés et que, de nouveau, ces ARP portent la balise canonique ID VLAN

Hôte recevant du trafic via VPC connecté à Leaf101 + 102 voit

• 12 demandes ARP provenant de l'adresse IP par défaut (ARP Gleaning on Steroids)

Test n ° 3: Envoyez 3xARP pour une adresse IP inconnue (sur le même sous-réseau) à partir du BMH attaché à la feuille 102

Résultat:

BMH Attaché à la feuille 102 - Celui qui envoie les ARP voit:

• Requêtes 3xARP à partir de l'adresse IP par défaut GW (ARP Gleaning au travail) PLUS
• 6xARP demandes de lui-même (192.168.92.10):
  • 3XARP au format non balisé
  • 3xARPs de l'hôte source (lui-même) encapsulé avec une balise VLAN canonique

La VM attachée à la feuille 101 voit:

• Requêtes 3xARP à partir de l'adresse IP par défaut de GW (ARP Gleaning at work)

VM attaché à la feuille 102 voit:

• Requêtes 3xARP à partir de l'adresse IP par défaut de GW (ARP Gleaning at work)

Hôte recevant du trafic via VPC connecté à Leaf101 + 102 voit

• 12 demandes ARP provenant de l'adresse IP par défaut (ARP Gleaning on Steroids)

Test n ° 4: envoyez 3 xARP pour une adresse IP inconnue (sur le même sous-réseau) à partir du BMH connecté à un commutateur via un VPC sur Leaf101 et Leaf 102

Résultat:

Hôte connecté via un commutateur via un VPC connecté à Leaf101 + 102

• 3xARP demandes de sa part (192.168.92.200) PLUS
• 12 demandes ARP provenant de l'adresse IP par défaut (ARP Gleaning on Steroids)

BMH Attaché à la feuille 102 voit:

• Requêtes 3xARP à partir de l'adresse IP par défaut GW (ARP Gleaning au travail) PLUS
• Requêtes 3xARP de l'hôte source (192.168.92.200) encapsulées dans un VLAN canonique

La VM attachée à la feuille 101 voit:

• Requêtes 3xARP à partir de l'adresse IP par défaut de GW (ARP Gleaning at work)

VM attaché à la feuille 102 voit:

• Requêtes 3xARP à partir de l'adresse IP par défaut de GW (ARP Gleaning at work)

Scénario n ° 2: l'hôte BM connecté en tant qu'accès (non balisé)

Les résultats étaient exactement les mêmes que ceux de l'encapsulation 802.1P

Scénario n ° 3: l'hôte de BM attaché en tant que coffre

Les résultats étaient exactement les mêmes avec les exceptions suivantes:

• L'hôte BM a reçu les demandes ARP Gleaning encapsulées avec la balise vlan 802.1Q de 2092 (Les requêtes ARP parasites encapsulées dans le VLAN canonique persistaient toujours)
• Lorsque l'hôte connecté BM envoie ses demandes ARP non balisées, elles ont été abandonnées (comme prévu) par le commutateur Leaf qui était maintenant configuré en tant que port de ligne réseau.

Screendumps pour le test n ° 1

Test#1 Capture from VM attached to Leaf101

Test n ° 1 Capture à partir de la VM attachée à Leaf101

Test#1 Capture from VM attached to Leaf102

Test n ° 1 Capture à partir de la VM attachée à Leaf102

Test#1 Capture from BMH Host (802.1P) attached to Leaf102

Test n ° 1 Capture à partir de l'hôte BMH (802.1P) attaché à Leaf102

show vlan extended

Montrer le VLAN étendu

Test#1 Capture from host attached to switch attached via VPC

Test n ° 1 Capture à partir de l'hôte connecté au commutateur connecté via VPC

Screendumps pour le test n ° 2

Test#2 Capture from VM attached to Leaf102

Test n ° 2 Capture à partir de la VM attachée à Leaf102

Test#2 Capture from VM attached to Leaf101

Test n ° 2 Capture à partir de la VM attachée à Leaf101

Test#2 Capture from BMH Host (802.1P) attached to Leaf102

Test n ° 2 Capture à partir de l'hôte BMH (802.1P) attaché à Leaf102

Test#2 Capture from host attached to switch attached via VPC

Test n ° 2 Capture à partir de l'hôte connecté au commutateur connecté via VPC

Screendumps pour le test n ° 3

Test#3 Capture from BMH Host (802.1P) attached to Leaf102

Test n ° 3 Capture à partir de l'hôte BMH (802.1P) attaché à Leaf102

Test#3 Capture from VM attached to Leaf101

Test n ° 3 Capture à partir de la VM attachée à Leaf101

Test#3 Capture from VM attached to Leaf102

Test n ° 3 Capture à partir de la VM attachée à Leaf102

Test#3 Capture from host attached to switch attached via VPC

Test n ° 3 Capture à partir de l'hôte connecté au commutateur connecté via VPC

Screendumps pour le test n ° 4

Test#4 Capture from host attached to switch attached via VPC

Test n ° 4 Capture à partir de l'hôte connecté au commutateur connecté via VPC

Test#4 Capture from BMH Host (802.1P) attached to Leaf102

Test n ° 4 Capture à partir de l'hôte BMH (802.1P) attaché à Leaf102

Test#4 Capture from VM attached to Leaf101

Test n ° 4 Capture à partir de la VM attachée à Leaf101

Test#4 Capture from VM attached to Leaf102

Test n ° 4 Capture à partir de la VM attachée à Leaf102

RedNectar

aka Chris Welsh

Publié par: RedNectar / Version originale en anglais

[Jimena Saez · Accepted solution]

La réponse...

J'utilise 3.0 (2k) et non pas 3.0 (1k). Désolé pour ça.
Quoi qu'il en soit, j'ai essayé de reproduire votre problème dans mon laboratoire aujourd'hui, mais il s'avère que quelqu'un a mis en production les commutateurs de feuilles de première génération qui étaient dans le laboratoire! Je n'ai donc pas pu tester la théorie de la 1ère génération. Pour le moment, en tout cas.

Bonne nouvelle, je suppose: sous 3.0 (2k), en utilisant des commutateurs 93180YC-EX, je n'ai PAS vu le même comportement chez un hôte directement connecté. J'ai essayé dans les trois modes (trunk, dot1p et non étiqueté). J'ai également effacé les terminaux après chaque modification, juste pour en être sûr. Dans mon cas, j'ai utilisé encap vlan-500. Le cvid sur le commutateur de feuille n’était pas 500. J’ai oublié exactement ce que c’était, mais ce qui est important c’est que ce n’était pas 500.

Dans les trois situations, j'ai seulement vu les demandes ARP de la passerelle par défaut être diffusées, comme prévu. Je n'ai vu aucun message ARP en monodiffusion ni d'autre adresse que la passerelle.

Une fois connecté, j'ai vu les images ci-dessus étiquetées avec le VID attendu: 500. Je n'ai rien vu étiqueté avec le cvid, ni rien non étiqueté.

Dans les modes 802.1p et non étiquetés, je ne voyais que des images non étiquetées. Rien d'inattendu.

Encore une fois, je suppose que c'est une bonne nouvelle. J'aimerais tester cette version avec un commutateur de première génération, mais je ne serais peut-être pas en mesure de le faire.

Nous sommes à la recherche d'une mise à niveau de la structure et nous avons été invités à mettre à niveau le laboratoire à la version 3.2. Espérons que cela se produira la semaine prochaine. Une fois que c'est terminé, je vais répéter le test encore une fois sur les commutateurs 93180YC-EX au moins, et je vous ferai savoir ce que je vois.

Contribution de: KELLEYD / Plus de détails ici (version en anglais)