Yes, last night it was 4Mbps the rate of incoming mails. I was wondering if I apply HTB to the following scheme: router -> gw-iface -> MX-server If HTB (new verb) the interface that communicates with MX, say, 2mbit, what will occur to the Input queue of gw-router-iface? Will I still get the link full for 4mbit or will it get lower to 2mbit too, as the inner interface? Appreciate comments -- Je
>Yes, last night it was 4Mbps the rate of incoming mails. >I was wondering if I apply HTB to the following scheme: > >You might want to investigate other anti-spam techniques... For example I find greylisting very effective, and several block lists have very low positives for my spam load. See the mailing list for your MTA if you want to know more though. If you are clever then I''m sure you can dream up even more clever ways to segregate spam senders from real email - in your position I would be blocking IP addresses by now... Ed
I appreciate you answer, Ed. Thank you. I already use some methods of spam contention, such RBLs, filters and SPF checks. But I really wanna know the answer for the question from my first e-mail. Thank you. 4MBIT INPUT router -> gw-iface 2mbit OUTPUT -> MX-server If HTB (new verb) the interface that communicates with MX, say, 2mbit, what will occur to the Input queue of gw-router-iface? Will I still get the link full with 4mbit or will it get lower to 2mbit too, as the inner interface? On 6/16/05, Ed W <lists@wildgooses.com> wrote:> > >Yes, last night it was 4Mbps the rate of incoming mails. > >I was wondering if I apply HTB to the following scheme: > > > > > > You might want to investigate other anti-spam techniques... > > For example I find greylisting very effective, and several block lists > have very low positives for my spam load. See the mailing list for your > MTA if you want to know more though. > > If you are clever then I''m sure you can dream up even more clever ways > to segregate spam senders from real email - in your position I would be > blocking IP addresses by now... > > Ed >
>4MBIT INPUT router -> gw-iface 2mbit OUTPUT -> MX-server > >If HTB (new verb) the interface that communicates with MX, say, 2mbit, >what will occur to the Input queue of gw-router-iface? Will I still >get the link full with 4mbit or will it get lower to 2mbit too, as the >inner interface? > >I would suggest that a read of the LARTC FAQ would be very useful. The main points to absorb would be about how TCP works under the bonnet. Everything else kind of falls out from that. Basically you can''t directly control how fast people throw data at you... The only thing you can do is ignore what they are sending you "and hope they go away"... Well, its a bit more technical than that, but TCP has only one option and that it is to throw away data that you already downloaded over your congested 4mbit link and hope that as a result the sender will slow down That doesn''t quite answer your question, but it should give you hope that it will basically work So in a nutshell, yes - if you use linux QOS to say that MX data can only use half of your available bandwidth, then that should be what you get (steady state). But if you are seeing thousands of new connections per second remember that you can''t control them except by ignoring them for a bit, so the startup process when they fling lots of data at you will still hurt quite a lot. To get started I suggest that you use one of the pre-built scripts and work from there. (And read the FAQ! It''s a great read actually!) Good luck Ed W
> Basically you can''t directly control how fast people throw data at > you... The only thing you can do is ignore what they are sending you > "and hope they go away"... Well, its a bit more technical than that, but > TCP has only one option and that it is to throw away data that you > already downloaded over your congested 4mbit link and hope that as a > result the sender will slow downNote quite true, there is ECN.> get (steady state). But if you are seeing thousands of new connections > per second remember that you can''t control them except by ignoring them > for a bit, so the startup process when they fling lots of data at you > will still hurt quite a lot.Slow start handles this pretty well.