cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

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.

1270
Views
0
Helpful
1
Replies
paul
Advocate

Concurrent MAB/Dot1x Again

Yes I know I have exhausted this topic on my previous post (https://community.cisco.com/t5/network-access-control/cpl-template-mab-dot1x-simultaneously/td-p/3749539) but I wanted to post again to ask a question of the BU on this topic.

 

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?"

 

If I look a the main bug that documents this issue, https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuy05270/?rfs=iqvred, the verbiage reads like this:

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

 

  1. If the switch port is in Open mode the Access Reject is ignored.
  2. 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?

 

Thanks.

 

1 REPLY 1
Massimo Baschieri
Participant

Probably those in attachement are the kind of issue the bug refers to.

I can see very few of them and it seems that host recover very quickly as you can see in the logs

Create
Recognize Your Peers
Content for Community-Ad

ISE Webinars


Miss a previous ISE webinar?
Never miss one again!

CiscoISE on YouTube