My class got over early so I have a little time to try to answer some of your questions.
Bob Ramstad wrote: > On 5/12/06, Tom Eastep <[EMAIL PROTECTED]> wrote: > >> > > 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. Then please post the contents of your /etc/shorewall/tcdevices and /etc/shorewall/tcclasses file. You have been talking about class 50 -- Shorewall's built-in traffic shaping can't generate a class 50 unless you have 50 interfaces (in which case the major class will be 50). > (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. With two documents bearing copyrights back to 2001, it is preposterous to conclude that they were written the same day. They were *last updated* 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? The example in the IPP2P document clearly states that it is a one-to-one translation of Example 2 in the IPP2P documentation into Shorewall rules (or what Example 2 was when I originally wrote the document in 2004). The original set of rules used the CLASSIFY target -- hence, I couldn't very well omit it from the translation. Is the four rule version sufficient for > traffic shaping when there is only one destination interface? Yes. We'd be pretty dim to include a example on the "traffic shaping" page that was inappropriate in a simple traffic shaping application. > Is here any special reason why the four rule version RESTORE tests for > zero, while the six rule version does not? Yes -- I pointed out in my prior post that it was inappropriate to mark packets then use RESTORE on those same packets. The "4-rule" example actually has 6 rules and the test for zero is there so that if one of the first two rules marks the packet, then the mark won't be overwritten by RESTORE. > 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. Yes -- but both examples work in the context in which they are presented. > > 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. Yes -- writing packet marking rules is a very primitive form of programming. And programmers must always be mindful of the surrounding environment when they insert (or copy and paste) code. > > 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. > I'll pass on your observation to the webmaster... -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ [EMAIL PROTECTED] PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
------------------------------------------------------------------------ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
