Re: UCARP Behind NAT (SOLVED)
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@keyedupmedia.com> 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@keyedupmedia.com> 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@keyedupmedia.com> 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
>> >
>
Reply to: