From: kashani <kashani-list@badapple.net>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Gentoo router redundancy via Ucarp?
Date: Sun, 04 Sep 2005 22:48:39 -0500 [thread overview]
Message-ID: <431BC017.8050306@badapple.net> (raw)
In-Reply-To: <loom.20050904T215305-267@post.gmane.org>
James wrote:
> Hello,
>
> I'm still hacking at my first Linux firewall. I decided to build
> in redundancy, via CARP which replaces the cisco protocol VRRP.
> I like to develop 2 versions:
This email primary covers the routing issues you're going to see.
For the record the Cisco equivalent of VRRP is HSRP. Here's a little bit
of history if you're interested.
http://tcpmag.com/qanda/article.asp?EditorialsID=306
This link might be interesting if you decide to look into VRRP which you
can run on Linux.
http://siag.nu/pen/vrrpd-linux.shtml
> A. 2 redundant routers on one cable modem(static IP) drop.
> B. 2 redundant router each with a different network/circuit
> to the internet.
>
> 'UCARP' is in portage, and I was wondering:
>
> 1. Has anyone used 'ucarp' with iptables, willing to share configs?
>
> 2. How do you get your ethernet cards to reply to arp/mac requests
> with the same MAC address? A pci based ethernet card with programmable
> MAC address would be keen. If one does not exist, I'm quite tempted
> to do the layout, and develop the firmware (not a big deal).
> Suggestions as to which chips to use, so as to be able to use
> an existing driver from a 10/100 card (realtek?) would be keen.
Any reasonable implementation should not be this complicated. In HSRP,
I can't speak for ucarp, your real network interfaces have their
hardware designated MAC addresses. When the virtual interface is created
a new MAC address is generated and assigned to that IP only. This way
the virtual IP and MAC can move easily between machines regardless of
the MAC address of the real interfaces. I'd imagine that any VRRP-ish
type system would do something similar.
Getting into some black magic, IIRC and the details are pretty hazy, a
state change in VRRP/HSRP would cause a gratuitous arp so that the
switch could see that the MAC address had moved to another port. Some
switches or firmware versions wouldn't respond correctly so traffic
continued to the old port until arp times out or was manually cleared.
Just something to watch out for if you're using low end gear... and even
some high end gear has at times flubbed this.
> 5. Since my cable access provider scans MAC address and locks up
> my cable box(therefore I have to shut if off for 5 minutes upon
> changing the MAC address of my router) if different MACs are used,
> do you have a workaround for this?
If you can get the cable modem to play nicely with the virtual IP and
virtual MAC it should work. That might be fairly difficult if you're
using DHCP.
> 6. If I implement UCARP on a network with 2 different wiring/circuits
> that support static TCP/IPs (cable modem and wireless T-mobile) how
> do I setup external routing to use both pipes, without BGP-4?
Is this a "for fun" project or a "if it breaks it'll cost me real
money" project? If it's for fun go nuts, but if this is a convoluted
plan to get some sort of real redundancy you're probably going to be
disappointed.
Here's the rub, load balancing outbound traffic is easy. Turn on
advanced routing in your kernel, recompile, reboot, add your two default
gateways and you're now using both connections. IIRC Linux does per
connection load sharing, not per packet so a single TCP stream can not
use the aggregate connection speed of both pipes.
However load balancing incoming traffic is hard even with BGP. I'd be
very surprised if either of your ISP's let you run BGP with them other
than announcing a default 0.0.0.0/0 route to you via a private AS
number. Assuming you even get that far I'm positive that their filters
are going to swallow any route announcement specific enough to modify
your traffic. Without BGP you have no redundancy for incoming traffic.
Here's an example.
These are your static IP's
cable 20.20.12.24
tmob 40.40.24.48
If I'm connected to the tmob IP and that connection goes down nothing
you can do will send me to the other IP. I'd have to reconnect and hope
round robin DNS might send me to the other IP this time. You could play
DNS games, but the failover time for all clients is going to be pretty long.
Going back to your original question, you can run two routers on a
single connection and that should work reasonably well though be limited
in the redundancy it can give you. Running two connections however is
more problematic and may not be worth the trouble if you're trying to
provide transparent failover for incoming connections.
I can break this down into better examples if anything doesn't make
sense. I don't know how much you know about routing and this could have
easily grown into four or five pages giving all the background info.
kashani
--
gentoo-user@gentoo.org mailing list
next prev parent reply other threads:[~2005-09-05 3:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-04 20:08 [gentoo-user] Gentoo router redundancy via Ucarp? James
2005-09-04 22:23 ` Mike Williams
2005-09-06 13:55 ` [gentoo-user] " James
2005-09-05 3:48 ` kashani [this message]
2005-09-06 13:46 ` James
2005-09-06 17:55 ` kashani
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=431BC017.8050306@badapple.net \
--to=kashani-list@badapple.net \
--cc=gentoo-user@lists.gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox