Wireless Access

Hello All.  Looking for some helpful info on this one.  I have a strange case where I have 2 pairs of clustered controllers, acting as the headend for RAPs.  As for the configs, as much as I can tell, everything is working just fine.  Pair 1's configs are setup virtually identically to the way my Pair 2 is setup (obviously IPs, vrrp id, etc are different).

The basic layout of the inside network is:  Firewall a/b - Switch a/b - Controller a/b.  A side is connected to A side, B side to B side.

The firewall(s) has(haave) an ACL allowing udp/4500 in and the controller(s) it/they sits in front of, is all layer 3.

If I point a RAP to the external IP of A, it connects.  If I point the rap to the "B" side external IP, it connects.  If I connect the RAP to the VRRP address, running "Master/Backup" between the 2 RAP controllers, it sits and spins.

On the controller side doing a show lc-cluster group-membership/vlan probe, it shows l2 (woo hoo) with it's leader and member; vlan probe shows L2 with 0 fails.  I have checked that the cluster is config'd so it shows that it's internal (controller-ip) and external ip is mapped correctly.

controller A and controller B can source ping it's external default gateway - which is an HSRP address on the uplink switch. Because of the security policy I have on the externa; interface of the controllers, I can't ping from the uplink switch to the controllers (although I guess I could remove it to see).

On my external interfaces of my controllers, I do have a session security policy created, to allow the vrrp multicast address between them, ltp2 allowed, and everything else denied.  This same policy I have applied in over 20 controllers globally, so I know it's not the policy (just adding for reference).

My routing is fine (from what I can tell) - I can reach these controllers from internal sources, and like I said before, my RAP can connect to the controllers if I use the external IP of the controller (just not vrrp).  IP route shows I'm directly connected to my external subnet and has a default route, as well as, default gateway.

I'm kind of stumped.  Looking for additional things to look for.  By all accounts, this pair should be working by way of vrrp.  I even went as far as making sure the vrrp address isn't outside of the subnet range.  

Code Im running is 8.7.1.2  

Anyone have any ideas on what I could check next?

Many thanks

In the cluster profile you will want the RAPs connecting to the addresses you have defined in the "RAP Public IP" field. I don't believe terminating it to the VRRP address will work for you. The APs will receive an internal address to connect to after contacting the controller, which obviously wont work coming from outside. Every time I have deployed this, or read about it its is always the Pub IP of one of the controllers in each cluster. Two clusters, one for LMS one for B-LMS. Clustering will take care of building a redundant node list on the AP for cluster failover.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos
------------------------------

Original Message:
Sent: Jan 21, 2022 04:10 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hello All.  Looking for some helpful info on this one.  I have a strange case where I have 2 pairs of clustered controllers, acting as the headend for RAPs.  As for the configs, as much as I can tell, everything is working just fine.  Pair 1's configs are setup virtually identically to the way my Pair 2 is setup (obviously IPs, vrrp id, etc are different).

The basic layout of the inside network is:  Firewall a/b - Switch a/b - Controller a/b.  A side is connected to A side, B side to B side.

The firewall(s) has(haave) an ACL allowing udp/4500 in and the controller(s) it/they sits in front of, is all layer 3.

If I point a RAP to the external IP of A, it connects.  If I point the rap to the "B" side external IP, it connects.  If I connect the RAP to the VRRP address, running "Master/Backup" between the 2 RAP controllers, it sits and spins.

On the controller side doing a show lc-cluster group-membership/vlan probe, it shows l2 (woo hoo) with it's leader and member; vlan probe shows L2 with 0 fails.  I have checked that the cluster is config'd so it shows that it's internal (controller-ip) and external ip is mapped correctly.

controller A and controller B can source ping it's external default gateway - which is an HSRP address on the uplink switch. Because of the security policy I have on the externa; interface of the controllers, I can't ping from the uplink switch to the controllers (although I guess I could remove it to see).

On my external interfaces of my controllers, I do have a session security policy created, to allow the vrrp multicast address between them, ltp2 allowed, and everything else denied.  This same policy I have applied in over 20 controllers globally, so I know it's not the policy (just adding for reference).

My routing is fine (from what I can tell) - I can reach these controllers from internal sources, and like I said before, my RAP can connect to the controllers if I use the external IP of the controller (just not vrrp).  IP route shows I'm directly connected to my external subnet and has a default route, as well as, default gateway.

I'm kind of stumped.  Looking for additional things to look for.  By all accounts, this pair should be working by way of vrrp.  I even went as far as making sure the vrrp address isn't outside of the subnet range.  

Code Im running is 8.7.1.2  

Anyone have any ideas on what I could check next?

Many thanks

Thank DB...but I do have it mapped that way.

within the cluster I have

+ IP address |  no group id |  no vrrp ip  |  no vrrp vlan  |  + RAP PUBLIC IP  |  no Mcast-Vlan


As I said, things are working, except for any connections coming to the vrrp address.
Original Message:
Sent: Jan 22, 2022 10:28 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

In the cluster profile you will want the RAPs connecting to the addresses you have defined in the "RAP Public IP" field. I don't believe terminating it to the VRRP address will work for you. The APs will receive an internal address to connect to after contacting the controller, which obviously wont work coming from outside. Every time I have deployed this, or read about it its is always the Pub IP of one of the controllers in each cluster. Two clusters, one for LMS one for B-LMS. Clustering will take care of building a redundant node list on the AP for cluster failover.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 21, 2022 04:10 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hello All.  Looking for some helpful info on this one.  I have a strange case where I have 2 pairs of clustered controllers, acting as the headend for RAPs.  As for the configs, as much as I can tell, everything is working just fine.  Pair 1's configs are setup virtually identically to the way my Pair 2 is setup (obviously IPs, vrrp id, etc are different).

The basic layout of the inside network is:  Firewall a/b - Switch a/b - Controller a/b.  A side is connected to A side, B side to B side.

The firewall(s) has(haave) an ACL allowing udp/4500 in and the controller(s) it/they sits in front of, is all layer 3.

If I point a RAP to the external IP of A, it connects.  If I point the rap to the "B" side external IP, it connects.  If I connect the RAP to the VRRP address, running "Master/Backup" between the 2 RAP controllers, it sits and spins.

