Wireless Access

Hi Guys,

I have a problem at hand. A particular project setup has an Andriod IP clock. This IP clock is configured with a static IP address.

However due to Andriod behavior, upon reboot the mac address of the device will change. This will result in 2 mac address with the same IP on the aaa user profile, causing traffic black hole.

The current solution is to clear previous user aaa profile for it to work.

For this case, do you think setting aaa user fast-age will help ?
I have seen other topics talking about this from the perspective of same mac but different IP address.

Your situation is very unusual and I am not sure if fast age will work.  Fast-Age is to deal with a situation where the mac address is the same but there is a different ip address.  Try it and let us know.

We are currently running 6.4.4.11 on our 7240's and M6's.  aaa user fast-age doesn't seem to be working for us to clear the issue.  Our scenario is when a user flips from our guest to our byod ssid.  Their mac is now associated with 2 different IP's and roles in our M6 DMZ controller.  This causes the guest captive portal screen to pop up when they are on the .1x byod ssid.  We have to cli in and aaa user delete mac x:x:x:x:x:x and ask them to connect to the byod ssid again.  Is there another way to fix this issue?

Is your DMZ controller admitting users through an untrusted wired interface?

We send our mobile and guest users into a trusted tunnel in the 7240 and they come out untrusted in the DMZ M6.  The AAA wired profiles associated are .1x authenticated for mobile users and captive portal for guests.

I am not sure aaa user fast-age was designed to deal with that specific situation.  There is a disconnect between client traffic to a controller via an AP and client traffic tunneled to another controller thereafter.

Thanks for the update.  I'll look at other options for us then.  I also mixed up saying M6 instead of M3 but you figured that out.

Do you have mac-auth enabled on the guest ssid and role?

There is a known issue with respect to this which I can upon recently.

The workaround I got back from engineering is as follows,

- either disable the mac-authentication on the AAA-profile 'guest'
OR
- configure the initial-role and the mac-auth derived role (to handle auth success/failure) as 'registration-role' to avoid caching the mac-auth status on the anchor user-entry.

To be honest I didn't have much luck with it and in the end things were changed slightly so that we would never encounter this issue.