ISE Alarms: Misconfigured Network Device Detected

[Arne Bier]

Hi all

I have a very mildly loaded network - hardly any activity at all but once in a while I see these ISE Alarms that tell me my Cisco WLC is misconfigured.

I don't understand these alarms because I have configured the Cisco WLC according to Cisco best practices (i.e. Craig Hyps BRK-SEC 3699).

When I click on the details I see this below (click on image to see the full screen version)

Not sure what I have misconfigured, since I have set the Interim Updates to 0 seconds.  The WLC is running 8.2.151.0

Any ideas?  I would open a TAC case but I already have 10 open cases with them.

WLC AAA config below

[Craig Hyps · Accepted solution]

Occasional alarms of this type are expected and should not be concerning.  The alarm "misconfigured NAD" is a bit of a misnomer as it gives the indication that a config change will resolve.  Making the changes as per BRKSEC-3699 should greatly reduce the occurrences of these events, but typically will not eliminate.  The alarm is simply stating that two events for same endpoint came in period under the configured threshold.

Craig

[Arne Bier]

What's the point of having alarms that one considers non-concerning?

I don't want to become blasé and end up missing the really important stuff.

I understand that there is a window in which one can set a threshold and perhaps this needs to be revised, or I should disable this alarm.  I can't see a way to change the settings.

At what point do I actually have a Misconfigured Device?  I think the default thresholds are not sensible at all.

Like I said, we're just getting off the ground with a single site deployment and there are fewer than 5 active users.  I get the same Alarm from my lab WLC as well (ain't nothing going on there either).

I can only imagine this Alarm will have lodged itself firmly by the time we start ramping up the traffic.  Or does more traffic have the opposite effect? If so then I am thoroughly confused.

[Craig Hyps]

The alarm is meant to be an indicator of potential cases where the NAD RADIUS timeout is too aggressive, or cases where there is excessive delay on the backend (for example, slow AD or LDAP response) which cause the RADIUS timeout to be exceeded, thus generating a successive RADIUS requests.  If seeing low latency and RADIUS timeout are not too aggressive (typically should be in range of 5-10 sec with 2-3 attempts), then you can disable the alarm if feel it is generating excessive noise.   You could also change the interval for triggering excessive attempts.

Regards,
Craig

[Arne Bier]

Craig, I cannot find the configuration setting for changing these intervals.  Would you know where that is done?

thanks

Arne

[Craig Hyps]

Administration > System > Settings > Protocols > RADIUS...

Ignore repeated accounting updates within _____  seconds.      

     >>> Allow 2 accounting updates in interval before trigger alarm.<<<<

Highlight steps longer than _____ milliseconds.
    >>> Start tracking step times in logs when step exceeds interval <<<<

The first parameter will less likely trigger if shorten interval.

The 2nd parameter is intended to determine source of excessive auth processing or backend delays.  Typically will see ID store lookups be source of this delay indicating a misconfiguration, connectivity issue, or overload of backend server.

I understand goal is not to trigger benign alerts.  It is difficult to say one setting fits all.  High alarms will often be a good indicator of NAD misconfig (short timeouts) or failure to enable client exclusions, or other issue.  We have customers that have requested alarms for every new endpoint that is detected on network.  What constitutes noise vs critical event will vary across customers so we do offer options to enable or disable alarms based on environment and preference.

Craig

[Craig Hyps]

After I awoke this morning, this thread stuck in my head for some reason and I realize that I took you a bit off course in my explanation.  My apologies.  More specifically, I started to talk about impact from RADIUS auth attempts ans backend ID store delays.  RADIUS Accounting also has a timeout setting and that can have a bearing, but backend delays are usually more specific to RADIUS re-transmission events.  When delay is excessive, you will often see increase in retransmits for RADIUS auth requests and short RADIUS auth timer can also induce this condition if too aggressive.

Misconfigured NAD alarm, albeit not named appropriately, is specific to RADIUS Accounting updates.  As noted, RADIUS Accounting timeout may be a contributor, but is more often associated with the NAD config for frequency of updates (not Stops, not Starts, but the interim updates that update the activity or status of session).   This is why we recommend disable the constant updates on WLC by setting Interim Update to enable, but Interval to 0.  This setting on WLC 8.0+ code will only generate interim updates on IP change and not regular updates for packets in/out or bytes in/out.  This info may be useful for call accounting records, but not utilized by ISE.  On wired switches, we recommend the "new-info" option when available as it only sends updates when info changes (not including packet/byte counts) and optionally set an interval of 1-2 days to keep session alive in ISE.

Where things can get off kilter is when NAD config for RADIUS updates is configured (or misconfigured) to send updates too frequently.  This becomes noise to ISE.  Another example includes devices which host other nodes or applications with their own IP address but only one MAC is seen on switchport.  This can result in hundreds of thousands of RADIUS Accounting updates from a single port in a matter of hours or few days.  This is where the Misconfigured NAD alarm is useful to detect and may necessitate increasing the Accounting Update interval to a much higher value.

/Craig