mynetworks hash tables
in [Postfix]
|
Prev: same mailboxname in both virtual alias maps && virtual mailboxmaps to create a forward ?
Next: Postfix inbound message configuration
From: Noel Jones on 3 May 2010 17:58 On 5/3/2010 4:30 PM, Gary Smith wrote: >>> I have a need to migrate some IP's from a static file to a hash file. These >> are singleton IP's (hash CIDR's). >> >> hash != cidr > > It was meant to read "singleton IP's (not CIDR's)". I need to do a little more proof reading before sending out these things. > >>> i.e. would this be acceptable for this type of map? >>> 10.20.0.2 ok >>> 10.20.1.91 ok >>> ... >> yes. but in this case, prefer cidr over hash. > > I think we are dealing with 50 or so IP's on a bunch of different blocks. The 10.20.x.x above was an example. Almost everything in the mydestination file is currently /32, with the exception of our internal ranges. It's these /32 that would be migrated to a hash. Either hash: or cidr: tables will work well for that purpose, with likely no measurable difference in overall performance. Hash: has the advantage that postfix will recognize changes automatically and restart affected services right away. Cidr: will take a little longer to pick up changes, but should use a little less memory (with your stated ~50 entries). I'd go with hash: if memory isn't an issue. -- Noel Jones
From: mouss on 4 May 2010 15:56
Noel Jones a �crit : > On 5/3/2010 4:30 PM, Gary Smith wrote: >>>> I have a need to migrate some IP's from a static file to a hash >>>> file. These >>> are singleton IP's (hash CIDR's). >>> >>> hash != cidr >> >> It was meant to read "singleton IP's (not CIDR's)". I need to do a >> little more proof reading before sending out these things. >> >>>> i.e. would this be acceptable for this type of map? >>>> 10.20.0.2 ok >>>> 10.20.1.91 ok >>>> ... >>> yes. but in this case, prefer cidr over hash. >> >> I think we are dealing with 50 or so IP's on a bunch of different >> blocks. The 10.20.x.x above was an example. Almost everything in the >> mydestination file is currently /32, with the exception of our >> internal ranges. It's these /32 that would be migrated to a hash. > > Either hash: or cidr: tables will work well for that purpose, with > likely no measurable difference in overall performance. > Hash: has the advantage that postfix will recognize changes > automatically and restart affected services right away. Cidr: will take > a little longer to pick up changes, but should use a little less memory > (with your stated ~50 entries). I'd go with hash: if memory isn't an > issue. > I would go with cidr, since these are networks, when one can list a /32; then move it to a /31 then to .... and to a /19. |