Wireless Access

I have a couple of customers with large campuses and multiple controller deployments.  When users auth'd through captive portal roam from an AP on the local controller they originally auth'd against to another local controller, they are forced to re-auth via captive portal.  As long as they roam back (it seems before the user-idle timeout expires) all is fine.

In both cases all users are on a single VLAN that spans the controllers, so IP mobility is disabled and should not be required.  And since we are only using a single VLAN, VLAN mobility should not be necessary.

We're theorizing that the 'ha-disc-onassoc' command under the VAP profile may rectify this issue.  Can anyone confirm or deny this?  If this is not the answer does anyone out there have the answer?  Do we need to enable VLAN mobility even though we are using a single VLAN?  I've scoured the BPDGs and the OS Manuals to no avail on this topic.

I ran into this a while ago and I don't think this is something that's supported for Captive Portal.  It even happens with MASTER-Controller redundancy (VRRP).  Maybe an Aruba tech and chime in if this is now available in later releases.  Last release I checked was on 6.0.

-Mike

I've had the exact same issue. It's my understanding that this is because the user table isn't synchronized across locals. So, as soon as you move from one local to another, the new local you are attached to doesn't know who you are.

Another option to fix this is to do IP Mobility. That way when you move over to another local, it tunnels you back to the local where you originated. Of course, I haven't tried this yet; but it should work, in theory. :smileywink:

Thnaks Z,

Yeah, I probably should have mentioned that in this unique case we can't do IP Mobility.  This would work if not for our unique situation.  Without going into too much detail, the users in question land in a VLAN with a seperate physical link to the DMZ.  In turn the controllers have an alternitve route to the internet.  One via the DMZ and the default via the Core.  When IP Mobility is enabled, roamed clients packets when forwarded back to the Home agent are de-encapsualted, and the home agent's route table is used to forward.  The default route for the internet leads to the core rather than the DMZ and these DMZ addressed packets end up dropped by the internal firewall.  :smileysad:

So after further mulling this over I think I can acomplish my desir via an L2 tunnel to the master as long as I am willing to sacrafice some redundancy.  Still, I would like to know or request if there was some way to share Auth'd CP user state across locals.