@paul , we aren't doing simultaneous dot1x/mab. We are currently doing dot1x-then-mab. We do this because Macs will not do the dot1x unless the switch starts the conversation.
But we would like to do either simultaneous dot1x/mab or maybe mab-then-dot1x because the dot1x timers mess up the devices that are trying to get on and do DHCP. As noted, some clients will give up on DHCP rather quickly!
I think I found a creative solution. We also never send a access-reject on a MAB policy map. I tweaked this event to handle that case...
event authentication-success match-all
! If AUTH with ISE was successful and if it was MAB…
10 class MAB do-until-failure
! Send the EAP-Request/Identity message.
! This should trigger both MAC OSX and Windows 10 devices
! to start the dot1X process.
10 authenticate using dot1x retries 2 retry-time 0 priority 10
With this setup we do the mab-then-dot1x serially, which totally bypasses the bug (behavior defect) that Cisco is referencing.
Probably 85% of our wired devices are BYOD and never do the dot1x, so the load on ISE is pretty low; most devices do the MAB and never end up doing the dot1x. Because we are doing MAB first we bypass all the dot1x retry timers, so devices get on really fast and can get an IP via DHCP.
Does this solve all problems? For devices that do dot1x it is a little bit slower because it does have to complete the MAB first before it can start the dot1x. But again, that's only happening for 15% of our devices. Also, the MAB happens very quickly because there are no back-end Windows AD lookups or anything else that would take dozens of milliseconds.
I can send the full IBNS config to you if you like.
