Glenn Tarbox, PhD wrote: > > I've included a dump as requested... its pretty huge so I figure that > just about anything you might need is in there...
> > So, the dump is for the simple case. I have a couplea rules to define > how I want internal traffic routed to providers. I have other rules to > provide bandwidth control in later chains through classification / > prioritization / queues... (of course, this didn't really make sense to > me... seems like with HIGH_MARKS one could "or" the low bits used for > prioritization and get it all done in prefilter in one shot... but > whatever... I'm sure theres a reason) Two reasons: a) MARK rules aren't terminating. So 'OR' rules are cumulative and must be used with extreme care. b) The routing subsystem looks at the whole mark (there's no provision for supplying a mask). > > but, then comes the question of whats happening with multi-provider > priority assignment. Looking at the mangle table, it almost looks like > it wants to classify... but none of the packets appear to be getting to > the queues in tcpost... at least from what I can tell... so, it could be > working, I guess, but I have no real way of knowing... You can see how traffic is flowing through the TC classes using "shorewall show tc". > > so, do I need to somehow use the "connection" marking stuff? No. > There's no explanation as to what that really is... Have you read http://www.shorewall.net/PacketMarking.html? > conntrack really wants to use it (its reporting something but not my stuff... at least a lot of the > time) It is not conntrack that uses it -- it is the 'track' option in /etc/shorewall/providers -- see http://www.shorewall.net/MultiISP.html#Providers. but I've played around some with it and it didn't appear to > help... perhaps by not doing the "save" and "restore" in tcrules I'm > not saving state between the prefilter / tcout / tcfor / tcpost... You don't have to. As explained at http://www.shorewall.net/PacketMarking.html, the packet mark is a field in the SKB which follows the packet while it is in the system. > > I see some reference to this being all "connection" based... but that > can't be right... we still need the data to end up in the queues to be > processed in a prioritized fashion... but, while some traffic appears to > get "classified" there... its nowhere near what I'm pumping... of > course, the connection stuff seems related to prefilter (meaning our > prefilter rules won't get run to insure that stuff gets routed back > correctly... ok, I'm cool with that)... after which we still should be > packet based... but then I read that just the first packet identifies a > connection... and there's other stuff doing save / restore ( e.g. > conntrack) so I don't know if thats in the way... are my marks geting > cleared before getting to the next chain? Perhaps going to the default > queue at the root? looks that way... but, who knows... The only time that you need to do connection marking in conjunction with Traffic Shaping is when you need to 'remember' that a connection has a particular characteristic. A good example is at http://www.shorewall.net/IPP2P.html. > > and, furthermore, while I can set rules in the prefilter, forward, and > post chains, the $FW stuff gets done in output... so, if I needed to do > a restore or save (again, whatever they are and why one might need to > use them) with that packet information... how would I reference the > tcout table to execute the store (only have :P, :F, :T)? so, I can't > route properly there perhaps due to strangeness with iptables... ok, I > set the bindaddr in asterisk... but I still need it prioritized... > doesn't appear to be happening even though it looks like the marks want > to be set in the tcout chain If you place your marking rules in the POSTROUTING chain (tcpost), then they will apply to both forwarded traffic and to traffic originating on the firewall. Refer to the diagram at the top of http://www.shorewall.net/NetfilterOverview.html. <rant about unrelated product deleted> > > I could use wireshark... but I still won't see the queueing used to put > the packets out... only by inferring that things are "better"... but > that seems kinda out there... I have read about trace... and even > thought about using accounting... but that didn't seem a no brainer > either.. Again, "shorewall show tc" shows you how many packets have been sent through each of the TC classes. While traffic is flowing through a class, you can also see the bit-rate. > > Also, the docs are pretty thin in explaining what really goes on in the > flow. i've read all the shorewall docs, and just about everything > referenced... but when it comes to actually explaining what the routing > is, how packet marketing is supposed to work between chains in various > tables, what a connection mark is, why it matters, how one might use > it... I'm baffled... If you have read http://www1.shorewall.net/NetfilterOverview.html and http://www.shorewall.net/PacketMarking.html and still don't understand it, then anything more that I would write here probably won't help. -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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
