Wireless Access

Good day everyone,

We have a customer with a Master-Local setup.

 

We made a configuration change on the Master and its backup and it pushed the change down to the locals as expected but it also rebooted all of the locals?

 

I cannot find any documentation that explains this behavior? Is that normal?

Shouldn't the change just be through the IPSEC tunnel and update the required config?

 

AOS: 6.1.3.0

Master 3600

Locals: 620

#3600

For the Change to be received through IPSEC that for sure have happened. I am not sure if this is the usual behaviour.

 

But I want to ask did you change any thing on AP groups which already have APs associated with and terminated on the local controller ? it can be the normal case or it can be something on the configuration caused the locals to reboot.

 

did the master rebooted also ?

The change was done to a netdestination which holds walled garden entries.

I just added 2 more entries.

 

Master did not reboot.

That is NOT supposed to happen.  Are you sure the controllers rebooted, or the access points rebooted?  What version of Aruba Code is this?

 

---

@cjoseph wrote:

That is NOT supposed to happen.  Are you sure the controllers rebooted, or the access points rebooted?  What version of Aruba Code is this?

 

---

its AOS: 6.1.3.0

---

@cjoseph wrote:

That is NOT supposed to happen.  Are you sure the controllers rebooted, or the access points rebooted?  What version of Aruba Code is this?

 

---

 

Confirmed locals rebooted by typing "show version" and we have around 99 locals, i didn't check them all but we have a dashboard that monitors all the APs through querying SNMP on all the locals and all of the APs went offline.

Reboot Cause: Datapath timeout.

 

I know that 6.1.3.2 has over 100 bug fixes, maybe it is time to upgrade to 6.1.3.4???

go for 6.1.3.3 its a stable version.  good luck :smileyhappy:

is there anything wrong with 6.1.3.4?

 

I have it deployed at other locations.

 

 

To be honest I do not know, I even did not go for the release note to see what fixes it has. But I recommed that you usually contact ARUBA TAC and ask for the most stable version because they are the ones who face and receive all the complains mostly "Bugs". I was informed that 6.1.3.3 is stable and goes fine. But you can use 6.1.3.4 for sure no issue. thats all.

 

:)

Thank you Abi.

 

I am still trying to find information or a configuration setting that would reboot all of my locals after I make a config change to the master.

 

I assume that if I reboot the master, the locals will reboot as well since the IPSEC tunnel is broken?

We are providing an external captive portal, therefore if the master goes down, the locals do not work.

Which is not the way it should be since the locals in theory should continue to function

I assume that if I reboot the master, the locals will reboot as well since the IPSEC tunnel is broken?

 

Local should not reboot, because when master reboot it would be like master went down from local Controller point of view, however, local should be up serving clients, IPsec tunnel between local and master do not carry user traffic the only thing that will happen when Master reboot is just loosing master controller functions e.g. configuration, management, locating and tracking etc.

 

For your captive portal, where do you create your guest users ? in the same external captive portal ?

 

==

The user credentials provided by the captive portal users must be authenticated against an
authentication server. Any server type available in ArubaOS can be used as an authentication server,
including the internal database. If the guest provisioning feature of ArubaOS is required, the internal
database must be used as the authentication server.
Create a server group that defines the internal database of the controller as the authentication server.
By default, the credentials entered on the captive portal page by the guests are validated against the
user credentials in the database of the master controller. So, in a master/local operation all the guest
user accounts are created in the internal database of the master controller.

==

 

 

This exact same scenario happened to us a few weeks ago.  We are on 6.1.3.0

 

Made a change to a walled garden net destination, and pushed the change and it restarted all 14 local controllers at every one of our sites.

 

Then in that same netdestination, it had duplicate entries of the same IP/host and I couldn't delete them.  So I figured what the heck I'd delete them all and start over.  Nope, even after removing the walled garden from the guest policy I couldnt delete the netdestination as it was 'in use'.  

 

What I found was, that if I created a netdestination with both IP address hosts and named hosts, thats when it got borked up.  So I made a new netdestination with just names, reapplied it to the guest policy and then pushed the config, all good. If you need names and IP's for your walled garden, just break them up in to two different netdestinations and apply both to the whitelist.

 

I did work with TAC on this, they said it was fixed in an upgrade but I didn't feel like upgrading at the time.

Well that's not good because when we lose the master, the locals cannot serve up our external captive portal that we provide ourself.

xml-api servers.

 

I assume that the captive portal comes from the Master pushed down to the locals but goes back to Master and back to our backend....

 

This is not making sense anymore as I know for a fact (after bootcamp and literature) that your statement is correct regarding rebooting or losing access to a master.

 

 

 

if you are not using master-db for Auth. then I do not see why CP will fail if Master fails !! :S   local will receive http packet and will redirect it to DNS to bring the page.. so the question does CP page appear to clients when Master is down ? if not then the problem is not in the authentication it would be in the DNS reply or something.

Again,

One controller is NEVER supposed to cause another to reboot. Please upgrade to the latest version of ArubaOS and open a tac case.

Sure thing will do. I will update this thread as I go along.