Wireless Access

Hi,

 

I fail to see the need for VRRP IP when clustering two controllers in 8.1.

I have an MM and two MD. When clustering the MD I get an option to set VRRP IP, but that IP has to be different for the two MDs. Isn't the point of clustering to have one cluster IP?

 

If I have AP-loadbalancing enabled and don't have VRRP IP set. Will it still loadbalance the AP between the controllers even tho I have my DNS pointing 'aruba-master' to MD1 IP?

 

If I don't use VRRP IP and I want to send RADIUS-request to Clearpass then the request will come from the IP of each MD. But what if i have VRRP. Will the requests from MD1 come from its VRRP IP and requests from MD2 come from VRRP IP2? 

 

Regards

Philip

 

 

Two things.

 

1. for AP discovery, when a NEW AP that has never talked to the cluster is added, you can point them to controller 1 of a 2c ontroller cluster. Once provisioned, the AP will get the node list provisioned on to the AP flash, which is the IP address of every controller in the cluster so that subsequent discoveries won't require DNS, DHCP, etc for that AP. However, if controller 1 of the cluster goes down, while previously provisioned APs will find controller 2 from the nodelist, NEW APs will not. So having a VRRP IP between the cluster members to point AP discovery to for new APs would be beneficial. 

 

Secondly, you would want VRRP IPs for COA, in case one client is moved from one controller to another and CPPM needs to send a COA. 

On your second point I get lost. Lets say I have two controllers:

CTRL1 with IP 192.168.0.1

CTRL2 with IP 192.168.0.2

First I add CTRL1 to the cluster with VRRP IP 192.168.0.10

Then I try to add CTRL2, but I can't use the same VRRP IP (it is giving me an error saying that 192.168.0.10 is used by CTRL1), so I have to use 192.168.0.20 for that.

 

Now Client1 connects, it get "assigned" to CTRL1 so the IP for COA will be 192.168.0.10.

Now Client2 connects and since both controllers in the cluster is active it gets assigned to CTRL2. When that does COA it will use IP 192.168.0.20.

This sort of beats the purpose of having VRRP, or have I got the theory wrong?

 

Two things:

 

For COA to work, within the clustering profile you create and assign a VIP to each cluster member as part of the cluster config. The MM will then assign the priorities to the cluster member automagically for you.

 

For AP discovery, if you want one single VRRP IP for the entire cluster, you would create a single VIP in the 'Redundancy' section and then set priority for all the other cluster members below whichever one you want as the master. That said, for AP discovery, I don't think you need all 12 added, just at least two for redundancy, but that's up to you. And that ONLY applies to new APs, as provisioned APs will have the node list, which contains the IP of every cluster controller.

Ah ok thank you. And if I enable AP LoadBalancing in 8.1 the cluster master will choose what MD the AP will go to.

 

With the new clustering feature we don't need to configure High Availability right?

Correct, the MM will do the cluster management. No need for HA correct.

