Dear list: I have a problem I cannot handle yet, and need to solve it as soon as possible. Would be very greatful with anybody who can help me. I have a 512/512 link to internet, that I want to share between several computers. I have eth0, with a public IP address, conected to Internet, and also, eth1, with a private IP address, for network with the surfing computers. I have a main class with the whole 512kbit, then 2 child classes in this way (you can see the complete script at the end): class 1: rate = ceil = 64kbit, prio 0, for VOIP class 2: rate = ceil = 448kbit, for SURFING Class 2 is subdivided again in about 20 classes, for 20 surfing computers, this way: class 3: rate = 18kbit, ceil = 448kbit, prio 1, SURF I have a classical problem (I think). As you can see, first 64kbit are for VOIP, so, it is necesary the best quality, and the minimal delays. 64Kbit is pretty enough for 1 VOIP channel (it is supposed to really use no more than 20kbit). And also, the 64kbit class has the highest priority. Nevertheless, specially when all 20 users are surfing, or some user are browsing weight pages, or when 2 or more users are downloading at the same time, I cannot get VOIP to work properly, because quality becomes very poor. I have made all kind of imaginable test, probes and combinations, trying to test with different burst values for classes, attaching sfq qdiscs to all leaf classes, then only to surfing classes, then only to VOIP classes, and even, gaming with R2Q/Quantums, that would not be necessary, because 64Kbit is very more than enough. So please, does anyone have any idea how to completely separate VOIP and SURFING, making 2 independent channels, without one service affect to other ?? Very thanks in advance. If you are still able to read, after having read all this stuff, here goes my script as is now... Best Regards to everybody. Ricardo. =============================================== #!/bin/bash tc qdisc add dev eth1 root handle 1: htb default 121 r2q 1 tc qdisc add dev eth0 root handle 1: htb default 20 r2q 5 tc class add dev eth1 parent 1: classid 1:1 htb rate 512kbit ceil 512kbit tc class add dev eth0 parent 1: classid 1:1 htb rate 512kbit ceil 512kbit tc class add dev eth1 parent 1:1 classid 1:10 htb rate 64kbit ceil 64kbit prio 0 tc class add dev eth0 parent 1:1 classid 1:10 htb rate 64kbit ceil 64kbit prio 0 tc class add dev eth1 parent 1:1 classid 1:20 htb rate 448kbit ceil 448kbit prio 1 tc class add dev eth0 parent 1:1 classid 1:20 htb rate 448kbit ceil 448kbit prio 1 # PER MACHINE OR IP CLASSES tc class add dev eth1 parent 1:20 classid 1:90 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:91 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:101 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:102 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:103 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:104 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:105 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:106 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:107 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:108 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:109 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:110 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:111 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:112 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:113 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:114 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:115 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:116 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:117 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:118 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:119 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:120 htb rate 18kbit ceil 448kbit prio 1 tc class add dev eth1 parent 1:20 classid 1:121 htb rate 18kbit ceil 448kbit prio 1 # SFQ QDISCS PER LEAF CLASS # VOIP tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 #SURFING tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev eth1 parent 1:90 handle 90: sfq perturb 10 tc qdisc add dev eth1 parent 1:91 handle 91: sfq perturb 10 tc qdisc add dev eth1 parent 1:101 handle 101: sfq perturb 10 tc qdisc add dev eth1 parent 1:102 handle 102: sfq perturb 10 tc qdisc add dev eth1 parent 1:103 handle 103: sfq perturb 10 tc qdisc add dev eth1 parent 1:104 handle 104: sfq perturb 10 tc qdisc add dev eth1 parent 1:105 handle 105: sfq perturb 10 tc qdisc add dev eth1 parent 1:106 handle 106: sfq perturb 10 tc qdisc add dev eth1 parent 1:107 handle 107: sfq perturb 10 tc qdisc add dev eth1 parent 1:108 handle 108: sfq perturb 10 tc qdisc add dev eth1 parent 1:109 handle 109: sfq perturb 10 tc qdisc add dev eth1 parent 1:110 handle 110: sfq perturb 10 tc qdisc add dev eth1 parent 1:111 handle 111: sfq perturb 10 tc qdisc add dev eth1 parent 1:112 handle 112: sfq perturb 10 tc qdisc add dev eth1 parent 1:113 handle 113: sfq perturb 10 tc qdisc add dev eth1 parent 1:114 handle 114: sfq perturb 10 tc qdisc add dev eth1 parent 1:115 handle 115: sfq perturb 10 tc qdisc add dev eth1 parent 1:116 handle 116: sfq perturb 10 tc qdisc add dev eth1 parent 1:117 handle 117: sfq perturb 10 tc qdisc add dev eth1 parent 1:118 handle 118: sfq perturb 10 tc qdisc add dev eth1 parent 1:119 handle 119: sfq perturb 10 tc qdisc add dev eth1 parent 1:120 handle 120: sfq perturb 10 tc qdisc add dev eth1 parent 1:121 handle 121: sfq perturb 10 # FILTERS # VOIP tc filter add dev eth0 protocol ip parent 1:0 prio 0 u32 match ip src 216.118.226.244 flowid 1:10 tc filter add dev eth1 protocol ip parent 1:0 prio 0 u32 match ip dst 216.118.226.244 flowid 1:10 # SURFING tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.2 flowid 1:90 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.3 flowid 1:91 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.101 flowid 1:101 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.102 flowid 1:102 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.103 flowid 1:103 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.104 flowid 1:104 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.105 flowid 1:105 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.106 flowid 1:106 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.107 flowid 1:107 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.108 flowid 1:108 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.109 flowid 1:109 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.110 flowid 1:110 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.111 flowid 1:111 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.112 flowid 1:112 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.113 flowid 1:113 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.114 flowid 1:114 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.115 flowid 1:115 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.116 flowid 1:116 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.117 flowid 1:117 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.118 flowid 1:118 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.119 flowid 1:119 tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.0.120 flowid 1:120 # END _________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Ricardo Soria wrote:> Dear list: > > I have a problem I cannot handle yet, and need to > solve it as soon as possible. Would be very greatful > with anybody who can help me. > > I have a 512/512 link to internet, that I want to > share between several computers. I have eth0, with a > public IP address, conected to Internet, and also, > eth1, with a private IP address, for network with the > surfing computers. I have a main class with the whole > 512kbit, then 2 child classes in this way (you can see > the complete script at the end): > > class 1: rate = ceil = 64kbit, prio 0, for VOIP > class 2: rate = ceil = 448kbit, for SURFING > > Class 2 is subdivided again in about 20 classes, for > 20 surfing computers, this way: > > class 3: rate = 18kbit, ceil = 448kbit, prio 1, SURF > > I have a classical problem (I think). As you can see, > first 64kbit are for VOIP, so, it is necesary the best > quality, and the minimal delays. 64Kbit is pretty > enough for 1 VOIP channel (it is supposed to really > use no more than 20kbit). And also, the 64kbit class > has the highest priority. Nevertheless, specially > when all 20 users are surfing, or some user are > browsing weight pages, or when 2 or more users are > downloading at the same time, I cannot get VOIP to > work properly, because quality becomes very poor. I > have made all kind of imaginable test, probes and > combinations, trying to test with different burst > values for classes, attaching sfq qdiscs to all leaf > classes, then only to surfing classes, then only to > VOIP classes, and even, gaming with R2Q/Quantums, that > would not be necessary, because 64Kbit is very more > than enough. > > So please, does anyone have any idea how to completely > separate VOIP and SURFING, making 2 independent > channels, without one service affect to other ?? > > Very thanks in advance. > > If you are still able to read, after having read all > this stuff, here goes my script as is now... > > Best Regards to everybody. > > Ricardo. > > ===============================================> > #!/bin/bash > > tc qdisc add dev eth1 root handle 1: htb default 121 > r2q 1 > tc qdisc add dev eth0 root handle 1: htb default 20 > r2q 5 > > tc class add dev eth1 parent 1: classid 1:1 htb rate > 512kbit ceil 512kbit > tc class add dev eth0 parent 1: classid 1:1 htb rate > 512kbit ceil 512kbit > > tc class add dev eth1 parent 1:1 classid 1:10 htb rate > 64kbit ceil 64kbit prio 0 > tc class add dev eth0 parent 1:1 classid 1:10 htb rate > 64kbit ceil 64kbit prio 0 > > tc class add dev eth1 parent 1:1 classid 1:20 htb rate > 448kbit ceil 448kbit prio 1 > tc class add dev eth0 parent 1:1 classid 1:20 htb rate > 448kbit ceil 448kbit prio 1 > > # PER MACHINE OR IP CLASSES > > tc class add dev eth1 parent 1:20 classid 1:90 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:91 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:101 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:102 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:103 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:104 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:105 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:106 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:107 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:108 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:109 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:110 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:111 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:112 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:113 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:114 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:115 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:116 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:117 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:118 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:119 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:120 htb > rate 18kbit ceil 448kbit prio 1 > tc class add dev eth1 parent 1:20 classid 1:121 htb > rate 18kbit ceil 448kbit prio 1 > > # SFQ QDISCS PER LEAF CLASS > > # VOIP > tc qdisc add dev eth0 parent 1:10 handle 10: sfq > perturb 10 > tc qdisc add dev eth0 parent 1:20 handle 20: sfq > perturb 10 > > #SURFING > tc qdisc add dev eth1 parent 1:10 handle 10: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:90 handle 90: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:91 handle 91: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:101 handle 101: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:102 handle 102: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:103 handle 103: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:104 handle 104: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:105 handle 105: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:106 handle 106: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:107 handle 107: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:108 handle 108: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:109 handle 109: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:110 handle 110: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:111 handle 111: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:112 handle 112: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:113 handle 113: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:114 handle 114: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:115 handle 115: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:116 handle 116: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:117 handle 117: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:118 handle 118: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:119 handle 119: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:120 handle 120: sfq > perturb 10 > tc qdisc add dev eth1 parent 1:121 handle 121: sfq > perturb 10 > > # FILTERS > > # VOIP > tc filter add dev eth0 protocol ip parent 1:0 prio 0 > u32 match ip src 216.118.226.244 flowid 1:10 > tc filter add dev eth1 protocol ip parent 1:0 prio 0 > u32 match ip dst 216.118.226.244 flowid 1:10 > > # SURFING > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.2 flowid 1:90 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.3 flowid 1:91 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.101 flowid 1:101 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.102 flowid 1:102 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.103 flowid 1:103 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.104 flowid 1:104 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.105 flowid 1:105 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.106 flowid 1:106 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.107 flowid 1:107 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.108 flowid 1:108 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.109 flowid 1:109 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.110 flowid 1:110 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.111 flowid 1:111 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.112 flowid 1:112 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.113 flowid 1:113 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.114 flowid 1:114 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.115 flowid 1:115 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.116 flowid 1:116 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.117 flowid 1:117 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.118 flowid 1:118 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.119 flowid 1:119 > tc filter add dev eth1 protocol ip parent 1:0 prio 1 > u32 match ip dst 192.168.0.120 flowid 1:120 > > # ENDI haven''t read the script properly, but generally three points come to mind. You need to back off more from link speed - total ceils to about 80% and share that between interactive and bulk. SFQ default queue length is too long to be used as you want - use esfq or change the length to 16 in the source code (see www.docum.org FAQs). You should really only send bulk to SFQ - It will behave better than a fifo if you mix traffic - but at the low rates you set it will still cause too much delay for interactive (small UDP/TCP). Andy. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
--- Andy Furniss <andy.furniss@dsl.pipex.com> escribió:> Ricardo Soria wrote: > > Dear list: > > > > I have a problem I cannot handle yet, and need to > > solve it as soon as possible. Would be very > greatful > > with anybody who can help me. > > > > I have a 512/512 link to internet, that I want to > > share between several computers. I have eth0, > with a > > public IP address, conected to Internet, and also, > > eth1, with a private IP address, for network with > the > > surfing computers. I have a main class with the > whole > > 512kbit, then 2 child classes in this way (you can > see > > the complete script at the end): > > > > class 1: rate = ceil = 64kbit, prio 0, for VOIP > > class 2: rate = ceil = 448kbit, for SURFING > > > > Class 2 is subdivided again in about 20 classes, > for > > 20 surfing computers, this way: > > > > class 3: rate = 18kbit, ceil = 448kbit, prio 1, > SURF > > > > I have a classical problem (I think). As you can > see, > > first 64kbit are for VOIP, so, it is necesary the > best > > quality, and the minimal delays. 64Kbit is pretty > > enough for 1 VOIP channel (it is supposed to > really > > use no more than 20kbit). And also, the 64kbit > class > > has the highest priority. Nevertheless, specially > > when all 20 users are surfing, or some user are > > browsing weight pages, or when 2 or more users are > > downloading at the same time, I cannot get VOIP to > > work properly, because quality becomes very poor. > I > > have made all kind of imaginable test, probes and > > combinations, trying to test with different burst > > values for classes, attaching sfq qdiscs to all > leaf > > classes, then only to surfing classes, then only > to > > VOIP classes, and even, gaming with R2Q/Quantums, > that > > would not be necessary, because 64Kbit is very > more > > than enough. > > > > So please, does anyone have any idea how to > completely > > separate VOIP and SURFING, making 2 independent > > channels, without one service affect to other ?? > > > > Very thanks in advance. > > > > If you are still able to read, after having read > all > > this stuff, here goes my script as is now... > > > > Best Regards to everybody. > > > > Ricardo. > > > > ===============================================> > > > #!/bin/bash > > > > tc qdisc add dev eth1 root handle 1: htb default > 121 > > r2q 1 > > tc qdisc add dev eth0 root handle 1: htb default > 20 > > r2q 5 > > > > tc class add dev eth1 parent 1: classid 1:1 htb > rate > > 512kbit ceil 512kbit > > tc class add dev eth0 parent 1: classid 1:1 htb > rate > > 512kbit ceil 512kbit > > > > tc class add dev eth1 parent 1:1 classid 1:10 htb > rate > > 64kbit ceil 64kbit prio 0 > > tc class add dev eth0 parent 1:1 classid 1:10 htb > rate > > 64kbit ceil 64kbit prio 0 > > > > tc class add dev eth1 parent 1:1 classid 1:20 htb > rate > > 448kbit ceil 448kbit prio 1 > > tc class add dev eth0 parent 1:1 classid 1:20 htb > rate > > 448kbit ceil 448kbit prio 1 > > > > # PER MACHINE OR IP CLASSES > > > > tc class add dev eth1 parent 1:20 classid 1:90 htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:91 htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:101 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:102 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:103 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:104 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:105 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:106 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:107 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:108 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:109 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:110 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:111 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:112 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:113 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:114 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:115 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:116 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:117 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:118 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:119 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:120 > htb > > rate 18kbit ceil 448kbit prio 1 > > tc class add dev eth1 parent 1:20 classid 1:121 > htb > > rate 18kbit ceil 448kbit prio 1 > > > > # SFQ QDISCS PER LEAF CLASS > > > > # VOIP > > tc qdisc add dev eth0 parent 1:10 handle 10: sfq > > perturb 10 > > tc qdisc add dev eth0 parent 1:20 handle 20: sfq > > perturb 10 > > > > #SURFING > > tc qdisc add dev eth1 parent 1:10 handle 10: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:90 handle 90: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:91 handle 91: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:101 handle 101: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:102 handle 102: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:103 handle 103: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:104 handle 104: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:105 handle 105: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:106 handle 106: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:107 handle 107: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:108 handle 108: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:109 handle 109: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:110 handle 110: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:111 handle 111: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:112 handle 112: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:113 handle 113: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:114 handle 114: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:115 handle 115: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:116 handle 116: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:117 handle 117: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:118 handle 118: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:119 handle 119: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:120 handle 120: sfq > > perturb 10 > > tc qdisc add dev eth1 parent 1:121 handle 121: sfq > > perturb 10 > > > > # FILTERS > > > > # VOIP > > tc filter add dev eth0 protocol ip parent 1:0 prio > 0 > > u32 match ip src 216.118.226.244 flowid 1:10 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 0 > > u32 match ip dst 216.118.226.244 flowid 1:10 > > > > # SURFING > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.2 flowid 1:90 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.3 flowid 1:91 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.101 flowid 1:101 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.102 flowid 1:102 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.103 flowid 1:103 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.104 flowid 1:104 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.105 flowid 1:105 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.106 flowid 1:106 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.107 flowid 1:107 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.108 flowid 1:108 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.109 flowid 1:109 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.110 flowid 1:110 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.111 flowid 1:111 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.112 flowid 1:112 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.113 flowid 1:113 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.114 flowid 1:114 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.115 flowid 1:115 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.116 flowid 1:116 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.117 flowid 1:117 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.118 flowid 1:118 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.119 flowid 1:119 > > tc filter add dev eth1 protocol ip parent 1:0 prio > 1 > > u32 match ip dst 192.168.0.120 flowid 1:120 > > > > # END > > > I haven''t read the script properly, but generally > three points come to mind. > > You need to back off more from link speed - total > ceils to about 80% and > share that between interactive and bulk. > > SFQ default queue length is too long to be used as > you want - use esfq > or change the length to 16 in the source code (see > www.docum.org FAQs). > > You should really only send bulk to SFQ - It will > behave better than a > fifo if you mix traffic - but at the low rates you > set it will still > cause too much delay for interactive (small > UDP/TCP). > > Andy. > > >Dear Andy: Very thanks for your answer. However, I need a little bit more extended explanation. First, you say that I should "back off more from link speed - total ceils to about 80% and share that between interactive and bulk". So, do you mean that if I have a total 512Kbit link, and 2 child classes, I should not divide the whole 512kbit between the 2 classes, but, I should only divide 410kbit between them, and share the remaining 102kbit between them?? Or do you mean I should only consider 410kbit as the whole link capacity?? Second, you say that I should not use SFQ as a sub-qdisc, because of the lenght of the queue, being it ESFQ (new for me) a better choice. But later, you say I should use SFQ for bulk traffic (I think you refer surfing as "bulk", and voip as "interactive"). So, should I use SFQ for bulk classes and ESFQ for interactive classes ?? Or, should I use ESFQ for all leaf classes?? Or, should I use ESFQ for bulk classes and default (pfifo, I think) for interactive classes?? Very thanks for your help. Best Regards. Ricardo. _________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Monday 15 November 2004 20:06, Ricardo Soria wrote: <snip>> Dear Andy: > > Very thanks for your answer. However, I need a little > bit more extended explanation. > > First, you say that I should "back off more from link > speed - total ceils to about 80% and share that > between interactive and bulk". So, do you mean that > if I have a total 512Kbit link, and 2 child classes, I > should not divide the whole 512kbit between the 2 > classes, but, I should only divide 410kbit between > them, and share the remaining 102kbit between them?? > Or do you mean I should only consider 410kbit as the > whole link capacity??I think he meant to treat your link as if it were only 410kbit. With some testing you can verify just how close to 100% of your advertised capacity you can get, but 80% is often a good place to start.> Second, you say that I should not use SFQ as a > sub-qdisc, because of the lenght of the queue, being > it ESFQ (new for me) a better choice. But later, you > say I should use SFQ for bulk traffic (I think you > refer surfing as "bulk", and voip as "interactive"). > So, should I use SFQ for bulk classes and ESFQ for > interactive classes ?? Or, should I use ESFQ for all > leaf classes?? Or, should I use ESFQ for bulk classes > and default (pfifo, I think) for interactive classes??I am curious about this myself. I placed a default sfq qdisc with the 128 queue default on a p2p class that had a rate of 144kbit and it routinely spiked to about 150kbit several times a second. If I use pfifo with a queue length of 10 I find my utilization for that class at around 146kbit instead. Is it the queue length causing this behavior? -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Jason Boxman wrote:> On Monday 15 November 2004 20:06, Ricardo Soria wrote: > <snip> > >>Dear Andy: >> >>Very thanks for your answer. However, I need a little >>bit more extended explanation. >> >>First, you say that I should "back off more from link >>speed - total ceils to about 80% and share that >>between interactive and bulk". So, do you mean that >>if I have a total 512Kbit link, and 2 child classes, I >>should not divide the whole 512kbit between the 2 >>classes, but, I should only divide 410kbit between >>them, and share the remaining 102kbit between them?? >>Or do you mean I should only consider 410kbit as the >>whole link capacity?? > > > I think he meant to treat your link as if it were only 410kbit. With some > testing you can verify just how close to 100% of your advertised capacity you > can get, but 80% is often a good place to start.Yes that''s what I meant. For uplink it''s to allow for link overheads and with dsl you should be careful about tweaking as it may be OK at 90% in a test with bulk traffic - all MTU size packets, but if there are lots of small packets the overhead miscalculations may mean well over limits at 90%. You can fix this, but not perfectly, with a patch Ed Wildgoose sent to this list. Incoming traffic is different - your queue is at the wrong end of the link. You have to set a lower limit just to have a queue at all.> > >>Second, you say that I should not use SFQ as a >>sub-qdisc, because of the lenght of the queue, being >>it ESFQ (new for me) a better choice. But later, you >>say I should use SFQ for bulk traffic (I think you >>refer surfing as "bulk", and voip as "interactive"). >>So, should I use SFQ for bulk classes and ESFQ for >>interactive classes ?? Or, should I use ESFQ for all >>leaf classes?? Or, should I use ESFQ for bulk classes >>and default (pfifo, I think) for interactive classes??What I meant was you could either change the sfq queue length or use esfq, which lets you choose length (and more). In practise you setup HTB so that your interactive traffic - doesn''t queue - yes you can attach what ever you like to it''s class - and (e)sfq would be OK, but if packets actually get queued in it you marking has failed and bulk got in or you really have run out of bandwidth. The point I made was that you shouldn''t really send a mix of traffic to SFQ which will still cause long delays at low bitrates and your users have potentially low rates (depends on what they do). I would do a bit more work to priorotise dns/empty acks/small tcp etc. as well as VOIP, then give them a class with plenty of rate spare and make bulk borrow. This would mean that each user would notice a bit less the fact they have hardly any bandwidth (if that''s the case). Choosing a queue length should really be related to link speed - but you can''t do this if you have lots of queues whose rate are variable. What to choose depends on typical and I suppose worst case traffic situation for your LAN. Alternatly if you were prepared to patch and use esfq you could use it to roughly share traffic by IP address - which is nice to save you marking and because you are able to set the queue length for the link. You do though, loose fairness per connection which may not affect you - again it depends on usage P2P. bittorrent etc.> > > I am curious about this myself. I placed a default sfq qdisc with the 128 > queue default on a p2p class that had a rate of 144kbit and it routinely > spiked to about 150kbit several times a second. If I use pfifo with a queue > length of 10 I find my utilization for that class at around 146kbit instead. > Is it the queue length causing this behavior? >I think these differences are too small to be representative. One packet could add 12kbit to a counter instantaneously and how you measure can decieve. For one really low rate class the way HTB uses DRR to even out fairness for different sized packets could, I think cause short term variations. P2P traffic is mixed packet size and quite variable depending on peers - so recreating behavior for tests may be hard. I don''t think queue length is involved here. Andy. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Tuesday 16 November 2004 09:53, Andy Furniss wrote: <snip>> I would do a bit more work to priorotise dns/empty acks/small tcp etc. > as well as VOIP, then give them a class with plenty of rate spare and > make bulk borrow. This would mean that each user would notice a bit less > the fact they have hardly any bandwidth (if that''s the case).Is it really helpful to initially prioritize all TCP handshake packets into the highest priority? After you walk through your list of traffic and reclassify flows based on your QoS policy, handshake packets for flows that matter ought to be properly accounted for. Likewise for flows that aren''t that interesting. For all other flows only having the handshake prioritized and all else going to a default class can''t be that beneficial?> Choosing a queue length should really be related to link speed - but you > can''t do this if you have lots of queues whose rate are variable. What > to choose depends on typical and I suppose worst case traffic situation > for your LAN.I have not noticed in any of the available documentation I have found any discussion on how to choose an appropriate queue length. The shorter the queue, the sooner applications become aware of a bandwidth bottleneck? I guess the queue just helps deal with short term busts? What rate was sfq''s 128p queue originally targeted at? 100Mbps Ethernet? <snip>> I think these differences are too small to be representative. One packet > could add 12kbit to a counter instantaneously and how you measure can > decieve. For one really low rate class the way HTB uses DRR to even out > fairness for different sized packets could, I think cause short term > variations. P2P traffic is mixed packet size and quite variable > depending on peers - so recreating behavior for tests may be hard. I > don''t think queue length is involved here.The difference for that leaf with sfq versus pfifo was pretty consistent. I should test with different queue lengths for pfifo. Thanks. -- Jason Boxman Perl Programmer / *NIX Systems Administrator Shimberg Center for Affordable Housing | University of Florida http://edseek.com/ - Linux and FOSS stuff _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Jason Boxman wrote:> On Tuesday 16 November 2004 09:53, Andy Furniss wrote: > <snip> > >>I would do a bit more work to priorotise dns/empty acks/small tcp etc. >>as well as VOIP, then give them a class with plenty of rate spare and >>make bulk borrow. This would mean that each user would notice a bit less >>the fact they have hardly any bandwidth (if that''s the case). > > > Is it really helpful to initially prioritize all TCP handshake packets into > the highest priority?Well it''s easy WRT marking :-) the gain can be quite alot for browsing and the ones that aren''t as important cost practically no bandwidth anyway (and I see getting all my TCPs up quickly as better - whatever rate/priority the traffic ends up getting allocated). After you walk through your list of traffic and> reclassify flows based on your QoS policy, handshake packets for flows that > matter ought to be properly accounted for. Likewise for flows that aren''t > that interesting. For all other flows only having the handshake prioritized > and all else going to a default class can''t be that beneficial?I call bulk traffic any that will try to grab bandwidth if left unchecked. I don''t just send it to a default class, it''s shared per IP and new connections (marked by connbytes) get their own class which gives prio and has a short queue so that packets get dropped quickly and slowstart is ended.> >>Choosing a queue length should really be related to link speed - but you >>can''t do this if you have lots of queues whose rate are variable. What >>to choose depends on typical and I suppose worst case traffic situation >>for your LAN. > > > I have not noticed in any of the available documentation I have found any > discussion on how to choose an appropriate queue length. The shorter the > queue, the sooner applications become aware of a bandwidth bottleneck? I > guess the queue just helps deal with short term busts? What rate was sfq''s > 128p queue originally targeted at? 100Mbps Ethernet?I can''t refer you to any docs, but I try to avoid extremes - and having 20x128 for 512 is an extreme. 3.5 meg x 2 wasted unswappable memory - they could absorb about a minutes worth of data at 512kbit. I would aim for < 1 sec each way, my ISP uses 600ms for 512 - the same for 1meg. As I said though, if you have many classes you have to compromise or each user''s queue will be too short. 128 1500 byte packets will queue 1 sec at about 1.5 mbit - I don''t know what it was designed for - but if you use alot of them it soon adds up.> > <snip> > >>I think these differences are too small to be representative. One packet >>could add 12kbit to a counter instantaneously and how you measure can >>decieve. For one really low rate class the way HTB uses DRR to even out >>fairness for different sized packets could, I think cause short term >>variations. P2P traffic is mixed packet size and quite variable >>depending on peers - so recreating behavior for tests may be hard. I >>don''t think queue length is involved here. > > > The difference for that leaf with sfq versus pfifo was pretty consistent. I > should test with different queue lengths for pfifo.Maybe there is a difference - If you want to test with different packet sizes just set mtu on a linux box start a connection set mtu to something different and start another and so on. You will know you are comparing like with like then. I would use sfq for P2P - On the upload side so that 56k users don''t get squeezed out by broadband, on download so I don''t go and drop the one and only packet that a 56k peer managed to get to me in recent seconds. Andy. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> Jason Boxman wrote: > > On Monday 15 November 2004 20:06, Ricardo Soria > wrote: > > <snip> > > > >>Dear Andy: > >> > >>Very thanks for your answer. However, I need a > little > >>bit more extended explanation. > >> > >>First, you say that I should "back off more from > link > >>speed - total ceils to about 80% and share that > >>between interactive and bulk". So, do you mean > that > >>if I have a total 512Kbit link, and 2 child > classes, I > >>should not divide the whole 512kbit between the 2 > >>classes, but, I should only divide 410kbit between > >>them, and share the remaining 102kbit between > them?? > >>Or do you mean I should only consider 410kbit as > the > >>whole link capacity?? > > > > > > I think he meant to treat your link as if it were > only 410kbit. With some > > testing you can verify just how close to 100% of > your advertised capacity you > > can get, but 80% is often a good place to start. > > Yes that''s what I meant. For uplink it''s to allow > for link overheads and > with dsl you should be careful about tweaking as it > may be OK at 90% in > a test with bulk traffic - all MTU size packets, but > if there are lots > of small packets the overhead miscalculations may > mean well over limits > at 90%. You can fix this, but not perfectly, with a > patch Ed Wildgoose > sent to this list. > > Incoming traffic is different - your queue is at the > wrong end of the > link. You have to set a lower limit just to have a > queue at all. >1. So, starting at 80% of total 512kbit bandwidth (410kbit), there would be a waste of 102kbit. Is this completely necessary?? I think this is to ensure I have the queue on my side, and the queue is not on the side of the ISP. But, I fell tempted to think that 102kbit is too much for this purpose, considering that I really have 512kbit all time. What would you finally recommend ??> > > > > > >>Second, you say that I should not use SFQ as a > >>sub-qdisc, because of the lenght of the queue, > being > >>it ESFQ (new for me) a better choice. But later, > you > >>say I should use SFQ for bulk traffic (I think you > >>refer surfing as "bulk", and voip as > "interactive"). > >>So, should I use SFQ for bulk classes and ESFQ for > >>interactive classes ?? Or, should I use ESFQ for > all > >>leaf classes?? Or, should I use ESFQ for bulk > classes > >>and default (pfifo, I think) for interactive > classes?? > > What I meant was you could either change the sfq > queue length or use > esfq, which lets you choose length (and more). > > In practise you setup HTB so that your interactive > traffic - doesn''t > queue - yes you can attach what ever you like to > it''s class - and (e)sfq > would be OK, but if packets actually get queued in > it you marking has > failed and bulk got in or you really have run out of > bandwidth. >2. Could you please tell me a secure and trustworthy way to know if I am having queued packets under this class??> The point I made was that you shouldn''t really send > a mix of traffic to > SFQ which will still cause long delays at low > bitrates and your users > have potentially low rates (depends on what they > do). >3. I am creating 2 different htb classes, one for interactive, and another for bulk, and also, 2 different sfq inferior classes, one for each service. What else can I do to avoid sending a "mix of traffic" ??> I would do a bit more work to priorotise dns/empty > acks/small tcp etc. > as well as VOIP, then give them a class with plenty > of rate spare and > make bulk borrow. This would mean that each user > would notice a bit less > the fact they have hardly any bandwidth (if that''s > the case). >4. If you still have a copy of my script, you can see I am giving "prio 0" to interactive classes, and "prio 1" to bulk classes. I also tested giving prio 0 and prio 1 at filters setup (and also, prio 1 to everybody, I am not so sure what worked better). What else can I do to emphasize interactive traffic priority??> Choosing a queue length should really be related to > link speed - but you > can''t do this if you have lots of queues whose rate > are variable. What > to choose depends on typical and I suppose worst > case traffic situation > for your LAN. > > Alternatly if you were prepared to patch and use > esfq you could use it > to roughly share traffic by IP address - which is > nice to save you > marking and because you are able to set the queue > length for the link. > You do though, loose fairness per connection which > may not affect you - > again it depends on usage P2P. bittorrent etc. > > > > > > > > I am curious about this myself. I placed a > default sfq qdisc with the 128 > > queue default on a p2p class that had a rate of > 144kbit and it routinely > > spiked to about 150kbit several times a second. > If I use pfifo with a queue > > length of 10 I find my utilization for that class > at around 146kbit instead. > > Is it the queue length causing this behavior? > > > > I think these differences are too small to be > representative. One packet > could add 12kbit to a counter instantaneously and > how you measure can > decieve. For one really low rate class the way HTB > uses DRR to even out > fairness for different sized packets could, I think > cause short term > variations. P2P traffic is mixed packet size and > quite variable > depending on peers - so recreating behavior for > tests may be hard. I > don''t think queue length is involved here. > > Andy. > > > --__--__--Sorry for the annoyances, very thanks in advance. Ricardo. _________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Ricardo Soria wrote:> 1. So, starting at 80% of total 512kbit bandwidth > (410kbit), there would be a waste of 102kbit. Is this > completely necessary?? I think this is to ensure I > have the queue on my side, and the queue is not on the > side of the ISP. But, I fell tempted to think that > 102kbit is too much for this purpose, considering that > I really have 512kbit all time. What would you > finally recommend ??It depends how much you care about latency & what the people on your LAN do/use. I don''t know what''s acceptable latency and jitter for VOIP.> 2. Could you please tell me a secure and trustworthy > way to know if I am having queued packets under this > class??Again how much you have to do depends on the usage of your network. You can explicitly mark each type of interavtive you want to priorotise. If you have 20 hackers using P2P 24/7 then life is going to be harder - if they just browse and email It''s probably not worth trying too hard.> > 3. I am creating 2 different htb classes, one for > interactive, and another for bulk, and also, 2 > different sfq inferior classes, one for each service. > What else can I do to avoid sending a "mix of traffic" > ??If you have one queue for bulk it would need to be esfq if you want per IP fairness. If you''d rather not patch then your origional queue for each user is OK - but you should change SFQ''s queue length.> > 4. If you still have a copy of my script, you can see > I am giving "prio 0" to interactive classes, and "prio > 1" to bulk classes. I also tested giving prio 0 and > prio 1 at filters setup (and also, prio 1 to > everybody, I am not so sure what worked better). What > else can I do to emphasize interactive traffic > priority?? >The prio is most important, other things I do are - make sure interactive has large burst and bulk none. Rather than mess with r2q I set quantum to my MTU for HTB and SFQ. HTB can be tweaked to be more accurate - but you may not need to bother. I also set a rate for my interactive larger than I ever expect to be used, this is probably unneccesary, but then I count game traffic a top prio - and I was using upto 20K bytes/sec incoming while on a 64 player enemy territory server recently.> Sorry for the annoyances, very thanks in advance.That''s OK - It would help to know what the users do and how many are active at once etc. Andy. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Andy Furniss wrote:> Ricardo Soria wrote: > > >> 1. So, starting at 80% of total 512kbit bandwidth >> (410kbit), there would be a waste of 102kbit. Is this >> completely necessary?? I think this is to ensure I >> have the queue on my side, and the queue is not on the >> side of the ISP. But, I fell tempted to think that >> 102kbit is too much for this purpose, considering that >> I really have 512kbit all time. What would you >> finally recommend ?? > > > It depends how much you care about latency & what the people on your > LAN do/use. > > I don''t know what''s acceptable latency and jitter for VOIP.not all that important. we have 400ms ping time to one site, but the voip is acceptable because it doesn''t synchronise. if packet loss is a problem, turn off any compression.> > >> 2. Could you please tell me a secure and trustworthy >> way to know if I am having queued packets under this >> class?? > > > Again how much you have to do depends on the usage of your network. > You can explicitly mark each type of interavtive you want to priorotise. > > If you have 20 hackers using P2P 24/7 then life is going to be harder > - if they just browse and email It''s probably not worth trying too hard. > >> >> 3. I am creating 2 different htb classes, one for >> interactive, and another for bulk, and also, 2 >> different sfq inferior classes, one for each service. What else can I >> do to avoid sending a "mix of traffic" >> ?? > > > If you have one queue for bulk it would need to be esfq if you want > per IP fairness. If you''d rather not patch then your origional queue > for each user is OK - but you should change SFQ''s queue length. > >> >> 4. If you still have a copy of my script, you can see >> I am giving "prio 0" to interactive classes, and "prio >> 1" to bulk classes. I also tested giving prio 0 and >> prio 1 at filters setup (and also, prio 1 to >> everybody, I am not so sure what worked better). What >> else can I do to emphasize interactive traffic >> priority?? >> > > The prio is most important, other things I do are - make sure > interactive has large burst and bulk none. Rather than mess with r2q I > set quantum to my MTU for HTB and SFQ. HTB can be tweaked to be more > accurate - but you may not need to bother. I also set a rate for my > interactive larger than I ever expect to be used, this is probably > unneccesary, but then I count game traffic a top prio - and I was > using upto 20K bytes/sec incoming while on a 64 player enemy territory > server recently. > >> Sorry for the annoyances, very thanks in advance. > > > That''s OK - It would help to know what the users do and how many are > active at once etc. > > Andy. > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Dear friends: Very thanks for all your help. I have made many changes to my scrip this days, fixing up some problems and mistakes I found. It seems now I have a very acceptable VoIP quality, and everything is working notably better. I am actually using 450kbit of the total 512 available. Next step I will take is to investigate about ESQF, so, I can implement it to my script. I will be annoying by here later ;-) Thanks. Ricardo. --- Rick Marshall <rjm@zenucom.com> escribió:> Andy Furniss wrote: > > > Ricardo Soria wrote: > > > > > >> 1. So, starting at 80% of total 512kbit > bandwidth > >> (410kbit), there would be a waste of 102kbit. Is > this > >> completely necessary?? I think this is to ensure > I > >> have the queue on my side, and the queue is not > on the > >> side of the ISP. But, I fell tempted to think > that > >> 102kbit is too much for this purpose, considering > that > >> I really have 512kbit all time. What would you > >> finally recommend ?? > > > > > > It depends how much you care about latency & what > the people on your > > LAN do/use. > > > > I don''t know what''s acceptable latency and jitter > for VOIP. > > not all that important. we have 400ms ping time to > one site, but the > voip is acceptable because it doesn''t synchronise. > if packet loss is a > problem, turn off any compression. > > > > > > >> 2. Could you please tell me a secure and > trustworthy > >> way to know if I am having queued packets under > this > >> class?? > > > > > > Again how much you have to do depends on the usage > of your network. > > You can explicitly mark each type of interavtive > you want to priorotise. > > > > If you have 20 hackers using P2P 24/7 then life is > going to be harder > > - if they just browse and email It''s probably not > worth trying too hard. > > > >> > >> 3. I am creating 2 different htb classes, one > for > >> interactive, and another for bulk, and also, 2 > >> different sfq inferior classes, one for each > service. What else can I > >> do to avoid sending a "mix of traffic" > >> ?? > > > > > > If you have one queue for bulk it would need to be > esfq if you want > > per IP fairness. If you''d rather not patch then > your origional queue > > for each user is OK - but you should change SFQ''s > queue length. > > > >> > >> 4. If you still have a copy of my script, you > can see > >> I am giving "prio 0" to interactive classes, and > "prio > >> 1" to bulk classes. I also tested giving prio 0 > and > >> prio 1 at filters setup (and also, prio 1 to > >> everybody, I am not so sure what worked better). > What > >> else can I do to emphasize interactive traffic > >> priority?? > >> > > > > The prio is most important, other things I do are > - make sure > > interactive has large burst and bulk none. Rather > than mess with r2q I > > set quantum to my MTU for HTB and SFQ. HTB can be > tweaked to be more > > accurate - but you may not need to bother. I also > set a rate for my > > interactive larger than I ever expect to be used, > this is probably > > unneccesary, but then I count game traffic a top > prio - and I was > > using upto 20K bytes/sec incoming while on a 64 > player enemy territory > > server recently. > > > >> Sorry for the annoyances, very thanks in advance. > > > > > > That''s OK - It would help to know what the users > do and how many are > > active at once etc. > > > > Andy. > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc > HOWTO: http://lartc.org/ > > > > begin:vcard > fn:Rick Marshall > n:Marshall;Rick > email;internet:rjm@zenucom.com > tel;cell:+61 411 287 530 > x-mozilla-html:TRUE > version:2.1 > end:vcard > >_________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Well, as I promised, here I am again :-) I have not got ESFQ yet, but what I think really helped was shorting bandwidth capacity to its 88%. But here I have a new problem again: there are certain moments when I am really running out of bandwidth. The scenario now is as follows: I am using my linux box as a router; forwarding packages from on subnet to another. But, since I have only one interface (eth0) for this purpose, both incoming and outgoing traffic passes for this interface. So, I though it was correct to duplicate bandwidth capacity (512kbit * 88% = 450kbit * 2 900kbit), considering that I have 512kbit for uplink and 512 for downlink. So, I am now considering a rate/ceil of 900kbit for eth0 on my script. Everything appeared to be OK, But, since I did this change, there are certain moments that I run out of downlink bandwidth, so, I think the script is trying to take more thank the total 512 of downlink I have. So, my question would be, how to ''divide'' or ''recognize'' incoming and outgoing traffic, and to treat it as different channels?? I was thinking about using a IMQ device for incoming traffic, but this apperas to be a ''little bit'' more complicated that what I expected. So, may it be a way to do this without installing IMQ ?? Very thanks in advance. Best regards. Ricardo. --- Andy Furniss <andy.furniss@dsl.pipex.com> escribió:> Ricardo Soria wrote: > > > > 1. So, starting at 80% of total 512kbit bandwidth > > (410kbit), there would be a waste of 102kbit. Is > this > > completely necessary?? I think this is to ensure > I > > have the queue on my side, and the queue is not on > the > > side of the ISP. But, I fell tempted to think > that > > 102kbit is too much for this purpose, considering > that > > I really have 512kbit all time. What would you > > finally recommend ?? > > It depends how much you care about latency & what > the people on your LAN > do/use. > > I don''t know what''s acceptable latency and jitter > for VOIP. > > > > 2. Could you please tell me a secure and > trustworthy > > way to know if I am having queued packets under > this > > class?? > > Again how much you have to do depends on the usage > of your network. You > can explicitly mark each type of interavtive you > want to priorotise. > > If you have 20 hackers using P2P 24/7 then life is > going to be harder - > if they just browse and email It''s probably not > worth trying too hard. > > > > > 3. I am creating 2 different htb classes, one for > > interactive, and another for bulk, and also, 2 > > different sfq inferior classes, one for each > service. > > What else can I do to avoid sending a "mix of > traffic" > > ?? > > If you have one queue for bulk it would need to be > esfq if you want per > IP fairness. If you''d rather not patch then your > origional queue for > each user is OK - but you should change SFQ''s queue > length. > > > > > 4. If you still have a copy of my script, you can > see > > I am giving "prio 0" to interactive classes, and > "prio > > 1" to bulk classes. I also tested giving prio 0 > and > > prio 1 at filters setup (and also, prio 1 to > > everybody, I am not so sure what worked better). > What > > else can I do to emphasize interactive traffic > > priority?? > > > > The prio is most important, other things I do are - > make sure > interactive has large burst and bulk none. Rather > than mess with r2q I > set quantum to my MTU for HTB and SFQ. HTB can be > tweaked to be more > accurate - but you may not need to bother. I also > set a rate for my > interactive larger than I ever expect to be used, > this is probably > unneccesary, but then I count game traffic a top > prio - and I was using > upto 20K bytes/sec incoming while on a 64 player > enemy territory server > recently. > > > Sorry for the annoyances, very thanks in advance. > > That''s OK - It would help to know what the users do > and how many are > active at once etc. > > Andy. > >_________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Dear Chris: Thanks for your sugestion. But my situation is really more complicated than that. What I am really doing is this: I have 2 cisco routers, a 1601, that gives me connection to Internet, and ahother, a 827, that gives me a connection to my other (remote) subnet. My linux box is in the middle of both ciscos. So, the ciscos, and my linux box have an IP address each, this IPs belong to the same subnet. What the linux box does is to receive the traffic from the cisco 1600, shape and filter this traffic, and forward the packages destined to the remote subnet, to the cisco 827. So, an additional ethernet card wouldn''t be so much aid, would it ?? Very thanks. Ricardo. --- Chris Bennett <chris@symbio.com> escribió:> I struggled with this sort of thing for a while. > Then I realized it was > easier to just buy another ethernet card for $10. I > suggest you do that. > > ----- Original Message ----- > From: "Ricardo Soria" <ricardo_soria@yahoo.com> > To: "Andy Furniss" <andy.furniss@dsl.pipex.com> > Cc: <lartc@mailman.ds9a.nl> > Sent: Wednesday, November 24, 2004 1:08 PM > Subject: Re: [LARTC] SEPARATING VOIP AND SURFING > > > > Well, as I promised, here I am again :-) > > > > I have not got ESFQ yet, but what I think really > > helped was shorting bandwidth capacity to its 88%. > > But here I have a new problem again: there are > > certain moments when I am really running out of > > bandwidth. The scenario now is as follows: > > > > I am using my linux box as a router; forwarding > > packages from on subnet to another. But, since I > have > > only one interface (eth0) for this purpose, both > > incoming and outgoing traffic passes for this > > interface. So, I though it was correct to > duplicate > > bandwidth capacity (512kbit * 88% = 450kbit * 2 > > 900kbit), considering that I have 512kbit for > uplink > > and 512 for downlink. So, I am now considering a > > rate/ceil of 900kbit for eth0 on my script. > > Everything appeared to be OK, But, since I did > this > > change, there are certain moments that I run out > of > > downlink bandwidth, so, I think the script is > trying > > to take more thank the total 512 of downlink I > have. > > > > So, my question would be, how to ''divide'' or > > ''recognize'' incoming and outgoing traffic, and to > > treat it as different channels?? I was thinking > about > > using a IMQ device for incoming traffic, but this > > apperas to be a ''little bit'' more complicated that > > what I expected. So, may it be a way to do this > > without installing IMQ ?? > > > > Very thanks in advance. > > > > Best regards. > > > > Ricardo. > > > > --- Andy Furniss <andy.furniss@dsl.pipex.com> > > escribió: > >> Ricardo Soria wrote: > >> > >> > >> > 1. So, starting at 80% of total 512kbit > bandwidth > >> > (410kbit), there would be a waste of 102kbit. > Is > >> this > >> > completely necessary?? I think this is to > ensure > >> I > >> > have the queue on my side, and the queue is not > on > >> the > >> > side of the ISP. But, I fell tempted to think > >> that > >> > 102kbit is too much for this purpose, > considering > >> that > >> > I really have 512kbit all time. What would you > >> > finally recommend ?? > >> > >> It depends how much you care about latency & what > >> the people on your LAN > >> do/use. > >> > >> I don''t know what''s acceptable latency and jitter > >> for VOIP. > >> > >> > >> > 2. Could you please tell me a secure and > >> trustworthy > >> > way to know if I am having queued packets under > >> this > >> > class?? > >> > >> Again how much you have to do depends on the > usage > >> of your network. You > >> can explicitly mark each type of interavtive you > >> want to priorotise. > >> > >> If you have 20 hackers using P2P 24/7 then life > is > >> going to be harder - > >> if they just browse and email It''s probably not > >> worth trying too hard. > >> > >> > > >> > 3. I am creating 2 different htb classes, one > for > >> > interactive, and another for bulk, and also, 2 > >> > different sfq inferior classes, one for each > >> service. > >> > What else can I do to avoid sending a "mix of > >> traffic" > >> > ?? > >> > >> If you have one queue for bulk it would need to > be > >> esfq if you want per > >> IP fairness. If you''d rather not patch then your > >> origional queue for > >> each user is OK - but you should change SFQ''s > queue > >> length. > >> > >> > > >> > 4. If you still have a copy of my script, you > can > >> see > >> > I am giving "prio 0" to interactive classes, > and > >> "prio > >> > 1" to bulk classes. I also tested giving prio > 0 > >> and > >> > prio 1 at filters setup (and also, prio 1 to > >> > everybody, I am not so sure what worked > better). > >> What > >> > else can I do to emphasize interactive traffic > >> > priority?? > >> > > >> > >> The prio is most important, other things I do are > - > >> make sure > >> interactive has large burst and bulk none. Rather > >> than mess with r2q I > >> set quantum to my MTU for HTB and SFQ. HTB can be > >> tweaked to be more > >> accurate - but you may not need to bother. I also > >> set a rate for my > >> interactive larger than I ever expect to be used, > >> this is probably > >> unneccesary, but then I count game traffic a top > >> prio - and I was using > >> upto 20K bytes/sec incoming while on a 64 player > >> enemy territory server > >> recently. > >> > >> > Sorry for the annoyances, very thanks in > advance. > >> > >> That''s OK - It would help to know what the users > do > >> and how many are > >> active at once etc. > >> > >> Andy. > >> > >> > > > > >_________________________________________________________> > Do You Yahoo!? > > Información de Estados Unidos y América Latina, en > Yahoo! Noticias. > > Visítanos en http://noticias.espanol.yahoo.com > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc > HOWTO: http://lartc.org/ > > > >_________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Ricardo Soria wrote:> Well, as I promised, here I am again :-) > > I have not got ESFQ yet, but what I think really > helped was shorting bandwidth capacity to its 88%. > But here I have a new problem again: there are > certain moments when I am really running out of > bandwidth. The scenario now is as follows: > > I am using my linux box as a router; forwarding > packages from on subnet to another. But, since I have > only one interface (eth0) for this purpose, both > incoming and outgoing traffic passes for this > interface. So, I though it was correct to duplicate > bandwidth capacity (512kbit * 88% = 450kbit * 2 > 900kbit), considering that I have 512kbit for uplink > and 512 for downlink. So, I am now considering a > rate/ceil of 900kbit for eth0 on my script. > Everything appeared to be OK, But, since I did this > change, there are certain moments that I run out of > downlink bandwidth, so, I think the script is trying > to take more thank the total 512 of downlink I have. > > So, my question would be, how to ''divide'' or > ''recognize'' incoming and outgoing traffic, and to > treat it as different channels?? I was thinking about > using a IMQ device for incoming traffic, but this > apperas to be a ''little bit'' more complicated that > what I expected. So, may it be a way to do this > without installing IMQ ??Yes you will need IMQ. I assume you can mark traffic from/to the ciscos. The detail depends on your exact setup - NAT, link speeds and type of link from ciscos etc. Do you just wan''t to shape traffic forwarded from internet to remote subnet? Andy. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Andy Furniss wrote:>> So, my question would be, how to ''divide'' or >> ''recognize'' incoming and outgoing traffic, and to >> treat it as different channels?? I was thinking about >> using a IMQ device for incoming traffic, but this >> apperas to be a ''little bit'' more complicated that >> what I expected. So, may it be a way to do this >> without installing IMQ ?? > > > Yes you will need IMQ.Second thoughts - you may be able to do without IMQ as long as it''s just forwarded traffic. Andy. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
--- Andy Furniss <andy.furniss@dsl.pipex.com> escribió:> Andy Furniss wrote: > > >> So, my question would be, how to ''divide'' or > >> ''recognize'' incoming and outgoing traffic, and to > >> treat it as different channels?? I was thinking > about > >> using a IMQ device for incoming traffic, but this > >> apperas to be a ''little bit'' more complicated > that > >> what I expected. So, may it be a way to do this > >> without installing IMQ ?? > > > > > > Yes you will need IMQ. > > Second thoughts - you may be able to do without IMQ > as long as it''s just > forwarded traffic. > > Andy. > >Andy: What I am exactly doing is this: I receive all traffic from the cisco 1600, then, filter/shape/monitor it, then, if this traffic is destined to the remote subnet, it is send to the cisco 827, but, if the traffic is for the local subnet (including both ciscos, and the linux box), it is directly delivered to its destination. All of this is done via eth0, as much outgoing as incoming traffic. So, specially cosidering about the local subnet, do you think I should definitively use IMQ or not?? However, I have also posted in linuximq list, because I cannot find IMQ patch for my linux box (Redhat 7.3, 2.4.18-3 Kernel) Very thanks in advance. Ricardo. _________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Ricardo Soria wrote:> --- Andy Furniss <andy.furniss@dsl.pipex.com> > escribió: > >>Andy Furniss wrote: >> >> >>>>So, my question would be, how to ''divide'' or >>>>''recognize'' incoming and outgoing traffic, and to >>>>treat it as different channels?? I was thinking >> >>about >> >>>>using a IMQ device for incoming traffic, but this >>>>apperas to be a ''little bit'' more complicated >> >>that >> >>>>what I expected. So, may it be a way to do this >>>>without installing IMQ ?? >>> >>> >>>Yes you will need IMQ. >> >>Second thoughts - you may be able to do without IMQ >>as long as it''s just >>forwarded traffic. >> >>Andy. >> >> > > > Andy: > > What I am exactly doing is this: I receive all > traffic from the cisco 1600, then, > filter/shape/monitor it, then, if this traffic is > destined to the remote subnet, it is send to the cisco > 827, but, if the traffic is for the local subnet > (including both ciscos, and the linux box),The only thing you would need IMQ for is if you need to shape traffic from the 1600 to a local process on the linux box - so you may - it depends on what else you are running on the shaping box that causes bulk traffic to it. it is> directly delivered to its destination. All of this is > done via eth0, as much outgoing as incoming traffic. > So, specially cosidering about the local subnet, do > you think I should definitively use IMQ or not??If eth0 has as much incoming as outgoing then there is no traffic to local process? Do you want to shape eth0 aswell as the internet link or is it OK for spare bandwidth? Andy.> > However, I have also posted in linuximq list, because > I cannot find IMQ patch for my linux box (Redhat 7.3, > 2.4.18-3 Kernel) > > Very thanks in advance. > > Ricardo. > > _________________________________________________________ > Do You Yahoo!? > Información de Estados Unidos y América Latina, en Yahoo! Noticias. > Visítanos en http://noticias.espanol.yahoo.com >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
--- Andy Furniss <andy.furniss@dsl.pipex.com> escribió:> Ricardo Soria wrote: > > --- Andy Furniss <andy.furniss@dsl.pipex.com> > > escribió: > > > >>Andy Furniss wrote: > >> > >> > >>>>So, my question would be, how to ''divide'' or > >>>>''recognize'' incoming and outgoing traffic, and > to > >>>>treat it as different channels?? I was thinking > >> > >>about > >> > >>>>using a IMQ device for incoming traffic, but > this > >>>>apperas to be a ''little bit'' more complicated > >> > >>that > >> > >>>>what I expected. So, may it be a way to do this > >>>>without installing IMQ ?? > >>> > >>> > >>>Yes you will need IMQ. > >> > >>Second thoughts - you may be able to do without > IMQ > >>as long as it''s just > >>forwarded traffic. > >> > >>Andy. > >> > >> > > > > > > Andy: > > > > What I am exactly doing is this: I receive all > > traffic from the cisco 1600, then, > > filter/shape/monitor it, then, if this traffic is > > destined to the remote subnet, it is send to the > cisco > > 827, but, if the traffic is for the local subnet > > (including both ciscos, and the linux box), > > The only thing you would need IMQ for is if you need > to shape traffic > from the 1600 to a local process on the linux box - > so you may - it > depends on what else you are running on the shaping > box that causes bulk > traffic to it. > > > it is > > directly delivered to its destination. All of > this is > > done via eth0, as much outgoing as incoming > traffic. > > So, specially cosidering about the local subnet, > do > > you think I should definitively use IMQ or not?? > > If eth0 has as much incoming as outgoing then there > is no traffic to > local process? >There may be traffic for a local (linux box) process, but the most of the traffic will be redirected or passed.> Do you want to shape eth0 aswell as the internet > link or is it OK for > spare bandwidth? >I cannot translate/understand perfectly this question, but I do need to shape the internet link. So, returning to the question that originated this discussion, how can I diferentiate/separate incoming and outgoing traffic for the same interface (eth0), without confusing each other, and without using IMQ devices if possible ??> Andy. > > > > > > However, I have also posted in linuximq list, > because > > I cannot find IMQ patch for my linux box (Redhat > 7.3, > > 2.4.18-3 Kernel) > > > > Very thanks in advance. > > > > Ricardo. > > > > >_________________________________________________________> > Do You Yahoo!? > > Información de Estados Unidos y América Latina, en > Yahoo! Noticias. > > Visítanos en http://noticias.espanol.yahoo.com > > > > >_________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Ricardo Soria wrote:> > There may be traffic for a local (linux box) process, > but the most of the traffic will be redirected or > passed. > > >>Do you want to shape eth0 aswell as the internet >>link or is it OK for >>spare bandwidth? >> > > > I cannot translate/understand perfectly this question, > but I do need to shape the internet link.I didn''t know if there was other (LAN) traffic that needed shaping aswell as internet traffic.> > So, returning to the question that originated this > discussion, how can I diferentiate/separate incoming > and outgoing traffic for the same interface (eth0), > without confusing each other, and without using IMQ > devices if possible ??If bulk transfers from internet to shaping box are rare enough for you not to care about them, then you can do without IMQ. As for seperating traffic - in prerouting you should be able to mark traffic by source MAC address (1600) and the same in postrouting for destination MAC. You could then use the marks to send to different HTB classes that don''t share. Andy. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Ricardo Soria wrote:> So, returning to the question that originated this > discussion, how can I diferentiate/separate incoming > and outgoing traffic for the same interface (eth0), > without confusing each other, and without using IMQ > devices if possible ??My mails don''t seem to be getting to/from LARTC - I assume you got my other reply. I put to mark on MAC - this only works for src MAC with iptables in prerouting or forward eg. iptables -I PREROUTING -t mangle -m mac --mac-source AA:BB:CC:DD:EE:FF -j MARK --set-mark 123 For dst MAC address you need to use u32 eg. tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800 0xFFFF at -2 match u32 0xCCDDEEFF 0xFFFFFFFF at -12 match u16 0xAABB 0xFFFF at -14 flowid 1:1 Andy. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
--- Andy Furniss <andy.furniss@dsl.pipex.com> escribió:> Ricardo Soria wrote: > > > So, returning to the question that originated this > > discussion, how can I diferentiate/separate > incoming > > and outgoing traffic for the same interface > (eth0), > > without confusing each other, and without using > IMQ > > devices if possible ?? > > My mails don''t seem to be getting to/from LARTC - I > assume you got my > other reply.I did receive your previous e-mail. Lartc mailing list appears to not be working now.> > I put to mark on MAC - this only works for src MAC > with iptables in > prerouting or forward eg. > > iptables -I PREROUTING -t mangle -m mac --mac-source > AA:BB:CC:DD:EE:FF > -j MARK --set-mark 123 > > For dst MAC address you need to use u32 eg. > > tc filter add dev eth0 parent 1:0 protocol ip prio 1 > u32 match u16 > 0x0800 0xFFFF at -2 match u32 0xCCDDEEFF 0xFFFFFFFF > at -12 match u16 > 0xAABB 0xFFFF at -14 flowid 1:1 >Very thanks for your suggestion, but... Consider that the traffic that comes from the cisco 1600 is not originated into itself; this router is just passing traffic that comes from Internet (infinite source MAC addresses possible), so, I really couldn''t shape traffic by its source MAC address. The same for the cisco 827, except that possible destination MAC addresses are not so much. Traffic that my linux box sends to cisco 827 is not finally for itself, but for any computer in the remote subnet.> Andy. > >_________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Ricardo Soria wrote:> Very thanks for your suggestion, but... Consider that > the traffic that comes from the cisco 1600 is not > originated into itself; this router is just passing > traffic that comes from Internet (infinite source MAC > addresses possible)I don''t think so - ethernet is link layer , so, I really couldn''t shape> traffic by its source MAC address.So if you use iptraf lan monitor you can not see the MAC of the ciscos sending and receiving? The same for the> cisco 827, except that possible destination MAC > addresses are not so much. Traffic that my linux box > sends to cisco 827 is not finally for itself, but for > any computer in the remote subnet.Even if the MAC bit doesn''t work, I think if you can manage to route the traffic properly, then you should be able to mark/filter it for shaping. Andy. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
--- Andy Furniss <andy.furniss@dsl.pipex.com> escribió:> Ricardo Soria wrote: > > > Very thanks for your suggestion, but... Consider > that > > the traffic that comes from the cisco 1600 is not > > originated into itself; this router is just > passing > > traffic that comes from Internet (infinite source > MAC > > addresses possible) > > I don''t think so - ethernet is link layer > > > , so, I really couldn''t shape > > traffic by its source MAC address. > > So if you use iptraf lan monitor you can not see the > MAC of the ciscos > sending and receiving? >It seems you are right: I was monitoring using iptraf, and I really could see cisco''s MAC addresses as source MACs of all traffic. It is strange for me. Could we say all packages take last node''s MAC address as source MAC address ??> > The same for the > > cisco 827, except that possible destination MAC > > addresses are not so much. Traffic that my linux > box > > sends to cisco 827 is not finally for itself, but > for > > any computer in the remote subnet. > > Even if the MAC bit doesn''t work, I think if you can > manage to route the > traffic properly, then you should be able to > mark/filter it for shaping.Ok, I agree, but finally, if I mark traffic by source MAC address, or by IP, or I don''t do it, that would only affect the way I would do filtering (tc filter...), but I cannot really see how this would help separating incoming and outgoing traffic by the same interface. By the way, I saw an example, possibly in lartc archive, where another guy had a similar problem, and he made 2 root classes, with the same bandwidth for both of them, one for outgoing and another for incoming. Do you think this is an acceptable way to try to separete it, and if so, do you think I should create 2 root qdiscs (is this possible??), or just 1 root qdisc and 2 root (child or qdisc) classes ?? Very thanks... Regards.> > Andy. > >_________________________________________________________ Do You Yahoo!? Información de Estados Unidos y América Latina, en Yahoo! Noticias. Visítanos en http://noticias.espanol.yahoo.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/