Wireless Access

Hi guys,

i have a lab environment with RAP setup and dot1x client connected to it.

the RAP connects via L3 routing to the controller.

i have a case in my customer site and re-created the case in my lab, the issue is when my RAP losses its connection to controller (persistent RAP), the RAP able to survives and stays broadcasting its SSID but the client would dis-associate itself after several minutes.

 

the minutes of disconnection client is pretty random. when i tried in my customer site, the user would dis-associate from the SSID randomly between 5-20 minutes. i use clearpass in my customer site.

when i recreated this issue my lab environment, the client dis-associate around 30 minutes. i uses NPS in my lab.

 

i have re-authentication in AAA disabled, client blacklisting after fail authentication also disabled. anyone ever experience this similiar issue?

 

tried to debug both the client and AP but i cannot get anything related to the issue.

client debug shows empty log when the RAP disconnects from the controller, even after the RAP re-provisioned, there are no entry about the client.

ap-debug doesn't show anyone for me. but just in case, i attach my ap-debug result.

 

thanks in advance. been struggling with this thing for few days now.

Is this a 802.1x (username and password) or a WPA2-PSK network?

 

Is the SSID bridged?

Hi Colin, this is RAP, bridged, dot1x.
I have tested both PEAP and TLS with the same result.

You can try to set the number-ipsec-retries parameter in the ap system profile to 0 so that the RAP does not reboot:  http://www.arubanetworks.com/techdocs/ArubaOS_65x_WebHelp/Web_Help_Index.htm#ArubaFrameStyles/1CommandList/ap_system_profile.htm?Highlight=ap system-profile ipsec

Hi Collin, thanks for the suggestion, i will give it a try tomorrow.
But my RAP doesnt reboot. It keep broadcasting ssid while my client disaasociates.

Well, it is just a suggestion.  I would open a TAC case if that does not solve it.

I will try your suggestion and open a TAC case if that doesnt solve it as you said. Will update it here once i got a solve.

Hi Ricky,

 

Please let me know the RAP model & firmware version running on the controller.

 

Lets say the RAP is up on controller & client is connected to it.

 

If the controller goes down the bridge-persistent SSID will still stay up & client will stay connected to it.

 

Can you check if the client is able to reach the gateway once the controller is unreachable ?

 

As Colin mentioned, RAP is going to reboot after 85 retries as well.

 

 

Hi Nitesh,

 

i am using multiple different controller, RAP, clients, and AOS. i am starting to suspect the problem is in the configuration. is it anything specific i need to do to achieve my goal?

in my first lab i use 7010, RAP 325, RAP 207. i use CPPM for the dot1x in this lab.

in my second lab i use 7005 and RAP 93. i use NPS for the dot1x in this lab.

same problem occur in both environment. i have tried AOS 6.4.4.9, 6.5.0.0, 6.5.1.0, 6.5.1.1, 6.5.1.2, 6.5.1.3

for testing, my client keep doing ICMP ping to the gateway. all smooth untul the client dis-associates and all ping failing.

 

RAP reboot is not the problem because when the client dis-associate, my RAP still broadcasting the SSID. i have config the bootstrap and ipsec timeout to zero.

Hi Ricky,

 

I recently came across an issue where clients won't pass traffic when connected to bridge-persistent mode SSID once the controller goes down.

 

That would get addressed in the upcoming releases.

 

I would suggest to open a TAC case so that outputs can be analyzed.

Hi Nitesh, thank you. i already have a case opened but they are still looking into the case. will update here once i have an answer.

just want to give an update.

this issue listed in the known bug for AOS 6.5.x. and currently has no fix (the newest when i post this is 6.5.1.4)

the bug ID is: 135100

Symptom: When the persistent VAP feature is enabled on a VAP, the
802.1X wireless clients connected to the VAP lose connectivity if the AP
loses connectivity to the controller.
Scenario: When the AP loses connectivity to the controller and there
are 802.1X clients connected to a persistent VAP, these clients lose
their connectivity until the connectivity to the controller is restored. This
issue is observed in 200 Series, 210 Series, and 220 Series access
points running ArubaOS 6.4.3.6.
Workaround: None.

Hi Ricky,

 

I beleive you were working with Uday on the case.

 

I had a discusison with him regarding the same.

 

Probably you can try having just a bridge-persistent based VAP in the AP-group & then test.

 

Do not add any additional VAP in the AP-group while testing.

Hi Nitesh,

 

i have tried to use only one SSID and it works fine. clients doesnt disconnect after WAN down.

It turns out this issue only occur if i add more than one VAP in the ap-group.

i am quoting Uday's mail;

"

As you have mentioned in your previous email, the issue is observed when the AP-group is mapped with two VAP (Standard and Persistent). When the AP loses communication with the controller, AP will trigger a radio-down event which will knock off all the clients connected to the AP. However when the AP-group is configured with only 1 VAP (Bridge + Persistent), radio-down event is not required hence the clients which are already authenticated doesn’t get de-authenticated.

"

Hi Ricky,

 

The reason it works fine with bridge-persistent is that there is no need for bringing down radios for this SSID as it is suppose to work even when controller is unreachable.

 

However, when you have another ssid (bridge-standard/tunnel etc) in the ssme AP-group, the radios need to be brought down as these SSID's can't survive without controller.

 

So, this radio down event in case of multiple SSID's (diff combination) causes the effect on bridge-persistent mode SSID as well.