Résoudre les problèmes DHCP sur Ruckus et Ucopia sous VMware : le rôle clé du Promiscuous Mode, MAC Address Changes et Forged Transmits

      +---------+           +-----------+            +----------+
      |   APs   |   GRE/L2  |   vSZ-D   |    VLAN     | Ucopia   |
      |(Ruckus) |---------->| Dataplane |-----------> | DHCP/AAA |
      +---------+           +-----------+            +----------+
                               |
                               | (vSwitch / Port Group)
                               v
                             (ESXi)

Introduction

Après la restauration des machines virtuelles (VM) Ruckus SmartZone ControlPlane et DataPlane (vSZ-D), il est possible que les clients Wi-Fi ne reçoivent plus d’adresses IP via le serveur DHCP (Ucopia dans notre cas). Bien que les tunnels GRE/L2oGRE entre les APs et le dataplane semblent fonctionnels, les clients ne parviennent pas à obtenir d’adresse IP. Ce problème, bien que complexe à diagnostiquer, est souvent lié à des paramètres réseau dans VMware, notamment le Promiscuous Mode, mais aussi les options MAC Address Changes et Forged Transmits.

Dans notre diagnostic, une difficulté supplémentaire était que nous observions des logs DHCP côté Ucopia, mais ces logs correspondaient à un autre contrôleur Ruckus en fonctionnement. Ce détail a initialement brouillé notre analyse. Cet article détaille le diagnostic complet, les commandes utilisées, et la résolution étape par étape pour rétablir la connectivité.

Pourquoi ce problème survient-il ?

Les infrastructures Ruckus utilisant un dataplane (vSZ-D) transportent le trafic des clients via des tunnels GRE ou L2oGRE. Cela implique que des paquets contenant des adresses MAC multiples (celles des clients) transitent à travers le dataplane.

  1. Promiscuous Mode désactivé sur VMware :
    Les vSwitches ESXi, par défaut, filtrent les paquets réseau et n’autorisent qu’une VM à recevoir les trames correspondant à sa propre adresse MAC. Sans Promiscuous Mode, les trames DHCP des clients, encapsulées via le dataplane, sont bloquées.
  2. MAC Address Changes désactivé :
    Si cette option est désactivée, les trames sortantes avec des adresses MAC différentes ne seront pas acceptées par le vSwitch, ce qui empêche le dataplane d’émettre correctement. Cette option doit être réglée sur « Accept » pour permettre au dataplane (vSZ-D) de recevoir des trames avec des adresses MAC multiples.
  3. Forged Transmits désactivé :
    Cette option empêche le dataplane (vSZ-D) d’envoyer des trames avec des adresses MAC qui ne correspondent pas à sa configuration initiale. Cette option doit être activée pour autoriser les paquets sortants avec une adresse MAC différente de celle de la VM.
  4. Complexité du diagnostic :
    Dans notre cas, les logs Ucopia montraient des requêtes DHCP. Toutefois, ces requêtes provenaient d’un autre contrôleur Ruckus encore actif.
  5. Modifications après restauration :
    Une restauration de VM peut introduire des changements subtils, comme des adresses MAC différentes, des modifications de VLAN, ou des ajustements de configuration réseau non alignés avec l’état précédent.

Symptômes observés

  • Les clients Wi-Fi connectés aux APs ne reçoivent pas d’adresses IP.
  • Les tunnels GRE entre les APs et le vSZ-D apparaissent comme UP dans les logs.
  • Les logs DHCP d’Ucopia n’affichent aucune requêtes DHCP provenant des bornes liées au contrôleur Ruckus défectueux,.
  • Les VLAN, les IP et la configuration globale semblent corrects.

Processus détaillé de diagnostic

1. Vérification initiale sur le ControlPlane (SmartZone)

Pour commencer, nous avons validé la configuration générale de la plateforme Ruckus.

  • Commandes utilisées :
    show running-config zone Permet de confirmer les zones et les WLAN configurés. show running-config data-plane Vérifie les VLAN associés au dataplane, l’adressage IP, et la configuration réseau globale.
    show running-config rks-gre Affiche les tunnels GRE/L2oGRE configurés.

Résultat :
Aucun problème apparent au niveau de la configuration du ControlPlane.

