Wireless Access

I believe I heard in mobility bootcamp a couple of years ago on how to setup DHCP and Aruba, but we're having odd issues that appear to be resulting from using a DHCP Superscope.

 

So, currently we're running a windows DHCP server, a superscope with 5x  '/24' subnets, broken down they are:

-WIFI Superscope

--172.29.90.0 /24  (vlan tag 90)  <-- all APs are booting and DHCP'ing off this subnet

--172.29.91.0 /24  (vlan tag 91) 

--172.29.92.0 /24  (vlan tag 92) 

--172.29.93.0 /24  (vlan tag 93) 

--172.29.94.0 /24  (vlan tag 94) 

 

On the aruba 3600 Controller VLan IDs 90-94 are created and added to a VLAN pool, that VLan pool is added to the VAP.

 

The problem the client devices are encountering are the following:

They will pull an IP address but are unable to pass traffic, this usually happens when they've roamed to another AP, perhaps in another building.

 

Has anyone seen this before, are we configured correctly?

 

 

 

#3600

As a general comment, I would adjust your VAP to exclude VLAN 90...if you are using that for APs, you generally don't mix in clients into that scope, instead leaving it free for expansion of the wireless infrastructure.  Just my own best practices approach.  Makes it easier to troubleshoot later for others.

 

Switching to your specific observations:   

 

If all of your APs are tunneled back to the controller, there should be no reason to lose connectivity when roaming between them, with or without a VLAN pool.

 

Can you describe more how the APs are configured (on access ports, on trunk ports?), are all SSIDs tunneled or some bridged?  when you describe roaming are there multiple controllers involved or just a single centralized one ?

JF 

Thanks for your quick reply.

 

We're using a single 3600

we're only using port '0' on the controller and its set to 'access'

all SSID's are tunnel under forwarding mode

 

Thanks again

Thanks for the quick reply.

If all APs are in tunnel, then all VLANs will converge at the controller.   There should be no loss of connectivity upon roaming from different subnets in this model of deployment.   We definately need to assess whats going on in that area.

 

On the controller port side, with these multiple VLANs, you typically would want a TRUNK to pass them upstream to a router/L3 switch if the goal is to keep all seperated.    If you are doing small /24 networks just for traditional broadcast control(sounds like you may well be since the vLANS are all tied to the same SSID), then the Aruba controller can easily help you do that in the current AOS releases WITHOUT chopping up your subnets to small/traditional sizes.  e.g. you can simplify your WLAN deployment and use a /23 or /22 with a single large VLAN with broadcast controls turned on instead of using the traditional /24s.  

 

May well simplify things for you.    

 

Could you set-up a test with a /22 network with broadcast controls and see if the roaming disconnections/performance impairments continue?   Would rule-in/rule-out the VLAN pool contributing to the issue at hand.

 

What version of code are you running ?

What type of APs ?

Are using 802.1x or open auth ?

What type of devices ? Windows or Mac ?

Do you see the devices in the user-table when this is occurring ? If they do can you do a show datapath session table <IP address >

Also check to see if there's any errors on the trunks on both sides( aruba and switch use by the APs) , show port stats ( on the Aruba side)

Where are those APs connected to ? Make sure there's no errors on the access ports going to the APs

And one last thing make sure that all the APs are running the SSIDs correctly

Show ap bssid | include <ap name>

I forgot to mention a key bit of information...  This is completely intermittent, I am unable to replicate or predict the issue.

 

victorfabian:

-  version 6.1.3.4_34587

- most of our APs are AP93s or AP105s

- security is open

- all devices can be affected, windows laptops, macs, iphone and android

- Yes we see them in the user table.   I dont have a particular client to check the datapath at the moment as mentioned above.

-  no errors seen on the aruba or on the swiches

- Here's a scenario.  I have an AP105 in my office, in which 10 people may be connected to the open SSID with no issues at all.  A new client connects, pulls an IP address and cannot access any network resources.

 

 

jfernyc:

 

As I forgot to mention, i cannot replicate, so it would be hard for me to change the subnets to test if it were a fix or not.

---

 

I'm really just wondering if superscope is the preferred way to do this, i cannot seem to find it documented anywhere.  I will note some things i've tried on a client with the issues above:

-  Ping core switch = fail

-  Ping management ip of aruba = fail

-  delete lease in dhcp, renew IP on client, ensuring to get a new IP = success, able to browse interwebs

 

 

Since we implemented broadcast controls into the solution, I always prefer larger VLANs than VLAN pools.

 

  It reduces complexity, and provides high performance at the same time.   Less complexity comes in handy when troubleshooting or teaching others about what I have done on the network.  Especially when chasing the intermittent issues we see from time to time in the IT world.

