Forum Discussion
Hi Kai,
he left our company some time ago , so I'm trying to get up to date with irules myself :-) .Basic irules isn't really an issue but I'm new to many of these commands used.
From what I see in this irule , a subtable is created for each combination of clientIP&uri. Entries in the subtable are mentioned with a lifetime of 20sec.Irule is counting the entries for each new HTTP_REQUEST.The timeout value ensures that they are forced out of the table , after the defined interval.
From your first remark , I understand it has no value putting the clientIP & uri into the subtable as a value . (as subtables are created per clientIP & uri) .The command you gave , is just putting a value "1" into the table . So we're consuming less memory per subtable because we are storing less info . Correct ?
The 2nd remark is basically to avoid using strict numeric as keys .But instead using "clock ticks" as key.As older entries get deleted , the count could remain the same and irule would start to overwrite existing entries in a subtable. (so risk of re-using same key several times. Clock ticks as key will avoid this)
I'm going to make the changes on acceptance setup & add some logging over there for further checking . we'll deploy to production also , but it gives me the opportunity to get acquainted with this irule.
We are still investigating the issue with the aborted connections. But it's more and more linked to specific client networks.(always same client IP's are getting aborted ) So looks like some specific client network setting is causing this. We're trying to identify a client & start testing with them.
greetings , werner
- Kai_WilkeDec 22, 2015MVPYou got my remarks 1 and 2 right. Its an easy to implement change, which would just correct certain things as they should be. Also I didn't noticed the rather small 20sec timeframe setting. So in this case the maximum amount of blocked memory is somewhat limited and would most likely not be enought to land your entire LTM. Seems save to me then... Good luck finding the the root cause of your problem. My gut feeling says, that fragmented TCP datagrams may be the root cause of the connection problems of this specific network (e.g. too large MSS values) :-)