No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.

Knowledge Base

Radius authentication request re-send intervel time setting not reasonable lead to DHCP user can not change from radius-auth to none-auth when auth-mode is radius-none prblem trouble shooting

Publication Date:  2012-07-27  |   Views:  262  |   Downloads:  0  |   Author:  Tian Ye  |   Document ID:  EKB0000497967


Issue Description

Live network configures a radius group, there are two radius servers in the group, and DHCP users under domain pldt are configured auth-mode radius-none, which means users will be authenticated by radius server when radius server state is up, when it goes down, users will get online without authentication.

The related configuration is like this:
authentication-scheme pldt
authentication-mode radius-none
authening authen-fail online
authen-domain redirect

domain pldt
authentication-scheme pldt
accounting-scheme default0
radius-server group testing
user-group pldt
ip-pool test

domain redirect
authentication-scheme none
accounting-scheme none
radius-server group testing
web-server url
user-group redirect
ip-pool test

radius-server group testing
radius-server authentication 1812 weight 0
radius-server authentication 1812 weight 0
radius-server shared-key testing123
undo radius-server user-name domain-included

After configured as above, customer found when they shut down both of the radius servers, ME60 still keep sending auth request packets to radius servers. user can not get online without authentication as expected.

Alarm Information


Handling Process

1. Check live network configuration, the authentication-mode configuration and other configuration related are all correct. Possible reason1 is excluded.

2. Live network re-occur the problem, and trace user information who has this problem for relatively long time(about 10 mins), from the trace info, we can see after both radius servers are shut down by customer, ME60 send auth-request packet to radius for at least 8 mins(that's the trace time lasts), which shows the re-sending is not normal, possible reason2 is excluded.

3. From the trace info we can see After the radius servers are shut down, ME60 send the user auth-request to server1 for the first time, without getting reply, ME60 re-sent the request to server1 for another 2 times every 5 seconds, without reply again, ME60 send the request to server2 for another 2 times every 5 seconds. Before ME60 send request to server2 for the third time, DHCP online time out info has been typied out:
--[2011/1/4 3:42:8-][DHCPR][000d-60a7-0166]:Timer out(DHCPR_DIS_WAIT_UCM_REQ_ACK_TIMER)
--[2011/1/4 3:42:8-][DHCPR][000d-60a7-0166]:Send cut-request message to CM successfully(MAC=00-0d-60-a7-01-66 user id=-1)
--[2011/1/4 3:42:8-][CM][000d-60a7-0166]:[CM State]Cib:127 Event:CONN_DOWN State From AUTH BUTT To DELETING BUTT

4. From the info above we suspect the reason is: ME60 DHCP module has the mechanism of when DHCP user can not get online on ME60 within 25 seconds, ME60 will cut this user, but 25 seconds is not enough for this user change from radius auth-mode to none auth-mode. So this problem happend(for how to count the total re-send time(auth-mode change time)pls see "Suggestion and Summary").

5. Add configuration "radius-server retransmit 2 timeout 3" under radius-group, change the intervel time of re-send auth-request time from default 5 seconds to 2 seconds. the total re-send time(auth-mode change time) will be less than 25 seconds. After re-test, DHCP users from domain pldt can get online without authentication when radius server is down. The problem sovled.

Root Cause

The possible cause of this problem could be:
1. Authentication mode is wrongly cofigured.

2. When Radius server is shut down by customer, ME60 can not sense it immediately, it will re-send authentication request packets to both radius servers for several times, after all the request get no reply, it will set set redius peer down state, so it is possible customer see the re-send packet as abnormal phenomenon.

3. Other reason, need further analysis.


The total radius authentication request re-send time(auth-mode change time) mesurement: Live network default configuration: The request send to each radius server for 3 times, the intervel of each time is 5 seconds, the total time is 5*3*2(two servers)=30seconds>25seconds(DHCP online time out) After changing configuration: The request send to each radius server for 3 times, the intervel of each time is 2 seconds, the total time is 2*3*2(two servers)=12seconds<25seconds(DHCP online time out)