Controllerless Networks

Hi All

 

I have a found a quirk with my Aruba Instant Wireless network.

 

I have 18 IAP 105's and 2 recently added 2 x 225's. One of the 225's has assumed master of the Virtual Controller but I found a quirk with random ipad/iphones trying to connect on the 225.

 

I receive an alert saying "

2014/3/21 12:28:47

90:b2:1f:c3:04:7c

DHCP request timed out

AP20 C BLOCK C2.

 

It then just gives it an IP address starting with 169.254._._

 

If i then walk over to another AP which is an IAP 105 and turn my wifi on and off my device it then instantly connects.

 

Does anyone have a similar thing happen or any ideas as to what im missing??

#AP225

What is providing DHCP on that network?

What version of instant are you running?

I am using windows Server 2008 R2 to give out DHCP. I have 2 of these running on my network.

 

The version of firmware is 6.3.1.2-4.0.0.4_42384.

Need more infromation on your setup to assist you, what is the setup and what is version. Is other client having the same issue?

The version of firmware is 6.3.1.2-4.0.0.4_42384.

 

I am using windows Server 2008 R2 to give out DHCP. I have 2 of these running on my network.

I use radius to authenticate against windows AD.

 

I have 20 x IAP 105's and 2 x 225's. I have noted that the wireless network will not run cohesively unless one of the 225's is the master.

I use a virtual controller which is why we bought the IAP series in the first place.

 

Can you think of anything else which would help.

I ran into the same issue with IAP 225 running 6.3.1.2-4.0.0.3 specialy with the 2.4GHZ clients. the clients werent getting the ip address and in the VC it was showing DHCP request timeout.

1st i reduce the power but it didnt work well  and still the clients werent getting the IP address after that disabled the client match, on restarting the IAP i was able to get the ip address.

So far its working fine have to check the behaviour for some time. 

 

 

When you say that you disabled the client match. What is that and where can I find it on the web interface of the VC?

Can you share the output of ?show tech-support? from your virtual controller?

I can get onto my virtual controller but where is the location of find tech support?

 

I find a section called support but it is blank.

If you are in the UI, please click the ?More > Support? link, and then select ?AP Tech Support Dump? from the first drop-list, select the AP you are having trouble with in the second drop-list, and then click on Run to see the output.

I want to add on this topic. we're have the exact same issue and I want to mention, that currently it seems like a general issue with IAP in a  802.11ac deployment, at least with the alcatel lucent IAP225's.

 

we already troubleshooted the issue and it's pointing out that the issue is already known and has to do with an client match issue in connection with 802.11AC clients/config. On my researches I found serveral post in this forum descriping this problem.

e.g:
http://community.arubanetworks.com/t5/Aruba-Instant-Cloud-Wi-Fi/Client-match-behavior/td-p/130249/page/2
http://community.arubanetworks.com/t5/Aruba-Instant-Cloud-Wi-Fi/IAP-105US-DHCP-PROBLEMS-CONNECTIONS-Please-Help/td-p/122247

 

like i mentioned, we're using branded alcatel lucent IAP's and we've opened up a service request there. 

 

the current sitation:

clients freaquently got kicked out of the wlan and are unable to reconnected, in most cases they do not get DHCP IP after reconnect, even if they are located directly under the accesspoint. 

At the moment it looks like we managed to workaround the issue with:

 

- upgraded to the lastest 4.0.0.2 firmware
- disabled clientmatch
- diabled 80mhz and even 40mhz channels
- set all IAP IPs staticly
- disabled all IAP firewall features under wlan profil (any any unristricted)
- disabled broadcast filter

 

 

so we basicly reduced the configuration to a "better 802.11n wifi"

 

 

 

i hope this issue got fixed soon...

 

 

Samuel,

 

How many IAPS do you have and how far apart are they?  What is their minimum and maximum power?

 

Hi joseph

 

our customer has kind of a high dense deployment, he's only uses wifi without wired lan connection for an enviroment of around 30 users splitted over 3 open space offices.

 

there are 9 IAP in total:

4x in the first open space office

