...
A Radius UDR belonging to a specific login session must always arrive before its corresponding Netflow UDRs. If a Netflow UDR arrives without a preceding Radius UDR, it must be deleted.
Within a Netflow UDR, the user initiating the session may act as a source or destination, depending on the direction of data transfer. Thus, it is important to match the IP address from the Radius UDRs with source or destination IP from the Netflow UDRs.
Note title Note! The Radius specific response handling will not be discussed in this example. For further information, see 9.60 64 Radius Agents.
Session Definition
For each session, all the necessary data must be saved. A suggestion of useful variables for this scenario is described below.
...
| Variable | Description |
|---|---|
| The user initiating the network connection. This value is fetched from the start Radius UDR. |
| The IP address of the user initiating the network connection. This value is fetched from the start Radius UDR. |
| A unique ID grouping a specific network connection session for the specific user. This value is fetched from the start Radius UDR. |
| The amount of downloaded bytes according to information extracted from Netflow UDRs. |
| The amount of uploaded bytes according to information extracted from Netflow UDRs. |
Association - Radius UDRs
The Radius UDRs are the Aggregation session-initiating units. They may be of two types in this example; start or stop.
...
Initially, the UDR is evaluated against the Primary Expression. If it evaluates to
false, all further validation is interrupted and the UDR will be deleted without logging (since no more rules exist). Usually invalid UDRs are set to be deleted. In this case, only the UDRs of type start (acctStatusType=1) or stop (acctStatusType=2) are of interest.
If the Primary Expression evaluation was successful, the fields entered in the ID Fields area, together with the Additional Expression are used as a secondary verification. If it evaluates to
true, the UDR will be added to the session, if not - refer to subsequent step.
Create Session on Failure is the final setting. It indicates if a new session will be created if no matching session has been found in step 2.
Association - Netflow UDRs
As previously mentioned, the IP address to match against in the Netflow UDRs depends on if data is being uploaded or downloaded. This results in the session initiator being either the source or destination. Hence, both these fields need to be evaluated in the Aggregation agent:
...
If the DestinationIP, situated in the ID Fields area in the first Rules tab, does not match any existing session, no new session is created. If a match is found, the UDR is associated with this session.
Regardless of the outcome of the first rule, all rules are always evaluated. Hence the second rule is evaluated. If the SourceIP situated in the ID Fields area in the second Rules tab does not match any existing session, no new session is created. If a match is found, the UDR is associated with this session.
Note title Note! Since Create Session on Failure is not enabled for any of the rules, the UDRs which do not find a matching session will be deleted and cannot be retrieved.
The APL Code
From the APL code (the agent configuration dialog), all actions related to both initiating and matching a session are defined. When a session is considered associated, the session variables are saved in a new UDR Type (outputUDR( out )) containing fields with the same name as the variables.
...