F5 BIG-IP icon   F5 BIGIP – Bug when using datagroups in LTM policies



Datagroups can be used in LTM policies to, for example, filter connections based on the client IP address (at least in my BIG-IP v13.0.0)

This is possible by adding a condition like this:
F5 BIGIP - Bug when using datagroups in LTM policies 1

“TCP” – “address” – “matches” – “in datagroup” <DATAGROUP> – at “request” time
(apply traffic on “remote” side of “external” interface)

Problem

This works correctly when the datagroup used in the condition is the only created one (in addition to the “aol”, “images” and “private_net” default ones)
F5 BIGIP - Bug when using datagroups in LTM policies 2

But if another datagroup is created…
F5 BIGIP - Bug when using datagroups in LTM policies 3

Altough we configure it in the condition…

F5 BIGIP - Bug when using datagroups in LTM policies 4

it seems the LTM policy only verifies the first datagroup that come first in order in the datagroup list (in this example DG_External_Providers) instead of the one configured in the rule (DG_External_Providers_2)

Workaround 1

As a workaround, not sure if using “any of” instead of “in datagroup” in the condition can be used:
F5 BIGIP - Bug when using datagroups in LTM policies 5

Workaround 2

The equivalent IRule to the condition does not reproduce the bug, so its a good workaround.

when HTTP_REQUEST {
   if { [class match [IP::client_addr] equals DG_External_Providers_2]} {
   log local0. "[IP::client_addr] IP client accepted"
   ...
   }
}

Bug ID

F5 confirmed this behaviour is bug-related, and they have filled bug ID688744 to track this problem. Since this is a new bug, no fix is available yet.

Update:
The issue has been solved on v13.1.0.8.
See https://support.f5.com/csp/article/K11793920 for details.

2 thoughts on “F5 BIGIP – Bug when using datagroups in LTM policies

Leave a Reply

Your email address will not be published. Required fields are marked *