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, I stripped out a lot of irrelevant things for readability.

when HTTP_REQUEST {
    switch -glob -- [string tolower [HTTP::host]] {
        "example.org" {
            set ha_pool "my-pool"
            switch -glob -- [string tolower [HTTP::path]] {
                "/" {
                    # ...
                }
                "/securestats" {
                    if { ([class match [IP::client_addr] equals ipv4_monitoring]) or ([class match [IP::client_addr] equals ipv6_monitoring]) } {
                        set members [active_members -list $ha_pool]
                        HTTP::respond 200 content $members
                    } else {
                        HTTP::respond 403 content {<html>403 Unauthorized</html>}
                    }
                }
            }
        }
        # ...
    }
}

The data group looks like this:

ipv4_monitoring:

  • 198.51.100.0/24
  • 203.0.113.2/32

When a request now hits the if containing the class matches on the two data groups something strange happens.

198.51.100.1 matches and gets the HTTP::respond 200

203.0.113.2 does not match and therefore gets the HTTP::respond 403

IPs and Names in the iRule have been changed to nonsensical but coherent values

  • 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

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

     

    https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-system-irules-concepts-11-6-0/6.html

     

     

     

    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:

     

     

     

    https://clouddocs.f5.com/cli/tmsh-reference/v13/modules/ltm/ltm_data-group_internal.html

     

     

     

    https://support.f5.com/csp/article/K73862425

     

    • 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

        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

  • 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

  • Have had info from F5 about the issue?

     

     

    Also you may check if the internal data groups work when used with Local Traffic Policy and not an iRule as the Local Traffic Policies have less bugs than iRules as Local traffic policies are F5 checked and verified.

     

     

    https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/big-ip-local-traffic-management-getting-started-with-policies-14-0-0/01.html

     

     

     

    Also you want to test mcpd reload just in case as this will clean the bigip.conf file issues as we see that there are issues with internal but not external data groups.

     

     

    https://support.f5.com/csp/article/K13030