Re: SEPARATING VOIP AND SURFING

Rick Marshall <rjm@xxxxxxxxxxx> · Thu, 25 Nov 2004 09:42:45 +1100

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@xxxxxxxxxx> 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@xxxxxxxxx>

To: "Andy Furniss" <andy.furniss@xxxxxxxxxxxxx>

Cc: <lartc@xxxxxxxxxxxxxxx>

Sent: Wednesday, November 24, 2004 1:08 PM

Subject: Re:  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@xxxxxxxxxxxxx>

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@xxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxx

http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

begin:vcard
fn:Rick  Marshall
n:Marshall;Rick 
email;internet:rjm@xxxxxxxxxxx
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: SEPARATING VOIP AND SURFING

Linux Advanced Routing and Traffic Control