Modify iRule Table through iControlREST ?

Thanks for replying.

 

I found the data-group function in the iControlREST documentation, but I didn't see anything about tables.

 

https://devcentral.f5.com/s/articles/the101-irules-101-datagroups-amp-tables

 

OK ok

curl -k -u admin:'blah' -H "Content-Type: application/json" -X PUT -d '{"name":"dg_ip_blacklist","partition":"/Common","source-path": "http://10.2.3.4:8080/etc/ip_blacklist.txt"}' https://10.191.58.180/mgmt/tm/sys/file/data-group/dg_ip_blacklist/?$filter=partition%20eq%20Common

If you'd rather manipulate data group entries individually you can use an internal datagroup and you should be able to use iControl REST to do that too.

The best fit for an IP Blacklist to be accessed from an iRule is an 'address' type datagroup (either internal or external), not a session table. Datagroups are like a keyed table that exist in memory, and can easily be accessed from an iRule.

If you really really need to use the session table this can be done remotely too (however you wouldn't use iControl REST). We can discuss if necessary but you'd have to have an unusual use-case.

I found the way to do this with the internal data-group function.

Unfortunately there is still not a function in the iControlREST API that allows me to append IPs to the list without updating the entire list each time in the payload.

Hi Ben, this is because data-group records are not subcollections. If they were it would be trivial. See this article for more details.

 

Any idea if it is on the roadmap to make data-groups a subcollection?

Should we have concerns if working with thousands of records at a time that might be getting updated repetitively? Since I have to perform a get of 8000 records, add 40 records, repeat every minute, etc. (It would be an internal data-group and IP type).

Thanks for the help.

Hi Ben, yes, the bug ID is 540657, you can open a case and make sure to add it against this bug.

Just to give F5 and the community a heads up, that we performed a loadtest this morning and during the loadtest I repetitively sent PUT calls with a JSON payload of 8000 IPs to the iControl Endpoint.

Each request took appx 5 seconds to get a response and generated significant CPU spikes. (2 cores hitting 80%+)

For context: Viprion Chassis (C2400)

Guest: BIG-IP 12.1.0 Build 2.0.1468 Hotfix HF2 vCMP 4 Cores

Continuously sending large payloads does not appear recommended at this time.