3 ms·
Sounds a lot like what FreeBSD CARP[1] suppose to do. [1] https://www.freebsd.org/doc/handbook/carp.html https://www.freebsd.org/doc/handbook/carp.html
by atmosx 9y ago
Sounds a lot like what FreeBSD CARP[1] suppose to do.
[1] https://www.freebsd.org/doc/handbook/carp.html https://www.freebsd.org/doc/handbook/carp.html
- gerdesj 9y agoNot quite. CARP (VRRP in Ciscoese) has two (or more) systems capable of presenting the same IP address and they agree amongst themselves which gets to be the master through a multicast based advertizing system. Generally each system will be near clones of each other and be capable of doing the full job themselves. I have a pair of rather large pfSense systems running CARP as my office routers. I can update the secondary, test it, fail over the CARP addresses and fifty IPSEC tunnels, five internet connections, 10 OpenVPN servers along with rather a lot of clients, five OpenVPN clients, 30 odd internal VLANs and all the states for the above along with many NAT inbound and outbound sessions will seamlessly switch over thanks to PFSYNC. Even voice calls don't drop - you might notice a sub second wobble if someone is talking at the wrong moment. Rinse/repeat for the other one. BGP, RIPx, OSPF and co. are routing protocols that deal with the route your connections take through a network. There are also things like LACP/LAG for layer two redundancy. You can even play games with DNS round robin and of course reverse proxies. CARP is one tool in the box for coping with failures and maintenance - there are lots of others, each with advantages and disadvantages. That's what makes the job interesting 8)
- geofft 9y agoYes, but in my case I wanted the two servers to be located in physically separate parts of our datacenter to guard against a switch failing (ideally it would have been split across multiple datacenters), and I think that OpenBSD's CARP, or similar protocols like Cisco's VRRP, can only handle the case of computers on the same subnet sharing another IP address on that subnet. The two machines were on different subnets, and there was a third /24 we assigned virtual addresses from. By making the user-facing address for the web server its own 32 and having the two servers say "Hey, if you want to reach 10.255.255.1 you can route through me" over OSPF, all the switches on the way from a client to the two servers would be able to handle the case of the next hop failing, and let traffic take the other route to the same IP address. (Never mind that 10.255.255.1 was independently served by two Apache processes on the two machines; for all they know it was actually being routed to a third computer directly hooked up to the first two.)