Nikos Vassiliadis wrote:
Sebastiaan van Erk wrote:

Thanks for the suggestion. I tried it, but unfortunately the carp device never leaves the INIT state when I put the ip on the bridge. :-( I did find some similar problem here:


I just noticed that. On -CURRENT carp tells you that's
not supported:
bridge0: carp is not supported for this interface type

OTOH why do you even have to use the VIP from the remote
side of the bridge?

The only reason I can think of, for doing  such a thing,
is to get *all* traffic from the remote location through
a "single" redundant router, the one with the VIP. Is this
the case?

It is indeed a "single" redundant router, though the traffic from the other side of the bridge (the OpenVPN clients) generally don't need to be routed redudantantly. The OpenVPN clients use OpenVPN's redundancy (multiple "remote xxx.xxx.xxx.xxx" lines), and thus use the non-redundant IP address of the OpenVPN client they're connected to as gateway (which is fine, because if the server dies OpenVPN connects to a different server anyway)...

So I don't really *NEED* the CARP ip address over the bridge (the static arp works, so I have a working solution, albeit an ugly one; an ARP request generates a reply from every member of the redundant cluster).

I guess it's just not a supported configuration yet and it's not my stupidity (in this case anyway ;-)) that's the problem.



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to