Wireless Access

I'm in the very early stages of troubleshooting some wireless connectivity complaints, and before I dig in much deeper and open up a support case I wanted to see if I could quickly verify what kind of behavior I should be expected.

I have a pair of local controllers set up as an HA pair.  It appears to me that when a user roams from an AP on controller A over to a controller B, no broadcast traffic is explicitly generated by the controllers.  This means that the rest of the upstream network still believes that the client is hanging off of controller A, and sends it there, where it goes off into the void.  This is in contrast to our old Trapeze network, where a broadcast packet of IP protocol 99 was generated whenever a client jumped controllers, keeping the rest of the network in sync.

Should I be expecting any kind of similar traffic, like a gratuitous ARP, from my Aruba controllers?

thanks!

Are the controllers in a mobility domain (L3) or is VLAN mobility (L2) enabled?

You mentioned the controllers are HA.  Do you mean the controllers are configured in an HA group (fast failover) in active/active (dual) mode?

They both share a common VLAN for client connectivity, and if I understand correctly yes, they are in an an active/active HA fast failover group.

If both locals share the same client VLANs then check the VAP in the ap group, and confirm that VLAN Mobility is checked an IP Mobility is unchecked.

Aha!  That sounds like it's the problem, as both of those settings are flipped the wrong way for me.  I'll get this flipped on the next available maintenence window and report back.  Thanks!

So I haven't had a window to make the change in yet, but as I read more into those settings it doesn't sounds to me like they're my issue.  All VLANs are shared across both local controllers, and all of my clients are always getting dropped into the same VLANs, so my reading of VLAN mobility doesn't sound like it should be necessary.  As for IP mobility, while I do have it enabled on some of my VAPs, all of the IP mobility commands say that it's globally disabled.

Does this still sound like something I should focus on?

thanks!

Nope - I have my RADIUS servers returning a VLAN name that maps back to a single VLAN.  Here are what I believe are the relevant config fragments:

vlan-name Wireless
vlan Wireless 1168

wlan virtual-ap "WPI-Wireless-vap_prof"
   aaa-profile "WPI-Wireless-aaa_prof"
   ssid-profile "WPI-Wireless-ssid_prof"
   vlan wireless
   band-steering
   broadcast-filter all
   auth-failure-blacklist-time 60
   blacklist-time 60
!

---

@fsweetser wrote:

I'm in the very early stages of troubleshooting some wireless connectivity complaints, and before I dig in much deeper and open up a support case I wanted to see if I could quickly verify what kind of behavior I should be expected.

 

I have a pair of local controllers set up as an HA pair.  It appears to me that when a user roams from an AP on controller A over to a controller B, no broadcast traffic is explicitly generated by the controllers.  This means that the rest of the upstream network still believes that the client is hanging off of controller A, and sends it there, where it goes off into the void.  This is in contrast to our old Trapeze network, where a broadcast packet of IP protocol 99 was generated whenever a client jumped controllers, keeping the rest of the network in sync.

 

Should I be expecting any kind of similar traffic, like a gratuitous ARP, from my Aruba controllers?

thanks!

---

Did you do a test like your client pinging the default gateway while it is roaming, or another wired device pinging your client while it is roaming from controller to controller to observe application performance?

IP Mobility (layer 3 mobilty) is not in effect, unless you turn it on globally and it is only used when a controller does not have a layer 2 VLAN that the client's initial controller had.  If it is not configured, it is not active, even when enabled at the Virtual AP level.

 Enabling VLAN mobility allows to target controller to look into its bridge table to assign the VLAN of a client that is roaming to it.  If your target controller had a VLAN pool in the VAP and you have Vlan mobility enabled, the controller will assign the VLAN based on the VLAN observed in the target controller's bridge table, instead of a VLAN pool.

Again, you should do an actual test where your client is pinging a wired device when it is roaming to determine if you have an issue or not.  Just the client roaming and sending traffic should update the bridge table, due to traffic leaving the controller.

I haven't been able to do as much testing as I'd like yet, but so far I have several reports from technical users as well as a couple of my engineers that they have connectivity issues that strongly correlate with roaming between controllers.  I have a single VLAN shared between both local controllers that is used for all of my clients, so my understanding is that I shouldn't need any mobility features enabled.

Well,