On the controller side doing a show lc-cluster group-membership/vlan probe, it shows l2 (woo hoo) with it's leader and member; vlan probe shows L2 with 0 fails.  I have checked that the cluster is config'd so it shows that it's internal (controller-ip) and external ip is mapped correctly.

controller A and controller B can source ping it's external default gateway - which is an HSRP address on the uplink switch. Because of the security policy I have on the externa; interface of the controllers, I can't ping from the uplink switch to the controllers (although I guess I could remove it to see).

On my external interfaces of my controllers, I do have a session security policy created, to allow the vrrp multicast address between them, ltp2 allowed, and everything else denied.  This same policy I have applied in over 20 controllers globally, so I know it's not the policy (just adding for reference).

My routing is fine (from what I can tell) - I can reach these controllers from internal sources, and like I said before, my RAP can connect to the controllers if I use the external IP of the controller (just not vrrp).  IP route shows I'm directly connected to my external subnet and has a default route, as well as, default gateway.

I'm kind of stumped.  Looking for additional things to look for.  By all accounts, this pair should be working by way of vrrp.  I even went as far as making sure the vrrp address isn't outside of the subnet range.  

Code Im running is 8.7.1.2  

Anyone have any ideas on what I could check next?

Many thanks

Right, and the VRRP address will not work.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos
------------------------------

Original Message:
Sent: Jan 24, 2022 08:59 AM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Thank DB...but I do have it mapped that way.

within the cluster I have

+ IP address |  no group id |  no vrrp ip  |  no vrrp vlan  |  + RAP PUBLIC IP  |  no Mcast-Vlan


As I said, things are working, except for any connections coming to the vrrp address.
Original Message:
Sent: Jan 22, 2022 10:28 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

In the cluster profile you will want the RAPs connecting to the addresses you have defined in the "RAP Public IP" field. I don't believe terminating it to the VRRP address will work for you. The APs will receive an internal address to connect to after contacting the controller, which obviously wont work coming from outside. Every time I have deployed this, or read about it its is always the Pub IP of one of the controllers in each cluster. Two clusters, one for LMS one for B-LMS. Clustering will take care of building a redundant node list on the AP for cluster failover.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 21, 2022 04:10 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hello All.  Looking for some helpful info on this one.  I have a strange case where I have 2 pairs of clustered controllers, acting as the headend for RAPs.  As for the configs, as much as I can tell, everything is working just fine.  Pair 1's configs are setup virtually identically to the way my Pair 2 is setup (obviously IPs, vrrp id, etc are different).

The basic layout of the inside network is:  Firewall a/b - Switch a/b - Controller a/b.  A side is connected to A side, B side to B side.

The firewall(s) has(haave) an ACL allowing udp/4500 in and the controller(s) it/they sits in front of, is all layer 3.

If I point a RAP to the external IP of A, it connects.  If I point the rap to the "B" side external IP, it connects.  If I connect the RAP to the VRRP address, running "Master/Backup" between the 2 RAP controllers, it sits and spins.

On the controller side doing a show lc-cluster group-membership/vlan probe, it shows l2 (woo hoo) with it's leader and member; vlan probe shows L2 with 0 fails.  I have checked that the cluster is config'd so it shows that it's internal (controller-ip) and external ip is mapped correctly.

controller A and controller B can source ping it's external default gateway - which is an HSRP address on the uplink switch. Because of the security policy I have on the externa; interface of the controllers, I can't ping from the uplink switch to the controllers (although I guess I could remove it to see).

On my external interfaces of my controllers, I do have a session security policy created, to allow the vrrp multicast address between them, ltp2 allowed, and everything else denied.  This same policy I have applied in over 20 controllers globally, so I know it's not the policy (just adding for reference).

My routing is fine (from what I can tell) - I can reach these controllers from internal sources, and like I said before, my RAP can connect to the controllers if I use the external IP of the controller (just not vrrp).  IP route shows I'm directly connected to my external subnet and has a default route, as well as, default gateway.

I'm kind of stumped.  Looking for additional things to look for.  By all accounts, this pair should be working by way of vrrp.  I even went as far as making sure the vrrp address isn't outside of the subnet range.  

Code Im running is 8.7.1.2  

Anyone have any ideas on what I could check next?

Many thanks

I think there might be some confusion here and or I forgot to include some important info:  I have my cluster setup here as I've posted.
My Vrrp is actually setup per node as a layer 2 redundancy.  

Node A:
vrrp id 201
vlan xyz
ip address 123.x.y.z
priority 110
prempt enable with 0 delay


Node B:
vrrp ID 201
vlan xyz
ip address 123.x.y.z
priority 100


Does this change your thought process at all?  As I said in my first post - My VRRP show as Master and Standby.  Traffic just won't connect to the vrrp; except traffic will connect to my external controller IP addresses.

Original Message:
Sent: Jan 24, 2022 10:16 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

Right, and the VRRP address will not work.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 24, 2022 08:59 AM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Thank DB...but I do have it mapped that way.

within the cluster I have

+ IP address |  no group id |  no vrrp ip  |  no vrrp vlan  |  + RAP PUBLIC IP  |  no Mcast-Vlan


As I said, things are working, except for any connections coming to the vrrp address.
Original Message:
Sent: Jan 22, 2022 10:28 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

In the cluster profile you will want the RAPs connecting to the addresses you have defined in the "RAP Public IP" field. I don't believe terminating it to the VRRP address will work for you. The APs will receive an internal address to connect to after contacting the controller, which obviously wont work coming from outside. Every time I have deployed this, or read about it its is always the Pub IP of one of the controllers in each cluster. Two clusters, one for LMS one for B-LMS. Clustering will take care of building a redundant node list on the AP for cluster failover.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 21, 2022 04:10 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hello All.  Looking for some helpful info on this one.  I have a strange case where I have 2 pairs of clustered controllers, acting as the headend for RAPs.  As for the configs, as much as I can tell, everything is working just fine.  Pair 1's configs are setup virtually identically to the way my Pair 2 is setup (obviously IPs, vrrp id, etc are different).

The basic layout of the inside network is:  Firewall a/b - Switch a/b - Controller a/b.  A side is connected to A side, B side to B side.

