Notre topologie commence à prendre forme. Jusqu’à maintenant, nous avons:

  • installé 2 Mobility Master
  • configuré la redondance de niveau 2 entre les deux MM du DC
  • configuré la redondance de niveau 3 entre les MM du DC et celui de HQ
  • associé les 2 contrôleurs (MC) de HQ à nos MM

Aujourd’hui nous allons mettre les deux MC de HQ en Cluster, comme décrit sur le schéma ci-dessous:

Nous ne rentrerons pas dans les détails du clustering de contrôleurs Aruba, mais il me semble important de rappeler les principes et avantages de cette fonctionnalité. Il s’agit d’une fonctionnalité disponible exclusivement en ArubaOS 8, dans une architecture avec MM.

Le cluster de contrôleurs permet de:

  • multiplier la capacité en nombre d’AP et nombre de clients (le 7280 pouvant accueillir jusque 2048 AP, et un cluster allant jusque 12 membres, je vous laisse faire le calcul)
  • répartir la charge entre les membres du cluster. Un algorithme se charge de répartir les AP et les clients entre les différents membres.
  • proposer un roaming hyper performant. Les clients sont ancrés sur un des membres (notion de UAC = User Anchor Controller), et conservent le même ancrage avec le roaming
  • augmenter le niveau de redondance. Les AP ont en permanence un tunnel vers un Active et un Standby controller (notion de AAP = AP Anchor Controller). De fait, le failover est transparent en cas de perte d’un membre du cluster

Ces éléments sont extrêmement détaillés dans les cours ACMP, et sont bien sûr supposés comme connus pour le passage de l’ACMX.

Donc sans plus attendre, entrons dans le vif du sujet. Comme pour les MM, la configuration d’un cluster se fait en plusieurs étapes:

  • configuration d’une adresse de VRRP
  • configuration du profil Cluster
  • assignation des contrôleurs au profil Cluster

Introduction sur la configuration dans la hiérarchie

En CLI, avant de commencer la configuration, il est également important de situer sur quel élément de la hiérarchie on va l’effectuer. Comme on l’a vu, la hiérarchie du MM s’obtient grâce à la commande show configuration node-hierarchy

(mm1) [mm] #show configuration node-hierarchy

Default-node is not configured. Autopark is disabled.

Configuration node hierarchy
----------------------------
Config Node                    Type    Name
-----------                    ----    ----
/                              System
/md                            System
/md/ACMX                       Group
/md/ACMX/DC                    Group
/md/ACMX/HQ                    Group
/md/ACMX/HQ/00:0c:29:4d:a8:6e  Device  vmc2
/md/ACMX/HQ/00:0c:29:cc:3e:99  Device  vmc1
/mm                            System
/mm/mynode                     System

Pour configurer sur le MM, il suffit de passer en mode configuration après avoir fait un cd /mm

(mm1) [mm] #cd /mm
(mm1) [mm] #configure t
Enter Configuration commands, one per line. End with CNTL/Z

(mm1) [mm] (config) #

De la même façon, si l’on souhaite configurer un noeud de la hiérarchie MD, on va se placer au niveau de la hiérarchie où l’on souhaite créer l’objet.

Par exemple, je peux créer un WLAN ou un autre élément de configuration au niveau /MD/ACMX, qui sera hérité dans l’ensemble de la hiérarchie:

(mm1) [ACMX] (config) #cd /md?
/md
/md/ACMX
/md/ACMX/DC
/md/ACMX/HQ
<node-path>             Path of config node
(mm1) [ACMX] (config) #cd /md/ACMX
(mm1) [ACMX] (config) #

Par contre, afin de modifier la configuration spécifique sur un contrôleur, il faut utiliser la commande change-config-node:

(mm1) [ACMX] (config) #change-config-node ?
/
/md
/md/ACMX
/md/ACMX/DC
/md/ACMX/HQ
/mm
/mm/mynode
vmc1                    Alias for /md/ACMX/HQ/00:0c:29:cc:3e:99
vmc2                    Alias for /md/ACMX/HQ/00:0c:29:4d:a8:6e
<node-path>             Path of config node

(mm1) [ACMX] (config) #change-config-node vmc1
(mm1) [00:0c:29:cc:3e:99] (config) #

Ce point est important pour la suite, car certains éléments (comme le VRRP) ne sont applicables que sur un contrôleur, et ne peuvent être configurés dans la hiérarchie.

Configuration d’une adresse de VRRP

A propos de VRRP pour un cluster

Concernant l’adresse de VRRP du Cluster, il est à noter que celle-ci n’est pas obligatoire pour que le protocole de découverte du contrôleur par les AP (ADP = Aruba Discovery Protocol) puisse découvrir l’ensemble du cluster.

En effet, il est tout à fait possible de se passer de VRRP. Dans ce cas, on peut pointer ADP (avec option 43, DNS,…) sur n’importe lequel des membres du cluster. Ce dernier se chargera d’envoyer la liste des membres, et d’assigner pour chaque AP le A-AAC (Active AP Anchor Controller) et le S-AAC (Standby AP Anchor Controller).

Néanmoins, l’activation du VRRP va permettre d’obtenir un haut niveau de disponibilité sur l’adresse utilisée pour la découverte. Sans VRRP, si le membre vers lequel ADP est dirigé est inopérant, la découverte n’est plus possible.

La configuration est appliquée sur VMC1 et VMC2.

Configuration sur VMC1

change-config-node vmc1
   authentication ***
   ip address 10.1.10.200
   vlan 110
   no shut
   priority 200
   preempt

Configuration sur VMC2

change-config-node vmc2
   authentication ***
   ip address 10.1.10.200
   vlan 110
   no shut
   priority 100