3x in second open space office

and 2x in two seperate rooms.

 

 

this picture were taken off hour when almost no client was connected to the wifi (only some ipad's left in the office)

 

befor we did some tweaking in the channel settings, about 5 AP's had there 5ghz channel set to 116, so we dediced to configure some of them manually in a pattern of 40,44,48... to make sure there is no co channel indeferience. 

we left the max transmit power to the max but we reduced the  min. transmit power to the minumum of 3db!

 

let me explain why we enabled a 4 channel strategy instead of go with the default 1,6,11. Like i mentioned we have 4 AP's very close together in one office, and we noticed that even with the min. transmit power set to 3db, no AP throttled down ther power lower than 15db, that caused the issue that even in a idle state there was a utilitsation of 50%...   unfortunatelly there is no way to turn of 2.4radio per AP.. so we dediced to go with 4 channels, which overlap a bit better than go with 3 channel which overlap more.

 

anyway i don't think that plays into this issue, because most clients stick on the 5ghz band... the issue is not related to an coverage or indeference problem and existst even if we turn of 50% AP's..  

 

in addition a want to point out, that our first direction in the troubleshooting process was to make sure that the DHCP server is not causing the issue.. 

 

 

because the detailed error message leat to that

 

 

we're using an ASA firewall as dhcp server and we can clearly see that all DHCP Discover messaged got answered properly:

 

I also setup a syslog debug for a short period of time, i attached the logfile. 

 

please note that the errors which contain "192.168.100.201" are probably releated to the circumstanced that i was connected via VPN to the virtualcontroller while i catched the syslog debugs... so you might ignor those messaged.

 

 

Heinrich,

 

The inability to receive DHCP could be an RF issue.  We need to ensure that the RF environment is very good, before we attempt to troubleshoot anything else.

 

You should have your access point power at min 12 and max 18 on the 5ghz side.  Why?  That is so that a user will not hang on to an access point that is far out of the access point radius, because the signal is still good.  having access points at the max power can cause roaming issues, because clients normally do not attempt to roam until the signal gets "bad enough".  In addition, since your client has an open office space area, RF can travel hundreds of feet, dragging tons of clients into a collision domain, as a result.

 

You should not use DFS channels, UNLESS a great majority of your clients support it, because not all clients can see DFS channels, so they will probably connect to a sub-optimal access point, and not the one right above it, as a result.  That would make that client connect to an access point further away and that will drag down the performance of all the users who are connected to that access point, because the client will take longer to transmit further away.

 

You should use 20mhz channels with any density so that you have 9 non-overlapping (non-dfs) channels instead of 4 with 40mhz (non-dfs).  This is because all clients cannot use 40 mhz channels and that means when those clients connect, 20mhz of spectrum will go unused...and other clients cannot use the other 20mhz.

 

When you have high density, you might want to try increasing the basic and tx rates on that SSID so that the management traffic takes less airtime and reduces your utilization.  by default the lowest management and data rate on the 5ghz is 6mb.  You could try changing it to something like 18 for each, and your utilization will drop.

 

You also do not have to set static channels.  Make enough channels available and ARM should do its thing.

 

Since any ip connectivity rides on RF connectivity, you will be able to see if there is an IP issue when you make the RF changes.  It is hard to troubleshoot an IP issue, when there are still RF issues.  There is only so much that Clientmatch can do.

 

Hmm.. seems like it comes down to something other than an RF issue :smileyindifferent:

 

Many threads on this specific problem. 

 

I'm brand new to Aruba and after deploying my first set of IAP-225s am experiencing exactly the same issue.  Definitely no RF issue (RSSI > 60, 3 devices all on seperate channels 1, 6, 11, covering a 5000sq ft indoor area with no significant noise).

Has there been any fix to this known issue?

yes it was definitively not a RF issue. 

 

we reduced the AP count and monitored the spectrum with some AP's = no effect

we disabled DFS channels = no effect

we tried almost every setting regarding tx rates and power levels = no effect

 

after we upgraded to 4.0.0.5 it worked immediatelly like a charm.