Wireless Access

Dear all,

We have 2 Aruba 650 controllers. They are on seperate locations in the country, on seperated VLANs. There's a 50Mbit L3 connection between these 2 locations.

What we would like to achieve:

-tell our RAP 2WG's which controller should be the primary controller. For people working in location A, we would like their RAPs to connect to the controller in location A and for people working in location B, we would like their raps to connect to the controller in location B, of course :)

-if either controller A or controller B is not available, we would like the RAP to automatically connect to the other controller. This also has to work when RAPs are switched on while either controller is not available.

How would we go about this?

Right now, the controllers are both set up as a master. I added the RAP-macs to the white-list on controller A and B. On controller A, the AP group that contains the RAP2WG has the AP System Profile set so that the LMS IP is set to controller A and the LMS Backup to controller B. The other controller of course, is set the other way around. However, when controller A goes down, the connected RAP does not switch to controller B, it just keeps on rebooting and trying to connect to controller A it seems.

Info that might matter: the initial connection from the RAP to controller A is made by manually entering controller A IP in the web-interface of the RAP 2WG. When I reset the RAP 2WG and enter the IP of controller B, it connects to controller B just fine. But it doesn't seem to 'listen' to the LMS settings.

I guess I'm doing something wrong, I hope someone can tell me what I'm missing :)

Hi,

Good afternoon

it's very simple :smileywink:

• Create two different ap-groups (one for each location) - those groups will be for the raps units only
• in each ap-group configure your ap-system profile with lms and backup lms (in one ap-group X is the lms and Y is the backup-lms,and in the 2nd ap-group Y is the lms and X is the backup-lms) *don't forget to mark the preemption*
• THAT'S IT (ofcourse in those ap-groups insert all the other config+vaps you would like)
• After that just provision each rap to the AP-GROUP based on the location/site.

finto! :smileyhappy:

Me.

Thanks for your reply! That sounds good. But on which controller should I set up these 2 groups? On both? On just one? Should they both be Master or should 1 be Local? Remember, the 2 controllers are on different locations/VLAN's, they can only communicate on L3.

Also, I think I already have something like this set up. On X, I have a ap-group where X is the LMS and Y the back-up LMS. But when X goes down, the RAP that is connected to X does not switch to Y. It just sits rebooting forever it seems. Could it be because I have not ticked Preemption?

Also, what happens if the RAP is switched on when its configured master controller is not available? Does the RAP remember the Backup LMS and is it then able to connect to the Backup LMS instead of the configured master controller?

Thanks for your help, but my problem remains that the RAP does not switch to the Backup LMS when the LMS becomes unavailable.

I also find no signs of it trying to connect to the Backup LMS in the Process Log of the backup LMS. So it just seems to ignore the setting.

Also, I read elsewhere on these support forums that the RAPS only remember a single Master Controller address when they are rebooted. They do not remember the LMS and BackupLMS according to those posts. If you are right, this behaviour has changed?

Thanks for your help, but my problem remains that the RAP does not switch to the Backup LMS when the LMS becomes unavailable.

how did u tested it? did u lower the timers ?

regarding your 2nd question:

The access point only needs to contact ONE controller to be operational. It can then be redirected to wherever its home is, using LMS-IP and then to the Backup LMS-IP if that initial controller goes away.

I have the RAP connected to Controller A. The AP-GROUP tells the RAP that LMS is IP of Controller A. The Backup LMS is IP of Controller B. I can confirm these settings are succesfully provisioned to the RAP, by using the 'Diagnostics-tab, System Status and entering the IP of the RAP and then checking 'LMS Information'.

When I pull the power plug from controller A, I expect the RAP to connect to Controller B after a minute or so. But it does not seem to happen.

Let me check one more time to be sure :) I'll let you know in 5 minutes.

it might  take more then 5 minutes if u will not lower the timers - just for the test.

some posts to read:

http://community.arubanetworks.com/t5/ArubaOS-and-Controllers/APs-failing-onto-master-instead-of-backup-lms/td-p/11191

http://community.arubanetworks.com/t5/ArubaOS-and-Mobility-Controllers/LMS-Preemption/td-p/62898

