Forum Discussion
Marco_Kamner
Altostratus
Altostratus/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
- Nikoolayy1
MVP
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> 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
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
- Marco_Kamner
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
- Nikoolayy1
1.You mentioned that even when you don't add /32 it still does not work as when you are creating internal data group you don't need to add /32.
https://clouddocs.f5.com/cli/tmsh-reference/v13/modules/ltm/ltm_data-group_internal.html
2.I still recommend checking bug tracker for data group issues that match yours:
https://support.f5.com/csp/bug-tracker?sf189923893=1
3.The final thing is to do "tmsh load sys config verify" for to see if there are errors and if you don't see any maybe do mcpd reload to clean the config and I am out of ideas :) :
https://support.f5.com/csp/article/K13030
- Marco_Kamner
To follow up on what you wrote:
- You are correct there, I do not need to add it explicitly - trying it both ways, as discussed above, was more of a paranoia move
- I did by now check the bug tracker for our exact version and unfortunately did come up empty
- I will take a look at this, though I think we are not looking at a de-sync of text vs binary config here
Again, thanks a lot for your help and ideas on this Nikolay
- Nikoolayy1
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
