-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gustavo,
: Sure, but I am talking about a simple setup that works for small : networks. In such cases there won't be DNS floods, unless someone : really wants to generate one. Well, perhaps you could give it a try in your example network and see how it fares. It might fare very well 90% of the time. If so, then you have an OK solution. : So the priorities are useless in real world with pfifo_fast, is : that it? This is bit surprising, IIUC. This is why I asked. Priorities are useless in the real world on a link that we expect to be congested (e.g. an ADSL link). If the link is not congested, there's no problem with using priorities. The question is not whether priorities are useless, but rather, how often do you expect your link to be congested? : What I was initially looking for was just TOS marking + plus : simple interface throtlling, i.e, the simplest form of shapping. : If it can't be done with pfifo_fast, my next idea was something : like: : : tc qdisc add dev eth0 root handle 1: htb default 10 : tc class add dev eth0 parent 1: classid 1:1 htb rate 7000kbps ceil 7000kbps : tc class add dev eth0 parent 1:1 classid 1:10 prio : : + : : iptables rules for setting TOS values : : Is this right? This seems to be similar to what you proposed : here: : : http://mailman.ds9a.nl/pipermail/lartc/2006q2/019138.html Well, indeed, I did post that! While that may solve the problem of the bottleneck, I have to confess, it's not a very good solution either! I'll post a follow-up to that thread shortly. : For a not so simple approach but which seems to be working well, : I have an adaption of Dan Singletary's script here: : : http://downloads.angulosolido.pt/QoS/ : : It uses directly HTB on both directions, for a setup with only 2 : network interfaces which is very common (no kernel patching is : needed). HTB in both directions is probably the best way to go (shaping upload and shaping download). I haven't examined the HTB_shaper.sh assiduously, but from a quick review, it seems quite reasonable (and better than my off the cuff remark in the earlier thread). I'm not crazy about the dropping of the MTU, but otherwise, the script seems to make sense. Basically divide up link capacity into components and limit the total transmission rate to the link capacity (so we are the bottleneck). Then, put some packets in each class. It's so far the best (and most general) solution in this thread. : Still, I want to test the simplest possible solution and see how : far one can go with only a few lines of bash, for both practical : and pedagogical purposes. I think it's important to have a simple : solution that works for typical scenarios (2 interfaces, linux : router with NAT) on stock kernels. ** : : ** nothing wrong about patching and compiling kernels, but it : brings maintenance overhead everytime there is system upgrade : for whatever reason Understood on the kernel patching/compiling business. That's not usually something you want to throw at beginners. Well, if the goal is practical administration and pedagogy, I'd suggest tcng [0], since the "beauty" of tc is hidden from the user. The language of tcng feels more like a programming language than the arcana of tc. Good luck, - -Martin [0] http://tcng.sourceforge.net/ - -- Martin A. Brown http://linux-ip.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEswsEHEoZD1iZ+YcRAhwGAJkBlygjpO6dfT9s+1/yHq91pSAJCQCg8E2a LRjKTkGjSvQHTLaFReomSlk= =ikoL -----END PGP SIGNATURE----- _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
