Server Fail Fallback and Authentication
The server fail fallback mechanism for 802.1X, MAC RADIUS, and captive portal authentication defines how devices states are handled if the RADIUS server becomes unavailable or rejects access.
Understanding Server Fail Fallback and Authentication on Switches
Juniper Networks Ethernet Switches use authentication to implement access control in an enterprise network. If 802.1X, MAC RADIUS, or captive portal authentication is configured on the switch, end devices are evaluated at the initial connection by an authentication (RADIUS) server. If the end device is configured on the authentication server, the device is granted access to the LAN and the EX Series switch opens the interface to permit access.
Server fail fallback enables you to specify how end devices connected to the switch are supported if the RADIUS authentication server becomes unavailable. Server fail fallback is triggered most often during reauthentication when the already configured and in-use RADIUS server becomes inaccessible. However, server fail fallback can also be triggered by an end device’s first attempt at authentication through the RADIUS server.
Server fail fallback enables you to specify one of four actions to be taken for end devices awaiting authentication when the server is timed out. The switch can accept or deny access to supplicants or maintain the access already granted to supplicants before the RADIUS timeout occurred. You can also configure the switch to move the supplicants to a specific VLAN. The VLAN must already be configured on the switch. The configured VLAN name overrides any attributes sent by the server.
-
Permit authentication, allowing traffic to flow from the end device through the interface as if the end device were successfully authenticated by the RADIUS server.
-
Deny authentication, preventing traffic from flowing from the end device through the interface. This is the default.
-
Move the end device to a specified VLAN if the switch receives a RADIUS access-reject message. The configured VLAN name overrides any attributes sent by the server. (The VLAN must already exist on the switch.)
-
Sustain authenticated end devices that already have LAN access and deny unauthenticated end devices. If the RADIUS servers time out during reauthentication, previously authenticated end devices are reauthenticated and new users are denied LAN access.
When a VLAN is configured with
Server Fail VoIP, and the server fails, an Interface Bridge Domain (IFBD) is created for
this VLAN during client authentication. This allows the switch to move VoIP clients to a
fallback VLAN if the authentication server is unreachable or times out, ensuring voice
traffic continuity. The server-fail-voip statement specifically handles
voice VLAN tagged traffic fallback actions, such as permitting access, denying access,
or moving clients to a designated VLAN already configured on the switch. If the
server-fail-voip statement is configured, the switch uses it to
isolate and manage VoIP client traffic during server fail conditions, maintaining voice
service availability even when authentication cannot be completed.
See Also
Configuring RADIUS Server Fail Fallback (CLI Procedure)
You can configure authentication fallback options to specify how end devices connected to a switch are supported if the RADIUS authentication server becomes unavailable.
When you set up 802.1X or MAC RADIUS authentication on the switch, you specify a primary authentication server and one or more backup authentication servers. If the primary authentication server cannot be reached by the switch and the secondary authentication servers are also unreachable, a RADIUS server timeout occurs. If this happens, because it is the authentication server that grants or denies access to the end devices awaiting authentication, the switch does not receive access instructions for end devices attempting access to the LAN, and normal authentication cannot be completed.
You can configure the server fail fallback feature to specify an action that the switch applies to end devices when the authentication servers are unavailable. The switch can accept or deny access to supplicants or maintain the access already granted to supplicants before the RADIUS timeout occurred. You can also configure the switch to move the supplicants to a specific VLAN.
You can also configure the server reject fallback feature for end devices that receive a RADIUS access-reject message from the authentication server. The server reject fallback feature provides limited access to a LAN, typically only to the Internet, for responsive end devices that are 802.1X-enabled but that have sent the wrong credentials.
Server fail fallback is supported for voice
traffic starting in Release 14.1X53-D40 and Release 15.1R4. To configure server fail fallback actions for VoIP clients sending
voice traffic, use the server-fail-voip statement. For
all data traffic, use the server-fail statement. The switch
determines the fallback method to use based on the type of traffic
sent by the client. Untagged data frames are subject to the action
configured with server-fail, even if they are sent by a
VoIP client. Tagged VoIP VLAN frames are subject to the action configured
with server-fail-voip. If server-fail-voip is
not configured, the voice traffic is dropped.
Server reject fallback is not supported for VoIP VLAN tagged traffic. If a VoIP client starts authentication by sending untagged data traffic to a VLAN while server reject fallback is in effect, the VoIP client is allowed to access the fallback VLAN. If the same client subsequently sends tagged voice traffic, the voice traffic is dropped.
If a VoIP client starts authentication by sending tagged voice traffic while server reject fallback is in effect, the VoIP client is denied access to the fallback VLAN.
You can use the following procedure to configure server
fail actions for data clients. To configure server fail fallback for
VoIP clients sending voice traffic, use the server-fail-voip statement in place of the server-fail statement.
To configure server fail fallback actions:
You can configure an interface that receives a RADIUS access-reject message from the authentication server to move end devices attempting LAN access on the interface to a server-reject VLAN, a specified VLAN already configured on the switch.
To configure a server reject fallback VLAN:
[edit protocols dot1x authenticator] user@switch# set interface interface-name server-reject-vlan vlan-sf
See Also
Configuring RADIUS Reachability to Reauthenticate Server Fail Sessions
When an authentication attempt triggers server fail fallback, the end device can
reattempt authentication after a period of time. The default time interval that
the end device must wait for reauthentication is 60 minutes. The
reauthentication time interval can be configured using the
reauthentication CLI statement.
The server might become available before the reauthentication timer expires. When the RADIUS reachability feature is enabled, it triggers reauthentication once it detects that the server is reachable, without waiting for the reauthentication timer to expire. Once a session moves to server fail fallback, the authenticator will periodically query the server by initiating authentication for that session. When the authenticator receives a response, indicating that the server is reachable, it will initiate authentication for all server fail sessions.
To enable RADIUS reachability, you must configure the query period, which determines how often the authenticator queries the server for reachability. Configure the query period using the following command:
set protocols dot1x authenticator radius-reachability query-period
The quiet period must be shorter than the query period. The quiet period is the period during which the interface remains in the wait state following a failed authentication attempt before reattempting authentication.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.