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...
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_KamnerAltostratus
AltostratusThanks 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
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
