The IP netmask on multi-subnet 131.111.0.0 ethernets

The following discusses the use of netmasks within the context of the sub-netting of the Class B 131.111.0.0/16 network but is applicable to the sub-netting of any Class B network in use in the University.

Introduction

It sometimes happens that a departmental or college ethernet grows beyond the addressing capacity of the single subnet of 131.111.0.0 initially assigned, and a second subnet of 131.111.0.0 is then routed down the same connection simply to provide extra address space. This is usually completely painless and transparent, but in special circumstances some tinkering with netmasks may be necessary. This note attempts to explain and advise.

Anyone actually considering adopting any of the suggestions below is however strongly advised to consult ip-register@ucs.cam.ac.uk before making any move. Local circumstances do vary, on both sides of the interface between the local network and the CUDN, both across Cambridge and as time passes.

Routing between local subnets of 131.111.0.0

Where two or more IP subnets of 131.111.0.0 share a single ethernet, and if the hosts are configured with the ordinarily appropriatenetmask, then the actual proximity of the subnets will not be noticed.

Traffic between hosts in a single subnet will go direct as usual, routed by ARP, and traffic between hosts in different subnets will go via the appropriate router even though it is then sent back down the same wire. Sometimes this insulation is a good thing and sometimes it is inevitable, but sometimes it causes difficulties and can be circumvented. General recommendations vary according to perceived general circumstances, but specific contrary recommendation may be appropriate in specific circumstances.

Proxyarp and subnets of 131.111.0.0

CUDN routers normally offer proxyarp for non-local subnets of 131.111.0.0. When this is so, a host in a subnet of 131.111.0.0 can pretend that all of 131.111.0.0 is local, setting the netmask to 255.255.0.0. Truly local hosts will respond to arp requests and communications will pass directly between them, even if they are in different subnets. For non-local hosts the CUDN router's proxyarp response will cause packets to be sent to it for routing elsewhere. Use of this network mask thus can represent a significant efficiency gain where such traffic is common, and it can also solve problems with broadcasts between local subnets, as discussed below. There are undoubtedly places where both of these points matter, but there are also many places where they really don't matter.

Unfortunately simply setting a 16-bit netmask for 131.111.0.0 does not always work. It notably fails where there are private local routers that cannot offer proxyarp. It will in any case be unhelpful where subnets of networks other than 131.111.0.0 are involved. Even where it does work, it is not in general obvious which strategy offers the better flexibility.

If it is decided to make a general migration from 24- to 16-bit netmasks, it is usually not necessary to make a wholesale overnight change. Most machines which were previously running satisfactorily will continue so to do, and certainly any self-sufficient machine can be left untouched.

Whether to use a netmask of 255.255.0.0 relying on CUDN proxyarp, or a netmask of 255.255.255.0 with explicit routing to the CUDN router is a matter for experienced judgement in the light of local circumstances.

IP broadcasts

IP broadcasts are used in Unix clusters to locate NIS servers, and comparably in NT clusters. ('Local broadcast' is used in BOOTP and DHCP, but by its very nature this should present no problem.)

It should be clearly understood that we are talking about IP broadcasts, not MAC (ethernet) broadcasts. The latter take place entirely below the IP level and are thus unaffected by any change in IP structure. The fact that IP broadcasts are implemented using MAC broadcasts (amongst other apparatus) is completely irrelevant.

CUDN routers do not forward broadcasts, and this can present a problem where a cluster straddling the subnets is to be stitched together by means of broadcast. The broadcast must be made to work without the assistance of the CUDN router. If the broadcaster and the intended recipient are in different subnets, the broadcaster will have to use a 16-bit netmask (255.255.0.0), treating all subnets as local. Whether the recipients need to be reconfigured is less certain. Although the broadcaster and the intended recipients must have compatible opinions about broadcast addresses, so that the recipient recognises as such the address the sender used, it should be remembered that 131.111.255.255 represents the 'all-subnets broadcast' under a 24-bit mask as well as the ordinary broadcast address under a 16-bit mask. In the common case where the broadcasts are unidirectional from clients to a server, therefore, it should be sufficient that the server netmask be changed to 16-bit last of all, if at all, after a leisured and orderly change of each of the clients. It may sometimes however be easier and less confusing to change netmasks all at once.

The 'local broadcast' address 255.255.255.255 may also be useful on systems which allow it to be configured.