The firewall(s) has(haave) an ACL allowing udp/4500 in and the controller(s) it/they sits in front of, is all layer 3.

If I point a RAP to the external IP of A, it connects.  If I point the rap to the "B" side external IP, it connects.  If I connect the RAP to the VRRP address, running "Master/Backup" between the 2 RAP controllers, it sits and spins.

On the controller side doing a show lc-cluster group-membership/vlan probe, it shows l2 (woo hoo) with it's leader and member; vlan probe shows L2 with 0 fails.  I have checked that the cluster is config'd so it shows that it's internal (controller-ip) and external ip is mapped correctly.

controller A and controller B can source ping it's external default gateway - which is an HSRP address on the uplink switch. Because of the security policy I have on the externa; interface of the controllers, I can't ping from the uplink switch to the controllers (although I guess I could remove it to see).

On my external interfaces of my controllers, I do have a session security policy created, to allow the vrrp multicast address between them, ltp2 allowed, and everything else denied.  This same policy I have applied in over 20 controllers globally, so I know it's not the policy (just adding for reference).

My routing is fine (from what I can tell) - I can reach these controllers from internal sources, and like I said before, my RAP can connect to the controllers if I use the external IP of the controller (just not vrrp).  IP route shows I'm directly connected to my external subnet and has a default route, as well as, default gateway.

I'm kind of stumped.  Looking for additional things to look for.  By all accounts, this pair should be working by way of vrrp.  I even went as far as making sure the vrrp address isn't outside of the subnet range.  

Code Im running is 8.7.1.2  

Anyone have any ideas on what I could check next?

Many thanks

You will want to point your RAPs to the External Addresses for the Cluster members (Node A External and Node B External) not to the VRRP address you have created between the two. Once the RAP joins the controller, the cluster will share out the node list that it will use (The RAP public IPs that are configured in your cluster profile)

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos
------------------------------

Original Message:
Sent: Jan 24, 2022 02:08 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

I think there might be some confusion here and or I forgot to include some important info:  I have my cluster setup here as I've posted.
My Vrrp is actually setup per node as a layer 2 redundancy.  

Node A:
vrrp id 201
vlan xyz
ip address 123.x.y.z
priority 110
prempt enable with 0 delay


Node B:
vrrp ID 201
vlan xyz
ip address 123.x.y.z
priority 100


Does this change your thought process at all?  As I said in my first post - My VRRP show as Master and Standby.  Traffic just won't connect to the vrrp; except traffic will connect to my external controller IP addresses.

Original Message:
Sent: Jan 24, 2022 10:16 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

Right, and the VRRP address will not work.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 24, 2022 08:59 AM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Thank DB...but I do have it mapped that way.

within the cluster I have

+ IP address |  no group id |  no vrrp ip  |  no vrrp vlan  |  + RAP PUBLIC IP  |  no Mcast-Vlan


As I said, things are working, except for any connections coming to the vrrp address.
Original Message:
Sent: Jan 22, 2022 10:28 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

In the cluster profile you will want the RAPs connecting to the addresses you have defined in the "RAP Public IP" field. I don't believe terminating it to the VRRP address will work for you. The APs will receive an internal address to connect to after contacting the controller, which obviously wont work coming from outside. Every time I have deployed this, or read about it its is always the Pub IP of one of the controllers in each cluster. Two clusters, one for LMS one for B-LMS. Clustering will take care of building a redundant node list on the AP for cluster failover.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 21, 2022 04:10 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hello All.  Looking for some helpful info on this one.  I have a strange case where I have 2 pairs of clustered controllers, acting as the headend for RAPs.  As for the configs, as much as I can tell, everything is working just fine.  Pair 1's configs are setup virtually identically to the way my Pair 2 is setup (obviously IPs, vrrp id, etc are different).

The basic layout of the inside network is:  Firewall a/b - Switch a/b - Controller a/b.  A side is connected to A side, B side to B side.

The firewall(s) has(haave) an ACL allowing udp/4500 in and the controller(s) it/they sits in front of, is all layer 3.

If I point a RAP to the external IP of A, it connects.  If I point the rap to the "B" side external IP, it connects.  If I connect the RAP to the VRRP address, running "Master/Backup" between the 2 RAP controllers, it sits and spins.

On the controller side doing a show lc-cluster group-membership/vlan probe, it shows l2 (woo hoo) with it's leader and member; vlan probe shows L2 with 0 fails.  I have checked that the cluster is config'd so it shows that it's internal (controller-ip) and external ip is mapped correctly.

controller A and controller B can source ping it's external default gateway - which is an HSRP address on the uplink switch. Because of the security policy I have on the externa; interface of the controllers, I can't ping from the uplink switch to the controllers (although I guess I could remove it to see).

On my external interfaces of my controllers, I do have a session security policy created, to allow the vrrp multicast address between them, ltp2 allowed, and everything else denied.  This same policy I have applied in over 20 controllers globally, so I know it's not the policy (just adding for reference).

My routing is fine (from what I can tell) - I can reach these controllers from internal sources, and like I said before, my RAP can connect to the controllers if I use the external IP of the controller (just not vrrp).  IP route shows I'm directly connected to my external subnet and has a default route, as well as, default gateway.

I'm kind of stumped.  Looking for additional things to look for.  By all accounts, this pair should be working by way of vrrp.  I even went as far as making sure the vrrp address isn't outside of the subnet range.  

Code Im running is 8.7.1.2  

Anyone have any ideas on what I could check next?

Many thanks

Hey Dustin:  what Im about to say - the tone could come off hostile/defensive....but believe me -- it is not in anyway. 

With that -- Why can I not use the vrrp address as my anchor IP?  I have seen Aruba documentation supporting this and even TAC recommending this. Even my Regional Account manager has shared this as being an option. As long as your ports are open and the VRRP is vrrp'ing and you Multicast address of 224.0.0.18 isn't being blocked to allow your nodes to participate - it should work fine.

Case in point:  I have 14 pairs of controllers running this config across the globe.  All but 1 pair are working fine.  Plus for redundancy during an upgrade or failover, I'm not relying on a hard coded IP, I can use something similar to a floating IP to spread its resilience.  In this example, I am merely looking for a reason why my network accessibility is there for everything but a RAP being able to communicate to the vrrp address, chokes.  I was hoping to hear of -- it's a bug or have you checked your routes or is it possible the acl is blocking anything?  Perhaps a security policy or acl on your external ip - just something maybe I was overlooking.