2. Vérification approfondie du dataplane (vSZ-D)

Nous avons ensuite analysé l’état du dataplane, à la recherche de problèmes liés aux tunnels GRE ou à la configuration des interfaces.

  • Commande : show status Vérifie l’état général du dataplane, incluant les VLAN, les IP et la connectivité au ControlPlane.
  • Commande : network-diagnostic simple Permet de détecter les erreurs de configuration réseau potentielles.
  • Analyse des tunnels GRE : show tunnel all Confirme que les tunnels GRE sont actifs, mais certains paquets sont perdus.

Résultat :
Les tunnels GRE étaient fonctionnels, mais des paquets encapsulés ne passaient pas (problème de ping notamment).

3. Investigation côté VMware

L’analyse s’est ensuite portée sur la configuration réseau de l’hyperviseur VMware.

  1. Vérification des port groups :
    Nous avons identifié que le dataplane et le controlplane étaient connectés à des port groups VMware différents. Ces port groups utilisaient des VLAN spécifique.
  2. Inspection du Promiscuous Mode :
    Le Promiscuous Mode était désactivé sur le port group du dataplane, ce qui bloquait le trafic DHCP encapsulé.
  3. MAC Address Changes et Forged Transmits :
    Ces options étaient également désactivées, ce qui bloquait les paquets sortants et limitait la fonctionnalité du dataplane.
  4. VLAN :
    Le VLAN utilisé était correctement configuré, mais le problème subsistait en raison des paramètres réseau VMware.

4. Vérification côté Ucopia

Pour s’assurer que le problème venait bien de la liaison entre le dataplane et Ucopia, nous avons analysé les logs DHCP :

  • Observation :
    Les logs d’Ucopia montraient des requêtes DHCP, mais elles provenaient d’un autre contrôleur Ruckus actif. Aucun trafic DHCP du dataplane en question n’était enregistré.

Résolution étape par étape

Étape 1 : Activer le Promiscuous Mode

  1. Connectez-vous à l’interface vSphere Client ou vCenter.
  2. Localisez le port group utilisé par le dataplane (vSZ-D).
  3. Accédez à l’onglet Security.
  4. Activez le Promiscuous Mode en le réglant sur Accept.
  5. Sauvegardez les modifications.

Étape 2 : Activer MAC Address Changes et Forged Transmits

  1. Toujours dans l’onglet Security du port group :
    • Activez MAC Address Changes : Réglez sur Accept.
    • Activez Forged Transmits : Réglez sur Accept.
  2. Sauvegardez les modifications.

Étape 3 : Vérifier les VLAN

  1. Confirmez que le VLAN utilisé pour le trafic client est bien configuré dans le port group.
  2. Assurez-vous que ce VLAN est correctement trunké jusqu’au serveur Ucopia.

Étape 4 : Relancer les APs et les clients

  1. Redémarrez les APs pour recréer les tunnels GRE avec le dataplane.
  2. Sur les clients Wi-Fi, forcez un renouvellement DHCP avec une commande comme : ipconfig /renew
  3. Surveillez les logs DHCP d’Ucopia pour confirmer que les requêtes des clients sont maintenant visibles.

Conclusion

Dans une infrastructure virtualisée Ruckus/Ucopia, un problème de distribution DHCP après la restauration des VM ControlPlane et DataPlane est souvent lié à une configuration réseau dans VMware. Dans notre cas, l’absence de Promiscuous Mode sur le port group du dataplane a empêché le traitement des trames DHCP clients.

La présence de logs DHCP sur Ucopia provenant d’un autre contrôleur actif a compliqué le diagnostic, mais l’analyse des tunnels GRE et des paramètres VMware a permis d’identifier la cause source.

Checklist pour les futures restaurations :

  1. Promiscuous Mode : Toujours activé sur les port groups des VMs Ruckus DataPlane (VSZ-D).
  2. MAC Address Changes : Réglé sur Accept pour autoriser les trames sortantes.
  3. Forged Transmits : Réglé sur Accept pour éviter le blocage des adresses MAC multiples.
  4. Vérification des VLAN : Assurez-vous que les VLAN nécessaires sont correctement propagés.
  5. Analyse réseau complète : Inclure les logs Ucopia et dataplane dans votre diagnostic.

Publications similaires