Null
When implementing portal authentication, it is often recommended to configure the "idle-cut" value in the configuration guide. For example:
[AC-V7-isp-1]authorization-attribute idle-cut 10 10240
What does "10" and "10240" mean in this example? Should this value be configured everywhere?
To understand this issue, it is necessary to first know what idle cut is and how it works.
In H3C's implementation of portal authentication, it is based on the existence of the IP address, meaning that when authentication is initiated and successful, the AC will create an authentication table entry based on the user's IP address as the primary clue.
For example:
Portal Authentication Test: during portal authentication for student "Zhang San", with IP address 192.168.100.100/24 and MAC address XXXXXX, once the authentication table entry is created, the AC will not proactively delete the entry without any external intervention. External intervention can be initiated by a server such as IMC issuing an instruction to delete the entry (i.e log out the user), or someone manually removing the portal entry on the AC.
So this mechanism of not proactively deleting the entries has one advantage and one disadvantage:
l
l
Through the above description, we can see that the portal entries on the AC cannot exist indefinitely, nor can they be deleted immediately when wireless users temporarily leave. So, how to solve this problem?
Here we introduce the idle cut mechanism, which has two parameters: one is time in minutes, and the other is traffic in bytes.
The traffic parameter is symbolic, representing any small traffic generated by any terminal indicating that the terminal is still alive. For example, 10240 bytes is about 1KB.
The key lies in the time parameter, and the configuration of this time parameter requires some careful consideration. Our experience suggests that it is recommended to configure it to be 1/3 of the DHCP lease time.
Why 1/3?
According to the DHCP protocol, terminals will renew their DHCP lease at the halfway point of the lease period. assuming the DHCP lease is for 1 hour, this renewal occurs at the 30-minute interval. If the idle cut parameter is set to 40 minutes, it will exceed the halfway point of the lease.
If the terminal is online for 30 minutes and still online after 40 minutes, idle cut will determine that the terminal has not left.
However, if the terminal leaves at the 41st minute and never comes back, DHCP will find that the IP address is not being used after the lease expires after one hour and will allocate it to others. At this point, idle cut needs to detect that the terminal has left and remove the entry in the next 40-minute interval, which is at the 80th minute. This causes a small number of terminals to continue to be unable to be removed by idle cut, resulting in unlucky new terminals failing to authenticate.
To avoid this extreme situation, our experience suggests that the idle cut time parameter should be set to less than half of the DHCP lease time. Therefore, setting it to 1/3 appears to be a good choice.
Extending this train of thought, if the DHCP lease time for the network is 24 hours, our portal idle cut should be set to less than 12 hours, and 8 hours is generally a good choice. This not only avoids the trouble of requiring users to re-authenticate when they leave for a while but also prevents the embarrassment of some people being unable to authenticate due to DHCP timeouts.
1/3 of the DHCP lease time.