|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|
Suppose the ISP ‘Local’ has a roaming arrangement with the ISP ‘Remote’. When the user of ‘Remote’ dials in to the NAS of ‘Local’, the NAS sends the authentication request to the ‘Local’ RADIUS server. The server then determines that this is a roaming user, stores a copy of the request in its internal queue, and forwards the request to the ‘Remote’ RADIUS server for processing. Thus, the ‘Local’ RADIUS server acts as a client for the ‘Remote’ RADIUS server.
When the ‘Remote’ RADIUS server responds, the ‘Local’
RADIUS server receives the response, and passes it back to the
NAS. The copy of the request from the server's queue determines
which NAS originated the request. Before passing the request back
to the NAS, the server removes information specific to the
‘Remote’ site, such as
Framed-Netmask, etc. Only the attributes marked with a
‘propagation’ flag (see section Attributes) are passed back to the
NAS. After removing site-specific attributes, the ‘Local’
RADIUS server passes the request through its user profiles
(see section User Profiles) to insert any local, site-specific information
that might be needed. Finally, it passes the reply back to the NAS.
Proxied accounting requests are processed in a similar manner, except that no attribute filtering takes place, as accounting responses do not carry any A/V pairs.
This example illustrates only the simplest proxy chain, consisting of two servers; real-life proxy chains may consist of several servers. For example, our ‘Remote’ RADIUS server might also act as a proxy, forwarding the request to yet another RADIUS server, and so on.
Note that when the accounting request passes through a chain of forwarding servers, the accounting records are stored on all servers in the chain.
This document was generated by Sergey Poznyakoff on December, 6 2008 using texi2html 1.78.