As a recap, CDW's standard since IBNS 2.0 came out is to do concurrent MAB/Dot1x. We have 10s of millions of switchports running concurrent MAB/Dot1x without an issue. We still use concurrent MAB/Dot1x on all of our installs today. So I started to ask myself "Why have we never seen a problem, but Cisco BU/TAC says their could be?"
"ISE is dropping Radius-Access requests when Switch sends dot1x and MAB at the same time
live logs will show what looks like multiple failed mab authentications and possibly client suppression."
Thanks second line seems to imply live logs showing failed MAB attempts which might mean MAB rules that use Access-Reject in the result so ISE might get confused and do client suppression.
In our CDW best practices we never issue Access Rejects for MAB results for two reasons:
If the switch port is in Open mode the Access Reject is ignored.
If you are issuing Access Rejects as your bottom MAB rule you are denying ISE the ability profile new devices using NMAP and SNMP data collection. Our default rule is an Access Accept with a limited access DACL to allow ISE PSNs to profile unknown devices.
Is there any chance the fact that we never issue an Access Reject to our MAB results the reason we have never seen issues with concurrent MAB/Dot1x? If so can we get the wording changed on the bug to include a work around of never issuing an Access Reject for MAB results?