Hi Stephan,
If route domain entries in the datagroup isn't working, I'd suggest opening a case with F5 Support. In the meantime, I think you could create the datagroup with a slightly different format and still get this to work.
If all of the entries are in the same route domain, you could omit the route domain from the datagroup, do a check to see if the client IP is in that route domain and if so, use class match to see if there is a match.
If you want to support multiple route domains in the same address type datagroup, you could create separate datagroups for each route domain using the route domain number in the name of the datagroup.
class 123
class dg_rd123_ip {
{
host 10.123.123.80
network 10.123.123.96/28
}
}
class 456
class dg_rd456_ip {
{
host 10.123.123.100
network 10.123.123.96/28
}
}
You could then strip off the route domain from the client IP if it's there:
when CLIENT_ACCEPTED {
Check if there is a route domain in the IP::client_addr value
if {[scan [IP::client_addr] {%[^%]%%%s} ip rdomain] == 2}{
There was a route domain for the client IP address
Check if there is a corresponding class
if {[class exists "dg_rd${rdomain}_ip"]}{
There is a corresponding class, so check if the client IP is in it
if {[class match $ip equals "dg_rd${rdomain}_ip"]}{
Client IP is in the corresponding class
}
}
} else {
Client IP doesn't have a route domain, so look up against a default route domain datagroup? ...
if {[class match [IP::client_addr] equals "dg_rd_default_ip"]}{
Client IP is in the corresponding class
}
}
}
Granted this is a hack, but it should give you a way to support route domains for the scenario until you get a fix from F5.
Aaron
Nimbostratus
