Re: UCARP Behind NAT (SOLVED)
- From: Chris Snyder <chris@xxxxxxxxxxxxxxxx>
- Date: Mon, 14 Nov 2011 22:27:43 -0500
Okay, so I have solved this. I was on the right track with thinking
the router was holding an ARP cache and when the fail-over occurred,
UCARP did not send anything out to cause the router to invalidate its
cached entry for the UCARP IP address.
I added "arping -c 1 -s 192.168.1.20 192.168.1.1" to the
/usr/share/ucarp/vip-up script which is called when the UCARP
interface takes over. This forces the router to clear its ARP cache.
There is now only about a second of downtime from the outside during
the fail-over process. It works beautifully!
You would think this would be built into UCARP.... I guess not. For
some reason I was under the impression that it used some sort of
virtual mac address to associate with the virtual IP. Apparently I was
wrong on that. I would still be interested to know why it doesn't do
that if anyone knows.
Thanks for following my quick little learning process here. Hopefully
it's useful for someone in the future.
- Chris
On Mon, Nov 14, 2011 at 7:09 PM, Chris Snyder <chris@xxxxxxxxxxxxxxxx> wrote:
Okay I feel like I'm talking to myself here, but I want to update this
with my progress. It always irks me to google something only to find a
thread years old with your exact problem but no solution!
It turns out that the router DOES fail-over to the second machine. It
just can take up to 5 minutes to do so.
I'm guessing, after a bit more research, that what is happening is the
router is keeping an ARP cache. It looks to be set at around 5
minutes.
I was under the impression that UCARP used a virtual MAC address, but
that doesn't seem to be the case. Maybe that's how it works in FreeBSD
with CARP, but not in the UCARP implementation of the protocol?
Is there a way to get UCARP to use a virtual MAC address? Or perhaps
sour the ARP cache or reset that cache when an interface takes over as
the master?
Does anyone have an idea if I'm at least on the right track here?
- Chris
On Mon, Nov 14, 2011 at 11:36 AM, Chris Snyder <chris@xxxxxxxxxxxxxxxx> wrote:
Any ideas where a good place to ask for help on this topic is? Is
there a UCARP mailing list? I realize it might be a little specific
for this list.
Thanks,
Chris
On Sun, Nov 13, 2011 at 8:13 PM, Chris Snyder <chris@xxxxxxxxxxxxxxxx> wrote:
Hey Guys,
First time here on the list, so hopefully I get everything right here.
I have two Squeeze systems that I have setup with UCARP for auto-failover.
Here's the relevant /etc/network/interfaces of Server 1:
10 iface eth0 inet static
11 address 192.168.1.21
12 netmask 255.255.255.0
13 gateway 192.168.1.1
14 dns-nameservers 8.8.8.8 8.8.4.4
15
16 # UCARP
17 ucarp-vid 3
18 ucarp-vip 192.168.1.20
19 ucarp-password [pass-here]
20 ucarp-advskew 100
21 ucarp-advbase 1
22 ucarp-master no
23
24
25 iface eth0:ucarp inet static
26 address 192.168.1.20
27 netmask 255.255.255.255
And /etc/network/interfaces of Server 2:
10 iface eth0 inet static
11 address 192.168.1.22
12 netmask 255.255.255.0
13 gateway 192.168.1.1
14 dns-nameservers 8.8.8.8 8.8.4.4
15
16 # UCARP
17 ucarp-vid 3
18 ucarp-vip 192.168.1.20
19 ucarp-password [pass-here]
20 ucarp-advskew 100
21 ucarp-advbase 1
22 ucarp-master no
23
24 iface eth0:ucarp inet static
25 address 192.168.1.20
26 netmask 255.255.255.255
Now this setup works great on the LAN. I can access 192.168.1.20 fine
while pulling the Ethernet cables from either server. The problem is
that I'm trying to forward an external IP to 192.168.1.20 through a
NAT.
It forwards fine when both machines first come up and Server 1 is
dominant. I can ping 192.168.1.20 and all is well. I can ping the
external IP and all is well. Then if I pull the cable on Server 1,
Server 2 picks up fine -- I can ping 192.168.1.20 and all is well.
However the external IP does not forward to 192.168.1.20. It acts as
if the forward is non-existent for Server 2. If I plug Server 1 back
in and unplug Server 2 so Server 1 takes back over, the external IP
forwards again.
I'm thinking this has something to do with UCARP's multicast. There is
traffic to a multicasted IP of 224.0.0.18. Is it possible this router
(Kentrox q2300) is having trouble with this multicasted IP address?
I guess I'm just looking for ways to troubleshoot where the problem
with this is. What gets me is that the LAN IP works great in all
regards, it's just the forwarding of the external IP address is
problematic. How can I get UCARP to use a broadcasted address rather
than multicasted one so I can try that?
Thanks guys,
Chris
--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Archive: http://lists.debian.org/CA+U_jXZ9PE0nVPE1A0JB1wQuJTu3_Ax4LsHX3bywAptuMfGX_g@xxxxxxxxxxxxxx
- Prev by Date: "capturing" console resolution from auto-detection for when KVM switched away?
- Next by Date: bcm5974 and mac book pro 8,1
- Previous by thread: "capturing" console resolution from auto-detection for when KVM switched away?
- Next by thread: bcm5974 and mac book pro 8,1
- Index(es):
Relevant Pages
|