(Jumping in because I'm going through this setup right now :-)

 

Once I set up the MDs with a cluster VRRP VIP, do I also need to manually set the RADIUS client source IP to the VIP, or will the controller automatically default to it?

I would set it to make sure the controller sends the VIP instead of the native IP. 

Makes sense - thanks very much!

Hi fsweetser,

 

So you will it up so every MD has their own VRRP IP (in the cluster) and that IP will be the source of Radius-packets?

Correct, that's exactly what I'm setting up.

When in the cluster config settings on the MM, when you assign a VRRP IP and VLAN for each MD being added to the cluster, the cluster manager will automatically create a VRRP ID across all cluster members, making that specific MD the Master (priority 255) and all others lower (235, 215, etc). For example, I have three controllers in my lab cluster that runs my network. They are:

 

VMC1 (ipaddr 192.168.200.13 - cluster VIP 192.168.200.23)

VMC2 (ipaddr 192.168.200.14 - cluster VIP 192.168.200.24)

VMC3 (ipaddr 192.168.200.15 - cluster VIP 192.168.200.25)

 

Below is the output from their 'show vrrp' output, but note that I only entered in the cluster cofig for each MD the cluster IP, the cluster VIP and VRRP vlan.

 

Note I also created a cluster-wide VIP for AP discovery as well (VRRP ID 200)

 

###################
(HH-VMC1) #show vrrp

Virtual Router 200:
Description AP_Discovery_200
Admin State UP, VR State MASTER
IP Address 192.168.200.20, MAC Address 00:00:5e:00:01:c8, vlan 200
Priority 255, Advertisement 1 sec, Preemption Disable Delay 0
Auth type PASSWORD, Auth data: ********
tracking is not enabled

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

Virtual Router 221:
Description
Admin State UP, VR State BACKUP
IP Address 192.168.200.24, MAC Address 00:00:5e:00:01:dd, vlan 200
Priority 235, Advertisement 1 sec, Preemption Enable Delay 0
Auth type NONE ********
tracking is not enabled

Virtual Router 222:
Description
Admin State UP, VR State BACKUP
IP Address 192.168.200.25, MAC Address 00:00:5e:00:01:de, vlan 200
Priority 215, Advertisement 1 sec, Preemption Enable Delay 0
Auth type NONE ********
tracking is not enabled
(HH-VMC1) #
###################
(HH-VMC2) #show vrrp

Virtual Router 200:
Description AP_Discovery_200
Admin State UP, VR State BACKUP
IP Address 192.168.200.20, MAC Address 00:00:5e:00:01:c8, vlan 200
Priority 245, Advertisement 1 sec, Preemption Disable Delay 0
Auth type PASSWORD, Auth data: ********
tracking is not enabled

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

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

Virtual Router 222:
Description
Admin State UP, VR State BACKUP
IP Address 192.168.200.25, MAC Address 00:00:5e:00:01:de, vlan 200
Priority 235, Advertisement 1 sec, Preemption Enable Delay 0
Auth type NONE ********
tracking is not enabled
(HH-VMC2) #
###################
(HH-VMC3) #show vrrp

Virtual Router 200:
Description AP_Discovery_200
Admin State UP, VR State BACKUP
IP Address 192.168.200.20, MAC Address 00:00:5e:00:01:c8, vlan 200
Priority 235, Advertisement 1 sec, Preemption Disable Delay 0
Auth type PASSWORD, Auth data: ********
tracking is not enabled

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

Virtual Router 221:
Description
Admin State UP, VR State BACKUP
IP Address 192.168.200.24, MAC Address 00:00:5e:00:01:dd, vlan 200
Priority 215, Advertisement 1 sec, Preemption Enable Delay 0
Auth type NONE ********
tracking is not enabled

Virtual Router 222:
Description
Admin State UP, VR State MASTER
IP Address 192.168.200.25, MAC Address 00:00:5e:00:01:de, vlan 200
Priority 255, Advertisement 1 sec, Preemption Enable Delay 0
Auth type NONE ********
tracking is not enabled
(HH-VMC3) #
###################

Is there any reason I couldn't re-use one of the cluster created VIPs for AP provisioning?  I only have a pair of MDs in my network, and that's not likely to change any time soon.

Nope that will work fine, I just did both to test.

Awesome!  Thanks very much for the quick confirmation.

Just to follow up, I have one MD brought up. It looks like it's started up the cluster, as it shows itself as isolated in show lc-cluster, but VRRP is completely inactive on it, and neither of the MD VIPs are pingable. My best guess is that they won't come online until the second MD has come online at least once (which I can't do until I've migrated my APs over), but I have an ATAC case open to verify.

Clustering, as a function of clustering, doesn't require VRRP. You would have had to have configured it as part of the VRRP component of the cluster config on the MM. Mine looks like this:

 

controller 192.168.200.13 priority 200 mcast-vlan 0 vrrp-ip 192.168.200.23 vrrp-vlan 200

    controller 192.168.200.14 priority 200 mcast-vlan 0 vrrp-ip 192.168.200.24 vrrp-vlan 200

    controller 192.168.200.15 priority 200 mcast-vlan 0 vrrp-ip 192.168.200.25 vrrp-vlan 200

 

But the VRRP component is NOT required. 

Yup, that matches my cluster config in my /md tree:

 

lc-cluster group-profile "campus-primary-cluster"
controller 130.215.39.54 priority 128 mcast-vlan 0 vrrp-ip 130.215.39.55 vrrp-vlan 1039
controller 130.215.39.56 priority 128 mcast-vlan 0 vrrp-ip 130.215.39.57 vrrp-vlan 1039
active-ap-lb
!

 

"show lc-cluster" on 130.215.39.54 shows it as the isolated leader of campus-primary-cluster as expected, but "show vrrp" returns no output at all.

Success! I was able to bring my second MD online, and as soon as I did the lc-cluster configured VRRP instances showed up and started working. Apparently they don't work until both (all?) of the MDs have actually checked in with the MMs at least once. Until then, the VRRP addresses do not come up.

Hopefully knowing this will save someone else this particular headache :)

