On Wednesday, Jan 29, 2003, at 08:24 US/Central, Phillip Smith (mailing list) wrote:

See reply below...

To create a somewhat redundant network connection, my friend has
connected to business level ADSL connections at his home (32 IPs
each). So, he has two routers, on two different networks
(ATT/UUNET)
and what he's doing is multi-homing his NIC cards and via some
interesting DNS set-up, theoretically, there is some network
redundancy or failover or something.

Anyway, here's the question... how would I set-up two
'defaultrouter'
IPs in my rc.conf? Is that were I would do such a thing?
I'd like to
have the same scenario that he's building with a
multi-homed NIC and
two IPs per VirtualHost directive. I guess there are actually many
steps to accomplish this (as I now start to think about it) but I'm
wondering how to set-up the networking piece first.

Many thanks in advance,
Two truly default routes is not really sensical.  You
generally play games based on source address, TCP port, or
something like that, and
make sure that they NAT separately.  [It has to involve NAT,
because for networks that small, you can't get routes
distributed widely enough to do true multihoming.]

So the answer depends on exactly what hack you want to do.
What I'd like to do is this... right now my NIC answers 212.12.12.212
(for instance) externally and that's the address I use for Apache's
NameVirtualHost directives. I would also like my NIC to answer on
252.12.12.212 (second network connection) and serve the same VirtualHost
directives...

So, what happens is, in NS1.NAMESERVER.NET (which is on the 212 network)
the A record for my box is 212.12.12.212 and, if that network should
fail, the requests will be answered by NS2.NAMESERVER.NET (which is on
the 252 network) and it has an A record for my box of 252.12.12.212. So,
in effect, the name server's availability actually directs the traffic
to the available network connection.

Does that make sense?

I have been running a setup like this for years, and it doesn't require cooperation from the ISP's. Just a little ipfw trickery...

Pick your 'primary' ISP, and set your machine up like normal, with default route etc.

Now alias an IP from the second network onto the same network interface. Now your machine will respond to requests under each address, but the responses will go through the default route. To fix that you can use just a sprinkle of ipfw magic: If the source address of an outbound package equals the second (aliased) IP, then use the 'fwd' command to redirect the package to the second router. Example: Let's assume you picked 212.12.12.212 as the primary address, and 252.12.12.212 as the second (aliased) IP (both /28 networks, <gw> is the last number in the second routers IP address, change as needed). Now these ipfw rules will do the trick:

add 1000 allow all from 212.12.12.212 to any
add 1010 allow all from any to 252.12.12.212/28
add 1020 allow all from any to 212.12.12.212/28
add 1030 fwd 252.12.12.<gw> all from 252.12.12.212 to any

The first rule short-circuits all packets coming from the 'primary' IP and sends them out unmodified.

The second and third rule make sure that the packets that stay within your networks are not modified.

The fourth rule takes the remaining packages coming from the 'secondary' IP and forwards them to the 'secondary' gateway.

This works fine with anything I tried.

However for connections coming from your network (eg your workstation) the default gateway is still honored. So when I am working and my primary connection goes down, I fire up a little script that reverses the roles of the primary and secondary ISP. But again that is only required for connections originating inside your network. All connections coming from the outside will do the right thing with above trickery.

Another note: Having the 2 name servers on the different networks return just the IP of 'their' nettwork is probably a bad idea. The name/IP pairs will be cached on other users systems (even if TTL is set low). It is probably better to simply return both IP's. Any decent (mail/http/whatever) client will try the second IP when the first times out. But that has the side effect of spreading connections over both ISPs, which may or may not be desired.

Gerd


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

Reply via email to