is that broadcast controls a new feature since 6.1.3.4?

 

If so i'm willing to make the change, if i can.  I'm going to need at least a  /22 (and honestly thats not big enough) but i'll have to do quite a bit of changes to the rest of the network to make it fit. 

If you are using the controller as a dhcp server you need to be careful not to exceed the recommend amount of leases .

JF is right you should look into a more recent AOS .

no, we use windows DHCP.

 

Does that feature require the integrated DHCP server?

It does not.   You can use with your existing windows server.

 

Please try larger VLAN (say /22) and have a look at the following in the command reference guide for familiarization and implementation: 

 

broadcast-filter-arp

bcmc-optimization

Drop Broadcast and Multicast

Convert Broadcast ARP requests to unicast

Dynamic Multicast Optimization (DMO)

**All of these features will help make your network more efficient.  

 

Another 'quick win' of substantial proportion tends to be in assessing how much Bonjour and NetBios you have on your network (UDP 5353, 137, 139 etc).  IN some networks its commonly 30,40,even 70 percent (a bad day..) of network traffic.   We can block those explicitedly with the PEF policy rules, or you can control the Bonjour protocol with Airgroup.

 

JF

 

You may choose to do a before and after wireshark to determine how much ARP, BroadCast, Multicast, Bonjour etc. you have on your network prior to puttting in controls.   I always like data before and after a change to quantify/objectify the impact. ;)

 

 

eh, as soon as i enable 'broadcast-filter-arp' & 'Drop Broadcast and Multicast'  i'll get calls about appleTV not working.   Somehow i managed to buy APs without enough PEF licenses, so at the moment PEF is disabled.  Hopefully i'll have that resolved in the next few weeks. 

 

I'm not familiar with AirGroup, i'll check it out

If you have ATV's in the network, then AirGroup will be your new Best Friend.

The best of all worlds... the AppleFans get their ATVs to work, and you get to sleep at night knowing your network isn't at 70% utilization because of a dozen iPhones and a half dozen ATVs chattering on to one another all the time ;)

 

Would be key to fix up the PEFNG side of things, i use it in every install, it's key.

 

JF

Yea, big oops on my part.  I'm only 4 PEF licenses short. 

 

Looks like Airgroup relies on ClearPass, we were just about to look into an Aruba BYOD solution, i guess this is another reason to get moving.

 

I guess what i'll have to do is create a /21 network first.  Then run wireshark for a while, then get PEF fixed and finally move into ClearPass.

 

I may have that network built tomorrow, i'll try to keep everyone up to date

Great approach.

 

I'll look for your updates.

Good luck!

JF

just an update of where we are.

 

- Created a /21 network

- Trunked ports on aruba controller

- added new vlan to aruba

- set IP on new vlan

- created a new DHCP scope on the windows server for the /21 network

- changed the unsecure VAP to the new VLAN

- Discovered we did have enough PEF licenses, and have applied them and created some basic policies

 

I'm not experienced in wireshark, but i ran a 10 minute capture and all total the capture summary was less than .5MB.  It was a fairly slow day but that sounds acceptable to me.

 

I'm getting pricing info on ClearPass, something we were wanting to do anyway for 802.1x, so hopefully we'll tackle that soon.

 

This setup is much easier to manage and troubleshoot, i haven't had any complaints yet in regards to the original issue and i may not for a while if it reoccurs.  I'll update here if I have any news on that.

 

So for now everything looks good and I thank everyone for their feedback!

Nicely done.  That's a great amount of work accomplished in a short time.

Within the Wireshark you are looking for 'repeated' or 'constant' traffic.   Then you would want to assess if its 'required' or 'necessary' traffic and groom accordingly.   I concur with your assessment, sounds pretty minimal at this point (where we want it when the system isn't under high loading).

 

Check on the system from time to time with the capture to make sure things are similar to 'normal' and go from there.  Now that you have one VLAN its much easier to work with for sure, including such captures...you don't miss anything nor have to repeat in different VLANs.  win:win.

 

Let's see how end-user (the important stat!) experience goes from here.

JF

Airgroup works fine without Clearpass, Clearpass adds more restrictions and controller on who access what using airplay or airprint

BTW, side note here... the code train of 6.1.3 is up to 6.1.3.10 at present.   That means your code release has 'room for optimization'. (aka it's 13-14 months old, and you can benefit from newer fixes, tweaks and changes made since).

 

Can you upgrade at some time in the near future to gauge how that improves your end-user experience?   My general guideline to clients is to stay within 6 months (so two upgrades per year) of current code releases on all IT gear.  Helps balance stability, with ever evolving feature-sets.

 

JF