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.
I am having trouble making something work.
I want to apply a service-template only if mab and dot1x both fail.
I am trying to use concurrent authentication.
I used a class that is listed as an example in the
This example is listed under the command match result-type
class-map type subscriber control match-all ALL-FAILED no-match result-type method dot1x none no-match result-type method dot1x success no-match result-type method mab none no-match result-type method mab success no-match result-type method webauth none no-match result-type method webauth success
Here is a debug after mab fails and followed by dot1x failed.
Nov 29 15:49:19: %DOT1X-5-FAIL: Authentication failed for client (001b.78f6.0aed) on Interface Gi1/0/1 AuditSessionID 0A3D011E0000006886626E6C
Nov 29 15:49:19: [PRE:RULE:EVENT:2F000038] Executing policy-map type control subscriber User_Test
Nov 29 15:49:19: [PRE:RULE:EVENT:2F000038] event (id:1 name:authentication-failure) match-first
Nov 29 15:49:19: [PRE:RULE:EVENT:2F000038] class ALL-FAILED do-until-failure policy instance 0x990200E4
Nov 29 15:49:19: [PRE:RULE:EVENT:2F000038] Evaluate: class-map type control match-all subscriber ALL-FAILED
Nov 29 15:49:19: [PRE:RULE:EVENT:2F000038] no-match result-type method dot1x none :failure
I expect that the method would be dot1x and the result type would be authoritative. So why do I not get a success on the no-match
Hope somebody can shed some light on this.
Please start with ISE Secure Wired Access Prescriptive Deployment Guide
match-all means all needing to be matched, I believe.
That is correct. The debug should evaluate each statement in the class.
no-match ... none should result in success. no-match ... success should also be success. For both mab and dot1x. I don't have web-auth in my actual class map. So ALL-FAILED needs to match for my policy to work.
I am no expert on IBNS 2.0 but using negative against negative would be problematic and leads to un-expected results. Please use the guide I pointed out and see how things work.
How is match-all against four no-match statements a double negative.
The example is listed in the command reference. I will review the guide again. Am currently on a mobile, so that will have to be later.
no-match result-type method dot1x none
Somehow it failed for this so it does not continue. I have no idea what it means exactly but
I guest no-match a no-result is negative against negative. hehe.
ISE Secure Wired Access Prescriptive Deployment Guide gives working examples. If any specific not working, please let mnagired know as he took it over from hariholla as the owner of this guide.
I looked through the guide, there isn't any reference to concurrent authentication nor to match/no-match result-type none.
One need to ensure that both mab and dot1x have completed. In other words the result-type is not success and not none.
I expect that if the result type is none, then the method is either never been started, is running, or has been terminated. There might be a result-type other than none after being terminated, but should be reset back to none if started again.
I believe this to be a bug. I have a case open with no feedback as of yet.
Please do not use concurrent DOT1X and MAB with ISE. At present, ISE is expecting the endpoint session either in DOT1X or in MAB at one time or another but not at the same time.
Unfortunately that is where we stand for now. See CSCuy05270
It would work if DOT1X and MAB requests are sent to two distinct ISE deployments.
Sorry to comment on this discussion since it is already marked as solved.
But isn't one of the buzzing marketing for using IBNS v2.0 is because of the concurrent Flexauth that it reduces time for endpoint to join the network compared to sequential Flexauth?
To be honest i find this IBNS v2.0 complex and not offering so much advantage over the IBNS v1.0 which is more clear.
The bug you posted was referencing failed MAB attempts. As I have posted in other posts we never have a failed MAB condition in our setups. We probably have 500k+ switch ports across our customers running simultaneous MAB/Dot1x with IBNS 2.0. Has the BU done any research to isolate the cause for that bug to see if the issue is really around the MAB failures?
In our setups MAB is successful in all cases immediately then Dot1x follows in a few second later. The switch properly implements the priority for Dot1x and moves the client to Dot1x. Works perfectly.