cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2186
Views
2
Helpful
3
Replies

ACS 5.1 with an aerohive AP issue

burnsidestev
Level 1
Level 1

We are authenticating clients for Aerohive APs on our ACS 5.1 servers.  Currently our logs are getting filled with spam of invalid radius attributes.  I have opened a case with them to see what is sending the request.  The message is "11014 RADIUS packet contains invalid attribute(s)"  Is there anyone to filter that message out of the log in the mean time?  it is causing us to lose all of our logging information from the servers in about 30 minutes.

1 Accepted Solution

Accepted Solutions

jrabinow
Level 7
Level 7

I have seen this error in the following case:

Send a radius request with zero length password to ACS Or, use the IOS config so it sends the same periodically "radius-server host 192.0.2.1 test username test1 idle-time 1"

Happens with zero length password

Not sure if this is your issue

Note I think it is possible to filter out these messages:

Go to:Monitoring Configuration > ... > System Configuration > Collection Filters and define a filter based on of the attributes in the syslog

View solution in original post

3 Replies 3

jrabinow
Level 7
Level 7

I have seen this error in the following case:

Send a radius request with zero length password to ACS Or, use the IOS config so it sends the same periodically "radius-server host 192.0.2.1 test username test1 idle-time 1"

Happens with zero length password

Not sure if this is your issue

Note I think it is possible to filter out these messages:

Go to:Monitoring Configuration > ... > System Configuration > Collection Filters and define a filter based on of the attributes in the syslog

With those filter options, it would remove all information from the APs both good and bad.

The solution ended up being to configure the Aerohive AAA client to use the radius for Authentication only.  Apparently the other entries were accounting information which isnt talking well between the systems right now.  I stll get all passed/failed authentication attempts, which is what I needed.

Nick Lowe
Level 1
Level 1

This issue may be being caused by the presence of an Acct-Terminate-Cause attribute in the Accounting-On and Accounting-Off forms of RADIUS accounting packets that Aerohive's access points send that the RFC specifies is invalid, mandating that it only be present in the Stop form:

https://tools.ietf.org/html/rfc2866#section-5.10

5.10.  Acct-Terminate-Cause

   Description

      This attribute indicates how the session was terminated, and can
      only be present in Accounting-Request records where the Acct-
      Status-Type is set to Stop
.

If so, that issue is resolved in HiveOS 6.6r1.

The Acct-Authentic attribute is also dubious as it is only semantically valid in the context of a session so shouldn't really be present in Accounting-On and Accounting-Off forms of RADIUS accounting packets that pertain to 'global' NAS state:

5.6.  Acct-Authentic

   Description

      This attribute MAY be included in an Accounting-Request to
      indicate how the user was authenticated, whether by RADIUS, the
      NAS itself, or another remote authentication protocol.  Users who
      are delivered service without being authenticated SHOULD NOT
      generate Accounting records.

This has been removed in HiveOS 6.6r1.

This issue may also have been caused by the Acct-Session-Id attribute being missed from the Accounting-On and Accounting-Off forms of RADIUS accounting packets that Aerohive's access points were sending that the RFC mandates be present.

If so, that issue was resolved starting with HiveOS 6.1r3 after I raised the non-compliance of the behaviour via a support case.

See: https://community.aerohive.com/aerohive/topics/radius_accounting_issue_with_330_and_320_series_aps