[LARTC] SEPARATING VOIP AND SURFING

[LARTC] SEPARATING VOIP AND SURFING

[Ricardo Soria]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Andy Furniss]

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.


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Ricardo Soria]

 --- 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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Jason Boxman]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Andy Furniss]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Jason Boxman]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Andy Furniss]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Ricardo Soria]

> 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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Andy Furniss]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Rick Marshall]

[-- Attachment #1: Type: text/plain, Size: 2867 bytes --]

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/



[-- Attachment #2: rjm.vcf --]
[-- Type: text/x-vcard, Size: 146 bytes --]

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

Re: [LARTC] SEPARATING VOIP AND SURFING

[Ricardo Soria]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Ricardo Soria]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Ricardo Soria]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Rick Marshall]

[-- Attachment #1: Type: text/plain, Size: 8145 bytes --]

i know this will sound a bit flippant - it's not meant to be.

why not get rid of the cisco routers - i haven't found a need for them 
yet.....

my networks work much better without them ;)

rick

Ricardo Soria wrote:

>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/
>  
>


[-- Attachment #2: rjm.vcf --]
[-- Type: text/x-vcard, Size: 146 bytes --]

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

Re: [LARTC] SEPARATING VOIP AND SURFING

[Andy Furniss]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Andy Furniss]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Ricardo Soria]

 --- 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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Andy Furniss]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Ricardo Soria]

 --- 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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Andy Furniss]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Andy Furniss]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Ricardo Soria]

 --- 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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Andy Furniss]

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/

Re: [LARTC] SEPARATING VOIP AND SURFING

[Ricardo Soria]

 --- 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/