On the other hand, if you have something that supports why I shouldn't use a vrrp -- please.  I'm down to review and familiarize myself.  

cordially,

G3
Original Message:
Sent: Jan 24, 2022 02:17 PM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

You will want to point your RAPs to the External Addresses for the Cluster members (Node A External and Node B External) not to the VRRP address you have created between the two. Once the RAP joins the controller, the cluster will share out the node list that it will use (The RAP public IPs that are configured in your cluster profile)

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 24, 2022 02:08 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

I think there might be some confusion here and or I forgot to include some important info:  I have my cluster setup here as I've posted.
My Vrrp is actually setup per node as a layer 2 redundancy.  

Node A:
vrrp id 201
vlan xyz
ip address 123.x.y.z
priority 110
prempt enable with 0 delay


Node B:
vrrp ID 201
vlan xyz
ip address 123.x.y.z
priority 100


Does this change your thought process at all?  As I said in my first post - My VRRP show as Master and Standby.  Traffic just won't connect to the vrrp; except traffic will connect to my external controller IP addresses.

Original Message:
Sent: Jan 24, 2022 10:16 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

Right, and the VRRP address will not work.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 24, 2022 08:59 AM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Thank DB...but I do have it mapped that way.

within the cluster I have

+ IP address |  no group id |  no vrrp ip  |  no vrrp vlan  |  + RAP PUBLIC IP  |  no Mcast-Vlan


As I said, things are working, except for any connections coming to the vrrp address.
Original Message:
Sent: Jan 22, 2022 10:28 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

In the cluster profile you will want the RAPs connecting to the addresses you have defined in the "RAP Public IP" field. I don't believe terminating it to the VRRP address will work for you. The APs will receive an internal address to connect to after contacting the controller, which obviously wont work coming from outside. Every time I have deployed this, or read about it its is always the Pub IP of one of the controllers in each cluster. Two clusters, one for LMS one for B-LMS. Clustering will take care of building a redundant node list on the AP for cluster failover.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 21, 2022 04:10 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hello All.  Looking for some helpful info on this one.  I have a strange case where I have 2 pairs of clustered controllers, acting as the headend for RAPs.  As for the configs, as much as I can tell, everything is working just fine.  Pair 1's configs are setup virtually identically to the way my Pair 2 is setup (obviously IPs, vrrp id, etc are different).

The basic layout of the inside network is:  Firewall a/b - Switch a/b - Controller a/b.  A side is connected to A side, B side to B side.

The firewall(s) has(haave) an ACL allowing udp/4500 in and the controller(s) it/they sits in front of, is all layer 3.

If I point a RAP to the external IP of A, it connects.  If I point the rap to the "B" side external IP, it connects.  If I connect the RAP to the VRRP address, running "Master/Backup" between the 2 RAP controllers, it sits and spins.

On the controller side doing a show lc-cluster group-membership/vlan probe, it shows l2 (woo hoo) with it's leader and member; vlan probe shows L2 with 0 fails.  I have checked that the cluster is config'd so it shows that it's internal (controller-ip) and external ip is mapped correctly.

controller A and controller B can source ping it's external default gateway - which is an HSRP address on the uplink switch. Because of the security policy I have on the externa; interface of the controllers, I can't ping from the uplink switch to the controllers (although I guess I could remove it to see).

On my external interfaces of my controllers, I do have a session security policy created, to allow the vrrp multicast address between them, ltp2 allowed, and everything else denied.  This same policy I have applied in over 20 controllers globally, so I know it's not the policy (just adding for reference).

My routing is fine (from what I can tell) - I can reach these controllers from internal sources, and like I said before, my RAP can connect to the controllers if I use the external IP of the controller (just not vrrp).  IP route shows I'm directly connected to my external subnet and has a default route, as well as, default gateway.

I'm kind of stumped.  Looking for additional things to look for.  By all accounts, this pair should be working by way of vrrp.  I even went as far as making sure the vrrp address isn't outside of the subnet range.  

Code Im running is 8.7.1.2  

Anyone have any ideas on what I could check next?

Many thanks

Please refer to this guide: https://www.arubanetworks.com/assets/so/SG_Remote-Access-Point.pdf

This can be found on Page 14: The RAP master cannot be a VRRP address. It can only be one of the cluster members controller-IPs, or a roundrobin DNS name that resolves to any of those same controller-IPs.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos
------------------------------

Original Message:
Sent: Jan 25, 2022 12:17 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hey Dustin:  what Im about to say - the tone could come off hostile/defensive....but believe me -- it is not in anyway. 

With that -- Why can I not use the vrrp address as my anchor IP?  I have seen Aruba documentation supporting this and even TAC recommending this. Even my Regional Account manager has shared this as being an option. As long as your ports are open and the VRRP is vrrp'ing and you Multicast address of 224.0.0.18 isn't being blocked to allow your nodes to participate - it should work fine.

Case in point:  I have 14 pairs of controllers running this config across the globe.  All but 1 pair are working fine.  Plus for redundancy during an upgrade or failover, I'm not relying on a hard coded IP, I can use something similar to a floating IP to spread its resilience.  In this example, I am merely looking for a reason why my network accessibility is there for everything but a RAP being able to communicate to the vrrp address, chokes.  I was hoping to hear of -- it's a bug or have you checked your routes or is it possible the acl is blocking anything?  Perhaps a security policy or acl on your external ip - just something maybe I was overlooking.

On the other hand, if you have something that supports why I shouldn't use a vrrp -- please.  I'm down to review and familiarize myself.  

cordially,

G3
Original Message:
Sent: Jan 24, 2022 02:17 PM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

You will want to point your RAPs to the External Addresses for the Cluster members (Node A External and Node B External) not to the VRRP address you have created between the two. Once the RAP joins the controller, the cluster will share out the node list that it will use (The RAP public IPs that are configured in your cluster profile)

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 24, 2022 02:08 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

I think there might be some confusion here and or I forgot to include some important info:  I have my cluster setup here as I've posted.
My Vrrp is actually setup per node as a layer 2 redundancy.  

