On 5/11/06, Tom Eastep <[EMAIL PROTECTED]> wrote: > Tom Eastep wrote: > > Bob Ramstad wrote: > >> On 5/11/06, Bob Ramstad <[EMAIL PROTECTED]> wrote: > >>> I see 22 connections with mark=1 right now, and 7 with mark=0 right > >>> now... and I suspect that if all 22 mark=1 connections were being set > >>> to class 50, the system would be behaving as I'd like. > >> I really thought I had it, but again, stymied. I came to the > >> conclusion that the connection was being marked, but the packets > >> obviously were not... so when RTFM I stumbled the documentation for > >> TEST :C in tcrules for matching a connection flag vs matching a packet > >> flag, and modified the last line in my recipe: > >> > >> RESTORE:F - - tcp > >> CONTINUE:F - - tcp - - - !0 > >> 1:F - - ipp2p ipp2p > >> SAVE:F - - tcp - - - 1 > >> 50 - - - - - - 1:C > >> > > > > That's because, except for the first p2p packet, all of the rest are > > getting packet mark = 1 -- not 50. > > > > Switch the third rule to 50:F and ditch the 5th rule. > > Oh -- and change the last column of the 4th rule from 1 to 50. > > -Tom
Thanks for helping, neighbor. (I'm just down the road from you in Ballard.) I'll try your changes tomorrow and let everyone know what happens. I'm kind of baffled as to why the example the ipp2p people wrote would work -- it seems way more complicated than what I was trying to do -- and yet what I did wouldn't work. The ipp2p example if I understand it correctly marks p2p traffic with a 1, and then takes everything that is marked with a 1 and puts it in one of two classes depending on the interface used. My version, above, is kind of stupid but basically was trying to do the same thing... mark p2p traffic with a 1, and then take everything marked with a 1 and put it in class 50. Certainly I don't need the flexibility of the ipp2p approach, and simple = good, so if four rules work and do what I need, excellent. While I'm at it, do you see the potential for a global performance penalty from these rules? 10:F - 10.11.1.0/24 tcp http 20:F - 10.11.1.0/24 tcp smtp 20:F - 10.11.1.0/24 tcp domain 20:F - 10.11.1.0/24 udp domain RESTORE:F - - tcp CONTINUE:F - - tcp - - - !0 50:F - - ipp2p ipp2p SAVE:F - - tcp - - - 50 In particular, since the class 10 and class 20 do not retain QoS on a per connection basis i.e. mark=0, and all rules are evaluated from top to bottom, it seems these classes every time will be re-evaluated for the possibility of being p2p traffic. I suppose if one was very paranoid (like if you were giving higher priority to http, and think people might be running p2p on port 80) that this might be appropriate, but would I see better performance by making those CF i.e. have a rule set of 10:CF - 10.11.1.0/24 tcp http 20:CF - 10.11.1.0/24 tcp smtp 20:CF - 10.11.1.0/24 tcp domain 20:CF - 10.11.1.0/24 udp domain RESTORE:F - - tcp CONTINUE:F - - tcp - - - !0 50:F - - ipp2p ipp2p SAVE:F - - tcp - - - 50 The docs indicate that adding the C tells the system to mark the connection with the appropriate code. I would think that this would be a good idea, but I'm not sure, and am also not certain that this is sufficient to do what I want. The other idea I had was: 10:F - 10.11.1.0/24 tcp http 20:F - 10.11.1.0/24 tcp smtp 20:F - 10.11.1.0/24 tcp domain 20:F - 10.11.1.0/24 udp domain RESTORE:F - - tcp CONTINUE:F - - tcp - - - !0 50:F - - ipp2p ipp2p SAVE:F - - tcp - - - 50 SAVE:F - - tcp - - - 10 SAVE:F - - tcp - - - 20 Finally, if this worked, it seemed that it might make sense for the rules to be reordered, to take advantage of the connection being marked and CONTINUE allowing a quick exit i.e. RESTORE:F - - tcp CONTINUE:F - - tcp - - - !0 10:F - 10.11.1.0/24 tcp http 20:F - 10.11.1.0/24 tcp smtp 20:F - 10.11.1.0/24 tcp domain 20:F - 10.11.1.0/24 udp domain 50:F - - ipp2p ipp2p SAVE:F - - tcp - - - 10 SAVE:F - - tcp - - - 20 SAVE:F - - tcp - - - 50 Thoughts? -- Bob ------------------------------------------------------------------------ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
