FireBrick FB6602, Руководство пользователя

Страница: 104 / 152

Supported RADIUS Attribute/
Value Pairs for L2TP operation
89
q[+]n Specify [or add to] quota for tx bytes. Use either q or Q. Action depends on Terminate-Action.
Q[+]n Specify [or add to] quota for total (tx+rx) bytes.
For change of authorisation the absence of a filter has no effect. To set normal routing table 0 zero, send T0.
To set not a member of a CUG send A0.
F.9. Notes
F.9.1. L2TP relay
L2TP relay means that an incoming call (ICRQ) is relayed to another L2TP endpoint. The decision of which
calls to relay to what endpoint can be made in one of two ways:-
• Configured pattern match based on calling number, called number, or login.
• RADIUS response to initial authentication request advising new endpoint for connection.
A test is made against the config on the initial connection based on known data. This is calling number (if
present), called number (if present) and login (proxy_auth_name if present). If a match is found the call is
relayed with no additional PPP packets exchanged.
If there is no proxy LCP provided, or the provided negotiation conflicts with the configuration, then LCP
negotiation is completed.
If there is no proxy authentication, PPP authentication is start until a response/login is received from the peer
(assuming authentication is required in the config).
At this point a further check is made for a configured relay which can now be based on a login if one was
not present before.
RADIUS authentication is completed, and if the response indicates a relay then the call is relayed.
The relayed call includes the incoming call parameters, and any LCP and authentication parameters that may
have been negotiated at that point.
F.9.2. LCP echo and CQM graphs
Depending on configuration, LCP echos are faked both ways from the FireBrick, and LCP echos are generated
by the FireBrick and responses checked. This allows the CQM graphs to be created. The graph is only created
for the outgoing part of the connection. If not configured to fake LCP echos, then these are passed through as
normal and no graph is created.
Each session gets a CQM graph which uses one second LCP requests and produces detailed loss/latency graphs
for the session. The graph name is picked based on the first available of :-
• Chargeable-User-Identity sent in the RADIUS authentication response.
• Calling-Station-Id from L2TP.
• User-name in RADIUS athentication response.
• Proxy-Auth-Name from L2TP.
• Negotiated user name from PAP/CHAP.
If a second session starts with the same graph name as an existing session then the existing session is cleared
with cause 13(Preempted). It is recommended that a unique circuit ID is passed as the Chargeable-User-Identity
in the authentication response to allow simple location of graphs.