Summary
The multihome_ops form allows address management for hosts that have
more than one address, known in the trade as multi-homed hosts. For
hosts with just a single address the single_ops form should be used in
preference, since it is undoubtedly more convenient and fool-proof,
but it fundamentally lacks the power needed to cope with multiple
addresses on a single box.
Multi-homed hosts
A general word about hosts with multiple addresses and their
representation in the DNS may be in order here. The normal arrangement
is that any single piece of equipment has a single "canonical
name", never mind any other names in the offing. The canonical
name identifies the physical box. If you look up the canonical name in
the DNS you get given a list of all the associated addresses, and if
you look up any of those addresses you get back the canonical name. A
multi-homed host specified with the multihome_ops form will appear
thus in the DNS. In many or most instances that is a sufficient
representation, and further names specific to individual interfaces
are not needed. This is because routers normally sort out optimal
routing irrespective of which address you actually specify. Moreover
one of the commonest cases of multi-homed hosts is the router itself,
and routing specifications are all in terms of addresses rather than
names, with the result that the name is largely irrelevant.
There are two cases where additional names are required. Occasionally different sets of services, possibly overlapping, are offered on the different addresses. In this case what is needed is just additional names resolving to specific addresses, all of which still map back to the canonical name. To set this up in the database you need to use the ANAME mechanism in addition to the basic multi-home representation. Very occasionally on the other hand the object of the exercise may be to make a single machine appear as two or more entirely independent machines, which as perceived across the network are completely separate, in other words true virtual hosts, each with their own separate canonical names. The usual reason for this is complex fast failover mechanisms. This case is dealt with by the VBOX mechanism. The creation of both VBOXes and ANAMEs is restricted to CS registrars, and further discussion is beyond the scope of this particular document.
Using multihome_ops
The general ethos of multihome_ops is somewhat different from that
seen in single_ops, which attempts to merge the presentation of the
box definition and the address definition. In multihome_ops there is
overt recognition of the underlying representation, which comprises a
box and a number of addresses, distinct objects though intimately
connected. This is first apparent in the display, which begins by
describing the box and then goes on to describe each address
separately. It is also apparent in the way you use the form to set up
multi-homed hosts. You start with a blank form, create a box object
devoid of any addresses, and then add addresses to taste. After every
operation, the current composite state is displayed and can be
modified, and of course you can display and modify the current
composite state of any box that already exists.
The "display" button, rather obviously, causes the named box and any associated addresses to be displayed, but it can also accept SQL wildcard characters in the name field, and will search the database for matches, displaying one and offering the others. The "find by address" button searches for a box associated with the specified address (which cannot include wildcards).
The "destroy" button is rather potent, not just destroying the box but wiping out all the address associations and the box in one fell swoop. It is therefore provided with a trigger guard, the "destruction enabled" checkbox that is reset at every opportunity.
The method of modifying attribute values will appear different from
that seen in single_ops or table_ops. None of the writable fields is
primed with anything. The current values of the attributes are
displayed separately as plain text, and empty fields are provided for
specifying replacement values. In the case of address attributes, the
address to be modified (or deleted) is the one selected by the radio
button group. The trick for clearing a field is to set it to a single
space, which is interpreted to as explicit clear. (cringe!)
When adding new addresses, you can either specify a known free address
exactly, or specify the usual constraints (mzone, lan, subnet) within
which to search for an unused address. No, you don't get a fancy
little text message on successful allocation, just the normal display
update. If you are messing with multiple addresses you are expected to
understand what you are doing. (If you do need a text representation
for any reason, go to single_ops and attempt to display by name. It
will moan that this isn't a simple system such as it can handle, but
it will nevertheless give you a text representation of what it
finds.)