You are the admin and you would have more information than they do.  How would a user know if he is roaming between controllers or not?  They would not be privvy to that information, would they?  Do they know what BSS is on one controller and what BSS is on another?  Only you would know that,  They don't even change ip addresses, so they don't even have that.  Do they have access to ARP tables?  It is difficult even for administrators to know when a client is moving between controllers because that information is typically a lagging indicator and unless you are really looking for it, by stradding the commandlines of both controllers, it is almost not possible to detect in realtime.

I submit that you do your own testing to get to the bottom of this and gather your own information.  It could be and many times is a genuine RF issue.

By the way, if you have ClientMatch enabled (by default it is), band steering is not active.

Oh, I've been in this game for far too long to take a random user's diagnosis at face value ;-)  Several of the reports come directly from my network architect, who's not a wireless guy, but he knows enough to correlate his roaming behavior with AP controller associations, and identify a disparity between the upstream infrastructure's FDB and ARP tables, and the controller he's associated on.

I have an open case with TAC, but it's still in the early back and forth stages while I fully explain my issue to them.  Hence my original question - given no IP or VLAN mobility, should I expect the controllers to take any action when a client roams to proactively update upstream FDB and ARP tables?  If so, that gives me a mechanism to begin troubleshooting, and if not, that means I have to find a way to take that into account in my overal architecture.

thanks!

The answer would be yes.  When a client roams to a new controller it should update the switching table if the client vlan is Layer 2 connected between a controller and switch.

Please let us know what you find.

@cjoseph wrote:

The answer would be yes.  When a client roams to a new controller it should update the switching table if the client vlan is Layer 2 connected between a controller and switch.

 

Please let us know what you find.

---

Could you please clarify, which "switching table" are you referring to?  I understand that the pair of Aruba controllers will update each other's switching tables, but from what I was told by Aruba TAC nothing special is done to update the upstream wired interfaces.

In my configuration, I have my two locals that are in an HA pair each uplinked to separate devices.  When a client roams, it typically is only sending unicast traffic, since it doesn't need to restart DHCP from scratch and already has an ARP entry for the default gateway.  This unicast traffic updates the FDB on the uplink switch for the new controller, but the uplink switch for the old controller will still point to the old controller, along with any other devices that aren't on the L2 path between the new controller and the default gateway.  Combine this with asymetric routing (which I have as normal in my network) and I end up with strange, partial outages for clients that roam until they happen to send out some broadcast traffic and update the rest of the L2 domain.

This is contrast to the Juniper/Trapeze wireless I'm used to.  When a client roamed on those controllers, the controller itself would spoof a packet of IP protocol 99, destined to ethernet broadcast, and a source address of the client ethernet address.  This would fully update all FDBs on all switches hosting that VLAN, preventing the problem.  Since (according to Aruba TAC) the Aruba gear doesn't have this behavior, I'm just going to have to find a way to accomodate it on my upstream network.

To be specific, unicast traffic from the client after it roams should update the switching table of the ethernet switch that the controller is connected to.  Nothing else special is done.  If both controllers are connected to the same switch, the swich should see unicast traffic from that client and update its switching table.  

If your controllers are connected to two different switches, the ARP table on the client should have the same default gateway and should be able to send traffic to the same default gateway that it did in the first place.  If the default gateway is physically located on a different switch, the first switch should know the mac of the default gateway and send the client traffic to that destination switch and along the way, the source mac of the client should update the switching table.

You would have to speak to the person who designed your network to understand if asymetric routing affects traffic on the same subnet, but coming out of a different physical port.  it should not, because your issue exists at the switching layer and not the routing layer.

The only thing that I can think of is if there is some ARP spoofing mechnism keeping a client from roaming from one port to another, but that is just a guess.

The "fdb-update-on-assoc" parameter on the Virtual AP controls whether the forwarding database is updated upon client association.  For most clients this is not necessary, but for silent clients that generate little to no traffic like headless devices it will gratuitously update the fdb database:  http://www.arubanetworks.com/techdocs/ArubaOS_6.4.4.x_WebHelp/Web_Help_Index.htm#ArubaFrameStyles/1CommandList/wlan_virtual_ap.htm?Highlight=fdb-update-on-assoc

For WLAN infrastructures where client traffic is placed directly onto the physical network from the AP updating the forwarding database is important and necessary.  For infrastructures where the traffic is tunneled, the switchport does not change often, and this is not needed.

Perfect!  That's exactly what I need, thanks very much.