Blog :: Configuration

IPFIX reporting with F5 Big IP (part 2)

adam

F5’s iRules are a powerful tool used to access information about the network traffic flowing through your load balancer. Using the Tools Command Language Tcl, a common interface found across the networking industry, we can focus on network-level events and extract information. Unlike most IPFIX-exporting devices, the user needs to manually build a netflow monitor in the Tcl/iRule environment. This means determining which metrics are important to us, where in the conversation they can be collected, and how the IPFIX messages will be structured prior to export.

The following example will review how to build a simple iRule to collect basic data from a virtual server load balancing HTTP traffic.

First, per F5’s recommendation, we need to initialize two variables when the iRule is first loaded:

when RULE_INIT {
   set static::IPFIX_DST ""
   set static::IPFIX_TEMPLATE ""
}

These values will be defined on the first client connection through the virtual server, then persist as long as this iRule is actively deployed.

This section references the IPFIX publisher defined in the previous section of the blog as “IPFIX_DST.”

This is analogous to defining an export destination in a Flexible NetFlow configuration.

IPFIX_TEMPLATE defines the structure of the exported flow messages as a list of fields.

when CLIENT_ACCEPTED {
   if { $static::IPFIX_DST == ""} {
      set static::IPFIX_DST [IPFIX::destination open -publisher /Common/name of IPFIX publisher from previous section]
         }
   if { $static::IPFIX_TEMPLATE == ""} {
      set static::IPFIX_TEMPLATE [IPFIX::template create "flowStartSeconds protocolIdentifier sourceIPv4Address destinationIPv4Address tcpSourcePort tcpDestinationPort flowDurationMilliseconds octetDeltaCount packetDeltaCount"]
         }
}

Next, we will begin collecting details about the client host and start a clock to monitor the duration of the exchange. This is tied into the HTTP_REQUEST network event. A new flow record is created using the IPFIX_TEMPLATE, then source IP and port are collected.

 when HTTP_REQUEST {
   set HTTP_msg [IPFIX::msg create $static::IPFIX_TEMPLATE]
   IPFIX::msg set $HTTP_msg sourceIPv4Address [IP::client_addr]
   IPFIX::msg set $HTTP_msg tcpSourcePort [TCP::client_port]
   set start [clock clicks -milliseconds]
}

Next, we will collect details about the server side of the connection when the HTTP_RESPONSE event is triggered. Collecting this type of information is critical in understanding how your virtual server has load balanced individual client sessions. For example, after a user reported poor performance at a certain time the previous week, we could go back and review exactly how their connection was handled and then address then problem service endpoint.

when HTTP_RESPONSE {
      IPFIX::msg set $HTTP_msg destinationIPv4Address [IP::server_addr]
      IPFIX::msg set $HTTP_msg tcpDestinationPort [TCP::server_port]
      IPFIX::msg set $HTTP_msg protocolIdentifier [IP::protocol]
}

Finally, we will collect the summarized information about our connection. To avoid overstating, we will collect metrics from only the server side of the virtual server. Additionally, here we’ll stop our duration counter for a time export and send our IPFIX message via our defined IPFIX destination.

when SERVER_CLOSED {
   set stop [expr {[clock click -milliseconds] - $start}]
   IPFIX::msg set $HTTP_msg octetDeltaCount [IP::stats bytes in]
   IPFIX::msg set $HTTP_msg packetDeltaCount [IP::stats pkts in]
   IPFIX::destination send $static::IPFIX_DST $HTTP_msg
}

Combining the sections above will give you the basic building blocks for exporting IPFIX data, which accounts for the traffic handled by a virtual server. As I mentioned in the first installment of this blog, iRule application should be handled with care and under the supervision of an F5 SME to avoid any possible interruptions to the service being balanced over the target virtual server. Once you have flow data coming from your F5 you still need a collector to send it too! Check out Scrutinizer, our high-performance IPFIX collector and analysis solution that can collect metadata from all of your network infrastructure including F5s!