Aggregation Example - Association of IP Data

Owned by Jenni Wallin
Last updated: Aug 10, 2023 by Former user (Deleted)
6 min read

To illustrate the Aggregation agent's features, an association example according to the following workflow setup is presented below. The workflow is handling IP traffic data, and will group information from routers and the corresponding network access servers.

An example where an Aggregation agent is used to associate IP data

The Netflow agent collects router data and logs the interacting network elements' addresses and amount of bytes handled, while the Radius agent keeps track of who has initiated the connection, and for how long the connection was up. Thus, each user login session consists of two Radius UDRs (start and stop), and one or several Netflow UDRs. The Aggregation agent is used to associate this data from each login session. These additional rules apply:

  • 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!

    The Radius specific response handling will not be discussed in this example. For further information, see 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.

Note!

The input UDRs are not stored. Information from the UDRs is extracted and saved in the session variables.


The Ultra definition for the session type:

session ExampleSession { 
   string user; 
   string IPAddress; 
   long sessionID; 
   long downloadedBytes; 
   long uploadedBytes; 
};



VariableDescription

user

The user initiating the network connection. This value is fetched from the start of Radius UDR.

IPAddress

The IP address of the user initiating the network connection. This value is fetched from the start Radius UDR.

sessionID

A unique ID grouping a specific network connection session for the specific user. This value is fetched from the start Radius UDR.

downloadedBytes

The amount of downloaded bytes according to information extracted from Netflow UDRs.

uploadedBytes

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.

Pay attention to the use of the Additional Expression. The fields associating the start and stop Radius UDRs are framedIPAddress and acctSessId. However, since there is no field matching the latter within the Netflow UDRs, this field cannot be entered in the ID Fields area.

The Aggregation profile - Association tab - Radius UDRs

This is how arriving Radius UDRs are evaluated when configured according to the figure The Aggregation Profile - Association Tab - Radius UDRs:


  1. 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.
     

  2. If the Primary Expression evaluation was successful, the fields entered in the ID Fields area, together with the Additional Expression are used as secondary verification. If it evaluates to true, the UDR will be added to the session, if not - refer to the subsequent step.
     

  3. 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:

The Aggregation profile - Association tab - Netflow UDRs

This is how arriving Netflow UDRs are evaluated when configured according to the figure, The Aggregation Profile - Association Tab - Netflow UDRs:


  1. If the DestinationIP, situated in the ID Fields area in the first Rules tab, does not match any existing session, and no new session is created. If a match is found, the UDR is associated with this session.
     

  2. 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!

    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.

Note!

The timeout of a session is set to five days from the current date. Outdated sessions are removed and their data is transferred to a UDR of type outputUDR, which is sent to ECS.

import ultra.Example.Out;

sessionInit { 
  Accounting_Request_Int radUDR = 
    (Accounting_Request_Int) input;
  session.user = radUDR.User_Name; 
  session.IPAddress = radUDR.framedIPAddress; 
  session.sessionID = radUDR.acctSessionId; 
}

consume { 
  /* Radius UDRs. 
  If a matching session is found, then there are two Radius UDRs 
  and the session is considered completed. 
  Remove session and route the new UDR. */

  if (instanceOf(input, Accounting_Request_Int)) { 
    Accounting_Request_Int radUDR = (Accounting_Request_Int)input;

    if (radUDR.acctStatusType == 2 ) { 
      OutputUDR finalUDR = udrCreate( OutputUDR ); 
      finalUDR.user = session.user; 
      finalUDR.IPAddress = (string)session.IPAddress; 
      finalUDR.downloadedBytes = session.downloadedBytes; 
      finalUDR.uploadedBytes = session.uploadedBytes; 
      udrRoute( finalUDR );
      sessionRemove(session); 
      return; 
    } 
  }

  /* Netflow UDRs. 
  Depending on if the user downloaded or uploaded bytes, the 
  corresponding field data is used to update session variables. */

  if (instanceOf(input, V5UDR)) { 
    V5UDR nfUDR = (V5UDR)input;

      if ( session.IPAddress == nfUDR.SourceIP ) { 
        session.downloadedBytes = session.downloadedBytes + 
          nfUDR.BytesInFlow; 
      } else { 
        session.uploadedBytes = session.uploadedBytes + 
          nfUDR.BytesInFlow; 
      } 
  }

  // A session will be considered outdated in 5 days. 
  date timer=dateCreateNow(); 
  dateAddDays( timer, 5 ); 
  sessionTimeout( session, timer ); 
}

timeout { 
   // Outdated sessions are removed, and a resulting UDR is sent on. 
   OutputUDR finalUDR = udrCreate( OutputUDR ); 
   finalUDR.user = session.user; 
   finalUDR.IPAddress = (string)session.IPAddress; 
   finalUDR.downloadedBytes = session.downloadedBytes; 
   finalUDR.uploadedBytes = session.uploadedBytes; 
   udrRoute( finalUDR );
   sessionRemove(session); 
}