On 24.03.2015 11:41, srithar jeevadurai wrote:
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.
Is far as I understand you want to implement proxy server using FreeRADIUS. If you plan to dynamically allocate addresses (e.g. not static subscriber--address binding), you also have to deallocate addresses on Accounting-Request/Stop. Address allocation/deallocation needs address database modification. Database access on accounting handling path is better to be postpone using raddb/sites-available/decoupled-accounting. Database access on authentication handling path cannot be postponed. High database latency can lead to radiusd request queue to overflow on request spikes. Request queue in radiusd is used for both authentication and accounting requests. When queue overflows radiusd starts dropping incoming requests, both authentication and accounting. If you do not want to lose accounting due to troubles with authentication, you better to run two radiusd processes, first listening on 1812 port and handling authentication and second listening on 1813 port and handling accounting.
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.
It is not clear why do you need home servers. What will they do? Will they proxy accounting requests to rad-dia converter? Proxy server can proxy RADIUS requests directly to rad-dia converter.