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!

Adam Howarth

Adam Howarth

Adam Howarth is a technical support representative at Plixer. He works with customers from all over the world, making sure they are getting the most out of their Plixer products. Adam holds CCNA Security certification as well as CNSS 4011 recognition. He also has experience in retail networking, POS systems, ERP administration and has a background in statistical analysis. In his free time he enjoys playing music and audio engineering.

Related