This article describes an intermittent authentication issue affecting endpoints authenticated through MAC-RADIUS on an interface configured for 802.1X. The affected device periodically transition from the "Authenticated" state to "Connecting", causing a temporary loss of network connectivity before successfully re-authenticating. 

The issue correlates MAC address aging, EAPOL activity, and the 802.1X authentication state machine to explain why the endpoint becomes stuck in the "Connecting" state. It also outlines the root cause, packet and traceoptions analysis, and the recommended configuration workarounds to prevent unnecessary 802.1X re-authentication attempts and maintain stable MAC-RADIUS authentication sessions.

• The device transitions from "Authenticated" to "Connecting" state approximately every 8–10 minutes. 
• During each cycle, the endpoint remains in the "Connecting" state for about two minutes before successfully re‑authenticating. 
• This behavior occurs when the interface is configured with dot1x. When dot1x is removed, the interface remains stable.
• The device authenticates via MAC‑RADIUS.

No clear triggers found, and the device transitions into "Connecting" state:

root@user> show dot1x interface ge-0/0/1    
802.1X Information:
Interface     Role           State           MAC address          User
ge-0/0/1.0    Authenticator  Connecting      aa:bb:cc:dd:ee:a1    No User      

After approximately 2 minutes, the device successfully re‑authenticated and returned to the "Authenticated" state:

root@user> show dot1x interface ge-0/0/1    
802.1X Information:
Interface     Role           State           MAC address          User
ge-0/0/1.0    Authenticator  Authenticated   aa:bb:cc:dd:ee:a1    00505685660f     

On this scenario, we have an end point connected to ge-0/0/1 which authenticates via MAC‑RADIUS:
 
root@user> show dot1x interface ge-0/0/1 detail 
ge-0/0/1.0
  Role: Authenticator
  Administrative state: Auto
  Supplicant mode: Multiple
  Number of retries: 2
  Quiet period: 60 seconds
  Transmit period: 30 seconds
  Mac Radius: Enabled
  Mac Radius Restrict: Disabled
  Mac Radius Authentication Protocol: EAP-MD5
  Reauthentication: Enabled
  Configured Reauthentication interval: 65535 seconds
  Supplicant timeout: 3 seconds
  Server timeout: 30 seconds
  Maximum EAPOL requests: 3
  Guest VLAN member: VLAN10
  Number of connected supplicants: 1
    Supplicant: 00505685660f, aa:bb:cc:dd:ee:a1
      Operational state: Authenticated
      Backend Authentication state: Idle
      Authentication method: Mac Radius   
      Authenticated VLAN: VLAN10
      Session Reauth interval: 65535 seconds
      Reauthentication due in 65490 seconds
      Session Accounting Interim  Interval: 720 seconds
      Accounting Update  due in 675 seconds
      Eapol-Block: Not In Effect
      Domain: Data

MAC‑RADIUS means the device was authenticated using MAC Authentication Bypass (MAB) rather than standard 802.1X credentials. Just a quick parenthesis on how MAC‑RADIUS works.

1. A device connects to the switch port.
2. The switch attempts 802.1X authentication.
3. If the device doesn't support 802.1X (common for IoT devices, printers, cameras, TVs, badge readers, etc.), the switch uses the device's MAC address as the identity.
4. The switch sends the MAC address to the RADIUS server.
5. The RADIUS server checks whether that MAC address is authorized and returns the appropriate VLAN and access policy.
    

On this scenario, the interface suddenly transitions from "Authenticated" to "Connecting" state, and then re‑authenticates after approximately 2 minutes. When tracking one of the events, we can see that at 17:39:06 the device was disconnected, and at 17:41:12 it re‑authenticated. This resulted in a total of 2 minutes and 6 seconds where the interface remained in the "Connecting" state. The following logs illustrate this behavior:
 
Jun 16 17:39:06  user dot1xd[5013]: DOT1XD_USR_SESSION_DISCONNECTED: Dot1x User 00505685660f session with MacAddress aa:bb:cc:dd:ee:a1 interface ge-0/0/1.0 vlan (null) disconnected
Jun 16 17:39:06  user dot1xd[5013]: DOT1XD_AUTH_SESSION_DELETED: Dot1x User No User session with MacAddress aa:bb:cc:dd:ee:a1 interface ge-0/0/1.0 vlan (null) deleted
Jun 16 17:41:12  user dot1xd[5013]: DOT1XD_USR_AUTHENTICATED: Custom_log MAC-RADIUS User 00505685660f logged in MacAddress aa:bb:cc:dd:ee:a1 interface ge-0/0/1.0 vlan VLAN10
 
The MAC table aging timer is configured to the default value of 300 seconds. We also narrowed down the timeframe when the device aged out of the MAC table. This event took place at 17:37:02—two minutes before the dot1x user session was disconnected, as shown in the logs above:
 