That's actually good to know! Thanks for following up!

This was EXACTLY what I was looking for in order to understand clustering VRRP. Thank you!

 

One question - prior to upgrading to 8.x, one of my interface VLANs was acting as a proxy for IGMP to join multicast groups. How does clustering work with multicast? Not all of my VLANs need to use multicast, only a few. I see that there is an option in the cluster profile to specify the multicast VLAN - which should I choose? My controller management VLAN?

 

Thanks!

Hi everybody,

 

As far as I know remember the following:

 

The cluster manager will use the VRID 220+, so if you are using VRRP for AP discovery please use a VRID below 220!

 

 

So can we use one of the VRRP IP address that was created as part of clustering as the DNS address for controller discovery?

hi,

 

In theory I think you can. There is always a backup VRRP on one of the other members of the cluster.

 

That said, I don't think it is best practise.

 

More important, with a cluster of 4 MC's you can setup the VRRP discovery IP on all four with different prio for VRRP. So you always have that AP discovery IP active. If you use the VRRP from a cluster member (intended for the CoA/Authentication) for the AP discovery you only count on two MC's, not the total of four.

 

Hope this helps

 

 

I wouldn't - there's a catch with VRRP.

 

If you bring up a single controller, the VRRP addresses are not active at all.  This means they won't work for AP discover, and the controllers will only use their directly configured IP addresses for RADIUS/TACACS.  Only once the cluster is up and running, will the VRRP addresses become active.

 

To work around this, I recommend two things.

1. Put all of the directly configured controller IP addresses into DNS for discovery, not the VRRP ones.
2. Make sure that your RADIUS server is prepared to handle requests from both VRRP and directly configured addresses.

That’s why it is recommended to have the separate VRRP (redundancy service) set up.

AFAIK the AP will not use all of the configured IP addresses in DNS for discovery so if one MC/MD is down new AP’s might not connect correctly.

Can anyone answer efisher214's question about the multicast VLAN? I'm confused about that too. I have several VLANs that I want to allow multicast on, but I have several others that I don't. The configuration only allows you to add one VLAN as the multicast VLAN, so would that be the management VLAN?

I worked with TAC on this. You just need to choose one of the VLANs to proxy the traffic for all of the VLANs. For example, I had multicast traffic on VLAN 301-305. I made VLAN 301 the mcast vlan. Everything works automagically.

OK - That's one of the other ideas I thought about trying. Thanks for the reply efisher214!

One question about cluster IP addresses.

So if I have 2 controller in a cluster, I need at least 5 IP addresses based on the documentation, namely:

• MD1 mgmt IP address (eg. 10.0.0.11)
• MD1 VRRP IP address to CoA (eg. 10.0.0.21)
• MD2 mgmt IP address (eg. 10.0.0.12)
• MD2 VRRP IP address to CoA (eg. 10.0.0.22)
• Cluster VRRP IP address for APs (eg. 10.0.0.10)

What happens if one MDs "VRRP IP address to CoA" matches the "cluster VRRP IP address for APs", will that cause any problems, or not?

