The configuration process involves creating and connecting the following configuration objects.

1. On the Main tab, click Local Traffic > Pools .
   The Pool List screen opens.
2. Click Create.
   The New Pool screen opens.
3. In the Name field, type a unique name for the pool.
4. Using the New Members setting, add the IP address for each IPFIX collector that you want to include in the pool:
   1. Type the collector's IP address in the Address field, or select a node address from the Node List.
   2. Type a port number in the Service Port field.
      By default, IPFIX collectors listen on UDP or TCP port 4739 and Netflow V9 devices listen on port 2055, though the port is configurable at each collector.
   3. Click Add.
5. Click Finished.

1. On the Main tab, click System > Logs > Configuration > Log Destinations .
   The Log Destinations screen opens.
2. Click Create.
3. In the Name field, type a unique, identifiable name for this destination.
4. From the Type list, select IPFIX.
5. From the Protocol list, select IPFIX or Netflow V9, depending on the type of collectors you have in the pool.
6. From the Pool Name list, select an LTM^® pool of IPFIX collectors.
7. From the Transport Profile list, select TCP, UDP, or any customized profile derived from TCP or UDP.
8. The Template Retransmit Interval is the time between transmissions of IPFIX templates to the pool of collectors. The BIG-IP system only retransmits its templates if the Transport Profile is a UDP profile.
   An IPFIX template defines the field types and byte lengths of the binary IPFIX log messages. The logging destination sends the template for a given log type (for example, NAT44 logs or customized logs from an iRule) before sending any of those logs, so that the IPFIX collector can read the logs of that type. The logging destination assigns a template ID to each template, and places the template ID into each log that uses that template.

   The log destination periodically retransmits all of its IPFIX templates over a UDP connection. The retransmissions are helpful for UDP connections, which are lossy.

9. The Template Delete Delay is the time that the BIG-IP device should pause between deleting an obsolete template and re-using its template ID. This feature is helpful for systems that can create custom IPFIX templates with iRules.
10. The Server SSL Profile applies Secure Socket Layer (SSL) or Transport Layer Security (TLS) to TCP connections. You can only choose an SSL profile if the Transport Profile is a TCP profile. Choose an SSL profile that is appropriate for the IPFIX collectors' SSL/TLS configuration.
    SSL or TLS requires extra processing and therefore slows the connection, so we only recommend this for sites where the connections to the IPFIX collectors have a potential security risk.
11. Click Finished.

1. On the Main tab, click System > Logs > Configuration > Log Publishers .
   The Log Publishers screen opens.
2. Click Create.
3. In the Name field, type a unique, identifiable name for this publisher.
4. Use the Log Destinations setting to select an existing IPFIX destination (perhaps along with other destinations for your logs): click any destination name in the Available list, and click << to move it to the Selected list.
   Important: If you configure a log publisher to use multiple logging destinations, then, by default, all logging destinations must be available in order to log to each destination. Unless all logging destinations are available, no logging will occur. If you want to log to the available logging destinations when one or more destinations become unavailable, you must set the logpublisher.atomic db variable to false.
5. Click Finished.

The BIG-IP^® software is shipped with the latest Information Elements (IEs) published by IANA. Each standard element is built into the system. You can use a standard element in your iRules^® by using its name and a ":base" extension (for example, "deltaFlowCount:base" or "observationTimeSeconds:base").

You can use this tmsh command to identify the available base IEs on the system:

list sys ipfix element

If an element is defined by IANA after the BIG-IP software is built, the element is not available in the system software. You can use a similar tmsh command, create sys ipfix element ..., to create such an element and use it in your iRules.

1. On the Main tab, click Local Traffic > iRules .
   The iRule List screen displays a list of existing iRules^®.
2. Click the Create button.
   The New iRule screen opens.
3. In the Name field, type a unique name for the iRule.
4. In the Definition field, type an iRule to match IP fields and log an IPFIX message based on their settings. You can use standard IPFIX elements.
   These sub-steps explain how to create all of the necessary iRule components.
   1. Open a new IPFIX::destination, which is a pre-created log publisher, with the following syntax:
      <ipfix_dest_handle> = IPFIX::destination open -publisher <logging_publisher>

      This returns a destination handle to be used later. The <logging_publisher> is required; this must already exist and include a pool of IPFIX collectors. This is a partition path to the publisher configuration, such as /Common/myPublisher.

      Note: Use a unique name for the variable that holds this handle. If two or more iRules in the same virtual server reference a variable with the same name, the results at run-time are unpredictable. Use the rule name in all of this rule's variables; do this once per destination in the iRule, and store all destinations in static variables. Every message that goes to a particular destination can reference the same static destination handle. Create this and initialize it to empty ("") in the RULE_INIT event.
   2. Create a new IPFIX::template with the following syntax:
      <ipfix_template_handle> = IPFIX::template create "<element_name> <element_name> ... <element_name>"

      This returns a template handle to be used in later IPFIX::msg commands. At least one <element_name> is required, and each element name must be defined through IANA or through tmsh commands. The element order you use here is the order of the IPFIX template. You can use the same element multiple times.

      Note: As with destination variables, template variables must have unique names across all iRules.

      Do this once per template in the iRule, and store all templates in static variables. Every message that uses the template can reference the same static template handle. Create this an initialize it to empty ("") in the RULE_INIT event.

   3. When you match an interesting event, create a new IPFIX::msg with the following syntax:
      <ipfix_message_handle> = IPFIX::msg create <ipfix_template_handle>

      This returns a message handle to be used in later IPFIX::msg commands. Use an <ipfix_template_handle> you created with an earlier IPFIX::template command. This starts the creation of an IPFIX message using the given IPFIX template.

      Note: Choose a unique name for the message across all iRules.
   4. Later in the same IP event, add interesting data the IPFIX::msg with the following syntax:
      IPFIX::msg set <ipfix_message_handle> <element_name> [-pos <position>] <value>

      • <ipfix_message_handle> is an IPFIX::msg you created earlier.
      • <element_name> is the name of an element in the message's IPFIX::template.
      • -pos <position> (optional) only applies to an element that appears more than once in the template. The first instance of an element is element zero. If you omit this, the system applies the value to the first instance of the element (instance zero).
      • <value> sets the value of the element.

      If you use this command on the same element position more than once, the final setting overwrites the previous settings.

   5. Send the finished IPFIX::msg to an IPFIX::destination, using the following syntax:
      IPFIX::destination send <ipfix_dest_handle> <ipfix_message_handle>
   For example, this iRule matches an HTTP exchange and sends a log about its basic parameters to IPFIX collectors:

   # This rule captures HTTP traffic and sends logs to IPFIX collectors.
   
     when RULE_INIT {
       set static::http_rule1_dest ""
       set static::http_rule1_tmplt ""
     }
   
     when CLIENT_ACCEPTED {
       if { $static::http_rule1_dest == ""} {
         # open the logging destination if it has not been opened yet
         set static::http_rule1_dest [IPFIX::destination open -publisher /Common/ipfix_publisher]
       }
   
       if { $static::http_rule1_tmplt == ""} {
         # if the template has not been created yet, create the template
         set static::http_rule1_tmplt [IPFIX::template create "flowStartSeconds sourceIPv4Address tcpSourcePort flowDurationMilliseconds"]
        }
     }
   
     when HTTP_REQUEST {
       # create a new message for this request
       set rule1_msg1 [IPFIX::msg create $static::http_rule1_tmplt]
            
       # compose the IPFIX log message
       IPFIX::msg set $rule1_msg1 flowStartSeconds [clock seconds]
       IPFIX::msg set $rule1_msg1 sourceIPv4Address [IP::client_addr]
       IPFIX::msg set $rule1_msg1 tcpSourcePort [TCP::client_port]
       
       # record the start time in milliseconds
       set start [clock clicks -milliseconds]
     }
   
     when HTTP_RESPONSE_RELEASE {
       # figure out the final duration and add it to the IPFIX log
       set stop [expr {[clock click -milliseconds] - $start}]
       IPFIX::msg set $rule1_msg1 flowDurationMilliseconds $stop
       
       # send the IPFIX log
       IPFIX::destination send $static::http_rule1_dest $rule1_msg1
     }
   }                

5. Click Finished.

1. On the Main tab, click Local Traffic > Virtual Servers .
   The Virtual Server List screen opens.
2. Click the name of the virtual server you want to modify.
3. On the menu bar, click Resources.
4. For the iRules setting, from the Available list, select the name of the iRule that creates custom IPFIX logs. Move the name into the Enabled list.
5. Click Finished.

1. Access the tmsh command-line utility.
2. To show IPFIX usage per IPFIX::destination, use the show command on the sys ipfix destinations tmsh component:
   show sys ipfix destination [<destination-name>]

   Note: The optional <destination-name> narrows the focus to a single IPFIX::destination. If you omit this, the output shows statistics for all active IPFIX destinations.
   For example, this shows statistics for two IPFIX destinations:

   root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)# show sys ipfix destination
   
   --------------------------------------------
   Sys::IPFIX Destination: ipfix_dest_tcp_14279
   --------------------------------------------
   Templates
     Registered            4
     Failed                0
     Withdrawn             2
     Timed Out             2
     Expired               2
     PDUs Sent             0
     PDUs Rejected         0
   
   Data
     Records Added        15
     Records Failed        0
     PDUs Queued           2
     PDUs Rejected        13
     PDUs Sequenced        0
   
   Connections Setup       0
   Connections Closed      0
   Queue High-Water Mark   0
   
   --------------------------------------------
   Sys::IPFIX Destination: ipfix_dest_udp_14279
   --------------------------------------------
   Templates
     Registered           0
     Failed               0
     Withdrawn            0
     Timed Out            0
     Expired              0
     PDUs Sent            0
     PDUs Rejected        0
   
   Data
     Records Added        0
     Records Failed       0
     PDUs Queued          0
     PDUs Rejected        0
     PDUs Sequenced       0
   
   Connections Setup      0
   Connections Closed     0
   Queue High-Water Mark  0
   
   root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)#

3. To show IPFIX-iRule usage on various TMM cores, use the show command on the sys ipfix rules tmsh component:
   show sys ipfix rules

   Each TMM core appears in its own table. The columns indicate the numbers of iRule objects created:

   • The Template column shows the number of times that an iRule invoked the IPFIX::template create command.
   • The Message column corresponds to the IPFIX::message create command.
   • The Destination column corresponds to the IPFIX::destination create command.

   The Total Sends field shows the total number of IPFIX:message send commands invoked on this core, and the Send Failures field shows how many of them failed.

   For example:

   root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)# show sys ipfix irules
   
   ---------------------------------------------
   Sys::TMM IPFIX iRules: 0.0
   ---------------------------------------------
   Memory         Template  Message  Destination
     Allocation          1        7            1
     Outstanding         1        0            1
   
   Total Sends           7
   Send Failures         0
   
   ---------------------------------------------
   Sys::TMM IPFIX iRules: 0.1
   ---------------------------------------------
   Memory         Template  Message  Destination
     Allocation          1        8            1
     Outstanding         1        0            1
   
   Total Sends           8
   Send Failures         0
   
   root@(localhost)(cfg-sync Standalone)(Active)(/Common)(tmos)#