Aron,

 : If I understand whay you are suggesting, there is a problem in your
 : design: It will only work if you use Hide NAT.

...and multiple public IPs.

 : The problem is that the ip_src == IP0 rule is wrong: The ip_src is not
 : changed by the router and it is not equal to the IP of any of the
 : machine interfaces.

OK--maybe the 'ip_src == IP0' rule is not applicable to your situation,
but that doesn't make it wrong.  You describe a different network
configuration than I was envisioning based on Gordan's description.

 : Can you think of a solution that will work in the following reasonable
 : scenario:

I can try!

 : Lets say I have two T1 internet connections connected to one ethernet
 : interface. I do not use Hide-NAT. I want to guarantee at least 512kbps
 : to HTTP traffic on each line (separately) in the 'virtual circuit'
 : method that you mentioned.

Are you pushing different networks across each T1?  If you have Network-A
from ISP-A and Network-B from ISP-B, then you have different addresses to
use in your configuration.

See an untested configuration with some fabricated addresses and netmasks
below.

  #define NETA 216.109.118.64
  #define NETAMASK 28

  #define NETB 63.209.4.192
  #define NETBMASK 27

  dev eth0 {
      egress {
          class ( <$neta> )  if ip_src:NETAMASK == NETA/NETAMASK ;
          class ( <$netb> )  if ip_src:NETBMASK == NETB/NETBMASK ;
          htb () {
            $neta = class ( rate 512kbps, ceil 512kbps ) ;
             $netb = class ( rate 512kbps, ceil 512kbps ) ;
          }
      }
  }


I would think this should provide a skeleton configuration for limiting
outbound (transmitted) traffic originating from separate IP networks on
the same host.

 : I see no way do do this unless I can attach a qdisc to a specific
 : virtual interface.

If you are using a single IP network and you have two different providers
(you're using BGP or similar), then you could consider marking the packets
(fwmark) based on outgoing interface, and perform traffic control based on
this mechanism.

These are just some thoughts based on how I interpret your description of
your network.

Good luck,

-Martin

-- 
Martin A. Brown --- SecurePipe, Inc. --- [EMAIL PROTECTED]
_______________________________________________
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Reply via email to