cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2458
Views
2
Helpful
21
Replies

5436 RADIUS packet already in the process

alliasneo1
Level 1
Level 1

Hi, has anyone seen this before or offer any advice?

Running ISE 3.4.068 with no patches installed.

Lots of devices are no longer matching against my polcies. Occassionaly they will match like in the example below but they will then continue in the logs as a fail. when I click on the details icon I get the following message:

Event5436 RADIUS packet already in the process
Failure Reason5436 RADIUS packet already in the process
ResolutionCheck whether the Average RADIUS Request Latency statistic is close to or exceeds the client's RADIUS request timeout. If so, determine whether the latency is caused by a slow external Identity Store or because this instance of ISE is being overloaded. To resolve this, increase the client's RADIUS request timeout, using a faster or additional, external Identity Stores, or reduce the load on this instance of ISE.
Root causeIgnoring this request because it is a duplicate of another packet that is currently being processed

 

alliasneo1_0-1736246882698.png

 

 

21 Replies 21

Hey, thanks for this.

I've spent today updating the nodes and I'm now running 3.0.4.608 Patch 1

 

 

However, I'm still seeing the Misconfigured supplicants and the same error message.

Arne Bier
VIP
VIP

You need to share your interface config. I want to see if this is IBNS 1.0 or 2.0 and if it's 2.0, then we also need to see the policy-map logic.  It sounds to me like the MAB is not successful (status = 'UNAUTHORIZED'), and that causes the NAC logic in the switch to clear the session and start over again.

show derived int x/y/z
show access-session int x/y/z detail

If IBNS 2.0 then also the policy-map (the policy referred to in the interface config)

show policy-map type control subscriber

 

Hi, This is my Interface config on all my switches:

int g1/0/1

switchport access vlan X
switchport mode access
switchport voice vlan X
device-tracking attach-policy IPDT_POLICY
no logging event link-status
authentication control-direction in
authentication event fail action next-method
authentication host-mode multi-auth
authentication open
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate 65535
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout tx-period 10
auto qos trust
spanning-tree portfast

 

This is the policy-map command:

GHC-ISETEST-EJC-SW01#show policy-map type control subscriber
BUILTIN_AUTOCONF_POLICY
event identity-update match-all
10 class always do-until-failure
10 map attribute-to-service table BUILTIN_DEVICE_TO_TEMPLATE
POLICY_Gi1/0/10
event session-started match-all
10 class always do-until-failure
10 authenticate using dot1x retries 2 retry-time 0 priority 10
event authentication-failure match-first
5 class DOT1X_FAILED do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
10 class DOT1X_NO_RESP do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
20 class MAB_FAILED do-until-failure
10 terminate mab
20 authentication-restart 60
40 class DOT1X_TIMEOUT do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
50 class always do-until-failure
10 terminate dot1x
20 terminate mab
30 authentication-restart 60
event agent-found match-all
10 class always do-until-failure
10 terminate mab
20 authenticate using dot1x retries 2 retry-time 0 priority 10
event authentication-success match-all
10 class always do-until-failure
10 activate service-template DEFAULT_LINKSEC_POLICY_SHOULD_SECURE
event violation match-all
10 class always do-until-failure
10 restrict

cklam
Level 1
Level 1

You are hitting a known bug:  https://bst.cisco.com/quickview/bug/CSCwh80062

Thanks for the reply. Yes everything in that bug matches up with what I'm seeing. Doesn't look like there is a fix at this time?

Yes. The latest patch addresses this bug.
Last week I moved this version into production. So far, the bug has not been triggered. Therefore, I think Cisco actually fixed the bug with the patch.

From what I'm seeing on the Cisco downloads page, Version 3.4 patch 1 is the latest version and that is what I am running, is this the one you are referring to?