Vérification du statut VRRP

! Connexion sur VMC1 depuis MM2
(mm1) [00:0c:29:4d:a8:6e] (config) #cd vmc1
(mm1) [00:0c:29:cc:3e:99] (config) #mdconnect

 Redirecting to Managed Device Shell

(vmc1) [MDC] #show vrrp
Virtual Router 110:
    Description
    Admin State UP, VR State MASTER
    IP Address 10.1.10.200, MAC Address 00:00:5e:00:01:6e, vlan 110
    Priority 200, Advertisement 1 sec, Preemption Enable Delay 0
    Auth type PASSWORD, Auth data: ********
    tracking is not enabled
(vmc1) [MDC] #exit


! Connexion sur VMC2 depuis MM1
(mm1) [00:0c:29:cc:3e:99] (config) #cd vmc2
(mm1) [00:0c:29:4d:a8:6e] (config) #mdconnect

 Redirecting to Managed Device Shell

(vmc2) [MDC] #show vrrp
Virtual Router 110:
    Description
    Admin State UP, VR State BACKUP
    IP Address 10.1.10.200, MAC Address 00:00:5e:00:01:6e, vlan 110
    Priority 100, Advertisement 1 sec, Preemption Disable Delay 0
    Auth type PASSWORD, Auth data: ********
    tracking is not enabled
(vmc2) [MDC] #exit

Configuration d’un profil Cluster

Ici la configuration peut être appliquée à l’endroit où vous le souhaitez dans la hiérarchie. Comme cette configuration cluster ne concerne que des contrôleurs sur HQ, je vais créer le profil dans /md/ACMX/HQ.

(mm1) [mm] (config) #cd /md/ACMX/HQ
(mm1) [HQ] (config) #lc-cluster group-profile HQ-Cluster
(mm1) ^[HQ] (Classic Controller Cluster Profile "HQ-Cluster") #controller 10.1.10.201
(mm1) ^[HQ] (Classic Controller Cluster Profile "HQ-Cluster") #controller 10.1.10.202
(mm1) ^[HQ] (Classic Controller Cluster Profile "HQ-Cluster") #write memory
(mm1) [HQ] (Classic Controller Cluster Profile "HQ-Cluster") #

Assignation des contrôleurs au profil Cluster

A propos du VLAN Probing

Maintenant que le profil est créé, il faut manuellement indiquer à VMC1 et VMC2 qu’ils doivent rejoindre ce cluster.

Il est à noter cette commande spécifique dans la configuration du Cluster:

lc-cluster exclude-vlan 1

Les différents membres d’un Cluster vont tenter de s’échanger des probes sur l’ensemble des VLANs configurés (vlan probing) :

  • si les probes sont reçus avec succès sur l’ensemble des VLANs, les membres du Cluster formeront un L2-Connected Cluster
  • si les keepalive ne sont pas reçus sur un ou plusieurs VLANs, les membres du cluster formeront un L3-Connected Cluster

Il faut garder à l’esprit que les VLANs configurés sur les ports d’un contrôleur seront utilisés pour passer le trafic data des clients. Si les VLANs ne sont pas identiques entre les membres d’un Cluster, cela signifie que le roaming de niveau 2 inter-contrôleurs ne pourra se faire. Le mécanisme de VLAN Probe est donc là pour signaler qu’un défaut existe sur un des contrôleurs.

Dans ma topologie, les 2 contrôleurs (VMC1 et VMC2) sont connectés au réseau sur une interface access avec uniquement le VLAN 110. Il sera donc impossible aux probes d’être transmises sur le VLAN 1 (qui est le VLAN par défaut, toujours existant sur les contrôleurs. Il convient donc de l’exclure afin que les probes puissent être transmises et reçues sur l’ensemble des VLANs configurés.

Il est également à noter que si mes contrôleurs étaient connectés à une interface Trunk, il conviendra de vérifier que les VLANs sont configurés à l’identique sur les deux contrôleurs afin d’éviter le scénario de L3-Connected Cluster, et s’assurer que le roaming de niveau 2 des clients puisse s’effectuer correctement.

La capture ci-dessous montre le résultat d’une erreur de VLAN sur un membre de Cluster:

Configuration des VMC

Après cet aparté sur les VLAN Probes, voyons la configuration des contrôleurs:

Configuration sur VMC1

! Cette configuration doit s'appliquer sur le contrôleur VMC1 directement
(mm1) [mm] (config) #change-config-node vmc1
(mm1) [00:0c:29:cc:3e:99] (config) #lc-cluster group-membership HQ-Cluster
! Il est important d'exclure le VLAN 1 de la formation du cluster comme
! expliqué juste avant
(mm1) ^[00:0c:29:cc:3e:99] (config) #lc-cluster exclude-vlan 1
(mm1) ^[00:0c:29:cc:3e:99] (config) #write memory
Saving Configuration...
Configuration Saved.

Configuration sur VMC2

! Cette configuration doit s'appliquer sur le contrôleur VMC2 directement
(mm1) [mm] (config) #change-config-node vmc2
(mm1) [00:0c:29:4d:a8:6e] (config) #lc-cluster group-membership HQ-Cluster
(mm1) ^[00:0c:29:4d:a8:6e] (config) #lc-cluster exclude-vlan 1
(mm1) ^[00:0c:29:4d:a8:6e] (config) #write memory
Saving Configuration...
Configuration Saved.

Vérification du fonctionnement

La capture ci-dessous montre le résultat attendu sur l’un des contrôleurs:

[ACMX] L2/L3 Infrastructure – L2/L3 Controller Clustering
Étiqueté avec :            

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *