The multihome_ops form


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.)