Fwd: Child is hung (max_request)

[srithar jeevadurai]

Hi Team,

I have understanded the proxy implementation. We are going to revamp our
application with following design.

I would like to know whether we will face any challenge in our design i.e.
freeRadius stack wise.

1) GGSN to send request to Radius proxy (listening on standard ports 1812
and 1813).
2) Radius proxy to accept only auth and allocate IP address and response to
auth request.
3) Radius proxy to forward acct request to home_server pool ( may be 2-3
home server on same server with different user id and port for acct request
instead of 1813).
4) Home_server to handle only acct request and fwd it to rad-dia converter
(diaclient). diaclient to convert rad request to dia request and send to
IN. diaclient to send response back to corresponding home server and home
server to send response back to Radius proxy.

Same Host: 1 Radius Proxy, 3 Home-Servers (different user id and port no
for acct req), 1 diaclient.


Assumption:
1) 2-3 home servers can be configured and run on same host with different
user name and port number for acct request.
2) Radius proxy to choose acct-start to be sent among home_servers and
forward further accouting request (i.e. updates and stop) to same
home_servers. i.e. load balancing can be automatically handled by Radius
proxy.
3) Radius proxy server can be modified to allocate IP address and response
to auth request (only for auth) and for acct-request it has to forward it
to home_server.
which configuration directs R-proxy to handle auth request by itself by
calling customized module and forward acct to home_server. It will be great
help if you can provide us same configuration for proxy to handle auth and
forward acct to home_servers.

Thanks in advance for your reply. Please let us know if there is any risk
or not right approach in above explaned design.

Regards,
Srithar


On Mon, Nov 24, 2014 at 12:28 PM, Iliya Peregoudov <iperegudov at cboss.ru>
wrote:

> On 22.11.2014 18:01, srithar jeevadurai wrote:
>
>> Hi LLiya,
>>
>> Thanks for your reply.
>>
>> If I understand your reply correctly. Our current implementation is like
>> radius worker thread calls our customized module of Radius (rlm_raddia)
>> to send request to diameter client (dia client will send the request to
>> IN and reponse will be sent back to radius thread from dia client). It
>> is a blocking call of Radius worker thread.
>>
>
> Yes, your current implementation uses custom freeradius module that
> implements in-house protocol client. All freeradius modules are blocking
> and your module is not an exception.
>
>  If we implement, radius server as proxy then it will take request from
>> NAS and send it to dia client (without waiting for response from dia
>> client) which is non blocking call of radius worker thread. Dia client
>> has to send response to radius server and radius server to send the
>> repsonse to NAS. The only change here is rad-worker thread is no need to
>> wait after sending request to dia client. Sending request and processing
>> respose from dia client will happen idependedlly by FreeRad.
>>
>
> Yes, RADIUS proxy functionality of freeradius is non-blocking.
>
>  If my above understanding is correct, Can we get a sample module code to
>> send radius request to external process (here it is dia client) and
>> process response from external process (idependedlly without waiting
>> req-res). I hope that we would have used any IPC like TCP/IP or message
>> queue etc.
>>
>
> RADIUS proxy functionality does not need any freeradius module. RADIUS
> proxy functionality is already implemented in freeradius core. RADIUS proxy
> functionality sends RADIUS requests to external RADIUS server (called
> "home" server). If your preacct section sets control:Proxy-To-Realm
> attribute for the accounting request received by freeradius from NAS,
> freeradius core will proxy this accounting request to the home server
> associated with designated realm. When the answer comes from home server
> freeradius core will proxy this answer back to the NAS.
>
> Example configuration of freeradius proxy:
>
> # raddb/proxy.conf
> home_server radius-diameter-translator-1 {
>         type = acct
>         ipaddr = 127.0.0.1
>         port = 4013
>         secret = secret
>         response_window = 3
>         no_response_fail = yes
>         zombie_period = 86400 # 1 day
>         revive_interval = 0
>         status_check = none
> }
> home_server_pool radius-diameter-translator {
>         home_server = radius-diameter-translator-1
> }
> realm radius-diameter-translator {
>         acct_pool = radius_diameter_translator
> }
>
> # raddb/sites-available/default
> ...
> preacct {
>    # Proxy all Accounting-Requests to radius-diameter-translator realm
>    update control {
>       Proxy-To-Realm := radius-diameter-translator
>    }
> }
> ...
>
> Your radius-diameter-translator module should listen RADIUS protocol on
> UDP/4013 port. Translator should implement RADIUS server (receive requests,
> send responses) and Diameter client (send requests, receive answers). Flow
> diagram is following:
>
>
> NAS         radiusd        r-d-t      diameter-server
>  |             |             |               |
>  |RADIUS ACR   |             |               |
>  |------------>|RADIUS ACR   |               |
>  |             |------------>|Diameter ACR   |
>  |             |             |-------------->|
>  |             |             |   Diameter ACA|
>  |             |   RADIUS ACA|<--------------|
>  |   RADIUS ACA|<------------|               |
>  |<------------|             |               |
>
>  I need to know how to start with proxy radius server impementation for
>> radius-diameter converter. It would be great if you can give me a
>> document link on the same please.
>>
>
> Proxy functionality is documented in raddb/proxy.conf.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/
> list/users.html
>



-- 
Regards,
Srithar Durairaj
Alternate Mail I.D: srijeevadurai1 at yahoo.co.in
Mobile: +919886251852