802.1x clients transition to MAC auth and back again, every hour?

Userlevel 5

Hi There,

Hoping someone can help me explain the behaviour below and say either if it is normal or a means to correct it.

It seems that every hour a re-authentication of 802.1x is triggered, that process initially introduces a MAC auth that temporarily hits the default catch all rule that we have yet to flip into a deny rule.

After that it then re-authenticates correctly using EAP-TLS until the next hour?



Many thanks in advance

13 replies

Userlevel 3

Is this wired?  If so, do you have reauth settings setup on your ports for every hour?

Userlevel 5

Hi Brian,

Thanks for answering.

Yes, it is wired and both MAC and 802.1x are set to re-auth at 3600 seconds, which I expected would explain the 1 hour, and the cycle it goes for that configuration could be natural? 

It doesn’t seem efficient or possibly correct switching between authentication methods and temporarily , albeit briefly, move to a catchall rule because of it.

The port has both a PC that is .1x capable and a phone that isn’t, hence both.

If that catch all rule was a deny / reject rule I’m not sure what the result would be?


Userlevel 5

Wonder if the answer is in this thread where Zdenek mentions IMHO.

Possibly it is just the end-system going through its steps of re-auth which will include a MAC auth and I’m required to add a rule that will deny it for some reason.

Maybe when the default catch all rule is moved to deny this will help?

Maybe it doesn’t matter?

I imagine there would be a slight drop in service at that time as the policy roles shift?


Userlevel 7

Only one session is applied. The default behavior is that MACauth is not applied if 802.1x is applied.

Are you sure there is a macauth authorization applied during the Dot1x reauth?

Userlevel 5

Hi Zdenek,

Thanks for replying.

Answer is, no, I’m not sure. Just seeing the results as in the End-System events as shown above and wondering:

  1. Is that normal?
  2. Why exhibit that behaviour (if normal), as on surface its seems to suggest a momentary MAC auth and ‘Default NAC Profile’ assignment before moving back to 802.1x?
  3. If not normal, what do I do to fix it?

Many thanks,


Userlevel 7

Hi Martin.

in the ES table you will not see the change = you should not see the change in the switch either.

in the ES history table you should see everything what happens = for auditing and debugging purpose.

example what you can see:

  • the ES table is authenticated and “accept” for 802.1X
  • in the ES history you can see the authentication is rejected or even disconnected for the mac auth session


Userlevel 5

Hi Z,

Ok, let me validate the MAC session is actually rejected or disconnected as that screenshot isn’t showing the whole picture.

Will try and post back shortly.


Userlevel 5

I’ve attached the full detail of the End-System events. 

This same pattern is happening on every 802.1x client by the way, but it does on the surface seem to show it legitimately going through a MAC auth, being accepted via the Default Catch All NAC rule.

Need to back this up I guess, by seeing if this mirrors whats happening on the switch also?

There is no reject being applied for MAC auth devices at this time, the tap hasn’t yet been turned off i.e. the Default Catch All rule is still set with the Default NAC Profile that is permit - would that have anything to do with it? Must the device hit some kind of reject on MAC auth?

Still, can’t explain why a 802.1x client will show a MAC authentication?

All the PC’s have had sleep mode disabled via GPO, so that’s not it?

Worth me opening a case?

Userlevel 5

So decided to watch the netlogin session on the switch.

The cycle in the end-system events seems to be:

  1. Shows authenticated with 802.1x for 1hr
  2. Switches to showing authenticated with MAC for 19 mins
  3. Cycle starts again

I watched the whole process and the below session remained the same throughout:

Slot-1 BHR-East-2ndFlr.2 # show netlogin session mac-address ec:b1:d7:6c:94:f8
Multiple authentication session entries

Port : 1:5 Station address : ec:b1:d7:6c:94:f8
Auth status : success Last attempt : Sat Jun 27 04:16:19 2020
Agent type : dot1x Session applied : true
Server type : radius VLAN-Tunnel-Attr : None
Policy index : 11 Policy name : Allow All Data (active)
Session timeout : 0 Session duration : 2 days, 16:41:25
Idle timeout : 300 Idle time : 0:00:00
Auth-Override : disabled Termination time : Not Terminated

Port : 1:5 Station address : ec:b1:d7:6c:94:f8
Auth status : success Last attempt : Mon Mar 9 10:54:53 2020
Agent type : mac Session applied : false
Server type : radius VLAN-Tunnel-Attr : None
Policy index : 16 Policy name : Enterprise User (active)
Session timeout : 0 Session duration : 112 days, 10:02:51
Idle timeout : 300 Idle time : 0:00:00
Auth-Override : disabled Termination time : Not Terminated

The station address is showing auth status success for both MAC and 802.1x, with 802.1x taking precedence.

The policy name Enterprise User is whats being assigned by the currently permit Default Catch All rule. Soon this will be disabled, so should show up denied.

The end-system events seemed to show up as the following sequence:

  • On the hour the first two lines of MAC(PAP) showed up
  • 19 minutes later the 3rd MAC(PAP) lined showed that includes the IP address
  • Straight after the 3 lines of 802.1x(EAP-TLS) showed up

So it seems to conclude that the actual session for the device on the switch never changes, so begs the question why XMC is showing otherwise?


Userlevel 7

Hi Martin.

you can see the 802.1X takes the precedence = Session applied : true

OneView → Control → End-Systems: In the top table there should be the “actual state” = you see dot1x authentication, IP, ….

If you select the end-system then in the bottom you see end-system events and Health Results = there you see also not active sessions and “audit” of what happens = IP resolution, hostname detection, re-authentications…



Userlevel 5

Thanks Z,

So I think I have translated this to being the fact that netlogin is showing both a 802.1x and MAC auth for the same device, with obviously 802.1x is taking precedence.

The re-auth for both auth types is set to 3600 seconds.

The end-system events is probably showing the audit logs of these going through re-authentication for each authentication type, 1 hour apart, there being a 19 minute difference between the two.

Whats probably happening is the time between a MAC re-auth and then a 802.1x re-auth (19 minutes) is showing up in the aduit as a MAC Auth, but the reality is the switch always remains authenticated using 802.1x.

Do you think that sums it up?



Userlevel 7

Hi Martin.

yes, I agree with your statements/summarization.


Userlevel 5

Great, Thanks Z.