Hi, 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:http://www.freebsd.org/cgi/query-pr.cgi?pr=125816I 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.
Nikos
Regards, Sebastiaan
smime.p7s
Description: S/MIME Cryptographic Signature
