All of lore.kernel.org
 help / color / mirror / Atom feed
From: bert hubert <ahu@ds9a.nl>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Need information on multi-homing
Date: Sun, 03 Mar 2002 11:16:54 +0000	[thread overview]
Message-ID: <marc-lartc-101515429931227@msgid-missing> (raw)
In-Reply-To: <marc-lartc-101511305202598@msgid-missing>

On Sat, Mar 02, 2002 at 09:36:59PM -0800, Bruce Perens wrote:
> Bert Hubert:
> > So what IP address do packets have that come from the firewall box? 
> 
> Oops, I didn't give enough information.  The Linux box is not a router -
> it's a multi-homed server. The DHCP net has one of those retail router
> boxes that does DHCP, NAT, and is a gateway to one of the DSL networks.

Ah ok, so we have the following:


	eth0 SDSL
        ---  
         |     
       Linux -------- [router appliance] ---- ADSL -internet
         |    eth1  
        ---
        eth2 DHCP

> If I try to follow a policy route to either of the DSL interfaces from the
> Linux system itself, not _through_ it as a router.
> 
> 	ip rule add from 216.15.108.186 table dnai-net 
> 	ip rule add from 67.114.175.138 table sbc-net
> 	ip route add default via 216.15.108.186 dev eth0 table dnai-net
> 	ip route add default via 67.114.175.138 dev eth1 table sbc-net
> 
> 	ping -I 67.114.175.138 www.gnu.org
> 
> I get an IMAP "unreachable" message back from the interface.

I still lack information - what are the IP addresses of the Linux machine?
Right now you are telling the kernel to route packets FROM 216.15.108.186 TO
216.15.108.186, which isn't happening :-)

> What I want is to be able to bind to the IP address of either of the DSL
> interfaces, and have the packets routed to that interface reliably.
> If there's a network partition effecting one DSL carrier and not the other,
> it should still be possible to reach the system and the return packets should
> be on the same network as the incoming ones.

You should make sure the policy routes are made from the IP address of eth0
and eth1, and go to the addresses of the routers there. In that case, ping
-I should work. Right now you aren't routing anything to anything, leading
to an ICMP unreachable.

> Load-balancing is secondary, but I have some ideas there. For example, why not
> have squid alternate addresses so that receive data is interleaved across the
> two DSL lines? Wouldn't that balance better than simply routing half of
> the internet through each interface?

It isn't persistent. Many internet sites rely on the fact that users keep
coming from the same IP address during their session.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2002-03-03 11:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-02 23:49 [LARTC] Need information on multi-homing Bruce Perens
2002-03-03  1:21 ` bert hubert
2002-03-03  5:36 ` Bruce Perens
2002-03-03 11:16 ` bert hubert [this message]
2002-03-04 18:51 ` Bruce Perens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-101515429931227@msgid-missing \
    --to=ahu@ds9a.nl \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.