authentication timer handshake-period

Usage Scenario

After enabling the handshake with pre-connection users and authorized users using the authentication handshake command, you can run the authentication timer handshake-period command to set the handshake interval. After that, if a user does not respond to the handshake request from the device within the handshake interval, the device deletes the user entry.

Precautions

• This command applies only to MAC address authentication, Layer 3 Portal authentication and 802.1X authentication.

• For Layer 3 Portal authentication users, only those who go online through S5730-HI, S5731-H, S5731S-H, S5731-S, S5731S-S, S5732-H, S6730-H, S6730S-H, S6730-S, S6730S-S, S6720-HI, and S5720-HI support this function.

• This function takes effect only for the wired users. For wired users who do not obtain IP addresses within 30 minutes, traffic detection will be performed (detection process can be seen as the following precautions). If traffic passes through the device, users are online. If no traffic passes through the device, users go offline.

• This function takes effect only for users who go online after this function is successfully configured.

• The handshake function is implemented using ARP probe packets or neighbor discovery (ND) probe packets.

• The handshake function can also be implemented by detecting whether there is user traffic on the access device. Assuming that the handshake interval is 3n, the device will detect user traffic at n and 2n. The following uses the 0-n period as an example. The process during the n-2n period is similar to that during 0-n. (This process applies only to authentication users who go online from the S5720-EI, S5720-HI, S5730-HI, S5731-H, S5731S-H, S5731-S, S5731S-S, S6720-HI, S5732-H, S6730-H, S6730S-H, S6730-S, S6730S-S, S6720-EI, and S6720S-EI. Other switch models do not detect user traffic and send probe packets at n and 2n.)

  • If user traffic passes the device during the 0-n period, the device considers that the user is online at n, so it will not send a probe packet to the user, but resets the handshake interval.
  • If no user traffic passes the device during the 0-n period, the device cannot determine whether the user is online at n, so it sends a probe packet to the user. If the device receives the reply packet from the user, it considers the user online and resets the handshake interval. If no reply packet is received, it considers the user offline.

  • If user traffic passes the device during the 2n-3n period, the device considers that the user is online at 3n and resets the handshake interval.
  • If no user traffic passes the device during the 2n-3n period, the device cannot determine whether the user is online at 3n and considers that the user is offline.

  If the device considers that the user is offline at n, 2n, and 3n, the device deletes all entries related to the user. To prevent the user from going offline unexpectedly when no operation is performed on the PC, do not set a short handshake period.
• For the models that do not support the handshake function implemented by detecting whether there is user traffic on the access device, if the number of ARP probe packets exceeds the default CAR value, the probe fails and the users are logged out (The display cpu-defend statistics command can be run to check whether ARP request and response packets are lost.). To resolve the problem, the following methods are recommended:

  • Increase the handshake interval based on the number of users. The default handshake interval is recommended when there are less than 8000 users; the handshake interval should be no less than 600 seconds when there are more than 8000 users.
  • Deploy the port attack defense function on the access device and limit the rate of packets sent to the CPU.