To prevent the CWP page from loading for existing Guests that have already signed in to SSID. Due to Roaming away and returning the next day or during the day.

[AnonymousM]

Hi,

I believe I have found the answer, however I would like to check if this has any unwanted affects to roaming.

I have a CWP for Guest self-registration over the Open SSID aerohive cloud RADIUS auth. This works well by sending the username and key to guests. 

The difference is the duration of the Usergroup is 6 mths, as these are trusted-non-staff, but not your general public guest, when normally a guest would have a few days duration.

The issue is each time users come back from departing the office during the day etc they are forced to re-enter their username/password over the CWP.

By using the defaults of the SSID for:

Roaming Cache Update Interval 60sec

Roaming Cache ageout 60

I understand this provides a 1hr Total roaming cache (60 sec x 60 = 3,600sec)

Currently I changed to:

Roaming Cache Update Interval 60sec

Roaming Cache ageout 1000 (max allowed)

Understand this provides 16hrs total roaming cache.

If I change the settings to:

Roaming Cache Update Interval 15,550 sec

Roaming Cache ageout 1000 (the max allowed)

I understand this provides a 6mths Total roaming cache (15,550 sec x 1000 = 4,320hrs)

I understand that the CWP setting Web Server Registration Period of 720mins does not change the period when the CWP is forced to be displayed forcing users to re-sign in.

If this is the best way to prevent users from seeing the CWP and re-entering their credentials, Do you think this is cause any unwanted issues with roaming.

thanks,

Jason

[samantha_lynn]

Hi Jason, unfortunately I don't have visibility in to feature requests any more, you'd want to ask your sales engineer to see where that request stands today. If you're unsure who to reach out to for your sales engineer I can email you their contact information, just let me know.

Also, I don't think you'd have any issues with roaming using the settings you've outlined.

[jason_hills]

@Sam Pirok​ Hi Sam,

I was wondering if there was any traction on the FR to increase the Roaming Cache Ageout from 1000 to 10,000 (or similar number).

I try to encourage the Guest SSID duration to 24 hours or max of 7 days, but one customer has asked for 60 days.

They will expect to not have to log back in each time the following day, or after the weekend, (using Cloud RADIUS Self-Registration) so I suspect the min cache to be 63 hours to cover from Fri 5pm to Mon 8am.

Total roaming cache: 120sec x 1000 = 33hrs. Plan to increase Roaming cache update interval to 240sec to achieve 66 hours.

Do you feel increasing from the default 60sec will have any adverse impact to AP roaming?

thanks,

Jason

[James_A]

This example sets the roaming cache update to 3600s, ie one hour https://extremeportal.force.com/ExtrArticleDetail?an=000079785

[samantha_lynn]

Lowering the Roaming Cache Ageout low enough to cause the device to be forgotten directly after registration would likely cause some odd network behavior. For example, this would mean clients who have authenticated and then roamed to a new AP would likely have to re-authenticate each time they roamed because they wouldn't be in the roaming cache any longer. I unfortunately do not have much hands on experience with A3, so a case might be your best route to a solution here.