Wireless Access

Learning on the fly here becuase our network guy who set these up has since left.

 

Controller is 3200 and running 6.2.1.5

 

Set this up the other day and brought it home with me to test. Used a url for our DNS for initial setup and everything seemed to go fine. Once connected at home, i lose connection to all external and internal sites every 5-8 min. It then will reconnect on its own without unplugging and i am able to browse to everything. I am getting a internal IP from our companies network when it is up and running.

 

When setting this up, we have an external ('Dirty') internet connection that i am able to test them on before they are given to people who work from home. While connected to that line they never once went down, reset, and were able to hit every webiste internal and external. To my knowledge it is no different from an internet connection from a residence.

 

The controller UI states that the UP time for the AP is constant, that even when it goes down on my end, the controller does not display that it is offline.

 

Did i miss something during setup, or is our DNS acting up? All of our other RAP2's in our environment have not had this issue.....yet. (We have about 60)

 

Thank you for any help

#3200

2 things you can do:

 

1. On the Virtual AP for that SSID, (if you are using wireless), Enable "Drop Broadcast and Multicast"

2.  If you are using the wired interface, as well, enable "Broadcast and Multicast Optimization" on the VLAN that the ethernet port is assigned to.

 

 

Another couple of suggestions that might help...

 

In the AP system profile associated with your RAP AP-group, try reducing the mtu if not already done? I find 1400 (or there abouts) works 99% of the time.

 

And, in the past I've found the "no broadcast" command in the wired-ap-profile (under advanced tab) very handy. It stops undesirable things coming up from the RAP physcial port (if you're using it) towards the core controller (like STP or similar).

 

Either of these can affect stability.

the.racking.monkey,

 

A few pieces of information:

 

Normally the MTU should only be changed if it absolutely does not work.  The MTU should not work most of the time and then suddenly stop.  A successful MTU should just work, once negotiated or set manually.  It should NOT be changed at all after that.

 

Here is what the "no broadcast" knob on the wired ap profile does:

 

1. Broadcast/Multicast traffic from the wired network will continue reach the RAP wired users and vice-versa.
2. The wired users are able to reach their default gateway and the controller IP on the same vlan (ARP works).
3. However, any broadcast including ARP from a wired rap user will not get forwarded to the tunnel to any other RAP wired user.

The direct impact is that wired rap users will not be able to communicate with each other, which will break the rap-wired-user to rap-wired-user phone communication.

 

Essentially the "no-broadcast" knob keeps wired RAP users from sending broadcasts to each other, but it does not prevent them from receiving broadcasts from the wired network at the datacenter:  bcmc-optimization on the VLAN on the controller prevents downstream broadcasts from the wired network from being propagated to the wired ports of RAPs that are on that VLAN.

 

This is something that is not explained often, so I hope it helps.

 

Historically that's not what I've seen.

 

A lot of customers appear to get initial reliability, and then drops when passing lots of data.

 

Out of about 100 customer deployments in the UK using RAPs, I've found the default MTUs prove a little unreliable about 70% of the time. Hence my default approach to lower it a little.

 

Regarding the broadcast drop on RAP ports, I've used this on at least 4 occasions to resolve instability. Typically, this has been where the remote site equipment (switches etc) was either unstable, being changed a lot, or sending undesirable STP upstream to the core controller as I mentioned. Turning the broadcast know off fixed all of them, so I find it better to have that off by default until it's known otherwise. In my experience, issues in this area always come from one or more remote site, not usually the DC/HQ.

 

It's just my view, not necessarily right of course.

 

 

the.racking.monkey,

 

What features actually do and user's experiences with them are usually two different things.  Thanks for sharing your history.

Wired connection

 

 

Here is a dumb question, how do i get to the AP interface? Im assuming that is accessed through the local connection to the AP, not the controller UI.

Pooh bear,

 

It is all done at the controller UI.  http://www.arubanetworks.com/techdocs/ArubaOS_63_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/Network_Parameters/Configuring_VLANs.htm

 

 

I guess im a bit confused...

 

 

Can i make changes to just the RAP's that seem to have the connection problems? If all others are functioning normally, im not sure i want to make any controller/vlan changes.

The change is to the wired VLAN interface, not the access point. The change(s) mention are fairly conservative.

Brought the RAP back in with me to work today to repeat my setup steps.

 

Factory reset, plugged in, and connected to a spare laptop. Entered in IP in browser interface once it opened.  All steps complete then it gets stuck at Continuing.  It just spins and tells me the AP is rebooting, but nothing happens at that point?