I am not using preemption. Preemption means the RAP automatically disconnects from the Backup LMS and reconnects to the LMS after X seconds. My problem is that it won't even go to the Backup LMS, so the setting and the timers have nothing to do with this problem?

[quote]The access point only needs to contact ONE controller to be operational. It can then be redirected to wherever its home is, using LMS-IP and then to the Backup LMS-IP if that initial controller goes away.[/quote]

so what happens when the controller that redirects it to the LMS or Backup LMS is not available?

the lms hold down + max request try .....

please read my 2nd post...

• and yes,you are using LMS = your master and BACKUP-LMS your backup.
• when u plug out the LMS after the hold down and max retries your rap units (that on this ap-group)  will connect to the BACKUP LMS.
• after the LMS will be back online - your RAPS will auto connect to the LMS if the preemption is marked.

The description of the LMS Hold Down Period in the WebUI is very different than what you are saying.

In the WebUI, it says it's the amount of time that an AP stays on the Backup before switching back to the Primary, if the Primary is available again. You say it's the time after which it connects to the Backup when the Primary is not available. That's very different.

You completly right. *It's the sun + heat +  the end of the day :) baking my head*

(Aruba650) (AP system profile "test") #lms-h?
lms-hold-down-period    Amount of time AP needs to stay on backup LMS before
                        switching to primary. Range: 1-3600. Default: 600.

 There is a parameter called "IPSEC retries" in the AP system profile that is normally set to 360. That is the number of IPSEC retries before the AP will even try the backup LMS. Tune that down and you should get the desired behavior. Previously RAPs used the bootstrap threshold and the bootstrap timer, but RAPs use the IPSEC retries parameter to determine when to switch.

First, is there are a reason you have these in multi-master setup rather than master-local?  If the controllers can communicate with one another, I usually set them up as master/local ensuring identical configurations.

Second, what IPs are you putting in the LMS and Backup LMS?   Internal or external?

Third, if you are going to keep them in multi-master, you need to make sure of a few things.

- both controllers have entire whitelist

- both controllers have identical configurations; especially ap-group names and assoicated profiles

- both controllers need to be accessible by the RAP; external IP address in LMS and backup LMS fields

kdisc: I don't think waiting time is the problem, I waited pretty long and the RAP rebooted quiet a few times already. Way more than 5 minutes.

clembo:

1: I thought Master-Local would only work when on the same L2 network. If that's not the case, then I'll gladly try Master-Local. I'll probably have to change some firewall-rules for that, I'll check it out tomorrow.

2: external IP's. The same IP's that both work fine when I enter them in the RAP after resetting it and letting someone connect from home.

3:

-entire whitelist? Isn't just the RAP I"m testing with enough?

-ap-group names and profiles might be not 100% the same. I'll check that out tomorrow.

-they are both accessible as noted above.

Thanks for all the help so far.

So long as the controllers can talk to one another, you can setup the master/local setup.   They need L2 connectivity for redundant master setups only.

I didn't mean you need the entire list, but meant in general.  The one you are testing is fine.  However, you'll need to make sure the AP Group name is exactly the same.    

I've changed settings so that the AP-GROUP-NAME and profiles are the same. It now DOES connect to the back-up controller. However, it does not fully function.

The back-up controller DOES show the RAP being connected and being in the proper ap-group. However, the RAP does not let any traffic through to port E1 it seems.

It shows the following messages in the logs of the back-up controller:

2013-08-16 09:02:05 User 192.168.124.25 with MAC address 00:00:00:00:00:00 and name 00:0c:87:c4:90:1f is authenticated with authentication mechanism 3 and the Role given is sys-ap-role

2013-08-16 09:02:05 User 192.168.124.25 with MAC address 00:00:00:00:00:00 and name 00:0c:87:c4:90:1f was authenticated with authentication mechanism 3 and the role assigned was sys-ap-role

2013-08-16 09:02:06 AP 00:0c:87:c4:90:1f has changed. Change type is 3

2013-08-16 09:02:06 Access point 00:0c:87:c4:90:1f (LMS 192.168.1.250) status 1

2013-08-16 09:02:06 For RAP with Mac address 00:0c:87:c4:90:1f uplink is 1

