Showing results for 
Search instead for 
Did you mean: 

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.


Hub behind a dot1x port

Hi Experts,
Is it possible to connect a hub to dot1x enable port and connect the endpoints to the hub and have them authenticate separately and then run posture for each of those endpoints individually?
I have the following commands set on the interface:
authentication violation restrict
authentication event server dead action authorize
authentication event server dead action authorize voice
authentication host-mode multi-auth
authentication port-control auto
authentication order dot1x mab
authentication priority dot1x mab
authentication event fail action next-method
authentication event server alive action reinitialize
dot1x pae authenticator
dot1x timeout tx-period 10
authentication periodic
authentication timer reauthenticate server
Is this possible and supported scenario?

VIP Advocate

In your config you mentioned

authentication order dot1x mab
authentication priority dot1x mab


change this to below command and good to go

authentication order mab dot1x
authentication priority dot1x mab

please do not forget to rate.

The order of authentication does not matter when wanting to authenticate multiple hosts on the same port.  The order would only be an issue if the tx-timeout were set to the default of 30 seconds and there were devices that were giving up on DHCP requests.  But the poster's configuration shows the tx-timeout set to 10 seconds which is a best practice and works just fine for 99% of deployments.  Just wanted to clarify so as to not confuse anyone.

With all due respect @Colby LeMaire authentication does matter when on multi host on same port.

please do not forget to rate.

@Sheraz.Salimplease help me understand how the order of authentication matters when a port is configured for either multi-auth or multi-host.

here link describe it in detail. according to cisco best practice order mab dot1x is preferred compare to order dot1x mab. that why in my first post i mentioned order should be mab dot1x and priority must be dot1x mab. 

I had encounter issue in past when doing a multi-auth on a single port where the other end was hub. having a config order mab dot1x were more beneficial compare to order dot1x mab. having said that, in my case we need to provision a client first therefore having a order mab dot1x.



please do not forget to rate.

I understand Flexible Authentication.  But it does not have anything to do with the original question.  The order and/or priority would not prevent multiple devices behind a hub from authenticating and posturing correctly.  As I said previously, I just wanted to clear that up for anyone that reads this thread.

Regarding the order/priority, I disagree that an order of "mab dot1x" and priority of "dot1x mab" is preferred.  Because when you do mab before dot1x, the switch will send the mab request immediately to ISE and then have to stop mab and start dot1x when it detects a supplicant (i.e. EAPOL frames).  The problem of that is that ISE receives more requests than necessary and the Radius Live Logs can fill up with bogus errors/failures such as "5400:  Endpoint abandoned EAP session and started new".  The better option is to do dot1x first and adjust your tx-timeout to 10 seconds with 2 retries (total of 30 seconds).  That works great in 99.9% of deployments.  I have only had one client over the years that needed a tx-timeout of 7 seconds because of custom equipment that wasn't waiting long enough for DHCP.

cisco recommendation is not to tune the values of tx-timeout unless you have a good understanding. I remember i read in Aaron Woland book where he mentioned not to change the tx values.  

please do not forget to rate.

You should almost always change the tx-timeout value to 10.  The default is 30 seconds with 2 retries.  Meaning that it could be a total of 90 seconds before the switch falls back to MAB.  That is too long and most devices give up trying DHCP.  Dropping it to 10 seconds gives you a maximum of 30 seconds before falling back to MAB.  Works great in 99.9% of deployments.  I was in Cisco Advanced Services for over 12 years doing NAC deployments (NAC Framework) since 2004 and deploying ISE from when it first came out (v1.0.4).  We always changed the tx-timeout to 10.

Colby LeMaire
VIP Collaborator

Your configuration is correct for authenticating multiple devices on the same port (host-mode multi-auth).  So yes, the switch and ISE will treat each unique MAC address as a separate device and each will have to authenticate and posture separately.

Hi Colby.


If my NAC deployment was 70% mab with only 30% dot1x, would you still advocate for a Dot1x then mab order first (with the timeouts like you mention?).  My concern with that order is with dealing with a bunch of dumb IoT devices that may be sensitive to the delay of waiting the 30+ seconds. 

Most NAC deployments have more MAB devices than 802.1x.  Consider IP phones, printers, access points, cameras, badge readers, etc.  In my experience, a lot of customers get 802.1x deployed for their Windows workstations and stop there.  A few will continue to push forward with 802.1x on IP phones and access points, but that still leaves a lot of MAB devices.  My point is that the recommendation has been a best practice for many years and only recently did it start to change to a timeout of 7 seconds with 3 retries (total of 28 seconds).  I have only had one customer environment where we had to reduce the timer down to 7 seconds with 2 retries (total of 21 seconds) because of a military piece of equipment that was too sensitive to the DHCP delay.  Other than that, I have seen no issues.

For me, it is just a preference.  I don't like the Live Logs being cluttered with unnecessary MAB transactions.  It makes it harder to troubleshoot and adds unnecessary load on ISE.  I would start with the recommendation and adjust if necessary.

Cisco Employee

Yes, configuration looks OK. It should work provided that you are using a real hub not a switch. Problem is that true hubs are hard to find these days.

Content for Community-Ad