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/
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/
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/
Am Thursday 30 September 2004 14:42 schrieb George Alexandru Dragoi:> Such traffic will be matched agains src ip or dest ip, or port numberIf 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/
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/