On May 1, 2011, at 7:26 AM, Mr Dash Four wrote: > >>> Anyway, it looks as though I cannot force traffic-shaping on incoming >>> traffic by using tcrules AND use it on my INPUT chain AND use ipsets AND >>> use user id - it seems impossible. >>> >> >> That's correct. There is *no* netfilter hook between the time that a packet >> enters the box and when it gets redirected to an IFB. That is the entire >> reason that /etc/shorewall/tcfilters was originally invented. At >> http://www.shorewall.net/traffic_shaping.htm#IFB, it clearly states that: >> "Entries in /etc/shorewall/tcrules have no effect on shaping traffic through >> an IFB. To allow classification of such traffic, the >> /etc/shorewall/tcfilters file has been added. Entries in that file create >> u32 classification rules." >> > So, in other words there is no way on gods green Earth that I could shape > incoming traffic by utilising ipsets and/or by using the tcrules file? If > that is correct, then my only choice seems to be tcfilters and there I cannot > use ipsets (yeah, catch22 that!).
There is no way to shape incoming traffic using an IFB and ipsets. If this is a router, you can shape traffic exiting the router on the local interface using ipsets. > >>> The documentation on tcrules is, well lets just say, there is a lot to be >>> desired from it (where and in what circumstances am I allowed to use "I" >>> and "CI" for example?) >>> >> >> :I and :CI are included for completeness (the tcrules file is the only way >> to mark packets using Shorewall and packet marks are the "Swiss Army Knife" >> of Netfilter). Neither affect either policy routing or traffic shaping and >> I've made that clear in the online copies of the tcrules man pages. >> > OK, could you show me a simple example when I can mark traffic in the INPUT > chain (presumably by using the "I" or "CI" flags) and include it in tc > classes for traffic shaping? Is that possible? Say incoming traffic destined > to "+web-ports" ipset (web-ports ipset containing 80, 8080-8082, 443 and 8443 > as its values). i.e. traffic *->$FW:+wep-ports, and shape that traffic from > 1mbit to full. There is no way. A Shorewall user requested the ability to mark packets in the INPUT chain (I've forgotten the rationale but it was legitimate) and I added it a while back. > >>> - I started by using classes, but gave up soon after as they work only on >>> the postrouting chain, >>> >> >> Completely not true. But then, it you are trying to shape incoming traffic >> with tcrules, I can understand your confusion. >> > Well, that is what the man pages state (quoting the major:minor > classification): "Classification occurs in the POSTROUTING chain except when > the SOURCE is $FW[:address] in which case classification occurs in the OUTPUT > chain." > > So, by that I can only conclude that if I wish to use classes hierarchy > (major:minor etc) the only choice open for me is POSTROUTING or OUTPUT, which > is more or less what I wrote above (in other words flags "P", "F" and "I" are > completely useless for this classification). That's correct if you use CLASSIFIERS (dev:class) in the MARK column. But if you use packet marks, you can mark in FORWARDING. > > Following on from this, I see no sense whatsoever in applying that > classification to ifb-type devices as there is NEVER going to be a match when > these are included in the tcrules file as, to my understanding, ifb operates > on the incoming/input chains and traffic. > > If that is indeed the case, why are ifb-type devices allowed to be used in > the tcrules file at all - what possible purpose would that serve (genuine > question as I cannot figure out what sort of match could there be if ifb > devices are used in tcrules)? I'll be happy to add an error message if an IFB is mentioned in the tcrules file. > >>> One other thing which I found in man shorewall-tcrules: in the classid >>> section it states that "the major class is the device number (the first >>> device in shorewall-tcdevices[3](5) is major class 1, the second device is >>> major class 2, and so on) and the minor class is the class's MARK value in >>> shorewall-tcclasses[4](5) preceded by the number 1 (MARK 1 corresponds to >>> minor class 11, MARK 5 corresponds to minor class 15, MARK 22 corresponds >>> to minor class 122, etc.)." >>> >>> So, following that if I have a device with major 1, then a class defined in >>> tcclasses as, say, 21, I should therefore use 121 in my tcrules file (as >>> "1:121" in this case). That does not work and it gives me "Unknown Class" >>> error. >>> >> >> That only applies if you let Shorewall pick the class numbers; you are >> specifying them explicitly in tcclasses. >> > Then perhaps the man page should be amended to make that clearer as this is a > bit misleading. Sure. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
PGP.sig
Description: This is a digitally signed message part
------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
