skip to content

IT Help and Support

University Information Services

The UIS hosting service allows institutions to have their servers hosted in UIS-managed data centre facilities, either physically or virtually. This page describes the networking available with this service.

More general information about the physical hosting service is available on the hosting service page.



The networking depends on the type of hosting:

  • Physical hosting (also known as "colocation") — an institution's own hardware is physically housed in one of the UIS-managed data centre facilities. The institution is responsible for the maintenance, replacement and upgrades of the hardware and physical connectivity.
  • Virtual hosting — UIS provides virtual machines that share the same physical hardware as other virtual machines. We provide and maintain the physical hardware and connectivity, and handle maintenance, replacement and upgrades. This option is currently only available by special arrangement.

For physical hosting, the networking can done in two different ways, depending on whether a dedicated rack is taken or not:

  • Dedicated rack — here the institution has an entire rack in which to locate their equipment: the rack has only dark fibre connections and it is the responsibility of the institution to organise networking to it, using GBN circuits and internal data centre dark fibres, or take a UDN PoP switch.
  • Shared rack — the institution is allocated space in a rack that is shared between themselves and other institutions. UIS provides network equipment at the top of the rack, which has connectivity to the UIS data centre network (DCN).

The following table summarises the responsibilities with the different options:

  Physical with dedicated rack Physical with shared rack Virtual
Network equipment Institution UIS UIS
Physical connections Institution Institution UIS
IP/VLANs Institution Institution UIS and institution


Physical connectivity in shared racks

This section applies only to physical hosting in a shared rack.

There are two main options for physically connecting a host to the DCN, differing by the number and type of top-of-rack (ToR) network devices it's plugged into.

  Single 1GE Dual 10GE
Physical connectivity Copper 100M/1G ethernet connection to a single ToR networking device (e.g. switch). Pair of SFP+ 10G ethernet connections to two ToR networking devices.  Connection should typically be made through direct attach cables (DACs).
Redundancy Single ToR device provides a single point of failure.  If it is unavailable, connectivity will not be restored until it is repaired/replaced. Dual ToR devices provide redundancy in the event of a single unit failing.
Link configuration Simple, standalone port.

Ports configured in a Link Aggregation Group (LAG) — sometimes called a 'port-channel' (Cisco) or 'trunk' (HP).

It is strongly recommended LACP with Slow PDUs/timeouts is used to manage this.

Hosts must not use 'host-based' or standby link redundancy.

Availability during software upgrades

The single ToR device will go offline for 5–10 minutes during a software upgrade.

Institutions will be notified of this work in advance but cannot ask for it to be rescheduled.

One ToR device will go offline and return before the other is similarly upgraded.  Connectivity should be maintained throughout.

Institutions will be notified of this work in advance.  They cannot ask for it to be rescheduled but should ensure that maintenance on their hosts is not taking place during this time, degrading redundancy.

Expansion options Can have more than one 1G connection to increase bandwidth in multiples of 1Gbit/s. Can have multiple pairs but must always be connected to both ToR devices.

Out-of-band management connection 

Through a another 100M/1G copper ethernet port to the same ToR device. Through a 100M/1G copper ethernet connection to a 1G ToR device (separate from the in-band 10G ToR devices).


LANs/IP addresses

This section applies to both physical hosting in a shared rack and virtual hosting.

Once physical connectivity has been established, one or more VLANs, with IP subnets, will need to be presented on the links to make them useful.

In all cases, the VLAN provided to a host will be one specific to the client institution (or group within an institution, if appropriate). Further hosts will be added to the same VLAN.

The VLAN must be separate from the ones provided to an institution elsewhere on the UDN — for example, they cannot be the same VLAN fed to an institution's PoP switch and, as such, will require that any hosted equipment uses IP addresses in a distinct subnet.

The subnet will be sized appropriately for the hosting needs of the client institution. When a new new subnet is set up, we'll discuss with the client institution what their future requirements are likely to be. In the event that a subnet is filled and a new, larger one is allocated, the institution will be expected to renumber their hosts into the new range, over an appropriate period of time.

There are two main ways the routing for the VLAN can be configured — direct and using an MPLS VPN. The following table summarises the differences:

  Direct MPLS VPN

Routing to institution


Out of the DCN, across the UDN and into the institution

Across the UDN inside the [private] MPLS VPN


Routing to the general UDN and internet Out of the DCN, across the UDN

Via the home institution's network


IP addresses Taken from the DCN ranges

From the home institution's ranges (with additional subnets allocated, if required)

Requirements at home institution None

Router (which can be a firewall, although there is often limited benefit), or

Additional VLAN inside the MPLS VPN and split horizon routing configured on necessary hosts


Typically: yes — using the UIS Server firewall, with rules managed on behalf of the institution by UIS Security Operations, or

Rarely: no — in circumstances where a firewall is inappropriate

Yes — if present at the home institution and traffic is routed through it, or

No — if the additional VLAN option is used

Use case

Vast majority of cases

Where a high-speed connection between the institutional and hosted servers is required and the connection is considered "secure".  An example of this would be backup from an on-site client to a hosted server.

In most cases, the direct option is the most suitable.

If there is a need for the MPLS VPN option, or another more complex configuration, these can be discussed with UIS Networks to explain the use case.

Last modified: 5 September 2019

UIS Service Desk

UIS Service Status

Phone padded  Service status line: (01223 7)67999
Website  Sign up for SMS/email status alerts
Website  Read major IT incident reports

UIS bITe-size bulletin

A regular newsletter aimed at the University's IT community, highlighting service and project news from UIS.

Sign up >

Latest news

University Wireless Service maintenance: Tuesday 21 September, 08:00–09:00

16 September 2021

The University Wireless Service will be undergoing essential maintenance between 08:00 and 09.00 on Tuesday 21 September while we apply a security software patch. This is a security update to ClearPass, which provides Wireless Service network access control. We're not expecting any disruption to service, but it should be...

Mailing list migrations from Mailman to Sympa

31 August 2021

We intend to migrate all remaining lists associated with colleges from Mailman to Sympa during the week commencing 13 September 2020. The current total is 1,567. How this will affect users of the mailing list management service Most mailing list subscribers shouldn't notice any difference. During the switchover, there will...

Managed Zone Service closedown and migration to Mythic Beasts

24 August 2021

The Managed Zone Service (MZS) is being shut down, and its data content migrated to a commercial provider, Mythic Beasts. There will be no interruption to the service, but MZS users in institutions will need to make arrangements to retain management access to their zones. What is changing? UIS set up the MZS many years ago...