Top Six Important Cisco WLC settings for ISE integration

[howon]

• Interim RADIUS Accounting Settings under WLANs
• Device Sensor
• RADIUS server timeout
• RADIUS Fallback
• RADIUS Aggressive Failover

Here I am listing top six settings I check for when looking at customer’s WLC settings when integrated with ISE. This document only describes few settings many admins mis-configure on the WLC and does not cover the full configuration. If you are looking for full WLC configuration, please refer to the following document:

AireOS WLC Configuration for ISE

Interim RADIUS Accounting Settings under WLANs

Interim accounting is important piece of message for ISE to maintain session table. If ISE fails to receive interim accounting message for an endpoint session beyond 5 days, ISE will stop maintaining the session. This would mean that ISE thinks an endpoint is no longer connected to the network while the wireless controller shows the endpoint still connected. Also, ISE cannot manage the device via CoA (Change of Authorization) as session is not maintained on ISE. To avoid this, go to WLANs, click on the target WLAN ID > Security > AAA Servers > Check ‘Interim Update’ and set the value to zero. This will ensure the WLC will send accounting updates during roaming.

While you are here, make sure the ‘RADIUS Server Overwrite interface’ is not enabled when WLAN is managed by ISE. This setting essentially sources RADIUS requests from the interface IP, which would be different from the main WLC management IP.

Device Sensor

Utilizing device sensor to forward DHCP & HTTP User agent string provides scalable profiling design for ISE. Go to WLANs, click on the target WLAN ID > Advanced > Radius Client Profiling. Check both DHCP & HTTP Profiling. This will make the WLC send the profiling information to ISE via RADIUS Accounting that is configured for the WLAN.

RADIUS server timeout

The default setting of 2 second may be short for large enterprise. It is recommended to set this value to 5 seconds. This provides enough time for the ISE to authenticate users via backend authentication or lookup group membership and attributes from the sources such as AD, LDAP, or SQL DB. Go to Security > AAA > RADIUS > Authentication > click on the target Server Index > Set ‘Server Timeout’ to 5 seconds. Do this for all ISE nodes.

RADIUS Fallback

With the default settings on the WLC, when the first RADIUS server in the list fails to respond, the WLC marks it as down and never tries it again. Using RADIUS fallback settings, you can ensure the primary PSN is used once the server or network recovers from outage. Go to Security > AAA > RADIUS > Fallback. There are two settings aside from the default setting, which is active and passive. Both settings will provide preemption, but the way it preempts is different. With active, the WLC will continuously send authentication request to the RADIUS server while the server is marked down and will mark the server alive once it receives valid response from the server. With passive, the WLC will wait the interval and unconditionally try the server for authentication and if it receives successful response then it will start using it, while it will make down again for the interval if there are no response from the server.

RADIUS Aggressive Failover

The default setting on the WLC enabled radius aggressive failover, which means WLC will failover to next configured RADIUS when a single endpoint is having issues with authentication. By disabling aggressive failover, the WLC fails over when 3 consecutive endpoints fail to get response from the RADIUS server. You can disable RADIUS aggressive failover by running following command from the CLI:

CLI> config radius aggressive-failover disable

[Arne Bier]

All of the above things are very valuable and nicely explained.

I wanted to challenge the Interim Update of 0 seconds.  I see this best practice in the BRKSEC-3699 (my 'bible').

I would agree with you that this is a good best practice in busy environment where the radius traffic could become bothersome.  However - it creates unpredictable results, because ISE may not see an interim for a long time (if e.g. the Session-Timeout is very long, and also if the user never roams.)  This is a problem because I like to be able to see my Active Endpoints in the ISE Home page.  I have therefore set my interim to 180 seconds - then at least when I look on the ISE dashboard I know how many active users I have.  I have yet to see interim accounting messages present a problem in my deployment.

I would make the update interval longer (300 sec) but I don't know at what stage ISE declares a session as no longer Active.  I can do more tests to find out.

[howon]

Arne, thanks for the feedback. If ISE received a ACCT start for a session, ISE will hold on to it for 5 days or until ACCT stop is received. 5 days is a long time and reauth timer will certainly kick in which renews the 5 day timer. Since 8.0, as long as the interim ACCT box is checked, the roaming event will trigger an interim accounting and recommendation is to set the interval to zero. If you are seeing the sessions being cleared from ISE even when ISE is getting updates with reauth interval, then it is a different issue.

