CPL Template MAB/Dot1x Simultaneously

[paul]

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.

[hslai]

ISE is expecting the auth is either MAB or DOT1X at a time but not currently supporting concurrent MAB + DOT1X.

[paul]

Hsing,



ISE shouldn't care either way or honestly have knowledge of what is happening on the switch side. ISE is processing authentications. It is up to the switch config to determine how to treat both authentications. If you look at one of the first CPL publications out there:



https://cisco-marketing.hosted.jivesoftware.com/servlet/JiveServlet/previewBody/68174-102-1-125094/How-To_13_Universal_3850_Wired_CPL_Config.pdf



Hosuk is doing MAB and Dot1x simultaneously. We have many customers doing this without issue.

[paul]

Also in the same document Hosuk lays out the justification quite well:



"There are many benefits to the new syntax, but most notably is the fact that 802.1x and MAB can run simultaneously without having to sequence the two distinctive authentication process whereby 802.1X authentication has to be failed for MAB to start and secondly use of service templates to control preconfigured ACL on the interface in the event of RADIUS not being available. With the legacy platforms, sequencing of 802.1X and MAB resulted in certain MAB endpoints not being able to get IP address in timely manner. By processing 802.1X and MAB simultaneously, the endpoint can get DHCP assigned IP address in timely manner."



This feature is one of the main driving features of CPL in our minds. Yes it adds more load in ISE, but honestly MAB authentications shouldn't be placing much load on ISE in the first place.

[hslai]

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.

[paul]

Hsing,



We have probably between 500k and 1 million ports running CPL with MAB and Dot1x simultaneously. I haven't seen the issue you described in this enhancement. MAB happens first because it takes longer for the switch to start the Dot1x process with the client.

[bern81]

Hi Paul,

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!

Please advise

Many thanks in advance

[paul]

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. 

[andy!doesnt!like!uucp]

Hello Paul

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):

https://community.cisco.com/t5/policy-and-access/ibns-2-0-fuji-16-9-3-mab-is-being-removed-from-inf-template-amp/m-p/3848916#M73050

[hslai · Accepted solution]

Let me repeat again. This is NOT currently supported by any shipping ISE releases.

Thus, if it ever causes any issue, you will have to reconfigure the switches to disable simultaneous MAB/DOT1X.

[paul]

Hsing,



We can take this offline as well. We have probably ½ million switch ports running with no issues with simultaneous MAB/Dot1x. If the BU is now going to say this is not supported, even though the original CPL documents put out by Cisco referenced this as one of the benefits of the CPL template, then the BU also needs to say "order mab dot1x" is no longer supported on the legacy template even though 1000s of customers probably have deployed that order since it has been a supported setup since ISE 1.0.



"order mab dot1x" behaves almost identical to simultaneous MAB/Dot1x doesn't it? As soon as the MAC address is learned by the switch the switch will run a MAB transaction. When the attaching device sends out an EAPOL Start a Dot1x transaction will be run as well and the switch will prefer the Dot1x transaction because of "priority dot1x mab". So in ISE you see a MAB transaction followed by a Dot1x transaction which is the same thing you see when doing simultaneous MAB/Dot1x. ISE and the switch have had no problems keeping that logic separate for years. Why is this an issue now?

[howon]

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.

[paul]

The bug references suppression and multiple failed attempts. If your wired setup is built correctly (in my opinion) you should never be doing an Access-Reject in a wired MAB result. That is probably why we have never seen an issue with this. None of our installs since almost the start of ISE have ever done an Access-Reject on a MAB result. I can least multiple reasons why you shouldn't do a reject for a MAB result but that is for a different conversation.



Can we at least get the BU to state if you aren't doing MAB Access-Rejects then simultaneous MAB/Dot1x is supported? Like I said we have ½ million ports (probably more) doing this with our best practice config and no issues.

[howon]

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.

[paul]

Ahh that makes sense. Just to give you some numbers to think about. I took a look at my largest deployment running simultaneous MAB/Dot1x. We are at 133,000 active connections and over 800k endpoints in our database. Our policy sets are properly built out so that each use case has its own policy set (wired MAB, wired Dot1x, each SSID, each VPN group etc.). Wired MAB is properly placed near the top of the policy set order.



If I look at our MAB transactions they are finishing between 40-60 ms. The Dot1x authentication is happening 150-300 ms after the MAB transaction. My MAB transactions would have to slow down 3-5 times before I even start to approach my Dot1x authentication start times. In the customers you have seen this issue with have you validate they have properly build policy sets?