topic Re: Hub behind a dot1x port in Network Access Control

Hub behind a dot1x port

dgaikwad — Tue, 21 Apr 2020 08:32:43 GMT

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
mab
dot1x pae authenticator
dot1x timeout tx-period 10
authentication periodic
authentication timer reauthenticate server
Is this possible and supported scenario?

Re: Hub behind a dot1x port

Sheraz.Salim — Tue, 21 Apr 2020 09:54:22 GMT

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

Re: Hub behind a dot1x port

Colby LeMaire — Tue, 21 Apr 2020 14:52:36 GMT

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.

Re: Hub behind a dot1x port

Colby LeMaire — Tue, 21 Apr 2020 14:56:20 GMT

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.

Re: Hub behind a dot1x port

Sheraz.Salim — Tue, 21 Apr 2020 17:11:19 GMT

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

Re: Hub behind a dot1x port

Colby LeMaire — Tue, 21 Apr 2020 17:29:57 GMT

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

Re: Hub behind a dot1x port

Sheraz.Salim — Tue, 21 Apr 2020 19:47:34 GMT

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.

Re: Hub behind a dot1x port

Colby LeMaire — Tue, 21 Apr 2020 20:10:26 GMT

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.

Re: Hub behind a dot1x port

Sheraz.Salim — Tue, 21 Apr 2020 21:09:30 GMT

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.

Re: Hub behind a dot1x port

Colby LeMaire — Tue, 21 Apr 2020 23:01:54 GMT

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.

Re: Hub behind a dot1x port

howon — Wed, 22 Apr 2020 03:01:33 GMT

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.

Re: Hub behind a dot1x port

Eduardo Ramirez — Tue, 08 Sep 2020 21:27:27 GMT

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.

Re: Hub behind a dot1x port

Colby LeMaire — Wed, 09 Sep 2020 14:06:36 GMT

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.