[Arne Bier]

oh right.  Then I must have done something wrong in my lab.  I will set the WLC to a longer Session Timeout, and also interim acct back to 0.  ANd see what happens.  I think I was in a testing phase where I was trying to provoke a certain behaviour in a short space of time.  The thing that concerned me is that ISE thought my sessions were no longer active.  I guess it was receiving acct stop and that is the trigger - longer session timeout should fix that.

Any advice on the idle timeout settings?

[tomnice81]

What does a value of 0 mean in the interim interval box?  Does that mean never send an update, or send updates continuously, or send updates as needed?  I tried finding documentation on it but couldn't find anything in Cisco's configuration guide for version 8.2 except a single sentence saying to make sure the value is in the valid range but then it doesn't even say what the valid range is.

[Arne Bier]

Thomas.  Setting interim to 0 seconds on Cisco WLC > v8.x means the following

• When WLC Client session is still active and client's IP address changes (I have not witnessed this myself) then Interim is sent out.    Or ...
• When WLC Client session is still active and client turns off wifi (WLC won't know/care about this), and then client turns on WiFi again, then the association request for an active WLC session causes an Interim to be sent out (and NOT an acct Start, since this was not the start of a new session, but merely a continuation of an existing session).

I consider it to be an alerting mechanism to the AAA server when something happens to the client inbetween the Acct Start and Stop.   Acct stop is sent when WLC terminates the session due to session timeout or forced removal.

[mitchp75]

Regarding Interim Update settings, we have ISE 2.3 for Guest Wireless and I'm seeing Alarms for  '12929 NAS sends RADIUS accounting update messages too frequently' and it appears to be Interim Updates. We have an Enterprise environment with 200 WLC's and all Guest SSID's are set to 0 for Interim Update however for the top 6 that are throwing this Alarm I have set it to 180 and it appears to lower the noise. We're currently on 8.0.140.0 code and the range for this is 180 to 3600 seconds so my question is I see 0 is best practice however if entering a value is needed what's the second best option with the range being 180-3600 seconds?

Also for the sites I've implemented 180 I'm seeing Authentication Latency lower than previously in the System Summary area, are there any thoughts around this setting affecting client speeds to connect or reconnect to the network faster or slower?  

[howon]

@mitchp75 

That is odd that you are seeing less accounting message with value other than 0. I recall that with certain version of 8.0 one could not set the value as 0 from the GUI so maybe you can validate the value from the CLI via ‘show wlan {ID}’ command and check the actual value to confirm what you are seeing on the GUI is what is set on the WLAN.

The 0 value on 8.x code means that interim accounting message will be sent on IP change, roaming, and for device sensor only. Setting this value anything other than 0 will add interim update every X seconds in addition to what is sent when it is set to 0. I suggest working with TAC to determine the root cause but for the value, the longer period the better, so I suggest 3600 if you are going to enter a value other than 0.

[angelofajardo]

Regarding this subject, I have another question, I added the radio server in SECURITY> AAA> RADIUS> Accounting, should I also add them to each WLAN? Thank you

[howon]

If it is enabled for user auth then no need to select it again under WLAN. However, if you have multiple RADIUS servers and want to control which servers (And order) to use per WLAN, then you can override it using the WLAN specific RADIUS list.

[angelofajardo]

Hi howon,

Thanks for your answer, do you know if the document has restricted access or is no longer available?

[David Cebula]

The How To article is still under restricted access. Can it or an updated version be made available? Thanks. 

[howon]

David, I've corrected the link. Here is link to the AireOS WLC configuration guide:

https://community.cisco.com/t5/security-documents/aireos-wlc-configuration-for-ise/ta-p/3918970

[angelofajardo]

Hi howon,

Thank you very much, very appreciated.

Best regards.

[ajc]

From Cisco ISE BU we were suggested to disable Interim Account in order to help with out high load for our deployment. In fact, I see tons of accounting interim updates messages hitting our ISE deployment so I am wondering if that is correct. Another thing is that no matter if you have that AIU or not happening the ACTIVE SESSIONS on dashboard are not accurate at all and we were also suggested to make an API call using ACTIVELIST in order to get the actual numbers. I guess this topic about interim updates need more clarifications.