On 5/12/06, Tom Eastep <[EMAIL PROTECTED]> wrote: > Yes -- the warnings at the top of the Shorewall traffic shaping > documentation means what they say. > > a) You can't understand Linux traffic shaping by reading just the > Shorewall documentation. >
If I've given you the impression that I'm only reading the Shorewall documentation, my apologies. I might also add that if I've given you the impression that I think I know what I'm doing, well, that's completely wrong as well. I spent 3 1/2 weeks understanding Sendmail by reading documentation and source code back in 1992, and I understand that these things take some effort. > b) You must not expect the Shorewall support team to make up the > difference between what you read in the Shorewall documentation and what > you need to know to make traffic shaping work. If I had the time and the > patience to bridge that gap, I would write a book about Linux traffic > shaping -- I have neither. > I contacted the LEAF list asking for help, and as it turns out, the two obstacles I faced were apparently 100% LEAF Bering distribution related and entirely undocumented i.e. if I want to use some of the more interesting features in Shorewall, I need to load two kernel modules ### required for Shorewall ipp2p ! dir /lib/modules/2.4.32/kernel/net/ipv4/netfilter ipt_CONNMARK ipt_connmark and even with this, LEAF Bering distribution doesn't supply ipt_CLASSIFY and so Shorewall generates rules that the iptables in the Bering distribution cannot accept. I do appreciate your help, but I never contacted the Shorewall support team, I contacted the leaf-users mailing list, and I didn't have any expectation except that I hoped there was some user out there who was using the Bering CD iso and was traffic shaping using ipp2p and they could share with me the basics of what they had to do to get the ipp2p examples out there to work. > I will close by giving you some basic principles: > <snip> > d) When you don't have CLASSIFY target support (as in your case), you > must include 'tc filter rules' in your traffic shaping configuration. > Those rules associate packet marks (fwmark) with tc classes. So in your > case, if you have class 1:50 as your p2p class, then you still need a tc > filter rule that sends packets with mark 50 (or whatever mark value you > use to designate P2P packets) to class 1:50. And remember, ONLY PACKET > MARKS APPLY TO TC FILTER RULES, not connection marks. If you are using > the built-in Shorewall shaper (tc4shorewall) then these tc filter rules > are created for you. > I am editing /etc/shorewall/tcrules to configure traffic shaping and from what I understand from the Bering documentation and Shorewall documentation, the implication is that I am using the built-in shaper. (I do have to load a number of kernel modules as well as the tc package and libm package loaded so that basic tc commands work, like "tc -s qdisc". It appears that the built-in Shorewall shaper requires a working tc command.) > e) Example 6 at http://www.shorewall.net/traffic_shaping.htm is the pp2p > example -- the text explains what each rule does and why. > Right, but a lot of my confusion came about because of the ipp2p example in http://www.shorewall.net/IPP2P.html which has more rules and while apparently similar in behavior, is quite different in syntax, even though the two documents were apparently written on the same day. I guess we're now at the point where I *am* asking a question of Shorewall support LOL. How are those two examples different? Is the sole point of the more complex example to show how to mark a connection with a particular value, and then mark the packets with different classes depending on the destination interface? Is the four rule version sufficient for traffic shaping when there is only one destination interface? Is there any special reason why the four rule version RESTORE tests for zero, while the six rule version does not? Obviously because of this the behavior would be completely different depending on where these rules were included in an existing tcrules setup. Similarly the four rule version uses !0 as the test for SAVE where the six rule version explicitly tests for 1. I also now notice that with the comment fields above that these examples imply that they come first in tcrules (or that they are the complete set of rules). I guess what I'm driving at is that the two examples are quite subtle, and the differences now strike me as incredibly meaningful if the intent is to merge the example with an existing set of tcrules. In particular, the four rule version could apparently be added in at the bottom of any tcrules configuration, because RESTORE tests for zero and CONTINUE tests for non zero so any traffic that's been marked should be left alone and not go through the ipp2p match or SAVE rule. Conversely, the six rule version would only work if it came at the top of a tcrules configuration, because it always RESTOREs (no test) and in that case, since any other packet classification would happen later, it is critical that SAVE and the two rules after explicitly test for the mark they are looking for, as opposed to just doing a SAVE with a non zero test... as that would mean that for all packet marks that they would become persistent and be RESTOREd next time around. (If someone was hiding p2p traffic by running it on the http port, depending on the ruleset, the connection could end up classified that way and never see the ipp2p rules again.) I understand that the examples are just that, examples, and that different people have different ways of doing things, and these look like they came from two different sources. That said, I think it would be interesting to point out the assumptions and the differences between the two, and have found it quite confusing to have two examples, one each, in different files, with similar but important differences. -- Bob ------------------------------------------------------------------------ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
