Reply
Highlighted
Contributor II

reply

1 - no, all clients are wireless
2 - yes
3 - yes

2 and 3 did make a big difference (we implemented them back when it was the proxy-arp voip command)
Highlighted
Guru Elite

Monitoring your wireless network


1 - no, all clients are wireless
2 - yes
3 - yes

2 and 3 did make a big difference (we implemented them back when it was the proxy-arp voip command)




Are you using anything to monitor the trends in your wireless network like Airwave?

This is important to match hard data up with any incidents you might have.

*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.5 User Guide
InstantOS 8.5 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
ArubaOS Consolidated Release Notes
Aruba Technical Webinars
Highlighted
Contributor II

sadly no...

Sadly we do not have airwave, we do have MMS, but it doesn't seem to be useful in this situation.
Highlighted
Guru Elite

Monitoring Solution




Whether you get something to gather all your syslogs and turn on user debugging or you evaluate Airwave, you should get something to gather data. This will help support narrow down your issues. Did you open a support case?


*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.5 User Guide
InstantOS 8.5 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
ArubaOS Consolidated Release Notes
Aruba Technical Webinars
Highlighted
Contributor I

Re: Band Steering behavior

As an aside to this issue, are there any ramifications I should tell the higher-ups regarding:
- drop broadcasts on at the Virtual AP layer?
- broadcast filter ARP on at the Virtual AP layer?

I can't think of any issues. Seems like a good idea.
Highlighted
Guru Elite

Drop Bcast


As an aside to this issue, are there any ramifications I should tell the higher-ups regarding:
- drop broadcasts on at the Virtual AP layer?
- broadcast filter ARP on at the Virtual AP layer?

I can't think of any issues. Seems like a good idea.




Just let them know that it improves overall performance. You should test every application carefully, however, to ensure that it works with this enabled.

*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.5 User Guide
InstantOS 8.5 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
ArubaOS Consolidated Release Notes
Aruba Technical Webinars
Highlighted
Aruba Employee

Re: Band Steering behavior

My experience with band steering has been that the client driver and configuration has a significant impact. If the client is configured to prefer 2.4GHz (or b/g, depending on the driver naming convention), then it will not attempt a 5GHz connection. The way band steering works is that we mark a client a band steering capable and ignore 2.4GHz association attempts from that client for a short time period hoping that the client will give up before the timeout and connect to the 5GHz radio. If it does not give up and continues to ask for a 2.4GHz connection, we will let it on as a b/g client (so as not to DoS ourselves :)). Maybe your clients are set to prefer 2.4GHz and are not requesting a 5GHz connection within the timeout window?
Highlighted
Aruba Employee

Re: Band Steering behavior

So, just to circle back around, I upgraded to 3.3.2.22 on Sunday with no change to the client experience. I'm really not leaning towards this issue being an Aruba problem at this point.

We do see the client trying to "roam," although it's to the same BSSID and at the point of error, OAC is throwing EAPOL errors like this:

"EAPOL-Key handshake message 1 discarded: No matching PMKID found so the association had to start all over with a full re-authentication."

Juniper is blaming the APs/Controllers for this, but the way I read the message, OAC was the one who couldn't find the PMKID and started a full auth which kills the connection. I'm going back and forth on that with them now. Just to refresh everyone's memory, this could happen after only be connected for 10 minutes.

I've upgraded OAC for one user that sees this issue chronically...from OAC 4.72 to 5.1 (latest version). His experience is now a bit different. He went from not being able to stay connected for more than 10-15 minutes to being able to stay connected for more than an hour sometimes. We also tried an external Linksys card instead of his internal Intel...problem still exists.

Now today, I put an AP right outside this user's cube because his signal was weak and he went a full eight hours without issue. So, that kind of does tell me that with a weaker signal his client does want to roam and perhaps OAC can't handle it under certain circumstances for some reason???

What does everyone else think of that theory???
Guru Elite

Band Steering


So, just to circle back around, I upgraded to 3.3.2.22 on Sunday with no change to the client experience. I'm really not leaning towards this issue being an Aruba problem at this point.

We do see the client trying to "roam," although it's to the same BSSID and at the point of error, OAC is throwing EAPOL errors like this:

"EAPOL-Key handshake message 1 discarded: No matching PMKID found so the association had to start all over with a full re-authentication."

Juniper is blaming the APs/Controllers for this, but the way I read the message, OAC was the one who couldn't find the PMKID and started a full auth which kills the connection. I'm going back and forth on that with them now. Just to refresh everyone's memory, this could happen after only be connected for 10 minutes.

I've upgraded OAC for one user that sees this issue chronically...from OAC 4.72 to 5.1 (latest version). His experience is now a bit different. He went from not being able to stay connected for more than 10-15 minutes to being able to stay connected for more than an hour sometimes. We also tried an external Linksys card instead of his internal Intel...problem still exists.

Now today, I put an AP right outside this user's cube because his signal was weak and he went a full eight hours without issue. So, that kind of does tell me that with a weaker signal his client does want to roam and perhaps OAC can't handle it under certain circumstances for some reason???

What does everyone else think of that theory???




Mike,

I want to go out on a limb and say that your problem may or may not be related to band steering. If that's the case, please start another thread so that only people with your specific issue will provide value. Turn band steering off and see how things work, if you need some more evidence. I hope that you also have a case open and that you have been feeding all this information back to TAC so that they can get to the bottom of your problem. We simply cannot gather enough personal information in this thread to help you, and it seems like it has been going on for some time. Since you are using the Juniper client, that is an added dimension that needs to be factored in, dealt with and addressed.

I'm attaching an older but still relevant document that could describe why you could be seeing the message in the Juniper Client, and what you can do to validate that.

*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.5 User Guide
InstantOS 8.5 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
ArubaOS Consolidated Release Notes
Aruba Technical Webinars
Highlighted
Aruba Employee

Re: Band Steering behavior

Thanks for the info Colin. Yeah, I have cases open with both Aruba and Juniper TAC on this one. We're taking troubleshooting one step at a time as far as changes go.

The thing about this issue is it only happens to certain people, and it happens to them just about all the time. The strange thing is, there's nothing different about any of us, everything is quite standard.