Portal Timers
As described in Table 1, an access device supports the following timers.
Portal Timer |
Purpose |
Application Scenario |
|---|---|---|
To prevent frequent authentication upon user authentication failures. Frequent authentication may cause DoS attacks and waste system resources. |
External Portal server that uses the Portal or HTTP/HTTPS protocol or built-in Portal server that uses the Portal protocol |
|
To ensure that online Portal users can go offline and new Portal authentication users can go online if communication between the access device and Portal server is interrupted due to a network fault or the Portal server is faulty. |
External Portal server that uses the Portal or HTTP/HTTPS protocol |
|
To ensure that online Portal users can go offline and correct accounting is performed for users who have already gone offline if communication between the access device and Portal server is interrupted due to a network fault or the Portal server is faulty. |
External Portal server that uses the Portal protocol |
|
To prevent the following situation: If the network between the access device and Portal server is unstable or packets are lost, the Portal server may fail to receive the user logout packet from the access device. In this case, the user is displayed as disconnected on the access device but is still displayed as online on the Portal server. |
External Portal server that uses the Portal protocol |
|
To prevent the following situation: When a user goes offline due to browser closing or network disconnection, user information is still retained on the access device. As a result, accounting is inaccurate or other users cannot go online. |
Built-in Portal server that uses the Portal protocol |
Quiet Timer
This section discusses the timer that controls when Portal authentication restarts after the number of failed Portal authentication attempts within 60 seconds reaches the value specified by the portal quiet-times fail-times command.
If a user fails Portal authentication, the access device waits for a period of time specified by the portal timer quiet-period quiet-period-value command. During this period, the access device discards the Portal authentication requests sent from the user. Figure 1 shows the operation of the quiet timer by using the Portal protocol as an example.
Portal Server Detection Timer
This section discusses the timer that controls the interval at which the Portal server state is detected. The value of the timer is specified by the server-detect interval interval-period command.
There are two Portal server detection modes: Portal-based and HTTP-based. For Portal-based Portal authentication, the device supports both of the two modes. For HTTP- or HTTPS-based Portal authentication, the device supports only HTTP-based Portal server detection.
In Portal-based Portal server detection mode: The Portal server periodically (at an interval of Ts) sends heartbeat packets to the access device. If the access device receives Portal heartbeat packets or other authentication packets from the Portal server before the Portal server detection timer expires, detection is successful and the access device considers the Portal server to be reachable and in Up state. Otherwise, Portal server detection fails. When the number of consecutive detection failures reaches the maximum number specified by the server-detect max-times times command, the access device changes the status of the Portal server from Up to Down.
In HTTP-based Portal server detection mode: The access device periodically sends HTTP packets to the Portal server and expects a response packet from the Portal server. If the access device receives a response packet within the specified detection interval (configured using server-detect interval interval-period), the detection is successful. Otherwise, the detection fails. When the number of consecutive detection failures reaches the maximum number specified by the server-detect max-times times command, the access device changes the status of the Portal server from Up to Down.
The Portal server detection process is shown in Figure 2 and Figure 3.
It is recommended that the value of interval-period configured on the access device be greater than the heartbeat packet interval configured on the Portal server.
Additionally, the access device takes the following actions to inform administrators of the Portal server states in real time and ensure that users have certain network access rights:
- Sends alarms: When the status of a Portal server is changed, the access device sends an alarm to the NMS. The alarm information records the IP address and status of the Portal server.
- Sends logs: When the status of a Portal server is changed, the access device sends a log to the NMS. The log information records the IP address and status of the Portal server.
- Enables the Portal escape mechanism. If the number of Portal servers in Up state is equal to or less than the minimum number (specified by the server-detect critical-num critical-num command), the access device disables Portal authentication so that all Portal users can access specified network resources. For details about authorization methods, see "The Portal server is Down" in NAC Escape Mechanism. When the access device receives a heartbeat packet or other authentication packets (for example, a user logout packet) from the Portal server, or HTTP-based Portal server detection success, the access device changes the status of the Portal server to Up. If the number of Portal servers in Up state is greater than the minimum value, Portal authentication is restored.
User Information Synchronization Timer
This section discusses the timer that controls the interval at which user information is synchronization. The value of the timer is specified by the user-sync interval interval-period command.
The Portal server periodically (at an interval of Tps) encapsulates online user information into a USER_SYN message (a user synchronization request packet) and sends it to the access device. Upon receipt of the USER_SYN message, the access device compares the online user information in the USER_SYN message with the local online user information.
- For user information that exists both in the USER_SYN message and on the access device, the access device marks the user information as synchronized.
- For user information that exists only on the access device but not in the USER_SYN message, the access device considers that user information fails to be synchronized. If information about a user fails to be synchronized before the synchronization timer expires, the synchronization failure is counted as 1. When the number of synchronization failures reaches the value specified by the user-sync max-times times command, the access device deletes the user information and forces the user to go offline.
- For user information that exists only in the USER_SYN message but not on the access device, the access device encapsulates the user information into an ACK_USER_SYN message and sends the message to the Portal server. The Portal server then deletes the corresponding user information.
Figure 4 shows the process of synchronizing user information.
This function is applicable only to the external Portal server that uses the Portal protocol. The access device can synchronize user information with Huawei Symantec TSM Portal server only.
It is recommended that the product of interval-period and times be greater than the interval for the Portal server to send USER_SYN messages. Otherwise, the access device may force users to go offline if it receives no USER_SYN message from the Portal server after the maximum number of synchronization failures is reached.
User Logout Retransmission Timer
This section discusses the timer that controls the timeout and retry behavior of a Portal authentication-enabled interface for sending NTF-LOGOUT messages.
During Portal authentication, after a Portal authentication user goes offline, the access device sends an NTF-LOGOUT message to instruct the Portal server to delete the user information. The access device waits for a period of time defined by the user logout retransmission timer, and sends another NTF-LOGOUT message if no response is received. The timer and the number of times it resends the NTF-LOGOUT messages are configured by the portal logout resend times timeout period command.
Figure 5 shows the operation of the user logout retransmission timer.
User Heartbeat Detection Timer
This section discusses the timer that controls the interval at which a built-in Portal server detects heartbeats of clients. The interval is specified by the portal local-server keep-alive interval interval-value command.
After a user is authenticated, the Portal server pushes a connection setup page that has a heartbeat program embedded to the user. The client then periodically sends heartbeat packets to the access device, indicating that the user is online. If the access device receives a heartbeat packet from the client, it resets the user heartbeat detection timer. If the access device does not receive any heartbeat packet or authentication packet from the client before the user heartbeat detection timer expires, the access device considers the user to be offline and logs out the user. Figure 6 shows the process of detecting user heartbeats by the built-in Portal server.
- Forcible mode: If the access device does not receive a heartbeat packet from a user before the user heartbeat detection timer expires, the access device logs out the user.
- Automatic mode: The access device checks whether the client browser supports the heartbeat program. If so, the forcible mode is used. If not, the access device does not detect user heartbeats. This mode is recommended to prevent user logout if the browser does not support the heartbeat program.
On the Windows 7 system, the heartbeat program is supported by Internet Explorer 8, FireFox 3.5.2, Google Chrome 28.0.1500.72, and Opera 12.00.
Browsers using Java1.7 and later versions do not support the heartbeat program.