Re: [LARTC] traffic state monitoring
is there any difference with one of these :- iptables -t nat -I PREROUTING -p tcp --dport 21 -m state --state NEW,ESTABLISHED,RELATED iptables -I FORWARD -p tcp --dport 21 -m state --state NEW,ESTABLISHED,RELATED I could be wacky, but at this early hour of the morning my foggy brain is noticing a few things. -Neither of these rules jump to anything. -The second rule is not attached to any table, which I don't think is possible... For the first rule, I believe that rules in the nat table only apply to getting things mangled. Specifying the state in there would mean that only things in that state get mangled (dnat, snat, etc), based on the rules following it. Other packets would just have done with them whatever happens to packets aren't associated with a session (arent claimed by NAT, or any listening socket) The second rule would catch packets that are to be forwarded (for nat, or for normal routing) that meet the specified requirements. What happens once it's caught depends on what you jump to Remember, I'm just an amateur, havent had my coffee yet, (insert other pithy excuse for my being wrong here). ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Commercial Alternatives
How is this possible? Is just goes out on the network and sucks up overlimit traffic, preventing it from getting to the destination? I'm pretty sure that all the products out there require the traffic to pass through them to perform the shaping, unless there's some deep voodoo out there that I'm not aware of. I liked their solutions because the traffic does not actually go through their boxes. It simply plug's into your network, and you tell it the gateways, and then all other machines use it as their gateway. It then load balances the connections or what ever else you want via intelligent routing logic. At least that was my understanding. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Commercial Alternatives
William L. Thomson Jr. said: From what I was being told at the time, over a year ago. You plug it into your network. Configure all machines to use it as their gateway. It will then make decisions regarding the next gateway or hop to use. So it replaces the Default Gateway. The traffic is pretty explicitly going through it in that case. :P ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Commercial Alternatives
William L. Thomson Jr. said: Yes, but not in sense that traffic comes in one interface and goes out another. From my understanding the main benefit of the SysMaster solution was the number of connections being balanced had nothing to do with the number of interfaces. ... so it would go in and then come out again on the same interface? I'm sure it's great as far as ease of configuration, but to tell the truth I'd rather plug in an extra cable or two, and not halve my available bandwidth by doubling the per-link traffic. I guess it's a very targeted product, I just think it sounds rather silly. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Commercial Alternatives
Kirby C. Bohling said: I'm guessing it has two interfaces. Hence the sentence: Yes, but not in sense that traffic comes in one interface and goes out another The fact that it does NOT come in one interface and go out another implies to me that there's only one interface. If there's two interfaces, it goes in one and out another.. which is what he says it's NOT doing :P The one interface connects to the local lan. The other connects to a network that can route to all of your upstream providers. I'm not familiar with WAN routing... is it common to have a network that can be connected to with one physical interface, that routes to many different providers? It's no harder to load balance 2 way then 4 way, but a lot of network equipment makers would charge you twice as much because there are twice as many interfaces (or would charge you a significant amount more to have 4 interfaces). I could see that.. but I was under the impression that on any network where you'd have routes to different providers that you want to load balance, you'd need a different physical interface to each network that the route was on. I'm guessing this is a pretty smart option assuming the aggregate traffic leaving you network is less then 100Mbit/s. If it's more then 100Mbit/s, you can afford better equipment. True :P ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HTB debug info in kernel log
On Thu, 13 Feb 2003 at 01:58:53, Brad Davidson wrote: I'm looking at the code in htb_dump, which appears to be what's called to get statistics information by the tc application. It looks to me like if you have debug enabled, as part of the stats collecting routine, it calls htb_debug_dump regardless of whether or not there's anything wrong with your setup. If you want to take a look at what I'm talking about, check out line 1211 of sch_htb.c BTW I just commented out the line in question and recompiled the module. It no longer floods the logs. As far as I can tell, there's no good reason for it to do that. It doesn't even check the requested debug levels, or do it of somtehing's wrong. Every time stats info is polled, you get debug info whether you wanted it or not. Anybody else confirm this going on? Or am I just crazy? ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] HTB debug info in kernel log
I set up a Perl script to parse the output of 'tc -s qdisc show dev if' to get stats for MRTG. The only problem is, every time the tc command runs, I get many lines output to my kernel level syslog - 84, to be exact They look something like this: oatmail kernel: htb*c10124 m=2 t=22748 c=19272 pq=0 df=4907008 ql=0 pa=0 f: oatmail kernel: htb*c10094 m=2 t=86150 c=86150 pq=0 df=237568 ql=0 pa=0 f: oatmail kernel: htb*g j=171630276 oatmail kernel: htb*r7 m=0 oatmail kernel: htb*r6 m=0 I found some reference in the source to a command to tc to set various debug levels, although the function that seems to be printing the info (htb_debug_dump) does not seem to care about the set level - if debug is defined, it prints. Short of altering the DEFINE statement and recompiling the kernel, is there any way to disable this output? Thanks, Brad ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Ingress qdisc functional?
Hello all! I've just subscribed to the list after looking around on Google and checking out the TC source code a bit. Here's my situation: I have a megabit DSL line that I'd like to set up some shaping on. I only have access to the linux router on my (client) end. Because of that, I was looking to do some shaping using the 'ingress' qdisc. However, I'm getting mixed messages as to whether or not it works. The source of q_ingress.c from ss020116 says in the header: -- * This is here just in case it is needed * useless right now; might be useful in the future -- Which leads me to believe that it's not really working, allthough I've seen posts claiming that it is. Can I get some verification either way, or possibly a newer version of the tools that I'm missing? Thanks! -Brad ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
