Wireless Access

I have a situation that I have 4 controllers divided into 2 clusters and both clusters are in the same VLAN. I configured the cluster as shown below.

 

Cluster 1

 

lc-cluster group-profile "lc-cluster1"
    controller 10.60.10.136 priority 128 mcast-vlan 0 vrrp-ip 10.60.10.138 vrrp-vlan 3010 group 0 rap-public-ip 0.0.0.0
    controller 10.60.10.137 priority 128 mcast-vlan 0 vrrp-ip 10.60.10.139 vrrp-vlan 3010 group 0 rap-public-ip 0.0.0.0

 

Cluster2

lc-cluster group-profile "lc-cluster2"
    controller 10.60.11.136 priority 128 mcast-vlan 0 vrrp-ip 10.60.11.138 vrrp-vlan 3010 group 10 rap-public-ip 0.0.0.0
    controller 10.60.11.137 priority 128 mcast-vlan 0 vrrp-ip 10.60.11.139 vrrp-vlan 3010 group 10 rap-public-ip 0.0.0.0

As you can see, both clusters are in the same VLAN (ID 3010) which has subnet 10.60.10.0/23. I changed the group ID in the second cluster, but now the following problem arises.

 

The VRRP configuration uses the same VRRP ID and generates the same MAC address.

 

VRRP ID 220 on cluster 1

Virtual Router 220:
    Description 
    Admin State UP, VR State MASTER
    IP Address 10.60.10.138, MAC Address 00:00:5e:00:01:dc, vlan 3010
    Priority 255, Advertisement 1 sec, Preemption Enable Delay 0
    Auth type NONE ********
    tracking is not enabled

VRRP ID 220 on cluster 2

Virtual Router 220:
    Description 
    Admin State UP, VR State MASTER
    IP Address 10.60.11.138, MAC Address 00:00:5e:00:01:dc, vlan 3010
    Priority 255, Advertisement 1 sec, Preemption Enable Delay 0
    Auth type NONE ********
    tracking is not enabled

Different virtual IP, but both the same MAC address, which leads to some nasty connectivity problems, like VIP's not reachable and authentication issues.

 

