| G.9. Notes | ||
|---|---|---|
 | Appendix G. Supported RADIUS Attribute/Value Pairs for L2TP operation |  |
| G.9. Notes | ||
|---|---|---|
| | Appendix G. Supported RADIUS Attribute/Value Pairs for L2TP operation | |
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:-
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 waits 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.
The Filter ID T which would normally set the payload table when terminating traffic is instead used to set the routing table for the outgoing relay tunnel.
On a relayed L2TP connection, the LCP echoes are normally generated by the far ends and passed through by the FireBrick. This means that the usual loss/latency information will not be present.
However, if a RADIUS reply sets the LCP rate/timeout and provides tunnel relay, then the incoming side of the relayed connection will use LCP echoes from the FireBrick in the middle rather than echoes passed through from the far end - we call this "man-in-the-middle LCP". This means that on the outgoing connection, the FireBrick answers LCP echoes from the relayed LNS. Loss/latency information is provided for the client-side in this situation (more details are given below).
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 :-
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.
Normally the FireBrick sends regular LCP echoes and generates a loss/latency graph. Where this is not enabled (LCP Rate is 0 or no graph is set) then graphs are created but with no loss/latency. This is the default behaviour for relayed connections (unless using man-in-the-middle LCP).
When a tunnel has no relaying, the FireBrick will send LCP echoes at a steady rate (and knows when they are sent) so it can straightforwardly determine the loss and latency.
However with simple relaying, the FireBrick isn't one of the ends. It doesn't control when the polls are sent and there's no requirement for polls to be regular in the L2TP standard. Gaps in the data could be normal, so it isn't able to provide useful loss or latency information in that situation.
Alternatively, the FireBrick can be configured to terminate the LCP on both sides, "man-in-the-middle LCP" as described above. If you're primarily interested in the connection from the LAC to the FireBrick, then this configuration will generate a graph allowing you to see loss and latency.
Be aware that in this scenario, the LNS and LAC see the loss and latency only as far as the relay, so anything they are doing themselves to monitor the whole path will no longer work. For instance, if the LNS is another FireBrick, then its graph will show the loss and latency to the relay, but no further.
Unfortunately this doesn't provide loss and latency for the LNS side, because there's only one graph per connection and so there's nowhere for this information to go. In practice this side of the relay is often to a much more reliable connection (e.g. another provider's data centre or your own LNS), so this limitation is generally not a problem.
IP over LCP is a non standard coding of PPP packets for IPv4 and IPv6. The coding uses the LCP code (C021) instead of the IPv4 (0021) or IPv6 (0057) code. The first byte which would normally be the LCP type is 0x4X (IPv4) or 0x6X (IPv6). The FireBrick assumes any such LCP codes are IPv4/IPv6 when received, and using a RADIUS response can send IP packets using LCP. This is specifically to bypass any carrier IP specific shaping or DPI.
Each session can have a CUG defined (1-32767) which may be allow or restrict. Interfaces (port/VLAN) may also be defined in the same way. A packet from an interface/session is tagged with a CUG if configured. If the source is restricted, that packet can only leave via an interface/session with the same CUG. Similarly if the target interface/session is restricted, then only a packet tagged with the same CUG can be sent to it.
The restrict option is useful when you want to control a series of tunnels or interfaces to communicate only with each other, and the allow option is useful for when you need them to have wider access via a specific gateway.
The FireBrick operates independent routing cores allowing a totally independent routing table to be used for L2TP wrapper traffic and payload traffic. It is also possible to set the payload table in use on a per session basis from RADIUS thus allowing a walled garden to be set up, or a private network, or simple an unusable session.
| |  | |
| G.8. Filter ID |  | Appendix H. Supported RADIUS Attribute/Value Pairs for VoIP operation |