I have a similar case, 15 users, 5 with p2p, I want to route p2p traffic on
a second trunk and live normal traffic on a primary trunk.
HOW TO DO IT?
I am a bit lost....
----- Original Message -----
From: "Adam Nellemann" <adam at nellemann dot nu>
To: <procha at volny dot cz>
Cc: <m0n0wall at lists dot m0n0 dot ch>
Sent: Tuesday, February 17, 2004 11:56 PM
Subject: Re: [m0n0wall] Dynamic traffic shaper - how?
> procha at volny dot cz wrote:
> > Hi,
> > I'm note sure if I understand everithing wall. I'll get example
> I'm afraid I'm not sure if I understand everything you write either,
> so I guess we're even :)
> > LAN total 10 users
> > Internet 128 kbit/sec , internet adresses on provider network 2
> > mbits/sec. Pipe1 128 kbit Queue 1 - 10 linked to pipe1 priority 2
> > for each user
> > I thinkt result of this configuration will be guaranted speed
> > 128/active users for each at the moment .
> You don't have to make 10 queues manually, instead you can use the
> "Mask" (in your case with LAN users, use "Source" for an outbound
> queue and "Destination" for an inbound queue), this should cause the
> shaper to make a queue for each LAN host!
> I think, however, that what you really want to do, is to mask the
> pipes in this way (possible in addition to the queues being masked).
> If you only make a lot of queues (or use masking to achieve the samme
> effect), that all goes through the same 128Kbit pipe, they will all
> share these 128Kbit!
> The general rule (as far as I can tell) is:
> - Use pipes to limit bandwidth. (Use one to share bandwidth between
> hosts dynamically. Use several, either manual or masked, to split
> bandwidth statically between hosts)
> - Use queues to prioritise bandwidth. (In your case it will probably
> be a good idea to mask the queues in the same way as the pipes, so
> each LAN host will have its own queue, and thus work exactly as if it
> had its own 128Kbit WAN connection.)
> Also, make sure to get the masks right, as otherwise you will end up
> with a pipe/queue for each internet host accessed by your LAN hosts,
> probably not exactly what you want, and might very well put a large
> strain on m0n0wall (swapping the masks would the LAN hosts 128Kbit to
> each WAN host it connects to, instead of 128Kbit total. Futhermore
> m0n0wall would have to maintain a pipe/queue for each WAN host
> currently connected to any of your LAN hosts, possibly quite a lot!)
> As I mentioned, you will probably want to make all your rules work on
> the WAN interface. There is seldom any reason to shape LAN traffic. An
> exception could be reserving a little LAN bandwidth for WAN traffic,
> preventing one set of LAN hosts from slowing down other hosts using
> the WAN. I would personally do this by making some pipes and queues
> for the LAN, and set these up to share the bandwidth dynamically, but
> if you want to be absolutely sure that LAN traffic never limits WAN
> traffic, you might want to use a static split instead?
> > Problem - limeted servers before provider shaper (email).
> > Possible solution:
> > 1. set higher pipe speed - you said I wouldn't work
> > 2. map ip adresses before shaper to other pipe (but I'm not sure
> > If I get all adresses)
> I'm unsure what you want here?
> If what you need is to prioritise some types of packages (ie. either a
> special kind of traffic, or traffic to a number of special servers),
> the this can be done by making a number of queues (two or three should
> suffice), each with different "Ratios", but going to the same pipe.
> You can then make some rules for the "special" packets (ie. either for
> some protocols, such as POP3 and SMTP, or for the server IPs), that
> uses the pipe with the higher "Ratio", and some rules for everything
> else that use the pipe with lower "Ratio". This should ensure that the
> "special" packets gets a higher priority than any "normal" traffic.
> Alternativly, you could make a seperate pipe for this "high priority"
> traffic, and let some rules direct all this traffic through this
> "dedicated" pipe (you should of course ensure that the bandwidth of
> all the pipes together does not exceed you actual bandwidth, for this
> to work.)
> The last possibility, which can be used in conjunction with either of
> the above solutions, is to bypass the queues altogether for certain
> kind of traffic, thus ensuring that these don't have to wait for other
> traffic. I guess this should only be done with packets which er either
> small or few in number, as you will otherwise risk backlogging you
> connection and thus effectivly put the shaper out of "control"!
> I hope this helps?
> P.S. To everybody reading this: If you find anything wrong with what I
> write about the shaper, in this or other posts, or if you have
> something further to add, please let me know. I am participating in
> the m0n0wall manual project, and might be the one to write the section
> about the shaper!
> 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