On 15.08.19 11:05, Daniel Tryba wrote:
On Wed, Aug 14, 2019 at 02:52:45PM -0400, PICCORO McKAY Lenz wrote:
In my setups I have a limit of 64 requests per 2s. But I also have whitelist (with/via the permissions module) for known high traffic ipaddresses. Dimensioning the pike module for the known high traffic hosts kind of defeats the purpose of using pike to detect strange unwanted traffic. The correct numbers depend on your endpoints.
i cannot use whitelist due my experiment are for all dinamyc ip clients so what its the meaning of "depend on your endpoints" ?
You need to dimension pike to at least normal expected traffic from your endpoints (and the max number of concurrent channels). If all your endpoints are residential phonelines, you might expect 1 or 2 active calls. In the worst case scenario you might "a few" call setups per second, so maybe bursts of 10 messages per second.
But if you know you have a call center with 50 phones, with a queue to accept bursts you might have more than 50 call setups in a worst case scenario in a second so you might get 150 messages per second from this endpoint (the queue answers directly, so 1 invite might result in a 100 trying, 180 ringing and a 200 OK within a second)
Since there is only 1 setting for pike you have to account for the highest number of legit messages possible.
If you want to keep the pike max number of message lower, you'll need to be creative. Like dynamically create a whitelist of known "excessive" trunks (by username) and exclude the ipaddresses they register from from pike.
Jumping in to point that pipelimit can be an alternative to pike for more dynamic needs. Pike is optimized for source IP addresses, but not as flexible as pipelimit, which can track traffic rates per what-ever-defined key, like user id, ip address, method type, etc ... With pipelimit one can define new "pipe" on-the-fly in routing block, not restricted to static definition via modparam.
Cheers, Daniel