2013-08-16 09:02:06 Access point 00:0c:87:c4:90:1f is up

2013-08-16 09:02:06 AP 00:0c:87:c4:90:1f has changed. Change type is 1

2013-08-16 09:02:06 AP 00:0c:87:c4:90:1f is on backup controller xxx.xxx.165.147 (primary controller is xxx.xxx.165.146)

2013-08-16 09:02:06 Access point 00:0c:87:c4:90:1f with Name Erik and IP address 192.168.124.25 cold-started 1 time(s)

Aug 16 09:02:05 authmgr[2367]: <522048> <WARN> |authmgr| AP-Group is not present in the Radius server for username=00:0c:87:c4:90:1f; AP will take the ap-group as provisioned in the AP

The IP for the RAP has now (automatically?) changed to 192.168.124.26 and the result is still the same. This line in the log is very strange "2013-08-16 09:02:06 AP 00:0c:87:c4:90:1f is on backup controller xxx.xxx.165.147 (primary controller is xxx.xxx.165.146)" because it is actually connected to controller xxx.xxx.165.146 at that moment and it is the back-up controller xxx.xxx.165.146 that prints that message in its log.

xxx.xxx.165.146 = back-up LMS.

Also, the line "Aug 16 09:02:05 authmgr[2367]: <522048> <WARN> |authmgr| AP-Group is not present in the Radius server for username=00:0c:87:c4:90:1f; AP will take the ap-group as provisioned in the AP" is strange. 00:0c:87:c4:90:1f IS in the white list of the backup-controller, WITH a proper AP-Group.

EDIT: It suddenly works now. I don't know why. What I did was unplug the betwork cable from the client connected to the RAP, then plugged it back in. And then it suddenly received an IP. Before that, I was only trying ipconfig /release and /renew.

Edit2: I can reproduce this. Every time the RAP fails over to the backup controller, it gets an IP, for example 192.168.124.27 and then pretty quickly it changes to 192.168.124.28. In the meanwhile, the client behind the rap receives a 192.168.11.X ip address. After that, I have to pull the network cable between the RAP and the client and reconnect it, and then the client is connected to the office VLAN again. Normal ipconfig /release and /renew does not work for some reason, the RAP does not let the client talk to the office VLAN untill I reconnect the network cable. Weird.

Next problem: if the master that was manually entered in the RAP is not available and the rap is switched on (was powered off), then it does not find it's master. Apparently, the backup LMS is not saved in the RAP when it's turned off, because it does not connect to the backup controller either. It is pretty common for our employees to unplug the RAP at home when they don't use it. How can we manage redundancy now?

I found in other topics that we might have to set-up a DNS-name for the RAPS with 2 IP's. However, this means we lose the ability to control which RAP prefers which controller, because the DNS will return an IP at random. Are there any suggestions for us?

We would like a RAP that is switched on to connect to the preferred controller first. If that one is not available, connect to the other controller. I guess this means the RAP would have to store the backup-LMS when turned off, but it does not seem to do so.

Edit3: maybe I can answer my own question :D If I combine the DNS-thing with the 2 ap-groups kdisc98 suggested, it might just work fine. I'll give that a go. (in one ap-group X is the lms and Y is the backup-lms,and in the 2nd ap-group Y is the lms and X is the backup-lms)

When using a working master-local setup, it works fine without pulling the network cable. Good.

1 more question: If I want RAPs to work even when they are switched on while the master is down, do I need to manually sync the internalDB and the RAP White list?

So I now have a Master-Local set-up. Both controllers are licensed for APs. Both have identical RAP-whitelist and identical InternalDB.

The RAPs are set to connect to vpn.mycompany.com, which returns the 2 public IP-addresses of the 2 controllers.

The RAP that I use for testing is set to a AP-group that has the primary LMS set to the Local controller. When the Master and Local are both running, the RAP connects to the Local controller just fine. When I shut down the Master while the RAP is connected to the Local, it keeps running fine. If I shut down the Local while the RAP is connected to the Local, it switches to the Master just fine.

When I shut down the Master controller and turn on the RAP after the Master is shut down, the RAP starts up, but does not seem to connect to the Local controller at all. When I turn on the Master controller again, it eventually connects to the Local just fine.

As far as I know it should be possible to have RAPs connect to the Local when the Master is down, right? I do not see anything about the RAP in the process log of the Local controller when the Master is down and the RAP boots up. I only see messages that that the Local can not reach the Master.

How can I analyze this further to see why the RAP is not connecting to the Local when the Master is down? Firmware = 6.2.1.3

---

@eriknl2 wrote:

So I now have a Master-Local set-up. Both controllers are licensed for APs. Both have identical RAP-whitelist and identical InternalDB.

 

The RAPs are set to connect to vpn.mycompany.com, which returns the 2 public IP-addresses of the 2 controllers.

 

The RAP that I use for testing is set to a AP-group that has the primary LMS set to the Local controller. When the Master and Local are both running, the RAP connects to the Local controller just fine. When I shut down the Master while the RAP is connected to the Local, it keeps running fine. If I shut down the Local while the RAP is connected to the Local, it switches to the Master just fine.

 

When I shut down the Master controller and turn on the RAP after the Master is shut down, the RAP starts up, but does not seem to connect to the Local controller at all. When I turn on the Master controller again, it eventually connects to the Local just fine.

 

As far as I know it should be possible to have RAPs connect to the Local when the Master is down, right? I do not see anything about the RAP in the process log of the Local controller when the Master is down and the RAP boots up. I only see messages that that the Local can not reach the Master.

 

How can I analyze this further to see why the RAP is not connecting to the Local when the Master is down? Firmware = 6.2.1.3

---

The RAP is only provisioned with one ip address that it will look for on bootup.  If that is pointed to the master, it will never come up.  If it is pointed to a DNS address with two ip address entries, it will try one, then the other.  That is the way you should probably go.

Thank you, that is exactly what I did, but it does not seem to function.

Like I said:

The RAPs are set to connect to vpn.mycompany.com, which returns the 2 public IP-addresses of the 2 controllers.

So it is set to connect to DNS vpn.mycompany.com (of course, it's actually something else than that, I'm using this as an example).

Nslookup vpn.mycompany.com returns 2 IP-addresses. These are the same 2 addresses that are used for LMS and back-up LMS.

So it should be working, but it's not. How can I find out what's going wrong?

Can I get further support on these forums, or should I contact Aruba support through e-mail or something?

You should contact support, because it is hard to know what is going on from here. 

support is adivising me to go the VRRP route, which is not possible for me, because the controllers are on different subnets.

He's saying the DNS method isn't guaranteed to work, because the RAP might try 1 of the IP's that the DNS name returns, instead of trying both IP's.

He's checking right now if there's any other solutions for this case right now, I hope he will find something :) He is a very friendly person. I think everything will be allright, I will wait to see what he comes up with.

---

@eriknl2 wrote:

Sadly, support is adivising me to go the VRRP route, which is not possible for me, because the controllers are on different subnets.

 

He's saying the DNS method doesn't guarantee work, because the RAP will try 1 of the IP's that the DNS name returns, instead of trying both IP's. That's different than what you were saying.

 

He's checking right now if there's any other solutions for this case right now, I hope he will find something :) And actually, I'm hoping that the DNS method should work.

---

The RAP should try one ip address, and then the other.  If it does not do that, then it is a bug:  http://www.arubanetworks.com/vrd/rapvrd/wwhelp/wwhimpl/common/html/wwhelp.htm#context=RAPVRD&file=appc.html

"The DNS sever can be configured to respond with multiple IP addresses for DNS resolution. If a RAP receives multiple IP addresses for a DNS resolution of the remote controller’s FQDN, the RAP will try to connect to the first IP address in the list. If the RAP is unable to connect to this IP twice in succession, it will try the next IP in the list."

I am wondering if the RAP directly tries to connect to an authorative DNS server. What if the RAP would use the DNS server provided by its DHCP-server, which would be for example a cable/dsl modem/router?

The DHCP server on my test modem/router tells its DHCP clients to use the modem as a DNS server (192.168.1.1). When I do a NSLOOKUP vpn.mycompany.com on a client, it only returns ONE IP address. That might explain the problem. The DNS server in the modem/router is not correctly providing the RAP with the 2 IP addresses.

The RAP should contact an authorative DNS server to make sure that it receives correct DNS information, but I guess it does not and just uses the DNS provided by the DHCP server. Is this possible?

The RAP uses the DNS server from its DHCP server.  Your scenario is entirely possible.

See if you can change the DNS server in the modem, or you can try to hardcode the DNS server, ip address, subnet mask, default gateway, etc in the RAP to see if that works.

Yes, when I do:

nslookup vpn.mycompany.com 8.8.8.8 (Google DNS server), it does return 2 IP addresses. So the DNS in the modem is the problem. I can fix this on my modem, but I can not fix this on all modems of our end users of course ;) And I can't hard code the DNS in all RAPs I guess?

Do you think it might be possible in the future to make it so that a RAP directly queries an authorative DNS server to find the IP of the controller instead of using the local DNS?

Anyway, I changed the DNS address to 8.8.8.8 in the DHCP options of the modem and will test later if Aruba Redundancy work now (have to wait untill no workers are connected to the Aruba before I can test).

---

@eriknl2 wrote:

Yes, when I do:

nslookup vpn.mycompany.com 8.8.8.8 (Google DNS server), it does return 2 IP addresses. So the DNS in the modem is the problem. I can fix this on my modem, but I can not fix this on all modems of our end users of course ;) And I can't hard code the DNS in all RAPs I guess?

 

Do you think it might be possible in the future to make it so that a RAP directly queries an authorative DNS server to find the IP of the controller instead of using the local DNS?

---

You cannot configure direct queries.  Your DNS server either provides all of the servers at one time, or it can provide it round-robin, one at a time.  Maybe round robin is an option for you.

It is also possible that based on your old TTL for your DNS entry, that your router/modem is caching and delivering a single entry.  Reboot your modem to see if that is the case.

Yes the modem is caching and only providing a single entry. But an Aruba RAP could circumvent modems behaving badly like this by directly query'ing an authorative DNS server. That would give it a higher chance of working correctly in a redundancy scenario.

---

@eriknl2 wrote:

Yes the modem is caching and only providing a single entry. But an Aruba RAP could circumvent modems behaving badly like this by directly query'ing an authorative DNS server. That would give it a higher chance of working correctly in a redundancy scenario.

---

OR....your DNS server could provide a short TTL when you know you are making changes to the entries.  That way nobody has to reboot their modem.  The modem is behaving as it should.    http://en.wikipedia.org/wiki/Domain_Name_System

I did not make changes to the DNS entry for at least a month. The modem's DNS server is only returning 1 IP even though it should return 2. So I don't think it's behaving as it should? Any other DNS server I query DOES return the 2 addresses.

I am glad you found the issue.

I have a cable modem that returns more than one address.  What model is your modem?

laptop:~ cjoseph$ nslookup
> server 192.168.1.254
Default server: 192.168.1.254
Address: 192.168.1.254#53
> www.google.com
Server:		192.168.1.254
Address:	192.168.1.254#53

Non-authoritative answer:
Name:	www.google.com
Address: 74.125.227.243
Name:	www.google.com
Address: 74.125.227.242
Name:	www.google.com
Address: 74.125.227.240
Name:	www.google.com
Address: 74.125.227.241
Name:	www.google.com
Address: 74.125.227.244
> 

My modem at home does return multiple addresses as well. So far, only the test modem at work (Vigor 120) does not. I will try restarting it tomorrow, see if it fixes it. If not, then it might have some limited implementation of DNS or something. If that's the case, let's just hope it's something rare, specific for that model.

Okay, I changed the DHCP settings in the test modem at work so that it tells clients to use 8.8.8.8 (google dns) for DNS instead of 192.168.1.1 (the test router itself). Now the redundancy for Aruba is working great!

Here's a screenshot of the behaviour of a client connected to the test modem when clients uses 192.168.1.1 for DNS. This is right after a restart of the modem. So the first time, it does return multiple addresses for google.com, but from that moment, it caches the first result and from then on, it only returns that one. Bad behaviour. I will notify Draytek of it. Let's hope this is not something common in home modems that our employees use at home.

When using the google DNS, it goes as it is suposed to: