Hitchhiker's Guide to Openbsd

Can I boot other kinds of kernels using PXE other than 
bsd.rd
?
Yes, although with the tools currently in OpenBSD, PXE booting is primarily intended for installing the 
OS. 
6.11 - The Common Address Redundancy Protocol (CARP)
6.11.1 - What is CARP and how does it work?
CARP is a tool to help achieve system redundancy, by having multiple computers creating a single, 
virtual network interface between them, so that if any machine fails, another can respond instead, and/or 
allowing a degree of load sharing between systems. CARP is an improvement over the Virtual Router 
Redundancy Protocol (VRRP) standard. It was developed after VRRP was deemed to be not free enough 
because of a possibly-overlapping Cisco patent. For more information on CARP's origins and the legal 
issues surrounding VRRP, please visit 
this page
. 
To avoid legal conflicts, Ryan McBride (with help from Michael Shalayeff, Marco Pfatschbacher and 
Markus Friedl) designed CARP to be fundamentally different. The inclusion of cryptography is the most 
http://www.openbsd.org/faq/faq6.html (25 of 33)9/4/2011 10:02:06 AM

---

6 - Networking
prominent change, but still only one of many. 
How it works: CARP is a multicast protocol. It groups several physical computers together under one or 
more virtual addresses. Of these, one system is the master and responds to all packets destined for the 
group, the other systems act as hot spares. No matter what the IP and MAC address of the local physical 
interface, packets sent to the CARP address are returned with the CARP information. 
At configurable intervals, the master advertises its operation on IP protocol number 112. If the master 
goes offline, the other systems in the CARP group begin to advertise. The host that's able to advertise 
most frequently becomes the new master. When the main system comes back up, it becomes a back up 
host by default, although if it's more desirable for one host to be master whenever possible (e.g. one host 
is a fast Sun Fire V120 and the others are comparatively slow SPARCstation IPCs), you can so 
configure them. 
While highly redundant and fault-tolerant hardware minimizes the need for CARP, it doesn't erase it. 
There's no hardware fault tolerance that's capable of helping if someone knocks out a power cord, or if 
your system administrator types 
reboot
in the wrong window. CARP also makes it easier to make the 
patch and reboot cycle transparent to users, and easier to test a software or hardware upgrade--if it 
doesn't work, you can fall back to your spare until fixed. 
There are, however, situations in which CARP won't help. CARP's design does require that the members 
of a group be on the same physical subnet with a static IP address, although with the introduction of the 
carpdev directive, there is no more need for IP addresses on the physical interfaces. Similarly, services 
that require a constant connection to the server (such as SSH or IRC) will not be transparently 
transferred to the other system--though in this case, CARP can help with minimizing downtime. CARP 
by itself does not synchronize data between applications, this has to be done through "alternative 
channels" such as 
pfsync(4)
(for redundant filtering), manually duplicating data between boxes with 
rsync
, or whatever is appropriate for your application.