Adam and you all friends:
The incoming traffic shaping works perfect!!! I did it works since the
version 21 beta of Monowall ant it solves my problem (i have a net with 12 users that share an
ADSL connecion 512 kbits downdstream and 128 kbits upstream and when one user opens a program like
Kazaa it takes all the bandwidth and the others users cant navegate).
I solve this making pipes of 64 kbits downstream and 32 kbits upstream, it is a solution, but
I read a lot of info but i dont know how can I do it!
Can anyone help me and helps a lot of guys like me that has the same problem?
> Dinesh Nair wrote:
> > On Mon, 10 May 2004, Tony Pitman wrote:
> >>Well, it is the incoming traffic that is going to be the big problem. I
> >>need to be able to limit how much bandwidth someone can use for
> >>downloading and web browsing. Please expand (without rehashing too much
> >>as you indicated) on what you mean.
> > incoming traffic reaches your m0n0wall before it can be shaped. if it's
> > reached your m0n0wall, it's already put a load on your incoming T1, thus
> > serving no useful purpose in reality.
> While this is true, some time ago there were some posts to the
> contrary (by someone apparantly with a great deal of knowledge about
> these things). It would appear that inbound shaping can have some
> effect, due to packets being dropped, which will apparantly cause most
> servers to slow down transmission of new packets or something along
> those lines?
> > however, since you have dual interfaces, you can set outbound traffic
> > shaping on your wan link and outbound shaping on your lan link. the
> > outbound on your lan should be equivalent to the inbound on your wan, and
> > under your control.
> While I'm not sure, I should think it would have (nearly) the same
> effect if the inbound shaping is done on the WAN interface, at least
> if a queue is used, as m0n0wall should then accept the packages and
> hold them in it's own queue, rather than simply dropping them. But as
> mentioned, it would appear that sometimes it is preferable that
> packets are dropped, so..?
> = = =
> I guess the issue here is to provide a static "cap" on the inbound
> bandwidth of 128K, so a given user only gets what has been paid for.
> The issue of optimal WAN line usage shouldn't be that important (after
> all it is a T1 line!) and as mentioned there is a good chance that it
> will actually result in rather good line usage even so.
> I would certainly try shaping both directions (possibly experimenting
> a bit to see if inbound should be done on the WAN or the LAN IF), only
> if this seem to cause some kind of problem would I consider removing
> the inbound shaping (in which case I'd try to do some clever outbound
> ACK shaping and such instead).
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
El objetivo escencial del correr es probar los limites de la voluntad humana...