Maybe I'm missing spmething. The statement to not run MAB and 802.1x exclusively might be something I'm misinterpreting.
In our network, we've been running gazillions of devices, each of which run either MAB or 802.1X authentication. The most common MAB devices are printers and AVAYA VoIP phones. The vast majority or our PCs are running 802.1x. We have both Macs and PCs, so we utilize EAP/TLS.
We've attempted to standardize our access ports, so that there is but one official configuration for an access port. Pre IBNS (say v3.7.4E), we used following for most ports
interface gi1/0/1
decsription generic 802.1x enabled access port
switchport access vlan 10
switchport mode access
switchport voice vlan1 110
authentication event fail action next-method
authentication event server dead action authorize
authentication event server dead action authorize voice
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication order mab dot1x
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
mab
dot1x pae authenticator
dot1x timeout tx-period 10
no mdix auto
spanning-tree portfast
spanning-tree bpduguard enable
ip dhcp snooping limit rate 20
Oftentimes, a phone would be plugged into a switch port, and a PC would be plugged into the phone. Things worked reasonably well, but we had an issue with one particular model of Avaya phone, which would often have issues booting whenever we moved the device. As long as it could get the same IP address, it was fine, but repovision it off of an other switch, and it would never complete it's configuration.
With the introduction of first IBNS when we upgraded to 16.3.7, and later C3PL when we upgraded to 16.6.6, we're finding that these same phones simple will not boot, even when they are not moved.
In playing around with some of the auto-generated policy-maps that were generated in the 16.6.6 upgrade, we started with the following policy map:
policy-map type control subscriber DOT1X-MAB
event session-started match-all
10 class always do-until-failure
10 authenticate using dot1x retries 5 retry-time 0 priority 10
event authentication-failure match-first
10 class DOT1X_NO_RESP do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
20 class MAB_FAILED do-until-failure
10 terminate mab
30 class DOT1X_FAILED do-until-failure
10 terminate dot1x
20 authenticate using mab priority 20
40 class AAA-DOWN do-all
10 authorize
20 activate service-template CRITICAL
30 terminate dot1x
40 terminate mab
50 class always do-until-failure
10 terminate dot1x
20 terminate mab
30 authentication-restart 300
event agent-found match-all
10 class always do-until-failure
10 terminate mab
20 authenticate using dot1x retries 5 retry-time 0 priority 10
This seemed to work well, but we found out otherwise when we upgraded a switch that had a lot of this particular model of phone. A coworker made soem changes and came up with the following policy-map:
policy-map type control subscriber MAB-DOT1X
event session-started match-all
10 class always do-until-failure
10 authenticate using mab priority 10
event authentication-failure match-first
5 class DOT1X_FAILED do-until-failure
10 terminate dot1x
20 authentication-restart 60
10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure
10 activate service-template DEFAULT_CRITICAL_VOICE_TEMPLATE
20 authorize
30 pause reauthentication
20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure
10 pause reauthentication
20 authorize
30 class MAB_FAILED do-until-failure
10 terminate mab
20 authenticate using dot1x retries 2 retry-time 0 priority 20
40 class DOT1X_NO_RESP do-until-failure
10 terminate dot1x
20 authentication-restart 60
60 class always do-until-failure
10 terminate mab
20 terminate dot1x
30 authentication-restart 60
event agent-found match-all
10 class DOT1X_MEDIUM_PRIO do-until-failure
10 authenticate using dot1x retries 2 retry-time 0 priority 20
event aaa-available match-all
10 class IN_CRITICAL_VLAN do-until-failure
10 clear-session
20 class NOT_IN_CRITICAL_VLAN do-until-failure
10 resume reauthentication
event inactivity-timeout match-all
10 class always do-until-failure
10 clear-session
event authentication-success match-all
This policy-map seems to work with some preliminary testing, but I don't see that the priorities are correct, so I've tweaked it a bit:
policy-map type control subscriber MAB-TEST
event session-started match-all
20 class always do-until-failure
10 authenticate using mab priority 20
20 authenticate using dot1x priority 10
event authentication-failure match-first
5 class DOT1X_FAILED do-until-failure
10 terminate dot1x
20 authentication-restart 60
10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure
10 activate service-template DEFAULT_CRITICAL_VOICE_TEMPLATE
20 authorize
30 pause reauthentication
20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure
10 pause reauthentication
20 authorize
30 class MAB_FAILED do-until-failure
10 terminate mab
20 authenticate using dot1x retries 2 retry-time 0 priority 10
40 class DOT1X_NO_RESP do-until-failure
10 terminate dot1x
20 authentication-restart 60
60 class always do-until-failure
10 terminate mab
20 terminate dot1x
30 authentication-restart 60
event agent-found match-all
10 class DOT1X_HIGH_PRIO do-until-failure
10 authenticate using dot1x retries 2 retry-time 0 priority 10
event aaa-available match-all
10 class IN_CRITICAL_VLAN do-until-failure
10 clear-session
20 class NOT_IN_CRITICAL_VLAN do-until-failure
10 resume reauthentication
event inactivity-timeout match-all
10 class always do-until-failure
10 clear-session
event authentication-success match-all
The changes are subtle. I explicitly added dot1x to the class always do-until-failure clause, and elevated the priority of dot1x to be higher (10) than that of mab (20).
I also reduced the priority of mab from 10 to 20 in the class MAB_FAILED do-until-failure clause.
I'm not 100% on either of the policy-maps, but in my mind, the MAB-TEST one seems more complete. Testing will continue. If anybody is a whiz at these newfangled uses of policy-maps, I would appreciate any feedback.
We have six PSNs, arranged in two mode groups, and we're servicing around 25K endpoints. We don't have an issue with load balancing. Looking at an F5 solution, but hardcoding a batch-size of 1800 seems to work for us.
Don't get me started on the docs that state that a batch-size greater than 25 is considered large. The field takes a value in the range of 1-2,147,483,647 (2**32)-1.
In any case, I think ISE performs just fine. My issue is with these particular Avaya handsets, which I'm stuck with for the time being, with no support. My wish is to have one port configuration that handles both MAB devices and 802.1x PCs, without subjecting the PC users to a lengthy delay when powering up/authenticating for the day.
I'm believe my wish is to initiate MAB upon sensing a MAC address, but if the device has a 802.1x supplicant, I want to belay that and immediately start 802.1x processing. It was easy to do before IBNS, and now there is a a more complicated global config, with the benefit of a slightly simpler interface config.
