Forum Discussion

Marco_Kamner's avatar
Marco_Kamner
Icon for Altostratus rankAltostratus
Jun 02, 2021

/32 IPs in Datagroup class match not matching

Hello everyone, maybe someone had a similar issue before and can guide me in the right direction as I can't find anything regarding this on the whole of the internet. Lets assume a simple iRule...
application delivery
iRules
LTM
  • Marco_Kamner's avatar
    Marco_Kamner
    Jun 07, 2021

    Thanks to the suggestion of using a external data group by  we did dig in to this again.

    Before going into how we solved this I just want to say that we are going to look into filing a issue about this and some of my technical understanding of the cause may be flawed.

    The root of the issue lies expression:

    [class match [IP::client_addr] equals ipv4_monitoring]

    The internal datagroup ipv4_monitoring was created with this content:

    • 198.51.100.0/24
    • 203.0.113.2/32

    And, looking at bigip.conf, we can verify that this gets persisted into configuration.

    But, whatever we add with /32 it will not match -> This is where we will look into filing a issue with F5, I will update this thread as applicable.

    Now we remove and recreate the data group using a external data group containing this:

    network 198.51.100.0/24,
host 203.0.113.2,

    And now we get a match in the expression in question and can live happily ever after

Marco_Kamner's avatar
Marco_Kamner
Icon for Altostratus rankAltostratus

> First of all you are using internal or external data group?

I'm using a internal data group

 

> The second is from what I see you may not need to specify the /32 mask in a data group, when you specify a host IP address so test this:

You are indeed true here, either way the /32 gets automatically stripped when saving the data group.

Out of paranoia I tested with both adding it and not adding it and it seems to make no difference in the experienced behavior.

 

From the documentation I gather it should not make a difference if this is a internal or external data group, would you recommend creating a external one to test if the behavior persists?

Nikoolayy1's avatar
Nikoolayy1
Icon for MVP rankMVP
Jun 07, 2021

1.Yes, you could do this testing with external data group as ou can check the bug tracker for known data group bugs for your tmos version https://support.f5.com/csp/bug-tracker?sf189923893=1.

 

 

2.Also add "" for the datagroup name when matching it as shown in the example:

 

https://clouddocs.f5.com/api/irules/class.html

 

when HTTP_REQUEST {

if { [class match [IP::client_addr] equals "localusers_dg" ] } {

COMPRESS::disable

}

}

 

 

It should look like:

 

 

    if { ([class match [IP::client_addr] equals "ipv4_monitoring"]) or ([class match [IP::client_addr] equals "ipv6_monitoring"]) } {

 

 

 

3.A final thing is to add log local0. too see if you matching the two switch statements as you may not match them and this is why the data group evaluation is never triggered. Add log local before and after the first switch -glob and so do for the second to follow your traffic. If you see issues use Fiddler or HTTPWatch to debug the HTTP traffic from a test client workstation.

 

 

 

 

https://devcentral.f5.com/s/articles/the101-irules-101-logging-amp-comments