2005/10/16 - Planned Network Outage
On Sunday 16th October 2005 we will be undertaking major re-cabling work in one of the server cabinets in Struben building. As a result, users will experience intermittent interruptions to various core network services.

Work will commence at 08:00 on the 16th and will be finished, at the latest, by 17:00 on the same day. During this time, services may be interrupted several times without additional prior warning.

Services that may be affected by this work include:
Whilst we will endeavour to ensure that there are as few interruptions to individual services as possible and that interuptions are reasonably short in duration, users are advised to assume that the aforementioned services will be completely unavailable between 08:00 and 17:00 on the 16th. Users are strongly encouraged to plan accordingly.

As usual, further information and updates to this notice will be posted on
For those who are interested in the details, this work entails re-wiring one of the 19" modem racks in our machine room with the intention of converting it from 100Mbps to 1Gbps networking. The rack in question houses many of the servers providing core network and file services and these services (particularly the file services) will greatly benefit from the improved network connectivity. At the same time, we're going to take the opportunity to tidy up some of the power and KVM cabling in the same rack.

Our plan is to remove most of the machines from the rack and temporarily reconnect them to power and networking in another location. We'll then make as many of the cabling modifications as possible to the rack before re-installing machines in the rack. As a result, there will be a number of interruptions as machines move around. Some of the less important machines not mentioned in the original post (for example, the IT Division management server hosting may not be reconnected in the interim.

A complete list of machines hosted in the affected rack is as follows:,,,,,,,, and three non production test machines. The rack also hosts two SDLT tape backup units, but these are only used in the dead of the night and are thus completely unaffected by the change.

Whilst is located in a physically separate rack, it is included in the first list because we're considering re-wiring its existing 100Mbps campus interface.

The complete list of web sites hosted on (iguana) is as follows:,,,,,,,,,,,,,,,,,,, and also hosts news://
In addition to the work above, we've decided to take the opportuntity on Sunday to rationalise some of the services we're running. This shouldn't affect the duration or impact of the outage at all, but it might have some implications once service is restored. Some possible effects of this are detailed in

For those who're interested, what we're doing is consolodating a number of services (authoritative and recursive dns, dhcp, outgoing e-mail, webmail, proxy/cache, radius, ntp, and ldap) onto a cluster of identically configured machines. Instead of having different machines dedicated to different services, we'll have each of the machines in the cluster servicing all of the aforementioned services. This has implications in terms of the reliability and redundancy of services and represents a significant advance towards our goal of providing a fully redundant network backbone.

Once this reconfiguration is complete, the only monolithic services remaining on campus will be web (, etc), imap/pop3 (i.e. delivery of e-mail into inboxes) and Novell file access. Whilst these services don't readily lend themselves to being distributed, plans are being made to try and ensure that we can minimise the downtime associated with losing these services in the event of a major disaster.

If you've been following posts to this noticeboard over the last few months you'll notice that the preparitory work for this change has been going on for a while. We've standardised service names and ensured that we're running one service per IP address. These changes have been made slowly to ensure that users have had time to update their settings, and for the most part our checks show that they have. You can find a list of best current practices for network configuration at Please be aware that this list is still evolving and might change.

You might also be interested to know that all of the services running on our new cluster of machines are fully IPV6 enabled. This means that clients on IPV6-capable subnets (currently only Hamilton and Struben buildings) can configure their machines to use IPV6 services. Support for IPV6 is, however, experimental at this stage.