For HPE Juniper Networking switching devices, when a supplicant (client device) is not getting authenticated in dot1x (802.1X) network and its status is stuck in the "held" state or connecting, it typically indicates an issue with the authentication process or connectivity.

There are multiple reasons on why this could happen :

• Incorrect credentials
• Radius server issues
• Config mismatch
• EAP type or time out settings etc.
• MTU issues along the path.

Below  is an instance observed on the customer's network where authentication remained in a held state :

root@switch> show dot1x interface ge-0/0/9           
802.1X Information:
Interface     Role           State           MAC address          User
ge-0/0/9.0    Authenticator  Held            00:aa:bb:68:dd:ee    host/user.domain

The following configuration is present in the switch:

protocols {

   dot1x {

       authenticator {

           authentication-profile-name dot1x;

           interface {

               mist-nac-dot1x-ports {

                   mac-radius {

                       authentication-protocol {

                           pap;

                       }

                   }

                    no-reauthentication;

                   guest-vlan VisitorNet;

                   server-reject-vlan VisitorNet;

               }

           }

       }

   }

• There was a power failure at customer's site.
• The device underwent a reboot, subsequently initiating the authentication process upon startup.
• We noticed that the server was “ dead “ at 8:06.

Jun ZZ 08:06:43 Switch authd[2062]: AUTHD_RADIUS_SERVER_STATUS_CHANGE: Status of radius server X.X.X.X set to DEAD (profile dot1x)

•  Due to the server being inactive and the absence of a server-fail VLAN configuration, the devices remained in a held state. 
• Additionally, the server status indicated it became active at 'Jun 8:10:13

Jun ZZ 08:10:13 Switch authd[2062]: AUTHD_RADIUS_SERVER_STATUS_CHANGE: Status of radius server X.X.X.X set to ALIVE (profile dot1x)

• Since there is no re-auth configured, EAPOL packets will not be exchanged, and hence this will be expected behaviour. 
• Port-bounce re-initiated the authentication process and the devices got authenticated.
• Once server came online, since there is no re-auth configured, EAPOL packets will not be exchanged, and hence this will be expected behaviour.

To resolve this:

• Configure reauthentication.
• Configure server-fail VLAN for Guest-access, if server fails.

If after the above you are still seeing authentication status in 'held', and there is reachability to the RADIUS server, you might see the following log:

root@switch> show log auth.log | match unreachable 
Apr 23 14:47:15.194202 RadiusServer: profile - dot1x, radius server - 192.168.1.1 status set to UNREACHABLE
Apr 23 14:52:06.457494 RadiusServer: profile - dot1x, radius server - 192.168.1.1 status set to UNREACHABLE
Apr 23 14:57:45.226894 RadiusServer: profile - dot1x, radius server - 192.168.1.1 status set to UNREACHABLE

There might be additional issues that need to be addressed, you will need to take packet captures to review the flow of packets towards the NAC server, configure traceoptions for dot1x and general authentication services. If you are seeing many retransmit errors and FIN, FIN, ACK, make sure you have the right TCP MSS value or adjust it to avoid fragmentation of TCP and the proper MTU on the other side to accommodate regular JUNOS MTU values. To configure the traceoptions add the following:

set system processes general-authentication-service traceoptions file authd.log
set system processes general-authentication-service traceoptions flag all
set protocols dot1x traceoptions file dot1x.log
set protocols dot1x traceoptions flag all

In some cases where the switch is part of a Campus Fabric and the switch uses and IRB to communicate to the cloud with an MTU of 9000, you will need to modify the MTU value of the source IRB as follows using additional CLI commands if no client is part of that VLAN:

set interfaces irb unit 0 family inet mtu 1500

https://www.juniper.net/documentation/us/en/software/junos/user-access/topics/topic-map/802-1x-authentication-switching-devices.html