RE: [LARTC] ROUTING, POSTROUTING, & Traffic Control

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff,

 : I may have been too quick to suggest a "solution" before describing the
 : problem I'm having. More specifically: machine A is an outbound emailer
 : and machine B runs a website. When A is sending at high volume it can
 : take up to 30 seconds to get an HTTP response from machine B. I naively
 : assumed the solution was to install more NIC cards and build separate
 : "channels" for A & B.

Chances are that the network interface card is not the bottleneck on your
bandwidth.  Chances are that it is something like a DSL line, or a T1, or
maybe capped bandwidth on an upstream router.  Whether you have one NIC or
two facing the outside world, the problem revolves around both machines
gluttonously gorging themselves on your bandwidth.  Your router can divide
access to bandwidth between machines A and B in a controllable manner.

<snipped diagram>

 : As for iptables, I currently include these two statements:
 :
 : -A PREROUTING -i eth0 -d 64.41.183.130 -p tcp -m tcp --dport 80 -j
 : DNAT --to-destination 192.168.1.17:80
 : -A PREROUTING -i eth2 -d 64.41.183.131 -p tcp -m tcp --dport 25 -j
 : DNAT --to-destination 192.168.1.26:25

Right--a little bit of DNAT never hurt anybody....

 : which presumably routes web traffic coming in on eth0 to the web server
 : (machine B) and which routes smtp traffic coming in on eth1 to the email
 : server (machine A). ASSUMING this is correct, I'd like to be able to turn
 : this around and map outbound traffic from A through 64.130.183.130 and
 : outbound traffic from B through 64.130.183.131.

How's this:

-A POSTROUTING -i eth1 -s 192.1.68.1.17 -j SNAT --to-source 64.41.183.130
-A POSTROUTING -i eth1 -s 192.1.68.1.26 -j SNAT --to-source 64.41.183.131

 : Another naive assumption I have made is that eth1 could become a
 : chokepoint and I could add eth3 with IP 192.168.1.9. So, that when
 : everything was done, I would have these 2 channels:

<snipped diagram>

Jeff, I don't think this is the correct solution for your problem.  I
think what will be better for you is to understand how to apply HTB (or
traffic control, more generally) to your problem.

Here's an off-the-cuff suggestion, patterned closely after this common
need (two or more bandwidth-hungry hosts competing over the available
bandwidth):

  - add an HTB class with rate equal to your total outbound bandwidth,
    minus a bit so that you become the bottleneck (10%?, Stef?)
  - add two nested HTB classes with an SFQ qdisc (per Martin Devera's
    suggestion on the HTB site)
  - set the rate on each class to a fraction of your total bandwidth,
    and set the ceil (ceiling) on each class to the rate of the
    parent class
  - classify traffic from machine A into one class; classify traffic
    from machine B into the other class

Good luck,

-Martin


-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux