On Mon, Mar 18, 2002 at 10:58:20PM +0100, Patrick Schaaf wrote:
> Hashing with chaining is fine, but for high performance, you want the
> chains only as a backdrop for the occasional hash collision. The "planned"
> oversubscription of the ip_conntrack hash table (1:8 hashsize/conntrack_max)
> do
Hi Harald,
> > On machines where I expect many connections, I'd use a hashsize
> > near the number of expected connections, and make conntrack_max
> > only about two times that value.
>
> But this obviously only helps if the hash function is distributing
> the conntrack entries equally among the
On Tue, 19 Mar 2002 08:56:03 +0100 (CET), Jozsef Kadlecsik
<[EMAIL PROTECTED]> wrote:
>Do you have an SMP machine?
No, it is an old faithful single processor P133.
>Can the crash be reproduced at will?
No. Actually, I have been using the test bed for my phone connectivity
for almost a week befo
> > Hi,
> > Does the old FTOS target zero the ECN bits?
>
> Quick Answer = YES
>
> Long Answer -> FTOS takes whatever HEX code you specify and overwrites
> _all_ 8 bits of the TOS field. So if you only specify say 0xf0 then the
> ECN are overwritten with 0's. make sense?
Perfectly clear, thanks.
> Perfectly clear, thanks. So the FTOS target (but not the new DSCP) can be
> also used to selectively remove the ECN-enabled bit from syn packets going
> to some "bad" hosts throwing away any ECN-enabled connection (until the new
> ECN target is finished ...).
Hmm, but you will overwrite TOS bit
On Tue, Mar 19, 2002 at 09:49:20AM +0100, Patrick Schaaf wrote:
> Hi Harald,
>
> > > On machines where I expect many connections, I'd use a hashsize
> > > near the number of expected connections, and make conntrack_max
> > > only about two times that value.
> >
> > But this obviously only helps
On Tue, 19 Mar 2002, Marc Haber wrote:
> On Tue, 19 Mar 2002 08:56:03 +0100 (CET), Jozsef Kadlecsik
> <[EMAIL PROTECTED]> wrote:
> >Do you have an SMP machine?
>
> No, it is an old faithful single processor P133.
Ack!
> >Can the crash be reproduced at will?
>
> No. Actually, I have been using t
> I'd rather like to have this information to be gathered at runtime within
> the kernel, where one could read out the current hash occupation via /proc
> or some ioctl.
OK, that's what I wanted to hear :-)
Actually, the interesting statistics for a hash are not that large, and all
aggregate:
- Original Message -
From: "Balazs Scheidler" <[EMAIL PROTECTED]>
To: "Jean-Michel Hemstedt" <[EMAIL PROTECTED]>
Sent: Tuesday, 19 March, 2002 08:50
Subject: Re: TPROXY
> On Wed, Mar 13, 2002 at 01:19:30PM +0100, Jean-Michel Hemstedt wrote:
> > hello,
> >
> > I'm quite new to netfilter,
On Tue, Mar 19, 2002 at 12:16:47PM +0100, Patrick Schaaf wrote:
> > I'd rather like to have this information to be gathered at runtime within
> > the kernel, where one could read out the current hash occupation via /proc
> > or some ioctl.
>
> OK, that's what I wanted to hear :-)
Well, it's IMHO
Replying to Patrick Schaaf:
>
> I think I can hack this up, today. Having the flu must be good for something...
It seems that we caught the flu both at the same time.
I will try to 'brain-analyze' hashfn here. Maybe, I shall try radix-tree
approach or something ...
--
Paul P 'Stingray' Komkoff
On Tue, 19 Mar 2002, Patrick Schaaf wrote:
> I agree that the hash function needs scrutiny. Do you (or somebody else
> here) have a good collection of real world /proc/net/ip_conntrack excerpts,
> maybe coming from the development of ctnetlink? I'll cook up a "hash
> occupation simulator" for use
Hi.
Looking into various ways of managing large rulebases using automated tools,
and was thinking, would it make sense to have a hashed jump operation?
I.e. in one operation, jump to one of 2^n chains depending on a 2^n sized
hash of a selected criteria (source, destination ip/port, protocol,
- Original Message -
From: "Patrick Schaaf" <[EMAIL PROTECTED]>
To: "Harald Welte" <[EMAIL PROTECTED]>; "Patrick Schaaf" <[EMAIL PROTECTED]>;
"Martin Josefsson" <[EMAIL PROTECTED]>; "Aviv Bergman"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, 19 March, 2002 12:16
Subject: Re: [Q]
Hello Jean-Michel,
thanks for your input. I appreciate it.
On Tue, Mar 19, 2002 at 03:56:32PM +0100, Jean-Michel Hemstedt wrote:
>
> I'm not a conntrack specialist, neither a kernel hacker, but I've
> some experience with ip hash caches in access servers (BRAS)
> that may be useful(?):
>
> som
> I agree that, since we already use a full division when calculating
> the hash function, we may as well use a power-of-two hashsize. This will
> waste some room in the last OS page of the array, but that's irrelevant
> given the overall size of the array.
Damn. The second lines is of course sup
On Tue, 19 Mar 2002 11:56:50 +0100 (CET), Jozsef Kadlecsik
<[EMAIL PROTECTED]> wrote:
>On Tue, 19 Mar 2002, Marc Haber wrote:
>> No. Actually, I have been using the test bed for my phone connectivity
>> for almost a week before the problem showed for the first time.
>
>Even if you try to reproduce
On Tue, 19 Mar 2002, Maciej Soltysiak wrote:
> > Perfectly clear, thanks. So the FTOS target (but not the new DSCP) can be
> > also used to selectively remove the ECN-enabled bit from syn packets going
> > to some "bad" hosts throwing away any ECN-enabled connection (until the new
> > ECN target
- Original Message -
From: "Patrick Schaaf" <[EMAIL PROTECTED]>
To: "Jean-Michel Hemstedt" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, 19 March, 2002 17:42
Subject: Re: [Q] connection tracking scaling
> Hello Jean-Michel,
>
> thanks for your input. I appreciate it.
>
> On
On Tuesday 19 March 2002 18:47, Paul P Komkoff Jr wrote:
> Have you seen hashed jump in routing code ? packet classifier, etc.
> Unfortunately I've not got it here but you can look at lartc on the
> net and find an example there.
Yes, but what I am interested in at this moment is to how to utili
[cannot claim I have been following the thread closely, mostly
guessing on what you are actually trying to acheive here.. so I may
be way off]
On Tuesday 19 March 2002 12:19, Jean-Michel Hemstedt wrote:
> REDIRECT could work in case of collocated proxy, and only if we
> have control on the pro
Hi!
newnat13 will be hopefully the latest version...
I've now done the following changes from newnat8:
1) ipchains.o and ipfwadm.o did contain unresolved symbols with newnat!
2) re-order members of struct ip_{conntrack,nat}_helper and changed other
patches accordingly
3) ported helper matc
22 matches
Mail list logo
