[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: UCARP Behind NAT



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: