Wireless Access

We are in the process of moving our Data Center from STL to Dallas.  I have a new Master Controller with the same config as the existing controller minus the interface updates. 

We attempted to swing our local controllers over to the new Master tonight.  I changed the Master IP on the local controller, saved, and reloaded.  The Local controller came up on the new master with no issues. 

The AP's attached to the Local controller also came up with no issues but the RAP's did not.  Previous to the change we made a DNS entry update to ping the master.com name to the new external IP address.  We checked several dns lookup services to verify the change had propagated. 

I have a local RAP3 and I rebooted it for it to reconnect to the original Master Controller. 

My question is do the RAP's cache the dns entry?  If so, how can that be cleared remotely to move these to the new Master?  If not, what would be the reason this RAP's are not attaching back to the New Master? 

Any help is greatly appreciated. 

Daniel

Hi,

More than likely the new controller does not have the NAT pool for the RAPs.  I can't remember the exact command, but search through the old master for a config that contains the word 'local' and you'll work out which command you need to put it.

If you can remember what inner ip the RAPs had when they came up, that will make it easier and you'll spot it.

Michael_Clarke is 100% correct.

In addition, you should have a firewall that NATs your inbound traffic from the public address that RAPs point to, to the private address that the master USED TO BE.  That NAT statement on your inbound firewall most likely has to be updated with the new master's ip address...

The NAT Pool would be missing even thou the New Master was setup using the flashbackup of the old?  Shouldnt that grab the entire config?

dp

Watching the firewall and a RAP3 after it was rebooted it never attempted to connect to the new Master IP via DNS.  It went directly to the old Master IP (External). 

dp

---

@dpatterson1976 wrote:

Watching the firewall and a RAP3 after it was rebooted it never attempted to connect to the new Master IP via DNS.  It went directly to the old Master IP (External). 

 

 

dp

---

If you only changed the internal ip address of the master, what you need to do is update your external firewall so that the NAT entry translating the incoming traffic to the private ip address is updated to the new master's private address.  This is by far the easiest route.

If you created a new NAT entry on your firewall for a new external and internal ip address, you have to change ALL of your RAPs, and that is not possible unless they can reach the old controller.

I do not believe we are doing any NAT translations at the FW. 

We use a FQDN on the RAP to point to the Master Controller.  This IP is on the Controller VRRP.  We made an external DNS change to point the FQDN at the new IP. 

---

@dpatterson1976 wrote:

 

I do not believe we are doing any NAT translations at the FW. 

 

We use a FQDN on the RAP to point to the Master Controller.  This IP is on the Controller VRRP.  We made an external DNS change to point the FQDN at the new IP. 

 

---

So is the ip address that the access pointing to a private address or a public address?   Are the access points located on your private or public network?   If they are both private, everything should work as long as access points are pointing to the DNS and it is supplying the new address.  If they are pointing to the old ip address, you will have problems.

If it is a public address and your new master does NOT have a public ip address on one of its interfaces, you probably have a firewall doing the translation and you need to look at that.

All RAPs are on a Public network pointing to a public IP address. 

The new Master has a Public IP on an interface. 

All APs on the private network came right up with no issues.  Which leads us to believe the RAP will need to be reset and repointed to the new master controller by FQFN. 

dp

---

@dpatterson1976 wrote:

All RAPs are on a Public network pointing to a public IP address. 

 

The new Master has a Public IP on an interface. 

 

 

 

All APs on the private network came right up with no issues.  Which leads us to believe the RAP will need to be reset and repointed to the new master controller by FQFN. 

 

 

dp

---

Yes.  Your RAPS were probably statically pointing to an ip address, instead of a DNS entry.  If you have a spare controller to put in the place of the old controller, we could do something to move those acces points over to the new controller.  If you do not have an old controller to do this, you will have to manually reset all of those RAPS.

As we sit right now we are all back up on the Old Master Controller.  We had to roll back due to the RAP's not coming online. 

Please see the article here:  http://community.arubanetworks.com/t5/Access-Points-and-Mesh-Routers/Migrating-RAPs-to-new-controllers/td-p/79736 on a way to move RAPs points to another controller.  The key, of course would be to push a fqdn to access points that have an ip address so that you can actually control them via DNS.

Well....  All RAPs have a FQDN now.  None of them are setup with a static ip address. 

Do they cache the IP on the RAP and use that until reset? 

Daniel

They use that ip address on reboot, yes.  The question is, how quickly does your DNS referesh with your changes.  Every reboot, they should look to DNS for an updated address..

We are a service provider and 95% of the RAPs connect to our plant doe DNS changes replicate pretty quickly.  We verified that the change had taken place prior to the change. 

Any thoughts on the RAP's caching the FQDN IP until reset?  Is this possible? 

We are at a loss here and are in a crunch to get our Master Controller service moved. 

Daniel

When you say "caching" you mean that they continue to resolve the old address even upon reboot?  If those APs use DHCP, find out what DNS server they are using for resolution and do an nslookup to those servers to see what is going on.  It should not cache it.

Also, make sure in that AP-Group, in the AP system profile, you don't have an LMS-IP redirecting them back to the old ip address.

Looks like the LMS-IP is set but its using the outside IP of the Local Controller which is still valid.  Is that OK or should it not have a LMS-IP at all? 

Daniel

If the controller that the RAP is initially pointing to is the one he will end up on, just remove the LMS-IP and it will stay on that controller.

If your new master controller is where your DNS points to, but the LMS-IP on that master is the old controller, the access points will switch back to that and create your issue.  Long story short, just remove the LMS-IP if your DNS points to the correct controller.

DNS is pointed  to the NEW Master and LMS is pointing to the External of the Local Controller which is still valid. 

Here are the steps we took. 

1)  Changed DNS to reflect the new External Master IP Address

2)  Verified DNS change had propogated

3)  Changed Master IP (Internal) of Local Controller

4)  Verified Local Controller was up on NEW Master

5)  Verified AP's were up on Local Controller

6)  Verified RAP's were NOT on local Controller.  From looking at the FW they never even attempted to hit the FW at the new location. 

Just trying to sort thru the issues. 

Your feedback is greatly apprecited. 

dp

What about this solution you posted a while back? 

http://community.arubanetworks.com/t5/Access-Points-and-Mesh-Routers/Migrating-RAPs-to-new-controllers/td-p/79736/page/2

---

@dpatterson1976 wrote:

 

 

What about this solution you posted a while back? 

 

 

http://community.arubanetworks.com/t5/Access-Points-and-Mesh-Routers/Migrating-RAPs-to-new-controllers/td-p/79736/page/2

---

That solution assumes you have connectivity to the local controller directly from the outside world.  I would provision an access point, NOT to the external ip address of the master controller, but to the external ip address of the local to see if any traffic is indeed coming in.

You would do a "show datapath session table | include 4500" on the commandline of the local to see if that test access point is even trying to send traffic.

The Whitelist DB is available on the new Master Contoller.