root@user> show ethernet-switching mac-learning-log | match aa:bb:cc:dd:ee:a1    
Tue Jun 16 17:37:02 2026 vlan_name VLAN10 mac aa:bb:cc:dd:ee:a1 was deleted from ge-0/0/1.0 with flags: 0x1000

When narrowing this down using traceoptions for dot1x and correlating with the MAC aging time, we can see that at 17:37:03—one second after the MAC address aged out—the MAC learning request for aa:bb:cc:dd:ee:a1 was generated:

Jun 16 17:37:03.465618 l2ald: received mac learn req for mac: aa:bb:cc:dd:ee:a1 vlan:0 bd_idx:20
Jun 16 17:37:03.465740 l2d query for mac aa:bb:cc:dd:ee:a1 ifl ge-0/0/1.0 vlan 96 supp-mode 2 is_trunk_configured 0
Jun 16 17:37:03.465804 pnac_ng_is_native_ifbd_marked_for_deletion:296 native vlan of port 780 NOT-MARKED for deletion

 
At this point, we can see that the authenticated session for MAC address aa:bb:cc:dd:ee:a1 was still present in the database:
 
Jun 16 17:37:03.465846 AuthSession node with Mac: aabbccdd-eea1 in session DB found !!!
Jun 16 17:37:03.465885 Don't learn mac when eap.start received
Jun 16 17:37:03.465927 AuthSession node with Mac: aabbccdd-eea1 in session DB found !!!
Jun 16 17:37:03.465968 pnac_process_l2ng_mac_learn_query: get_mac_status returned AUTH_PENDING
Jun 16 17:37:03.466000 pnac_l2ald_update_auth_pend update the cache pending db for mac (aa:bb:cc:dd:ee:a1)
Jun 16 17:37:03.466031 pnac_l2ald_cache_auth_pend cache request for mac aa:bb:cc:dd:ee:a1

Immediately afterward, we observed an EAPOL frame received on the port—specifically an EAPOL‑Start message. This event transitions the device session back into the "Connecting" state:
 

Jun 16 17:37:03.802900 Invoking state machine for frame received on interface ge-0/0/1 
Jun 16 17:37:03.802924  Received an EAPOL Frame... >>> Interfaces received an EAPOL frame.
Jun 16 17:37:03.802962  Frame is targetted to this machine...
Jun 16 17:37:03.803005 pnac_ng_is_native_ifbd_marked_for_deletion:296 native vlan of port 780 NOT-MARKED for deletion
Jun 16 17:37:03.803031 EAPOL Frame Received on Port: 780 supp-mode 2 EapType 1
Jun 16 17:37:03.803080 AuthSession node with Mac: aabbccdd-eea1 in session DB found !!!
Jun 16 17:37:03.803121 EapolBlock 0x0 EapolType 1 FlexCpCfg 0   >>> EapType 1 is typically EAPOL-Start.
Jun 16 17:37:03.803144 ReAuthenticate 0 AuthPaeState 3 authmode 1
Jun 16 17:37:03.803167  AuthHandleInEapFrame: Received MAC based Eap Frame
Jun 16 17:37:03.803209 AuthSession node with Mac: aabbccdd-eea1 in session DB found !!!
Jun 16 17:37:03.803248 pnac_ng_native_vid:243 native vlan 96 of port 780
Jun 16 17:37:03.803271  Port: 780 obtained Native Vid: 96
Jun 16 17:37:03.803306  Session Node for MAC: -aabbccdd-eea1- Port: 780 obtained ... 
Jun 16 17:37:03.803344  ASM Called with Event: EAPSTART_RCVD, and State: Connecting >>> The Authentication State Machine (ASM) received an EAPOL-Start event and the session transitions into the Connecting state and begins authentication.

The device continues attempting authentication via EAPOL:

 
Jun 16 17:37:03.803653  ASM moved to state: CONNECTING !!
Jun 16 17:37:03.803696 Set authentication mode as DOT1X when EAP frame is received for session aa:bb:cc:dd:ee:a1
Jun 16 17:37:03.803741  TMR: Transmit Timer Started for port:780, Duration: 30 !! >>> The switch starts the Transmit Period timer.
Jun 16 17:37:03.803793 TMR: Timer 7 is started for port 780 duration 30
Jun 16 17:37:03.803902 Queuing EAPOL frame to be transmitted out on interface ge-0/0/1 >>> If authentication doesn't progress, another EAP request can be sent when this timer expires.
Jun 16 17:37:03.803965  EAP Frame Sent with code:  1 !!!
Jun 16 17:37:03.804005 EAP Req Id 2 Frame Sent !!!  >>> This is important, the switch sends an EAP-Request/Identity to the endpoint.
Jun 16 17:37:03.804057 Processing complete for frame received on interface ge-0/0/1
Jun 16 17:37:03.804087 Deleted background job to process received EAPOL frames
Jun 16 17:37:03.804144 Task transmit function invoked
Jun 16 17:37:03.804632 EAPOL frame transmitted out on interface (ge-0/0/1.0) auth_disabled 

