Re: [LARTC] SEPARATING VOIP AND SURFING

[Rick Marshall <rjm@zenucom.com>]

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