I wonder whats the best way to solve this. Manually changing the VRRP ID on the controllers from cluster 2 or can something be done in the lc-cluster group-profile configuration (it seems that changing group-id doesn't help).

 

ArubaOS 8.5.0.0 will allow you to manually change the Cluster VRRP ID and add a passphrase (to solve your current issue) for the COA VRRP instance:

 

A word:

Many people configure the COA VRRP ip address on each controller when adding a controller to a cluster, but NEVER use COA.  This forces you to manage multiple VRRP instances of 220 and over for something that you do not use and creates complexity.  Second:  If you want to add a controller to the cluster later, it will force you to remove the cluster configuration from each MD down the line if you have a VRRP ip address configured.  You can totally sidestep this issue by not configuring a VRRP ip address when adding controllers to the cluster if you are NOT actively using COA.  You can certainly re-add those controllers with an ip address later if you want to actively use COA.  Below is how controllers look when added to a cluster without a VRRP ip address and they work fine.:

 

Since I need COA I managed to get it "fixed" via the following steps:

 

1. Remove both controllers from the lc-cluster
2. Manually configure the VRRP config with different VRRP ID's
3. Add the controllers back to the lc-cluster

The lc-cluster is layer 2 connected and I see that load-balancing of APs and clients is working. You do receive an error message on the controllers.

 

vrrp[4957]: <313446> <4957> <ERRS> |vrrp|  VRRP IP address of vrid 220 conflicts with vrid 241 
vrrp[4957]: <313446> <4957> <ERRS> |vrrp|  VRRP IP address of vrid 221 conflicts with vrid 242 
vrrp[4957]: <313446> <5352> <ERRS> |vrrp|  VRRP IP address of vrid 220 conflicts with vrid 241 
vrrp[4957]: <313446> <5352> <ERRS> |vrrp|  VRRP IP address of vrid 221 conflicts with vrid 242 
vrrp[4957]: <313624> <4957> <ERRS> |vrrp|  VRRP IPv4 220 failed to start: mp/.sock/16301.sock
vrrp[4957]: <313624> <4957> <ERRS> |vrrp|  VRRP IPv4 221 failed to start: mp/.sock/16301.sock
vrrp[4957]: <399816> <4957> <ERRS> |vrrp|  VRID 220: IP address for vrid 220 conflicts with another vr id 241
vrrp[4957]: <399816> <4957> <ERRS> |vrrp|  VRID 221: IP address for vrid 221 conflicts with another vr id 242
vrrp[4957]: <399816> <5352> <ERRS> |vrrp|  VRID 220: IP address for vrid 220 conflicts with another vr id 241
vrrp[4957]: <399816> <5352> <ERRS> |vrrp|  VRID 221: IP address for vrid 221 conflicts with another vr id 242

I don't have a good feeling about that.  I would check to see if COA works.  Even if it does, I don't have a good feeling about it.

I've been running with two clusters in the same VLAN for awhile now with CoA with no known issues. One cluster was originally on 8.3 and used the 'default' VRRP config, the other cluster I configured from the ground up on 8.5 so I was able to customize the VRRP IDs and passphrase so they didn't conflict with the first one. The second cluster is my dev/test cluster, that's the only reason there are two on the same VLAN.

 

But, just a note for anyone else finding this thread to keep in mind: If you connect an AP to the same VLAN as this VLAN with two clusters, you will have little or no control over which cluster the AP joins using L2 ADP discovery when new APs or added or when they reboot. And APs will jump back and forth between clusters, sometimes in an endless loop if you are running two different software versions. To resolve this, disable L2 ADP on the cluster that you don't want APs to automatically join:

 

no adp discovery
no adp igmp-join 

 

Maybe it helps...

 

In my customer setup i run two ArubaOS 8.5.0.5 clusters in the same VLAN. With COA because we use it. I specify a unique VRRP ID per cluster configuration like this. I use DHCP option43/60 for AP provisioning.

 

* picture is from my HomeLAB *

 

 

---

@cjoseph wrote:

. You can totally sidestep this issue by not configuring a VRRP ip address when adding controllers to the cluster if you are NOT actively using COA.  You can certainly re-add those controllers with an ip address later if you want to actively use COA.

---

Doesn't changing/adding the CoA VRRP require you to remove the controllers from the cluster? 

Seems for that reason alone it would be a good best practise to just start with the CoA VRRP configured even if you do not need it. 

 

Heck, people should also be using Clearpass and hence need the CoA.

Yes, that will require you to remove the cluster configuration from each MD once.  If you remove it from each MD and then add them back to the cluster without the COA VRRP configuration, cluster maintenence will not involve removing the MD-specific cluster info in the future.

 

Again, the documentation and slides imply that like everyone has to configure cluster VRRPs at the cluster level, but it is only required for COA and is strictly OPTIONAL.

What version are you running ?
In AOS8.5.0.4 and onwards, you can define the cluster VRRP ID start range

Thank you

Victor Fabian

Pardon typos sent from Mobile

Currently running 8.4.0.2 in the customer environment. Will check what I can do regarding upgrade asap or some manual "intervention" on the VRRP config

 

Hi,

Can I ask if I already have a  cluster which is holding user/AP's and then want to set a VRRP ID and passphrase will it cause any form of outage for the customer ?

Many Thanks


------------------------------
David Hurley
------------------------------

Original Message:
Sent: Dec 12, 2019 11:20 AM
From: Ren� Jorissen
Subject: 2 lc-clusters in same VLAN

Currently running 8.4.0.2 in the customer environment. Will check what I can do regarding upgrade asap or some manual "intervention" on the VRRP config

 

You may need to remove each member of the cluster and add it back in for the changes to take effect. In my experience, adding/removing cluster members may bounce the APs radios and briefly (5-10 seconds) disrupt connectivity. I would highly suggest doing anything like this after-hours.

------------------------------
Michael Haring

AirHeads MVP 2017, 2019-2021
------------------------------

Original Message:
Sent: Jul 29, 2021 06:50 AM
From: David Hurley
Subject: 2 lc-clusters in same VLAN

Hi,

Can I ask if I already have a  cluster which is holding user/AP's and then want to set a VRRP ID and passphrase will it cause any form of outage for the customer ?

Many Thanks


------------------------------
David Hurley

Original Message:
Sent: Dec 12, 2019 11:20 AM
From: Ren� Jorissen
Subject: 2 lc-clusters in same VLAN

Currently running 8.4.0.2 in the customer environment. Will check what I can do regarding upgrade asap or some manual "intervention" on the VRRP config