AFM Enhancements in BIG-IP v13

As you've noticed, DevCentral is covering some new features of F5 BIG-IP version 13 this month.  Today we'll review some core updates to Advanced Firewall Manager (AFM). Next week we'll dive deeper into AFM DoS service improvements. In BIG-IP v13, AFM looks to improve performance, expand configuration flexibility, and make your administrative life a bit easier; something we all need.

Per-Policy Compilation: YES!

Prior to v13, policy compiling could be a lengthy process. Compiling monolithic polices with large rule lists/rules resulted in high memory use and long waits (depending on the depth of the policy).  BIG-IP v13 introduces a per-policy compilation variable designed to alleviate these symptoms.

(tmos)# show security firewall container-stat field-fmt
security firewall security {
    activation-time-fmt Mar 17 2017 09:44:46-0700
    compile-duration-fmt 0:0:0
    container-size 14.3K
    context-name vs_kielbasa
    context-type virtual
    ovrlpck-duration-fmt 0:0:0
    per-policy-compilation Yes
    policy-name afm_policy_a
    policy-type Staged
    process-mem 54.3M
    rule-count 5
    slot-id 0

This enables the Packet Correlation Classification Daemon (pccd) to detect changes, and recompile only changed policies.  Unchanged policies will have results copied from the compiled policy objects.  The above TMSH command displays the enabled variable but it can be turned off for various reasons if needed (talk to F5 support prior to screwing around with db variables).

Pccd received several other updates, honorable mentions below:
  • Increased memory usage statistic accuracy - useful for diagnostics
  • Compiler Speed Improvements
  • Improvements to HA handling - Active/Standby delays are reduced and stability improvements
  • Rule overlap check improvements now includes unused policies

Send To Virtual Server Enhancements

Prior to v13, users were limited to source/destination address and port when selecting virtual servers in rules. Now any attribute used to match firewall rules can be used to select the virtual server.

In the above image we are selecting GeoIP-based traffic and sending them to HADES, our honeypot virtual server. We can add additional conditions including:

  • VS & Policy based on Geolocation
  • VS & Policy for non-contiguous port ranges
  • VS & Policy combinations of full 5-tuple (and VLAN/Geo/FQDN)

We can expand our use cases with these enhanced conditions and create value add for other BIG-IP modules like AAM/LTM so only specific data classes proceed on to downstream services; think Geolocation/User based DNS/WAF/TCP options policies.  These improvements should allow you to reduce firewall complexities and maybe even remove some of the patchworks implemented to get around the previous versions limitations.

As with new features, there are some caveats to be aware of (highlights):

  • Send to Virtual rules are applicable in global and route domain contexts
  • No recursive redirects (no re-redirects)
  • You cannot swap protocols with Send to Virtual
  • Traffic and the virtual server addressing must be in the same family (IPv4/IPv6)
  • Traffic and the virtual server must be in the same route domain

To review statistics for traffic handled by a Send to Virtual rule use:

tmctl fw_sendtovirtual_stats


BIG-IP's AFM's increased flexibility and performance is making firewall administration nearly enjoyable at this point.  Not that I'd rather build rule sets over going Skiing, but it's a heck of a lot easier.  As we investigate more AFM improvements next week, you'll start to see how big BIG-IP v13 really is.  If you haven't downloaded an evaluation copy yet, what are you waiting for?  Let us know if you want us to dive deeper on these and other changes.  Thanks for reading!

Published Mar 20, 2017
Version 1.0

Was this article helpful?


  • Hi,


    Great article. I wonder what user means in this info "VS & Policy based on Geolocation or User". I can't see anything looking as user specification in rule definition - or Subscriber field in Source means user? If so how users are identified? Based on config in new Subscriber Management section? This sections seems to be related to PEM module - or it can be used without PEM license?


    Another question is about statement in limitations "Send to Virtual rules are applicable in global and route domain contexts". Is that mean this will not work if policy will be applied to VS?




  • Per your second question, the policy will work for a virtual server if they're in the same route domain or global policy. A diff between policy and virtual server can create a mismatch count in tmctl. This increments the protocol, address, or route domain mismatch counter.


    For the VS/Policy based on GeoIP or User, think in terms of mixing previously unusable attributes to match against a VS.


    Source Specifies packet sources to which the rule applies. Leaving this field blank applies the rule to all addresses and all ports. You can specify the following source/destination items when matching a VS:


    • an IPv4 or IPv6 address
    • an IPv4 or IPv6 address range
    • FQDN
    • geographic location
    • VLAN
    • address list
    • port
    • port range
    • port list
    • address list

    From there, the idea is to combine the VS receiving the traffic into other modules. I do not have PEM licensed on this system to make these options available.


  • Hi,


    Thanks for answer. Still a bit lost, maybe I am not getting context concept right. To make it simpler (I hope), let's assume I am creating Policy that has rule using Sent to and then assign it to VS, will it work?


    For first question I was specifically interested what is user as source, it was mentioned before in some articles but never with explanation how user is identified. I have no PEM license as well but still in v13 interface there is section Subscriber Management available (seems to be related to PEM so I am puzzled why it's there). Another topic is Subscriber option as Source when creating Rule - no info about it in BIG-IP help but still it's there.




  • Piotr;


    Sorry for the delay. I had to go back into my notes to find out the source from where I referenced "user". We had gone down a "sandbox" route and using several iApps were able to map user to IP address and then apply that to the AFM rules. It was messy so I am going to update this article to remove that until we figure out how to make it easier. It is not an APM user/group or PEM subscriber policy like you would want it to be.


    For your first question. If you're creating a policy that has a Send To: and assign to a VS, that is supported in v13.


  • Hi Chase,


    Waiting for deep dive article on 'AFM DoS service improvements'