Wireless Access

The option to use the backup option is not working on arubaOS 8.2+ version.

I tested with the 8.2.1 and with the new version 8.2.1.1, both with 205H and 303H. Bellow is what I am getting.


Wireless Backup is coming up, the user can connect and browser.

But the RAP is not able to detect the controller if it came back, and because of this, someone need to access the reduced managed interface of the RAP(in the back-mode) to do a reboot(very impracticable).

For some reason on the interface of the back-up mode is showing the LMS - with the internal IP of the controller, but using diagnostic to tried to connect to the controller a least on the logs it is trying to connect to the correct Public IP of the controller but is failing to do that( even if it is able to ping to the controller).

In the wired side, I can not make the clients rout to anywhere, on the 8.2.1 I was able to ping wireless user because of the option remote-local backup(something like that),even if they are in another scope of dhcp, but only that, I was not able to reach the IP of the RAP.  the wired users on the 8.2.1.1 is not able to reach the wireless users, the RAP and consequelenty anything, I am trying to see if the are able to ping others wired clients, but even that works it will not help me.

Sad...

Ok more details...

the good news is that the RAP is able to come back to the controller  by itself. Not sure how many seconds it is needing, don't look like it is the default 600 seconds, I am trying to change by hand to see if it is able to be more fast and to see if it really is capable of come back para itself or if the ap reboot when is was alone.

Second, the wired user are able to talk to itself, but not able to talk to the RAP or  ''iniciate a conversation'' with the Wireless Users.

The wireless users are able to rout, and able to ping the wireless users, not sure if a printer is going to work...

Update:

Forget it, 30 minutes and nothing about coming back, I supposed it reboot alone in the first place when I was eating lunch, I will continue to observe...

I think you should have some network diagram is better to explain this.

Cloudq...

Is a typical RAP design like you image...

And I am even simplificate to do a site test using my 4g to be my wan link carrier of the APs.

There is a central location hosting my standalone VMC 8.2.1.1

and I am using a 3g/4g as a test to simulate a internet wan link of my APs... and That is it. Everything is working and by that you should read ''enteprise auth, dhcp, vlan, and rules'' And like I said, the problem is when my connection with my central site is blocked, in this cases the backup ssid is showing up and more or less working, what is not working is my AP is no coming back by itselft to the controller, and the wired ports don't rout...

Is a bug very easy to replicate there is nothing fancing about the network.

Ok, the engineering need to be involved on this. 

Good news is, the RAP are really able to come back, but there is somekind of  incompatibility with palo-alto firewall..

The firewall is up to date, and the problem is...
to simulate a disconnect situation, I block the public IP of the RAP that arrive in controller. This is working, my RAP is turning on the Backup SSID and rebooting the wired ports, but  disblocking, is not working.. the ping is able to come back, but I think there is is some kind of packets that is not been sended or able to pass through the firewall because it not coming back without a ''manual'' reboot..

I tried in another environment with a meraki firewall and the AP is able to go back by itself, and on the paloalto site I starting testing by disable the controller network interface...

But !! The wired ports are still broken, there is no away to make it rout, it can ping and comunicate with others wired users but it cannot ping its own gateway(the RAP). Another syntom that I discover is that doing a packetcapture in the specifics ports through the RAP console activate the the ping responses from the gateway, but only that, they still cannot rout beyond that.

engineering please, start looking in this feature to work on a fix !!

I'm afraid that this "feature" still exist even after upgrade to arubaOS 8.4.0.0 (tested with AP-203RP and "wired" users connected to e1 port).

There is no issue in case of backup scenario with wireless access.

Please let me know if someone has working wired setup.

The RAP-backup function on the wired network should source-nat any traffic from devices out of the ip address of the AP when in backup mode so that they can reach the internet.  Traffic between users on the same wired subnet should not go through the RAP so they should always be allowed.  It is not clear whether or not you should be able to ping the default gateway of the clients in this mode, but you should be able to ping beyond that.  That is how it should function.  If it is not and you want it to work, please open a TAC case so see if it is a configuration issue, a topology-specific issue or a bug that is keeping your network from performing as it should.

I have tried a few different options without success.

I hope that I missed a "magic" setting which would be much easier and simpler to fix. 

Yes, I will open a TAC case after the Holidays.

Merry Christmas!

The only magic setting should be the "rap-backup" option in the wired AP profile:  https://www.arubanetworks.com/techdocs/ArubaOS_83_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/1CommandList/ap_wired_port_profile.htm?Highlight=rap-backup

"rap-backup" option is enabled by default so if do not remove it is already in place.

My setup is very simple:

LAN <-->Aruba Ctrl <--> INTERNET <--> (E0) RAP (E1) <--> (eth) PC

In "normal" operation (with split-tunnel forwarding) PC gets IP addr from DHCP server on Controller. All traffic from PC to LAN is working properly as well as traffic to Internet is send as it should be by RAP (src-nat works correctly).

After RAP connection to controller is lost traffic from PC to the Internet is still working for about 30s, after that time RAP is changing his mode to backup (puts E1 port Down and UP) and PC gets new IP from RAP's DHCP pool (same subnet different IP range). This part works well but ...PC traffic to the Internet is blocked by RAP.

In the same time wireless connection in normal and backup mode (two different VAP profiles) is working properly - no issue with that at all.

I really appreciate if you can share an example of ANY working configuration for RAP backup and "wired" PC.

Yes it is not working on 8.4 too.

I did test on my enviroment and confirm it.

I have a opened the case in the same date as I first posted on this thread and still nothing changed, tac did not even regonized this and put on '' known issues'' in the releases documents, they are still in the phase to get logs and investigate (for months by the way).
To confirm this problem someone only need a H(205h,303h) AP model and a controller on 8.X+, shouldn't need more that 4 hours to set up a lab, still... disappointed.

If you are having problems with a TAC case, you should be able to escalate it if you feel like you are not getting anywhere.  What is the TAC case #?

Hi has anyone any news for this issue, i'm hitting the same problem.. is there any known version, where this feature is working? thanks

Hello,

I'm exactly on the same situation. When RAP loses connectivity the bridge connection doesn't work as expected.

The DHCP server on the RAP works as expected. Both wireless and wired users receive an IP address but wired clients can't reach anywhere besides the local network.

I see the ARP entry of the RAP, I can ping all the other clients wired and wireless, but no luck on going out natted as expected, it seems as it's not doing the route src-nat that should by default.

This is what I found about it on the user guide.

Backup Configuration Behavior for Wired Ports

• If the connection between the remote AP and the Managed Device is disconnected, the remote AP will be exhibit the following behavior:
• All access ports on the remote AP will be moved to bridge forwarding mode ,irrespective of their original forwarding mode.
  Clients will receive an IP address from the remote AP's DHCP server.
• Clients will have complete access to Remote AP's uplink network. You cannot enforce or modify any access control policies on the clients connected in this mode.

I even tried enabling allowall on the ap-system profile but I still can't ping the RAPs DHCP IP address.

I will open a case to see it through. If anybody finds a solution please share, it would be much appreciated!

Cheers,

Aarón

Are you using the last stable version 8.2.2.4 ??

I read the known issues and didn't see this bug stated there.

I give-up the case a few months ago, It was to much hassle and a I got lot of resquest that make me setup my lab again and again (trial licenses), so the support could get more informations (a lot of the time the same of before). I didn't have time to continue doing it.

Good luck. Keep us updated.