Node A:
vrrp id 201
vlan xyz
ip address 123.x.y.z
priority 110
prempt enable with 0 delay


Node B:
vrrp ID 201
vlan xyz
ip address 123.x.y.z
priority 100


Does this change your thought process at all?  As I said in my first post - My VRRP show as Master and Standby.  Traffic just won't connect to the vrrp; except traffic will connect to my external controller IP addresses.

Original Message:
Sent: Jan 24, 2022 10:16 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

Right, and the VRRP address will not work.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 24, 2022 08:59 AM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Thank DB...but I do have it mapped that way.

within the cluster I have

+ IP address |  no group id |  no vrrp ip  |  no vrrp vlan  |  + RAP PUBLIC IP  |  no Mcast-Vlan


As I said, things are working, except for any connections coming to the vrrp address.
Original Message:
Sent: Jan 22, 2022 10:28 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

In the cluster profile you will want the RAPs connecting to the addresses you have defined in the "RAP Public IP" field. I don't believe terminating it to the VRRP address will work for you. The APs will receive an internal address to connect to after contacting the controller, which obviously wont work coming from outside. Every time I have deployed this, or read about it its is always the Pub IP of one of the controllers in each cluster. Two clusters, one for LMS one for B-LMS. Clustering will take care of building a redundant node list on the AP for cluster failover.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 21, 2022 04:10 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hello All.  Looking for some helpful info on this one.  I have a strange case where I have 2 pairs of clustered controllers, acting as the headend for RAPs.  As for the configs, as much as I can tell, everything is working just fine.  Pair 1's configs are setup virtually identically to the way my Pair 2 is setup (obviously IPs, vrrp id, etc are different).

The basic layout of the inside network is:  Firewall a/b - Switch a/b - Controller a/b.  A side is connected to A side, B side to B side.

The firewall(s) has(haave) an ACL allowing udp/4500 in and the controller(s) it/they sits in front of, is all layer 3.

If I point a RAP to the external IP of A, it connects.  If I point the rap to the "B" side external IP, it connects.  If I connect the RAP to the VRRP address, running "Master/Backup" between the 2 RAP controllers, it sits and spins.

On the controller side doing a show lc-cluster group-membership/vlan probe, it shows l2 (woo hoo) with it's leader and member; vlan probe shows L2 with 0 fails.  I have checked that the cluster is config'd so it shows that it's internal (controller-ip) and external ip is mapped correctly.

controller A and controller B can source ping it's external default gateway - which is an HSRP address on the uplink switch. Because of the security policy I have on the externa; interface of the controllers, I can't ping from the uplink switch to the controllers (although I guess I could remove it to see).

On my external interfaces of my controllers, I do have a session security policy created, to allow the vrrp multicast address between them, ltp2 allowed, and everything else denied.  This same policy I have applied in over 20 controllers globally, so I know it's not the policy (just adding for reference).

My routing is fine (from what I can tell) - I can reach these controllers from internal sources, and like I said before, my RAP can connect to the controllers if I use the external IP of the controller (just not vrrp).  IP route shows I'm directly connected to my external subnet and has a default route, as well as, default gateway.

I'm kind of stumped.  Looking for additional things to look for.  By all accounts, this pair should be working by way of vrrp.  I even went as far as making sure the vrrp address isn't outside of the subnet range.  

Code Im running is 8.7.1.2  

Anyone have any ideas on what I could check next?

Many thanks

Thank you for the share.  I'll have to confirm that.  I see what you're saying, but when it refers to the "RAP Master", I question the reference and if it's referring to the MM in this case.  The way it was explained to me; whether its a new RAP out the box, factory reset where it phones home and comes from Activate, or the split situation when you're doing an upgrade, you can use the VRRP address to establish the initial link.  Once the RAP hits the vrrp, it gets pulled to the Active Leader and then maps to the External/Internal IP address, where it's then managed by the cluster.  In the logs, you'll even see the request go from VRRP to the assigned controller IP.

Regardless, I appreciate the assist in this and the info share.  I highly encourage you try this, whether its hardware or VM.  You may find this explanation is not 100% accurate. 

Also as an update to all of these posts:  I did remove the vrrp  config via the web gui and tried re-adding it.  I was met with an error of  InValid VRRP VLAN-ID...which is weird since it was added as L2 at the "site" level above the nodes...and the nodes recognized this vlan as layer 2.  After re-pushing the L2 config and re-adding the vrrp config via CLI, my vrrp started working and I was able to terminate RAPs to it.

Sounds like some invalid cached info on the initial install?  Not sure, but things appear to working.

Again, appreciate the info Dustin.  Personally - I highly recommend you try testing it in a lab or at home if you have that option.  

Original Message:
Sent: Jan 25, 2022 12:25 PM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

Please refer to this guide: https://www.arubanetworks.com/assets/so/SG_Remote-Access-Point.pdf

This can be found on Page 14: The RAP master cannot be a VRRP address. It can only be one of the cluster members controller-IPs, or a roundrobin DNS name that resolves to any of those same controller-IPs.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 25, 2022 12:17 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hey Dustin:  what Im about to say - the tone could come off hostile/defensive....but believe me -- it is not in anyway. 

With that -- Why can I not use the vrrp address as my anchor IP?  I have seen Aruba documentation supporting this and even TAC recommending this. Even my Regional Account manager has shared this as being an option. As long as your ports are open and the VRRP is vrrp'ing and you Multicast address of 224.0.0.18 isn't being blocked to allow your nodes to participate - it should work fine.

Case in point:  I have 14 pairs of controllers running this config across the globe.  All but 1 pair are working fine.  Plus for redundancy during an upgrade or failover, I'm not relying on a hard coded IP, I can use something similar to a floating IP to spread its resilience.  In this example, I am merely looking for a reason why my network accessibility is there for everything but a RAP being able to communicate to the vrrp address, chokes.  I was hoping to hear of -- it's a bug or have you checked your routes or is it possible the acl is blocking anything?  Perhaps a security policy or acl on your external ip - just something maybe I was overlooking.

On the other hand, if you have something that supports why I shouldn't use a vrrp -- please.  I'm down to review and familiarize myself.  

cordially,

G3
Original Message:
Sent: Jan 24, 2022 02:17 PM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

You will want to point your RAPs to the External Addresses for the Cluster members (Node A External and Node B External) not to the VRRP address you have created between the two. Once the RAP joins the controller, the cluster will share out the node list that it will use (The RAP public IPs that are configured in your cluster profile)

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 24, 2022 02:08 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

I think there might be some confusion here and or I forgot to include some important info:  I have my cluster setup here as I've posted.
My Vrrp is actually setup per node as a layer 2 redundancy.  

Node A:
vrrp id 201
vlan xyz
ip address 123.x.y.z
priority 110
prempt enable with 0 delay


Node B:
vrrp ID 201
vlan xyz
ip address 123.x.y.z
priority 100


Does this change your thought process at all?  As I said in my first post - My VRRP show as Master and Standby.  Traffic just won't connect to the vrrp; except traffic will connect to my external controller IP addresses.

Original Message:
Sent: Jan 24, 2022 10:16 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

Right, and the VRRP address will not work.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 24, 2022 08:59 AM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Thank DB...but I do have it mapped that way.

within the cluster I have

+ IP address |  no group id |  no vrrp ip  |  no vrrp vlan  |  + RAP PUBLIC IP  |  no Mcast-Vlan


As I said, things are working, except for any connections coming to the vrrp address.
Original Message:
Sent: Jan 22, 2022 10:28 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

In the cluster profile you will want the RAPs connecting to the addresses you have defined in the "RAP Public IP" field. I don't believe terminating it to the VRRP address will work for you. The APs will receive an internal address to connect to after contacting the controller, which obviously wont work coming from outside. Every time I have deployed this, or read about it its is always the Pub IP of one of the controllers in each cluster. Two clusters, one for LMS one for B-LMS. Clustering will take care of building a redundant node list on the AP for cluster failover.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 21, 2022 04:10 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hello All.  Looking for some helpful info on this one.  I have a strange case where I have 2 pairs of clustered controllers, acting as the headend for RAPs.  As for the configs, as much as I can tell, everything is working just fine.  Pair 1's configs are setup virtually identically to the way my Pair 2 is setup (obviously IPs, vrrp id, etc are different).

The basic layout of the inside network is:  Firewall a/b - Switch a/b - Controller a/b.  A side is connected to A side, B side to B side.

The firewall(s) has(haave) an ACL allowing udp/4500 in and the controller(s) it/they sits in front of, is all layer 3.

If I point a RAP to the external IP of A, it connects.  If I point the rap to the "B" side external IP, it connects.  If I connect the RAP to the VRRP address, running "Master/Backup" between the 2 RAP controllers, it sits and spins.

On the controller side doing a show lc-cluster group-membership/vlan probe, it shows l2 (woo hoo) with it's leader and member; vlan probe shows L2 with 0 fails.  I have checked that the cluster is config'd so it shows that it's internal (controller-ip) and external ip is mapped correctly.

controller A and controller B can source ping it's external default gateway - which is an HSRP address on the uplink switch. Because of the security policy I have on the externa; interface of the controllers, I can't ping from the uplink switch to the controllers (although I guess I could remove it to see).

On my external interfaces of my controllers, I do have a session security policy created, to allow the vrrp multicast address between them, ltp2 allowed, and everything else denied.  This same policy I have applied in over 20 controllers globally, so I know it's not the policy (just adding for reference).

My routing is fine (from what I can tell) - I can reach these controllers from internal sources, and like I said before, my RAP can connect to the controllers if I use the external IP of the controller (just not vrrp).  IP route shows I'm directly connected to my external subnet and has a default route, as well as, default gateway.

I'm kind of stumped.  Looking for additional things to look for.  By all accounts, this pair should be working by way of vrrp.  I even went as far as making sure the vrrp address isn't outside of the subnet range.  

Code Im running is 8.7.1.2  

Anyone have any ideas on what I could check next?

Many thanks

When it says RAP Master, it is referring to the primary or LMS Controller. You would have another controller set to secondary or B-LMS.

The note may be a recommendation or supported configuration if it works even if Aruba says not to. There may be some corner cases where using VRRP might cause issues. From what I remember from digging into it in the past, your failovers may not work to well. I would test a failover. 


------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos
------------------------------

Original Message:
Sent: Jan 25, 2022 01:37 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Thank you for the share.  I'll have to confirm that.  I see what you're saying, but when it refers to the "RAP Master", I question the reference and if it's referring to the MM in this case.  The way it was explained to me; whether its a new RAP out the box, factory reset where it phones home and comes from Activate, or the split situation when you're doing an upgrade, you can use the VRRP address to establish the initial link.  Once the RAP hits the vrrp, it gets pulled to the Active Leader and then maps to the External/Internal IP address, where it's then managed by the cluster.  In the logs, you'll even see the request go from VRRP to the assigned controller IP.

Regardless, I appreciate the assist in this and the info share.  I highly encourage you try this, whether its hardware or VM.  You may find this explanation is not 100% accurate. 

Also as an update to all of these posts:  I did remove the vrrp  config via the web gui and tried re-adding it.  I was met with an error of  InValid VRRP VLAN-ID...which is weird since it was added as L2 at the "site" level above the nodes...and the nodes recognized this vlan as layer 2.  After re-pushing the L2 config and re-adding the vrrp config via CLI, my vrrp started working and I was able to terminate RAPs to it.

Sounds like some invalid cached info on the initial install?  Not sure, but things appear to working.

Again, appreciate the info Dustin.  Personally - I highly recommend you try testing it in a lab or at home if you have that option.  

Original Message:
Sent: Jan 25, 2022 12:25 PM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

Please refer to this guide: https://www.arubanetworks.com/assets/so/SG_Remote-Access-Point.pdf

This can be found on Page 14: The RAP master cannot be a VRRP address. It can only be one of the cluster members controller-IPs, or a roundrobin DNS name that resolves to any of those same controller-IPs.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 25, 2022 12:17 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hey Dustin:  what Im about to say - the tone could come off hostile/defensive....but believe me -- it is not in anyway. 

With that -- Why can I not use the vrrp address as my anchor IP?  I have seen Aruba documentation supporting this and even TAC recommending this. Even my Regional Account manager has shared this as being an option. As long as your ports are open and the VRRP is vrrp'ing and you Multicast address of 224.0.0.18 isn't being blocked to allow your nodes to participate - it should work fine.

Case in point:  I have 14 pairs of controllers running this config across the globe.  All but 1 pair are working fine.  Plus for redundancy during an upgrade or failover, I'm not relying on a hard coded IP, I can use something similar to a floating IP to spread its resilience.  In this example, I am merely looking for a reason why my network accessibility is there for everything but a RAP being able to communicate to the vrrp address, chokes.  I was hoping to hear of -- it's a bug or have you checked your routes or is it possible the acl is blocking anything?  Perhaps a security policy or acl on your external ip - just something maybe I was overlooking.

On the other hand, if you have something that supports why I shouldn't use a vrrp -- please.  I'm down to review and familiarize myself.  

cordially,

G3
Original Message:
Sent: Jan 24, 2022 02:17 PM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

You will want to point your RAPs to the External Addresses for the Cluster members (Node A External and Node B External) not to the VRRP address you have created between the two. Once the RAP joins the controller, the cluster will share out the node list that it will use (The RAP public IPs that are configured in your cluster profile)

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 24, 2022 02:08 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

I think there might be some confusion here and or I forgot to include some important info:  I have my cluster setup here as I've posted.
My Vrrp is actually setup per node as a layer 2 redundancy.  

Node A:
vrrp id 201
vlan xyz
ip address 123.x.y.z
priority 110
prempt enable with 0 delay


Node B:
vrrp ID 201
vlan xyz
ip address 123.x.y.z
priority 100


Does this change your thought process at all?  As I said in my first post - My VRRP show as Master and Standby.  Traffic just won't connect to the vrrp; except traffic will connect to my external controller IP addresses.

Original Message:
Sent: Jan 24, 2022 10:16 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

Right, and the VRRP address will not work.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 24, 2022 08:59 AM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Thank DB...but I do have it mapped that way.

within the cluster I have

+ IP address |  no group id |  no vrrp ip  |  no vrrp vlan  |  + RAP PUBLIC IP  |  no Mcast-Vlan


As I said, things are working, except for any connections coming to the vrrp address.
Original Message:
Sent: Jan 22, 2022 10:28 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

In the cluster profile you will want the RAPs connecting to the addresses you have defined in the "RAP Public IP" field. I don't believe terminating it to the VRRP address will work for you. The APs will receive an internal address to connect to after contacting the controller, which obviously wont work coming from outside. Every time I have deployed this, or read about it its is always the Pub IP of one of the controllers in each cluster. Two clusters, one for LMS one for B-LMS. Clustering will take care of building a redundant node list on the AP for cluster failover.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 21, 2022 04:10 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hello All.  Looking for some helpful info on this one.  I have a strange case where I have 2 pairs of clustered controllers, acting as the headend for RAPs.  As for the configs, as much as I can tell, everything is working just fine.  Pair 1's configs are setup virtually identically to the way my Pair 2 is setup (obviously IPs, vrrp id, etc are different).

The basic layout of the inside network is:  Firewall a/b - Switch a/b - Controller a/b.  A side is connected to A side, B side to B side.

The firewall(s) has(haave) an ACL allowing udp/4500 in and the controller(s) it/they sits in front of, is all layer 3.

If I point a RAP to the external IP of A, it connects.  If I point the rap to the "B" side external IP, it connects.  If I connect the RAP to the VRRP address, running "Master/Backup" between the 2 RAP controllers, it sits and spins.

On the controller side doing a show lc-cluster group-membership/vlan probe, it shows l2 (woo hoo) with it's leader and member; vlan probe shows L2 with 0 fails.  I have checked that the cluster is config'd so it shows that it's internal (controller-ip) and external ip is mapped correctly.

controller A and controller B can source ping it's external default gateway - which is an HSRP address on the uplink switch. Because of the security policy I have on the externa; interface of the controllers, I can't ping from the uplink switch to the controllers (although I guess I could remove it to see).

On my external interfaces of my controllers, I do have a session security policy created, to allow the vrrp multicast address between them, ltp2 allowed, and everything else denied.  This same policy I have applied in over 20 controllers globally, so I know it's not the policy (just adding for reference).

My routing is fine (from what I can tell) - I can reach these controllers from internal sources, and like I said before, my RAP can connect to the controllers if I use the external IP of the controller (just not vrrp).  IP route shows I'm directly connected to my external subnet and has a default route, as well as, default gateway.

I'm kind of stumped.  Looking for additional things to look for.  By all accounts, this pair should be working by way of vrrp.  I even went as far as making sure the vrrp address isn't outside of the subnet range.  

Code Im running is 8.7.1.2  

Anyone have any ideas on what I could check next?

Many thanks

I don't know why, but after the month or 2 of time it's been, something prompted me to look back in these discussions for any unresolved business?  To this discussion -- after all was said and talked about, what fixed the issue was a controller reboot.  Everything I mentioned before for a configuration, still stands.  A reboot fixed this issue and since then I have tested failover - works as expected.

I hate to say it, but when all else fails, try the reboot to see if this does the trick.  On to my next chapter (testing 8.9 and 6e).
Original Message:
Sent: Jan 25, 2022 08:50 PM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

When it says RAP Master, it is referring to the primary or LMS Controller. You would have another controller set to secondary or B-LMS.

The note may be a recommendation or supported configuration if it works even if Aruba says not to. There may be some corner cases where using VRRP might cause issues. From what I remember from digging into it in the past, your failovers may not work to well. I would test a failover. 


------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 25, 2022 01:37 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Thank you for the share.  I'll have to confirm that.  I see what you're saying, but when it refers to the "RAP Master", I question the reference and if it's referring to the MM in this case.  The way it was explained to me; whether its a new RAP out the box, factory reset where it phones home and comes from Activate, or the split situation when you're doing an upgrade, you can use the VRRP address to establish the initial link.  Once the RAP hits the vrrp, it gets pulled to the Active Leader and then maps to the External/Internal IP address, where it's then managed by the cluster.  In the logs, you'll even see the request go from VRRP to the assigned controller IP.

Regardless, I appreciate the assist in this and the info share.  I highly encourage you try this, whether its hardware or VM.  You may find this explanation is not 100% accurate. 

Also as an update to all of these posts:  I did remove the vrrp  config via the web gui and tried re-adding it.  I was met with an error of  InValid VRRP VLAN-ID...which is weird since it was added as L2 at the "site" level above the nodes...and the nodes recognized this vlan as layer 2.  After re-pushing the L2 config and re-adding the vrrp config via CLI, my vrrp started working and I was able to terminate RAPs to it.

Sounds like some invalid cached info on the initial install?  Not sure, but things appear to working.

Again, appreciate the info Dustin.  Personally - I highly recommend you try testing it in a lab or at home if you have that option.  

Original Message:
Sent: Jan 25, 2022 12:25 PM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

Please refer to this guide: https://www.arubanetworks.com/assets/so/SG_Remote-Access-Point.pdf

This can be found on Page 14: The RAP master cannot be a VRRP address. It can only be one of the cluster members controller-IPs, or a roundrobin DNS name that resolves to any of those same controller-IPs.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 25, 2022 12:17 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hey Dustin:  what Im about to say - the tone could come off hostile/defensive....but believe me -- it is not in anyway. 

With that -- Why can I not use the vrrp address as my anchor IP?  I have seen Aruba documentation supporting this and even TAC recommending this. Even my Regional Account manager has shared this as being an option. As long as your ports are open and the VRRP is vrrp'ing and you Multicast address of 224.0.0.18 isn't being blocked to allow your nodes to participate - it should work fine.

Case in point:  I have 14 pairs of controllers running this config across the globe.  All but 1 pair are working fine.  Plus for redundancy during an upgrade or failover, I'm not relying on a hard coded IP, I can use something similar to a floating IP to spread its resilience.  In this example, I am merely looking for a reason why my network accessibility is there for everything but a RAP being able to communicate to the vrrp address, chokes.  I was hoping to hear of -- it's a bug or have you checked your routes or is it possible the acl is blocking anything?  Perhaps a security policy or acl on your external ip - just something maybe I was overlooking.

On the other hand, if you have something that supports why I shouldn't use a vrrp -- please.  I'm down to review and familiarize myself.  

cordially,

G3
Original Message:
Sent: Jan 24, 2022 02:17 PM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

You will want to point your RAPs to the External Addresses for the Cluster members (Node A External and Node B External) not to the VRRP address you have created between the two. Once the RAP joins the controller, the cluster will share out the node list that it will use (The RAP public IPs that are configured in your cluster profile)

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 24, 2022 02:08 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

I think there might be some confusion here and or I forgot to include some important info:  I have my cluster setup here as I've posted.
My Vrrp is actually setup per node as a layer 2 redundancy.  

Node A:
vrrp id 201
vlan xyz
ip address 123.x.y.z
priority 110
prempt enable with 0 delay


Node B:
vrrp ID 201
vlan xyz
ip address 123.x.y.z
priority 100


Does this change your thought process at all?  As I said in my first post - My VRRP show as Master and Standby.  Traffic just won't connect to the vrrp; except traffic will connect to my external controller IP addresses.

Original Message:
Sent: Jan 24, 2022 10:16 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

Right, and the VRRP address will not work.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 24, 2022 08:59 AM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Thank DB...but I do have it mapped that way.

within the cluster I have

+ IP address |  no group id |  no vrrp ip  |  no vrrp vlan  |  + RAP PUBLIC IP  |  no Mcast-Vlan


As I said, things are working, except for any connections coming to the vrrp address.
Original Message:
Sent: Jan 22, 2022 10:28 AM
From: Dustin Burns
Subject: RAPs-Vrrp Connectivity

In the cluster profile you will want the RAPs connecting to the addresses you have defined in the "RAP Public IP" field. I don't believe terminating it to the VRRP address will work for you. The APs will receive an internal address to connect to after contacting the controller, which obviously wont work coming from outside. Every time I have deployed this, or read about it its is always the Pub IP of one of the controllers in each cluster. Two clusters, one for LMS one for B-LMS. Clustering will take care of building a redundant node list on the AP for cluster failover.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jan 21, 2022 04:10 PM
From: Neal Tarbox
Subject: RAPs-Vrrp Connectivity

Hello All.  Looking for some helpful info on this one.  I have a strange case where I have 2 pairs of clustered controllers, acting as the headend for RAPs.  As for the configs, as much as I can tell, everything is working just fine.  Pair 1's configs are setup virtually identically to the way my Pair 2 is setup (obviously IPs, vrrp id, etc are different).

The basic layout of the inside network is:  Firewall a/b - Switch a/b - Controller a/b.  A side is connected to A side, B side to B side.

The firewall(s) has(haave) an ACL allowing udp/4500 in and the controller(s) it/they sits in front of, is all layer 3.

If I point a RAP to the external IP of A, it connects.  If I point the rap to the "B" side external IP, it connects.  If I connect the RAP to the VRRP address, running "Master/Backup" between the 2 RAP controllers, it sits and spins.

On the controller side doing a show lc-cluster group-membership/vlan probe, it shows l2 (woo hoo) with it's leader and member; vlan probe shows L2 with 0 fails.  I have checked that the cluster is config'd so it shows that it's internal (controller-ip) and external ip is mapped correctly.

controller A and controller B can source ping it's external default gateway - which is an HSRP address on the uplink switch. Because of the security policy I have on the externa; interface of the controllers, I can't ping from the uplink switch to the controllers (although I guess I could remove it to see).

On my external interfaces of my controllers, I do have a session security policy created, to allow the vrrp multicast address between them, ltp2 allowed, and everything else denied.  This same policy I have applied in over 20 controllers globally, so I know it's not the policy (just adding for reference).

My routing is fine (from what I can tell) - I can reach these controllers from internal sources, and like I said before, my RAP can connect to the controllers if I use the external IP of the controller (just not vrrp).  IP route shows I'm directly connected to my external subnet and has a default route, as well as, default gateway.

I'm kind of stumped.  Looking for additional things to look for.  By all accounts, this pair should be working by way of vrrp.  I even went as far as making sure the vrrp address isn't outside of the subnet range.  

Code Im running is 8.7.1.2  

Anyone have any ideas on what I could check next?

Many thanks