The DevCentral iRules, iControl, & Advanced Design & Configuration wikis are flourishing.  However, if you are not listening to the weekly roundup podcast, you may not be aware of the excellent contributions hitting the site.  This series will highlight new and interesting contributions from you, the community!

Ruby makes a splash

Community member mkelly spends significant cycles in testing and developed some iControl tools to increase the efficiency of test scenario setup and teardown.  The first three are standalone tools that allow you to create/delete bulk nats, vips, and wips, the remaining are classes that must be called from a Ruby program that allow you to switch the WebAccelerator policies and change BigIP profiles/routes on the fly.  Thanks mkelly for being the initial Ruby contributor!

  1. Bulk Nat Maker
  2. Bulk Vip Maker
  3. Bulk WideIP Maker
  4. WebAccelerator Policy Switcher Class
  5. BigIP Profile Switcher Class
  6. BigIP Route Changer Class


This nifty iRule performs NAT on ftps in clear command channel mode by searching for 227 Entering Passive Mode in the server response and corrects the IP address so that the client will connect to the correct address.  Kudos to member jos.andel for this handy submission!

# Set DEBUG to 1 to get debug-logging of this iRule in /var/log/ltm

when RULE_INIT {

  set DEBUG 0



if { $::DEBUG } { log local0. "FTP connection from [IP::client_addr]:[TCP::client_port]. \

Mapped to [serverside {IP::local_addr}]:[serverside {TCP::local_port}] \

-> [IP::server_addr]:[serverside {TCP::remote_port}]" }





  # If in debug mode, log payload of received packet

  if { $::DEBUG } { log local0. "payload " }

  # check if payload contains the string we want to replace

  if { [TCP::payload 50] contains "227 Entering Passive Mode" }


     # If in debug mode, log that the payload matched

     if { $::DEBUG } { log local0. "payload matched" }

     # use a regular expression to save the dataport part of the pasv output

     regexp "\[0-9]{1,3},\[0-9]{1,3},\[0-9]{1,3},\[0-9]{1,3},\(\[0-9]{1,5}),\(\[0-9]{1,5})"  TCP::payload] all first second

     # empty payload entirely so there is no packet to send to the server

     # then fill the packet with the new 227 string

     TCP::payload replace 0 [TCP::payload length] ""

     # edit rule below to match your virtual-server ip address

     set packetdata "227 Entering Passive Mode (xx,xx,xx,xx,$first,$second)\r\n"

     TCP::payload replace 0 0 $packetdata

     # if in debug mode, log the new payload to /var/log/ltm

     if { $::DEBUG } { log local0. "changed payload " }


    # release the packet, and collect a new one




F5 Wireshark Plugin

This one really should get more attention.  Yeah, it's a little more work on the front-end to patch the source and compile, but it may very well help you troubleshoot flows through the LTM with the additional information provided in the decodes.  Looking at the source of the plugin, some of the additional details available when capturing on your LTM (version 9.4.1 and later) include the TMM & VIP servicing the flow, the flow ID and type, the HA unit, the ingress slot & port, the vlan, etc.  This Wireshark plugin was contributed by the good folks here at F5 Networks. 

That's it for this edition.  Keep the influx coming, community.