The cycle continues back and forth in the Connecting state, with EAPOL‑Start messages sent from the supplicant and EAP‑Request/Identity frames returned by the switch. However, during this timeframe we never see an EAPOL‑Response/Identity frame from the client to the switch. This absence of a response is why the device remains stuck in the "Connecting" state, repeating the cycle throughout the re‑authentication process until the entry is eventually deleted:

 
Jun 16 17:37:05.851241 Invoking state machine for frame received on interface ge-0/0/1
Jun 16 17:37:05.851265  Received an EAPOL Frame...
Jun 16 17:37:05.851303  Frame is targetted to this machine...
Jun 16 17:37:05.851371 EAPOL Frame Received on Port: 780 supp-mode 2 EapType 1
Jun 16 17:37:05.851826  ASM Called with Event: EAPSTART_RCVD, and State: Connecting
Jun 16 17:37:05.852319 Queuing EAPOL frame to be transmitted out on interface ge-0/0/1
Jun 16 17:37:05.852380  EAP Frame Sent with code:  1 !!!
Jun 16 17:37:05.852587 EAP Req Id 2 Frame Sent !!!
Jun 16 17:37:06.882621 Invoking state machine for frame received on interface ge-0/0/1
Jun 16 17:37:06.882646  Received an EAPOL Frame...
Jun 16 17:37:06.882684  Frame is targetted to this machine...
Jun 16 17:37:06.882753 EAPOL Frame Received on Port: 780 supp-mode 2 EapType 1
Jun 16 17:37:06.883065  ASM Called with Event: EAPSTART_RCVD, and State: Connecting
Jun 16 17:37:06.884011 Queuing EAPOL frame to be transmitted out on interface ge-0/0/1
Jun 16 17:37:06.884075  EAP Frame Sent with code:  1 !!!
Jun 16 17:37:06.884117 EAP Req Id 2 Frame Sent !!!

We can see that the MAC address is not fully learned while EAPOL‑Start messages are being received. The MAC table entry for this host will only be populated once the device successfully re‑authenticates:

 
Jun 16 17:39:06.598367 Don't learn mac when eap.start received
Jun 16 17:39:06.598449 pnac_process_l2ng_mac_learn_query: get_mac_status returned AUTH_PENDING
Jun 16 17:39:06.598481 pnac_l2ald_update_auth_pend update the cache pending db for mac (aa:bb:cc:dd:ee:a1)

We then observed the deletion of the session:

 
Jun 16 17:39:06.888571 DEBUG dot1x_server_send_mac_ifbd_response: Sent IFBD DEL to l2ald for aa:bb:cc:dd:ee:a1 vlan:0 bd:0
Jun 16 17:39:06.889322 pnac_client_delete_session: MAC: aa:bb:cc:dd:ee:a1 authenticatedStateCause: 0 AuthenticatorState: 3 SessionID: 9337473830258075854
Jun 16 17:39:06.889374 Send Radius Accounting STOP   >>> The switch notifies the RADIUS server that the session ended.
Jun 16 17:39:06.889413 [(aa:bb:cc:dd:ee:a1) 8O2.1x81955efa0009e8ce] previously ACCTG was not Started[890]. New req rcvd: STOP
Jun 16 17:39:06.889437 ACCTG State no change
Jun 16 17:39:06.889484 Queuing session cleanup message message to auth client
Jun 16 17:39:06.889602 Generated Unique SessId 9337473903272760042, aSessId :8O2.1x81955f0b000d92ea
Jun 16 17:39:06.889643 TMR: Timer 5 is deleted for port 780
Jun 16 17:39:06.889682  ASM moved to state: DISCONNECTED !!  >>> The 802.1X state machine explicitly entered the DISCONNECTED state.
Jun 16 17:39:06.889719  Trying to delete the session for MAC: -aabbccdd-eea1- on Port: 780 ... 
Jun 16 17:39:06.889754  Trying to delete the Session Node : 3bfa000 ... 

 
After the device deleted the dot1x entry following its failed attempt to authenticate via EAPOL, we observed that it was finally able to transition into the authenticated state. However, in this instance there was no EAPOL traffic exchange between the device and the switch:

