This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
Currently running 4 ACS 5.1 servers to load balance our 802.1x requests, but am getting an error message which is a bit unhelpful in terms of details.
The error message is
11051 RADIUS packet contains invalid state attribute
and only seems to occur on one port port on one particular switch....not quite sure what is causing this for this port as all the other ports on the same switch are not having any issues.
The troubleshooting says
The state attribute in the RADIUS packet did not match any active session.
Do the the following: Check the network device or AAA Client for hardware problems or known RADIUS compatibility issues ; Check the network that connects the device to ACS for hardware problems.
The network device is set up the sames as at least 50 other switches in ACS.
The switch port is nominally designated as being for a client PC.
Anyone have any ideas what is causing this error.
I'm still seeing these 11051 errors on one of my secondaries ... seems similar to what grnetcomss was seeing. I corrected the ntp and timezone issues, but one ACS appliance does not appear to be doing any successful authentications and only logging the 11051 errors in the RADIUS authentication log. Distributed System Management says its OK and replication status is "UPDATED". I tried reloading it, but made no difference. Has anyone else managed to get to the bottom of this??
Finally think I've sorted it: The secondary in question had become disconnected from AD. I had to unregister it from the primary, clear the AD config, reconnect it to AD, then factory default it (it maintains it's IP config so it's OK), re-enter the license, then re-associate it with the primary. Now it's all green :-).
I also had this problem ... Found that a couple of the secondaries had wrong timezone and no NTP set. From the command line:
clock timezone Australia/Brisbane
You then need to restart ACS.
It's all good now ... Thanks for pointing me in the right direction :-)
Old thread but I'm going to go ahead and provide an update on what solved this issue for me in hopes that it will help someone out. I had a case on this issue with TAC for 4 days with no resolution. It turns out that the "server" service on one of my Windows Domain Controllers (2008 R2) was stopped. This server held the FSMO role of "PDC Emulator" so therefore authentications coming from my ACS server to AD failed. This was a difficult issue to find but none the less that is what solved it for me.