[LARTC] Scalability

[LARTC] Scalability

[George Alexandru Dragoi]

Hello everyone,


I want an opinion from people who tryed different matching modules to
match diferent types of traffic, especially p2p ones.
I would like to hear which scales better as CPU usage and latency :
ipp2p, iptables-p2p or l7-filter with the p2p patterns. I want to use
one of them to block most of p2p (except maybe dc++ and emule which i
want to shape). I would use the matching rules in mangle table, i hope
there is a way not to make the entire traffic matching the rules.
After i mark such traffic, i want to use connmark to mark the entire
stream and then to change the mark based on ip of every LAN client.
Perhaps a tweak would be to send 0x0 marked traffic to a chain and
apply such matches there, so really few traffic will  go to p2p
matching. Everything you people will tell me are very apreciated, i
wil probably begin working on this on a server from now in some days.

Thanks in advance.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Scalability

[Andreas Klauer]

George Alexandru Dragoi wrote:
> Perhaps a tweak would be to send 0x0 marked traffic to a chain and
> apply such matches there, so really few traffic will  go to p2p
> matching.

That's the way I'm doing it. But it's useful only if you're not blocking
the p2p traffic. If you're blocking it, the connection should be closed
anyway, so there's no need to check wether a connection was already
marked or not. At least, ipp2p proposes it this way... you don't need
connmark at all if you're just blocking all p2p traffic.

However, the result won't be that "really few traffic" will go to p2p
matching... it's just that the already identified p2p connections won't
go to p2p matching again.

All other traffic will still go to this chain. ipp2p has no "this is
definitely NOT p2p" return value which would allow for further
optimizations. You could try your luck with some other conditions, like
if a connection was checked 10 times, don't check it again or something
like that.

HTH
Andreas

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Scalability

[George Alexandru Dragoi]

I meant i want to block most of p2p, and allow only few of them and
shape them. So i will use connmark only for dc++ and edonkey. I want
that the bulk non p2p traffic, which is not really few, wont get
parsed by the p2p matches. Such traffic will be matched agains src ip
or dest ip, or port number (I even may may use IPMARK) which is not
CPU destroyer and wont generate bad latency. I know i should post that
to netfilter mailing list, I am still waiting for opinions.



On Wed, 29 Sep 2004 16:42:06 +0200, Andreas Klauer
<andreas.klauer@metamorpher.de> wrote:
> George Alexandru Dragoi wrote:
> > Perhaps a tweak would be to send 0x0 marked traffic to a chain and
> > apply such matches there, so really few traffic will  go to p2p
> > matching.
> 
> That's the way I'm doing it. But it's useful only if you're not blocking
> the p2p traffic. If you're blocking it, the connection should be closed
> anyway, so there's no need to check wether a connection was already
> marked or not. At least, ipp2p proposes it this way... you don't need
> connmark at all if you're just blocking all p2p traffic.
> 
> However, the result won't be that "really few traffic" will go to p2p
> matching... it's just that the already identified p2p connections won't
> go to p2p matching again.
> 
> All other traffic will still go to this chain. ipp2p has no "this is
> definitely NOT p2p" return value which would allow for further
> optimizations. You could try your luck with some other conditions, like
> if a connection was checked 10 times, don't check it again or something
> like that.
> 
> HTH
> Andreas
> 
> 



-- 
Bla bla
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Scalability

[Andreas Klauer]

Am Thursday 30 September 2004 14:42 schrieb George Alexandru Dragoi:
> Such traffic will be matched agains src ip or dest ip, or port number

If you can use these kinds of optimizations, then that's fine.
In my case, P2P applications can run on any port and any IP,
so it's not possible for me. If I added a filter rule like that,
chances are good that clients would find out and use these ports
for their P2P applications.

Andreas
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Scalability

[George Alexandru Dragoi]

My intension is of course to match p2p first, then others. I realised
i must be more carefully  with marks, since it does not get marked
from first packets. I belive some sort of masks applyed to marks are
necesary, the p2p should begin all with, let's say 0x2 then 3 hex
"digits" so i can distinguish non p2p for other purpose later. Is it
possible better ? (i bet it does).

On Thu, 30 Sep 2004 15:00:39 +0200, Andreas Klauer
<andreas.klauer@metamorpher.de> wrote:
> Am Thursday 30 September 2004 14:42 schrieb George Alexandru Dragoi:
> > Such traffic will be matched agains src ip or dest ip, or port number
> 
> If you can use these kinds of optimizations, then that's fine.
> In my case, P2P applications can run on any port and any IP,
> so it's not possible for me. If I added a filter rule like that,
> chances are good that clients would find out and use these ports
> for their P2P applications.
> 
> Andreas
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 



-- 
Bla bla
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/