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.
One of the advantages of using the CPL (IBNS 2.0) style template is you have the option to run MAB and Dot1x simultaneously. This means closed mode is not as detrimental to MAB devices or you can do VLAN moves in open mode without the worry of devices getting an IP on the original VLAN.
I have had Cisco Advanced Services tell some of my customers "We don't recommend doing MAB and Dot1x at the same time because we have seen issue." I like generic descriptions like that. When I had the customer press AS for what issues, the only thing they came back with is that is adds extra load to ISE. Yes there is extra load because all Dot1x sessions will have a MAB authentication, but I have deployments doing 100k+ active authentications doing all CPL switch templates with no issues.
I am just checking to see if others are running MAB and Dot1x simultaneously and what their experience has been. Our standard is to run them simultaneously at our customers and we haven't had a reason to change it.
Solved! Go to Solution.
The devil is in the detail. ISE used to try doing like that and caused issues internally. I quoted this enhancement CSCuy05270 in the other thread.
Sorry for replying to this old topic but i find it interesting since i am currently labing IBNS v2.0 to see if we implement it in our production environment. Specifically for this Concurrent Auth. advantage to prevent DHCP and PXE timeout and possible use of IPv6 in the near future.
I see that you provide positive feedback so far for 3CPL.
Could you please share a best practice SW configuration for this including AAA down scenario?
So far i noticed that even if i see the port authentication with the sh access-session cmd it takes around 20 sec to be able to ping the endpoint.
also noticed that in case Dot1x fails let's say because the endpoint is still not provisioned via PXE the first time, we still have to wait for the (dot1x timeout tx-period x (max-reauth-req) + 1) countdown to consider dot1x failed!
Many thanks in advance
IBNS 2.0 document doesn't do simultaneous MAB/Dot1x. This is our top section of the policy:
event session-started match-all
10 class always do-all
10 authenticate using dot1x priority 10
20 authenticate using mab priority 20
The rest is similar to IBNS 2.0.
could u pls share ISE version & HW/SW on the switches?
meanwhile answering to your original Q (i know it's not quite timely :0) we have problem on the switch side (worth to note we r using ISE 1.4 though):
Paul, you raise a good point regarding the similarity between MAB > 802.1X ordering and concurrent authentication. I have not dug deep in to the details but I suspect this is related to the completion of the MAB authentication request that determines whether the network device is mis-behaving and ignoring one of the requests. In the case of MAB > 802.1X, switch doesn’t process EAPoL-start from the endpoint until the MAB is completed whereas with concurrent authentication, switch processes EAPoL start concurrently with the MAB request and ISE ends up receiving two authentication request in a short period. If ISE was able to respond to MAB request before EAP authentication request reaches ISE then you would not see any issues and I suspect that this is generally what happens as your customers are not having any issues. However, if ISE isn’t able to respond to MAB request before it gets EAP request, this is where the problem in CSCuy05270 comes into play.
As Cisco switches are setup to provide same session ID for both MAB and 802.1X request. When ISE receives multiple authentication request in a short period ISE is designed to drop one of the request as both contains same session ID. This was one of the protection that we put into ISE to limit the impact of mis-behaving network devices in the past. It allowed ISE to scale better even with issues that was present on some of the network devices.
Due to the potential issues, this is not a supported configuration but we do see that there is a good value to support this for our customers. We’ve already raised this with the PM team and hope to resolve this issue in the near future.
The failed attempts in the bug is not due to access-reject in policy, rather it is due to ISE considering the subsequent request as continuation of initial authentication and ISE is sending back reject. This should not be the case as subsequent authentication is 802.1X and not part of initial authentication which is MAB request, and we will work on addressing this in the future. I understand that certain setup is working without issues, but we do see issues in the field thus the defect.