I think somethink like this:

• MD1 mgmt IP address (eg. 10.0.0.11)
• MD1 VRRP IP address to CoA (eg. 10.0.0.21)
• MD2 mgmt IP address (eg. 10.0.0.12)
• MD2 VRRP IP address to CoA (eg. 10.0.0.10)
• Cluster VRRP IP address for APs (eg. 10.0.0.10)

I have inherited an Aruba network that is set up this way, and because we are in the process of troubleshooting client connectivity issues, I would like to know if this could cause a problem?
 
Thanks!

Original Message:
Sent: Jan 16, 2019 12:31 AM
From: mrtwentytwo
Subject: Clustering MD in 8.x. The need for VRRP IP?

That's why it is recommended to have the separate VRRP (redundancy service) set up.

AFAIK the AP will not use all of the configured IP addresses in DNS for discovery so if one MC/MD is down new AP's might not connect correctly.

If there is manual configuration for the Cluster VRRP IP that has a duplicate IP address as what is configured for CoA, one of them likely isn't working properly already.  One of the VRRP instances should be in an error state.

Changing the CoA address for MD2 will require reconfiguring the cluster profile, do that during a maintenance period.

------------------------------
Carson Hulcher, ACEX#110
------------------------------

Original Message:
Sent: Oct 23, 2023 06:38 PM
From: safranek
Subject: Clustering MD in 8.x. The need for VRRP IP?

One question about cluster IP addresses.

So if I have 2 controller in a cluster, I need at least 5 IP addresses based on the documentation, namely:

• MD1 mgmt IP address (eg. 10.0.0.11)
• MD1 VRRP IP address to CoA (eg. 10.0.0.21)
• MD2 mgmt IP address (eg. 10.0.0.12)
• MD2 VRRP IP address to CoA (eg. 10.0.0.22)
• Cluster VRRP IP address for APs (eg. 10.0.0.10)

What happens if one MDs "VRRP IP address to CoA" matches the "cluster VRRP IP address for APs", will that cause any problems, or not?

I think somethink like this:

• MD1 mgmt IP address (eg. 10.0.0.11)
• MD1 VRRP IP address to CoA (eg. 10.0.0.21)
• MD2 mgmt IP address (eg. 10.0.0.12)
• MD2 VRRP IP address to CoA (eg. 10.0.0.10)
• Cluster VRRP IP address for APs (eg. 10.0.0.10)

I have inherited an Aruba network that is set up this way, and because we are in the process of troubleshooting client connectivity issues, I would like to know if this could cause a problem?
 
Thanks!

Original Message:
Sent: Jan 16, 2019 12:31 AM
From: mrtwentytwo
Subject: Clustering MD in 8.x. The need for VRRP IP?

That's why it is recommended to have the separate VRRP (redundancy service) set up.

AFAIK the AP will not use all of the configured IP addresses in DNS for discovery so if one MC/MD is down new AP's might not connect correctly.

Jerrod,  did you ever run into an issue when upgrading a controller via the USB port?  The controller sees the USB when I do a "show USB", but nothing comes up when I do a "show storage".   The USB has the folder Arubaimage with file inside.

------------------------------
Peter Abene
------------------------------

Original Message:
Sent: Aug 03, 2017 08:27 AM
From: Jerrod Howard
Subject: Clustering MD in 8.x. The need for VRRP IP?

Two things.

 

1. for AP discovery, when a NEW AP that has never talked to the cluster is added, you can point them to controller 1 of a 2c ontroller cluster. Once provisioned, the AP will get the node list provisioned on to the AP flash, which is the IP address of every controller in the cluster so that subsequent discoveries won't require DNS, DHCP, etc for that AP. However, if controller 1 of the cluster goes down, while previously provisioned APs will find controller 2 from the nodelist, NEW APs will not. So having a VRRP IP between the cluster members to point AP discovery to for new APs would be beneficial. 

 

Secondly, you would want VRRP IPs for COA, in case one client is moved from one controller to another and CPPM needs to send a COA.