Jun 16 17:41:12.189815 ASM TxWhenTimer CONN: If ge-0/0/1.0: TxReqId Count 4 Max Req 3
Jun 16 17:41:12.189858 Current authentication mode: Dot1x Next authentication mode: Mac-Radius
Jun 16 17:41:12.189893 Session aa:bb:cc:dd:ee:a1 reached max dot1x retry. Moving to next authentication mode: Mac-Radius
Jun 16 17:41:12.189928 Init Mac radius
Jun 16 17:41:12.189964 PnacAuthAsmInitMacRadius Intf ge-0/0/1.0: Launch MACAUTH.
Jun 16 17:41:12.190032  ASM Called with Event: RXRESPID, and State: Connecting
Jun 16 17:41:12.190071  for Port: 780, MAC: aabbccdd-eea1 
Jun 16 17:41:12.190105  Id: 0, SessionNode: 3bfa000 
Jun 16 17:41:12.190139 ASM: Inside PnacAuthAsmRxrespConnecting
Jun 16 17:41:12.190175  ASM moved to state: AUTHENTICATING !!
Jun 16 17:41:12.190212  BSM Called with Event: AUTHSTART, and State: Idle
Jun 16 17:41:12.190247  for Port: 780, MAC: aabbccdd-eea1
Jun 16 17:41:12.190281  Id: 0, SessionNode: 3bfa000 
Jun 16 17:41:12.190316  BSM moved to state: RESPONSE !!
Jun 16 17:41:12.190354  ASIF: Transferring Server-data to Auth Server for the user, aabbccddeea1.
Jun 16 17:41:12.190418 AuthSession node with Mac: aabbccdd-eea1 in port session AIP DB found !!!0
Jun 16 17:41:12.193723  ASIF: Radius REQUEST_ID: d9
Jun 16 17:41:12.193772  ASIF: Tx of Server-data to Auth Server succeeded
 

We observed that MAC learning is sent to the L2ALD process after the device completes authentication:

Jun 16 17:41:12.363221 Learn response notification to l2ald sent for mac (aa:bb:cc:dd:ee:a1), vid (10), port (780) and result (1)
Jun 16 17:41:12.363252 dot1x_is_bd_ready: bd_idx 7 bd_rg_id 0
Jun 16 17:41:12.363281 AuthSession node with Mac: aabbccdd-eea1 in port session AIP DB found !!!

This issue is triggered by the aging event of the MAC address, which subsequently forces the endpoint to re‑authenticate. However, the endpoint sends an EAPOL‑Start message, the switch replies with an EAPOL‑Request Identity, and the endpoint never responds. After some time, the cycle repeats: the endpoint sends another EAPOL‑Start, the switch replies, and again the endpoint does not respond. This is why the device remains in the Connecting state for several minutes until the switch deletes the entry, at which point the device is finally able to authenticate via MAC‑RADIUS.

With MAC‑RADIUS, no EAPOL exchange is required. The switch learns the device’s MAC address from normal traffic (ARP, DHCP, etc.), then sends a RADIUS Access‑Request using the MAC address as the username/identity.

When a switch acting as an 802.1X authenticator receives an EAPOL-Start message from an authenticated client, the switch tries to re-authenticate the client using the 802.1X method and typically returns an EAPOL-Request message, and waits for a response. If the client fails to respond, the switch attempts to re-authenticate the client using MAC RADIUS or captive portal method if these methods were configured. Clients that have been authenticated using MAC RADIUS or captive portal authentication are non-responsive, and traffic is dropped on the interface as the switch attempts re-authentication.

This specific endpoint does authenticate using EAPOL, which is why it falls back to MAC‑RADIUS authentication. When the device attempts to re‑authenticate, it first retries via EAPOL. After reaching the maximum dot1x retries, the session is deleted so that the next authentication method in the order—MAC‑RADIUS in this case—can begin.

To avoid this re‑authentication issue triggered by EAPOL frames, you can configure "mac‑radius restrict" on the interface. This ensures that the three dot1x authentication attempts will not occur and MAC authentication will take place immediately. At the same time, set the "no‑mac‑table‑binding" to prevent termination of the authentication session when the associated MAC address ages out of the ethernet-switching table:
 

• set protocols dot1x authenticator no-mac-table-binding
• set protocols dot1x authenticator interface <interface-name> mac-radius restrict
   

We can also configure "eapol‑block mac‑radius" configuration using:

• set protocols dot1x authenticator interface <interface-name> eapol-block mac-radius

This command configures the switch to ignore EAPOL‑Start messages sent from a client that has already been authenticated via MAC‑RADIUS or captive portal. With EAPOL blocking in effect, if the switch receives an EAPOL‑Start message from the client, it does not return an EAPOL‑Request message, and the existing authentication session is maintained. 

This "eapol‑block mac‑radius" is documented here:

https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/topic-map/flexible-authentication-order.html#id-configuring-eapol-block-to-maintain-an-existing-authentication-session