Bug 598

Summary: Optimal rrl-size
Product: NSD Reporter: Sergei Mamonov <mrqwer88>
Component: DocumentationAssignee: NSD team <nsd-team>
Status: ASSIGNED ---    
Severity: enhancement CC: wouter
Priority: P5    
Version: 4.0.x   
Hardware: Other   
OS: Linux   

Description Sergei Mamonov 2014-07-27 09:37:16 CEST
How can we calculate the rrl-size?
How it is spent?
Now, with suspiciously small number of locks is a lot of errors "bucket collision" - 
mamonov@ns2:~$ grep -c "ratelimit block" /var/log/nsd.log.1
32
mamonov@ns2:~$ grep -c "bucket collision" /var/log/nsd.log.1
8
mamonov@ns2:~$ grep -c "ratelimit block" /var/log/nsd.log
11
mamonov@ns2:~$ grep -c "bucket collision" /var/log/nsd.log
3

It have very little information in nsd.conf.sample and http://www.nlnetlabs.nl/blog/2012/10/11/nsd-ratelimit/ .
And unthinkingly increase rll-size not good.
Too much hash should result whith overspending memory and performance degradation.

Now we have 4.0.4, default rrl-size - 1000000 and rrl-ipv4-prefix-length: 32.
Comment 1 Wouter Wijngaards 2014-07-28 11:00:57 CEST
Hi Sergei,

For your case I would increase the rrl-size by 10x.

You have the prefix length set to 32bits, but the default is 24bits.  With 24bits there would be less collisions.  But perhaps you wanted more details in the ratelimits (for some reason)?  The /24 is because that is a network that likely shares the same upstream pipe (and DNS resolver).

Best regards,
   Wouter
Comment 2 Sergei Mamonov 2014-07-28 17:18:02 CEST
But why 10x?
Between 32bits and 24bits the difference is not 10x.

We want to drop and etc. only attacks ip, not all subnet.
Because we use rrl-ipv4-prefix-length - 32.
Comment 3 Wouter Wijngaards 2014-07-30 09:12:30 CEST
Hi Sergei,

The 10x is an estimate.  Then you can look at the logs again.

It is using a lot more of the rrl to keep track of the non-blocked traffic, i.e. how many packets per second for them.  That is where you are getting the collisions from, not (so much) from the rrl entries used to block.

Best regards,
   Wouter