skip to primary navigationskip to content

PoP switch

Connections to the UDN (University Data Network) from an institutional network are typically made through a PoP (Point-of-Presence) switch, physically located on the client site.  ISPs typically call this CPE (Customer Premises Equipment).

The PoP switch provides an interface between the UDN backbone and the client institution, presenting the UDN services in a form appropriate to that institution (e.g. which physical ports have which VLANs tagged and untagged).

This page describes the PoP switch hardware and software configuration, as well as the other equipment installed at the client site.

Institutions can choose to connect without a PoP switch using the BGP service


Client site equipment

In most cases, one or two pieces of equipment are installed as part of a UDN connection (in addition to any cabinets or fibre termination):

This equipment is described below.

PoP switch

There are three main models of PoP switch available, all from the Cisco Catalyst 3850 range, taking up 1U of rack space:

OptionModelInstitution downlink portsUDN uplink ports
1 — 1G C3850-24P 20x 10M/100M/1G copper w/ PoE+
2x 1G SFP
2x 1G
2 — 1+10G C3850-48P 44x 10M/100M/1G copper w/ PoE+
2x 1G/10G SFP+
2x 10G
3 — 10G C3850-12XS 10x 1G/10G SFP+ 2x 10G
4 — Split 10G 2x C3850-12XS 14x (= 2x 7x) 1G/10G SFP+ 2x 10G

The 1GE option (option 1) is largely analogous to the previous generation PoP switches, the Cisco Catalyst 3560G-24PS, installed in 2008.  The other options are for institutions requiring a 10GE connection to the UDN backbone:

  • The 1+10GE option (option 2) provides 44x copper ports with PoE+ for institutions who wish to retain some copper edge device connectivity on the PoP, as well as 2x 1G/10G SFP+ downlinks to an institutional network.  Note that, due to technical limitations of the Catalyst 3850 range, this needs to be a 48-port switch to support the 4x 10G module required to provide 2x 10G uplinks and 2x 10G downlinks.
  • The 10GE option (option 3) provides 10x 1/10G SFP+ downlinks to institutional switches, allowing it to be used as an aggregation switch for the core of an institutional network.
  • The Split 10GE (option 4) provides 2x 7x (7 per switch) 1G/10G downlinks, using two switches that can be located in physically separate locations, interconnected by 3 fibre links.  This is described in more detail below.

All options are supplied with two hot-swappable, redundant power supplies, eliminating the need for the separate Redundant Power Supply (RPS) unit supplied with the previous Catalyst 3560G PoP switches.  Power will seamlessly fail back and forth between units, without interruption.  It is recommended that institutions notify UIS Networks that they perform maintenance on the power feeds to avoid an interruption being suspected as a sign of impending equipment failure, but a short outage during a likely maintenance window will typically be ignored.

The switches featuring copper ports (options 1 and 2) are supplied with a 715WAC power supply, providing a total of 435W PoE.  All ports are capable of supplying PoE+ power, up to that maximum.

Uninterruptible Power Supply (UPS)

To power the switch in the event of a mains power failure, it is recommended that one of the two power supply inputs is attached to an Uninterruptible Power Supply (UPS) and the other to a separate feed.

The UIS no longer supplies a UPS with a PoP switch as standard.  However, one can be requested for an additional charge (as described on the charges page).  All models of PoP require a 1000VA UPS with one additional battery to provide around 3 hours of runtime (although this figure will vary, according to the number of live ports and the amount of PoE drawn).

PoP switch connections

All PoP switches require 2 ports for use as the UDN uplink.

10G PoPs (option 3) leave all the remaining 10 ports available for institutional downlinks; the Split 10G PoPs (option 4) leave 7 ports for institutional downlinks.

On a copper PoP switch (options 1 and 2), 4 ports are reserved for UDN use, leaving 20 or 44 (depending on the option) available to an institution:

Picture of rear of Cisco Catalyst 3560G-24PS switch and RPS-2300 showing cabling
The ports are designated as follows:

Port(s)Assigned toPurpose

Option 1

24 port, 1G

Option 2

48 port, 1+10G

Option 3

12 port, 10G


Split 10G

SFP 1+2

SFP+ 1+2

SFP+ 1-10

SFP+ 1-7 Institution Institutional downlinks — to institutional edge devices or network equipment via copper or fibre
21 45 - Institution Diagnostic port — with institution main VLAN and voice VLAN (via CDP/LLDP-MED) for temporary connection of test devices
22 46 - UIS Monitoring port — for attachment of UDN traffic capture probes (usually temporarily)
23 47 - SFP+ 11 UIS Reserved port — temporary attachment of UIS equipment (e.g. engineer's laptop)
24 48 - UIS UPS management port — connection a UIS-managed UPS
- - - SFP+ 8-10 UIS Split PoP interconnects
SFP 3+4 SFP+ 3+4 SFP+ 11+12 SFP+ 12 UIS UDN uplink ports — redundant fibre uplinks to UDN backbone

Institutional downlink ports (copper and fibre)

Copper ports 1-20 (option 1) / 1-44 (option 2) on the PoP are available for the connection of any devices the institution requires. These can be edge devices (e.g. phones, computers, wireless APs) or network devices (e.g. internal switches, firewalls, routers).  Essentially, the institution can request any configuration of the available ports (with appropriate VLANs, PoE, QoS, etc.) it desires.  However, for consistency, it is recommended that ports 1-12 / 1-36 are used for the connection of edge devices and ports 13-20 / 37-44 are used for connections to network equipment.  It is understood that this might not be appropriate in all cases.

SFP+ ports 1 and 2 (options 1 and 2), 1-10 (option 3) or 1-7 (option 4) can be used the same as the above copper ports.  They will typically be used for fibre or Direct Attach cables to other network equipment, perhaps in the role of an aggregation switch.  One transceiver is available with the PoP switch: this can be singlemode or multimode SFP (options 1, 2, 3 or 4) or SFP+ (options 2, 3 or 4) with LC presentation.  Additional modules can be supplied by the UIS; third-party Cisco-compatible modules can be installed by the institution.

For more information on how these ports can be set up, see institutional connection configuration, below.

Diagnostic port

It is recommended institutions keep port 21 (option 1) / 45 (option 2) free for the temporary connection of diagnostic equipment (e.g. a voice handset or test host).  Essentially, this port just has the main institutional VLAN untagged and the institutional voice VLAN tagged and advertised with CDP/LLDP-MED so two devices (or daisy-chained phone and PC) can be attached.

These ports are useful, in the event of a network fault, to perform tests from outside an institution's network and confirm if the fault is from the PoP upwards to the UDN.  If these ports are used for the permanent connection of devices, an available test point is removed and can make diagnostics more difficult.  Note that the port profile is that of an edge port, so only a single device should be connected.

Monitoring port

When diagnosing faults, it can be useful to direct a copy of the network traffic to a probe to analyse it.  Sometimes this can be done remotely but, occasionally (as with many Quality of Service [QoS] problems) it can be useful to install a traffic capture probe on-site.  Port 22 (option 1) / 46 (option 2) provides a location where such a probe can be attached and a copy of the relevant network traffic directed.

This port is for the attachment of a probe by UIS Networks.  If institutions wish to do this for their own use, one of the institutional downlink ports can be used, with a separate monitoring configuration.

Reserved port

Port 23 (option 1), 47 (option 2) or SFP+ 10 (option 4) is reserved for either temporary diagnostic or other purposes by UIS Networks.

UPS management port

If the institution has a managed UPS attached, the cable to the management card of the Uninterruptible Power Supply will be attached to port 24 (option 1) or 48 (option 2), enabling the UPS to be monitored and controlled.

UDN uplink ports

PoP switches have two connections to the UDN backbone for redundancy.  These will go to different UDN backbone routers to help remove the impact of a single backbone device failing and, where possible, will take diverse physical routes across the GBN (Granta Backbone Network).

Redundancy on routed VLANs will be handled by a First Hop Redundancy Protocol such as VRRP or HSRP.  Switched VLANs (e.g. the UDN 'VLAN Service') will be redundantly handled across the backbone to the corresponding destination PoPs.  Institutions should not need to perform any reconfiguration or notice any outage, other than a brief (maximum 3 seconds, in the case of routed VLANs) interruption while backup connections take over

Institutional connection configuration

There are four main ways in which the institutional downlink ports can be configured.  These affect parameters other than just the VLANs, including Quality of Service, Spanning Tree and CDP (Cisco Discovery Protocol).

The different configurations between these port types are summarised below:

Port type
EdgeATA-24Wireless APTrunk
Purpose A single device - computer, phone, 2-port ATA (e.g. Cisco ATA-186) or computer/phone daisy-chained); mini-hubs/switches over 4 ports should not be attached (a Trunk port should be used here). 24-port analogue telephony adapter (e.g. Cisco VG224). Direct connection of a single University Wireless Service access point (multiple APs attached to a downstream switch should use a Trunk port). An institutional network, either entire or part, with multiple downstream devices (computers, phones, wireless access points, etc.); this would be connected to a switch, firewall or other networking device.
VLANs Optional untagged ('access') and optional tagged voice VLAN Untagged VLAN (voice) One untagged (for AP management) and, if required, one or more local institutional VLANs tagged Optional untagged ('trunk native') and any number tagged ('trunk')
Cisco switchport mode Access Trunk
Spanning Tree Enabled with 'portfast [trunk]' and 'root guard' Enabled
VoIP QoS profile Single phone (128kbit/s payload, 32kbit/s signalling) Up to 24 phones (3Mbit/s payload, 768kbit/s signalling) Many (>1000) phones (64Mbit/s payload, 10Mbit/s signalling)
MAC address limit 20 addresses, 15 minute aging upon inactivity None
PoE Enabled Disabled
CDP Enabled Disabled
LLDP / MED Policy TLV Enabled / Enabled Enabled / Disabled
DHCP Snooping Untrusted, limit 15pps Trusted, limit 2000pps
ARP Inspection Trusted, limit 15pps Untrusted, limit 15pps Trusted, limit 2000pps

It is important to use the appropriate type of connection for the device being connected to a particular port: using the wrong type of port configuration may appear to work at first but present problems later (e.g. issues with Spanning Tree or QoS thresholds).  It is also possible additional features may be enabled in future that will cause a port being used in an incorrect way to stop working; if in doubt, please contact UIS Networks for advice.

Ports can be reconfigured by contacting UIS Networks.  Note that unconfigured ports will typically be shutdown/disabled but this should not be relied upon.  If asking for a port to be reconfigured that is physically up, it is best to confirm this, when contacting the UIS, to avoid additional delay while we make sure the wrong port number has not been given (and reconfigure an active device).

Spanning Tree

An important change from the previous PoP configuration is that Cisco Rapid-PVST+ Spanning Tree is now configured on institutional downlink trunk ports (it has always been configured on edge ports, however).

Previously, Spanning Tree was disabled on those ports, using the "BPDU Filter" and "Portfast Trunk" settings.  The first of these settings blocks the sending and receiving of Spanning Tree BPDUs (Bridge Protocol Data Units — the frames which are used to exchange Spanning Tree information between switches), preventing interaction between the PoP and institutional switches using the Spanning Tree Protocol.  The second setting causes the port to move immediately into the forwarding state, rather than waiting 30s to see if there is an adjacent switch speaking Spanning Tree and check for a loop or other topology change (which would not be detected anyway, since BPDUs are filtered out) .

The new configuration has these settings removed.  These result in the following changes:

  • If the attached switch does NOT speak Cisco Rapid-PVST+ (i.e. it speaks a version of IEEE spanning tree, or no spanning tree protocol at all), a trunk port will take 30s to move into the forwarding state, when a link is brought up.
  • If IEEE protocols are used by the institutional switches, the Spanning Trees will not interact and redundant topologies involving the PoP cannot be built: the effect is as if the other side of the network does not have Spanning Tree configured.  Note, however, that BPDUs can flow through the VLANs on either side as they will usually be ignored by switches running a different protocol; this can have odd effects, as Spanning Trees or VLANs can be joined unexpectedly.
  • If the attached switch DOES speak Cisco Rapid-PVST+, the switchport mode and trunk native VLAN must match those presented on the PoP.  For example, if VLAN 789 is presented on the PoP as trunk native / untagged, but the institution is using a different number, e.g. VLAN 1, also configured trunk native / untagged, the port will block due to a VLAN ID mismatch.  Likewise, the port would also block if the institution end is configured as an access mode port, even if the VLAN ID matches.

Incompatibilities between VLAN IDs can often be worked around by filtering Spanning Tree BPDUs at the institutional end, but these can also prevent genuine problems from being detected and result in wider outages.  It is strongly recommended that the institutional network is configured to match the VLANs and modes of the PoP.

In addition to the above changes, root guard (where the PoP would block a port where the root bridge role appears) is NOT configured on trunk ports, allowing institutions to move the root bridge for a VLAN inside their network.  These changes allow institutions to build redundant topologies involving the PoP switch, including redundant uplinks.  The UDN will use priorities of 16384 and numerically higher (i.e. lower in effective priority); institutions wishing to take over the root bridge role must configure a priority numerically lower than 16384 (i.e. 4096, 8192 or 12384).

The backup port service offered on the previous PoPs is no longer available on the new PoPs.  It is recommended that institutions move to use spanning tree or port channels, as a mechanism to build a redundant topology involving the PoP.  This can be combined with the split PoP service to build a fully redundant connection with the PoP.

Institutions must verify the configuration of their internal network and how it interconnects with the PoP to understand the implications of these changes and make any preparatory changes in advance, or at the point where the connections are moved across to the new PoP.  Despite Rapid-PVST+ being a Cisco proprietary protocol, many other vendors support this protocol, although it is unlikely to be configured as the default.

It is recommended institutions enable Rapid-PVST+ and ensure their VLAN and port configurations match those on the PoP, as this will give the best interoperability with the UDN.  Running alternative protocols is supported but institutions must understand the limitations and side effects of a mixed configuration.

Requesting reconfiguration of the PoP

When an institution wishes for a port on the PoP to be changed to a different type (e.g. edge to trunk) or a change in the VLANs presented, they should contact Information Services with the following information:

  • the [institutional downlink] port number, or a range of numbers
  • the type of port required (edge, ATA-24, wireless AP, trunk)
  • for edge ports:
    • the untagged/access VLAN to be used (if required)
    • if the voice VLAN is to be served tagged, via CDP/LLDP-MED
  • for trunk ports:
    • which VLAN is to be untagged/native (if any)
    • which VLAN(s) is/are to be tagged/trunk (if any)

Note that untagged VLANs lose their 802.1p CoS (Class of Service) information, which may affect the ability of other some other network devices to determine the appropriate Quality of Service.  Note that the UDN uses DSCP (DiffServ) to determine QoS, and will set the 802.1p value based on this, so will not be affected by this.

Recommendations for PoP switch port configuration

Whilst any arrangement of ports of different type and VLAN is available, it is strongly recommended that ports configured similarly are physically grouped on the switch.  For example, if there are two voice downlinks to separate switches, they use physically adjacent ports.

Also, while it is possible to use untagged VLAN presentation as a way to feed a VLAN into an institutional network and retag it, this can result in the wrong VLANs being interconnected, if a mistake is made.  Using institutional VLAN IDs that match the UDN VLAN numbering system and tagged connections minimises the chances of this happening.

When VLANs on a particular port are no longer required, or a port is not needed any more, it is recommended they are unconfigured by contacting UIS Networks.  Not doing this can result in traffic passing down links unexpectedly (perhaps affecting Quality of Service or traffic levels in general), new devices being temporarily connected to the wrong VLANs or undetected loops causing packet storms.

Finally, while ports can be given fixed speed or duplex settings, it is recommended they remain left to autonegotiate these parameters.  Disabling autonegotiation can also affect other link parameters and increases the potential for mismatched settings.  Most network devices now correctly autonegotiate link settings over both fibre and copper interfaces; the odd exception is often fibre-to-copper media converters.

Pinging the PoP switch

The status of the PoP switch can be checked by using the PING utility.  Note, however, that the IP addresses of PoP switches are on special 'management VLANs' that are separate from the institutional VLANs.  As such, traffic to and from them must be relayed through the upstream UDN router; just because the PoP is not responding might not mean that it is not operational but the upstream connection is broken in some way and traffic cannot be routed between the two VLANs.

The UDN Network Status page also lists each institution's PoP and its operational status.  The names of the PoPs are of the form pop-<inst> (or, for option 4, spop-<inst>; the 's' standing for 'split') where <inst> usually corresponds to an institution's domain name under, possibly followed by a site identifier, where an institution has multiple PoPs.  The name should also be shown on the identification label on the front.

Miscellaneous PoP configuration settings

A number of global settings are configured on the PoP switch to protect the network and improve reliability. These settings should not have any effect on the network during normal operation but are described here for reference.

Storm control

To avoid broadcast storms flooding the network and consuming bandwidth away from other traffic, all interfaces (regardless of type) have a limit on ingress of broadcast traffic of 5% of total operational bandwidth (e.g. for a 1Gbit/s interface, a maximum of 50Mbit/s).  Traffic over this limit will be dropped; non-broadcast traffic (unicast or multicast) will continue to be forwarded.

This level has been chosen as it is very unlikely that the normal operation of the network will require this amount of broadcast traffic; situations where this is exceeded are most likely to be loops or problematic clients.  The switch records an event in its internal log that this has happened.

DHCP Snooping / ARP Inspection

To improve the reliability and security of the network, DHCP Snooping and ARP Inspection are enabled on all VLANs fed into the institutional network.  These two features validate DHCP and ARP traffic to make it harder for rogue devices to affect the operation of the network:

  • DHCP Snooping prevents rogue DHCP servers from operating on switch ports which are not nominated as trusted by blocking packets from servers being received, or packets to servers from being transmitted on those ports.  In addition, the DHCP traffic flowing through the switch is snooped to build a binding database of MAC/IP/interface mappings for hosts on untrusted ports.
  • ARP Inspection uses the binding database built by DHCP Snooping to block ARP packets advertising MAC/IP mappings which do not match those issued by the DHCP server, unless the port on which they are received is nominated as trusted.

The rationale behind the configuration of the ports on a PoP switch is that DHCP servers are usually either inside the institutional network or upstream on the UDN, so edge ports are untrusted for DHCP Snooping.  However, many institutions do not rely on DHCP to configure client addresses exclusively (rather than static configuration) so the PoP cannot filter ARP packets and must treat all ports as trusted, unless they have devices which are known to be managed by DHCP from the UDN (such as wireless APs or ATAs).

In addition to the above functions, the features also rate limit these packets as an excessive number of them can have a serious detrimental effect on the operation of the upstream router.  if these limits are hit, the PoP switch will drop packets randomly, to stay under it.  This can prevent devices from being able to work reliably, until the rate of packets is reduced below the configured limit.

It is strongly recommended that institutions deploy these features internally, according to local policy, and mitigate these problems before they reach the PoP, where the effect of the packet drops will be more widespread.

MAC address limit on edge ports

As stated above, edge and ATA-24 ports have a limit of 5 MAC addresses with a 15 minute inactivity timer. This helps prevent problems caused by devices with faulty network interface adapters emitting many different, and invalid, MAC addresses and filling the internal switch MAC address forwarding table, causing flooding of traffic.

This value was chosen as a sensible limit for a port with a computer and phone, possibly with a small number of desktop VMs (Virtual Machines) leaving some spare addresses for additional MAC addresses on virtual machines (for example).  If the limit is reached, an event is recorded in the switch's log and the additional addresses not learnt.

If multiple devices are to be attached to an interface on the PoP switch, it is important to ensure that interface is configured as a trunk type, regardless of whether a large, rackmount switch or desktop mini-switch is used.

Services available on the PoP

Aside from the client configurations listed above, a number of additional services can be enabled on the PoP switch upon request.

Institutional monitoring

If an institution wishes to monitor traffic passing through the PoP, they can request that one or more of the downlink ports is configured as a monitoring destination, monitoring one or more other downlink ports.  This can either be as a temporary measure, to investigate a specific current problem, or as a more permanent installation to log inbound/outbound traffic.

If the institution requires this service, it should contact UIS Networks with the parameters for the traffic to be captured:

  • the destination [downlink] port to receive the monitored traffic
  • the source [downlink] port(s) whose traffic is to be copied to the monitor port (this can be 'all')
  • the VLAN(s) to be monitored (this can be 'all VLANs')
  • whether inbound, outbound or both directions are to be captured

The institution cannot request monitoring of VLANs or ports used by the UDN itself (e.g. the uplink ports or the management VLANs).  It should also be noted that monitoring multiple ports or a full-duplex link may result in more traffic being copied to the monitor port than can be handled by it (e.g. a full-duplex 1Gbit/s link is capable of carrying up to 2Gbit/s) - in this case, traffic will be discarded by the monitor port.

Port channels

To increase the bandwidth of logical links, the PoP switches support the configuration of port channels (also called sharing groups or trunks [usually HP; not to be confused with Cisco switchport trunks]).  These allow multiple physical links to be aggregated together into a single logical link.  As the uplinks to the UDN backbone are both active, a 1G PoP can technically receive up to 2x 1Gbit/s of traffic, saturating a single downlink port..

Typically, the port channel is managed using the LACP protocol with slow LACPDUs (LACP Data Units, the frames which control LACP).  LACP allows switches at both ends to negotiate to ensure that all the ports are in the same group and can be aggregated successfully; if not, the links which cannot be aggregated will be deselected (not used).  This helps avoid misconfigurations either at the software level, or in the physical cabling.

This service is particularly useful on the split PoP (option 4) as ports can be aggregated across the two switches into a single link, allowing an active-active, physically redundant topology, assuming the institutional equipment supports a similar configuration.

Local VLAN Service

If an institution requires a VLAN to be kept locally within a site but fed through the PoP (e.g. an 'internal' VLAN behind a firewall they want fed back through the PoP to be served as an untagged/access VLAN on phones attached to the PoP, or another switch attached to a separate port on the PoP), it can request this.

There is no charge for this service but:

  • institutions are limited to a maximum of two VLANs per site
  • the VLAN 802.1Q tag will be chosen by UIS Networks and will be allocated according to the UDN VLAN number allocation system
  • the VLAN cannot pass onto the UDN core

The institution should contact the UIS stating which ports on the PoP switch the VLAN is desired on and whether it should be tagged or untagged.

If the VLAN is required elsewhere on the UDN, the full (chargeable) UDN VLAN Service can be ordered from the UIS.

UDN VLAN Service and Q-in-Q tunneling

If an institution requires a VLAN to cross the UDN, it can request the UDN VLAN Service with optional Q-in-Q tunnelling.  This is a chargeable service and is described separately.

SNMP monitoring

If an institution wishes to monitor the PoP switch for status or statistics, read-only SNMP access can set up to allow this. Requests should be made to the UIS stating:

  • the desired community string (which cannot be 'public', 'private' or any names reserved by the UIS)
  • an institutional address (or network/mask) from which queries will be sent

Access will be granted to the standard system and interfaces areas of the MIB (Management Information Base).  It should be noted that the PoP switches reside on special 'management' VLANs which are separate from the normal institutional VLANs so requests will be relayed through an upstream UDN router and will not be available if that connection is unavailable.

Split PoP

The Split PoP service gives institutions a pair of switches, typically installed in physically separate locations, that are configured to operate as a single logical switch from the point of view of spanning tree and other services.  In particular, LACP port channels can be created across both switches, to present a single logical link. If an institution has a similar feature on their own switches, they can form a physically redundant topology that doesn't rely on spanning tree and is active-active.

This solution results in many of the benefits of the BGP service but without the institution needing to undertake the overhead of running BGP and the associated costs of equipment and staff resource.

split pop ports

For institutions requiring equipment or physical redundancy for their PoP switch, the Split 10G (option 4) solution may be appropriate.  Here, two 10G SFP+ PoP switches, of the same model as option 3, are installed and interconnected via three fibre links:

  • 2x 10G links form the StackWise Virtual interconnect — this is the link which allows the two switches synchronise configuration and runtime information
  • 1x 1G link is used as the Dual Active Detect — a link which, if both of the StackWise Virtual interconnects fail (or there's an operational problem with the link) is used to prevent both switches becoming active independently

The interconnects between the two switches should take physically diverse paths, where possible.  If all of these links fail, the switches will go active independently and cause connectivity problems, essentially breaking the connection.  These links can use GBN and/or institution-owned fibre (either singlemode or multimode, although note that the StackWise Virtual interconnects must run at 10Gbit/s).  The UIS will typically plan and order these on behalf of the institution, but will discuss with them, if there are any specific requirements.  If the interconnects involve GBN circuits, these will be recharged at cost.

This functionality requires some hardware capabilities present in the Catalyst 3850-12XS not present in the 1G models (including the Catalyst 3850-24P and 3850-48P).  As such, it is not possible to offer this service on a 1G UDN PoP option.

Maintenance of the PoP equipment

The UIS will, from time to time, make changes to the PoP switch software and configuration to maintain its operation, keep up to date with security and resolve problems. In most cases, these can be made without affecting service to the client institution.  However, if downtime is required (e.g. an operating code update), the client institution will be given suitable warning and this will happen during an appropriate "at risk" period, where possible.

In the event of a hardware fault or other situation where the PoP equipment needs to be physically accessed, the UIS will need to visit the site and carry out the appropriate work.  For this reason it is requested that:

  • items are not placed on top of the PoP, making removal or access difficult
  • cables between other devices in the same cabinet that hang in front of the PoP can be moved out of the way, enabling the PoP to be removed without affecting other connections
  • cables connected to the PoP use different colours or identifying labels to indicate different configurations (port type and VLAN[s]), making it easier to identify the cables, if the equipment is swapped
  • access to the rear of the switch is maintained, especially for the connection of a serial console cable for out of band access
  • the PoP cabinet area is kept clean and generally tidy

Failure to observe these guidelines may render the UIS unable to perform the desired maintenance or cause it to take excessive time.

Upgrade during calendar year 2018

All the UDN PoP switches are expected to be replaced during the calendar year 2018-19.  The upgrade will be conducted on a site-by-site basis.  Institutions will be contacted to confirm their choice of new PoP — this will be the last opportunity to an upgrade to a 10GE-capable PoP at the discounted prices: after this, an upgrade will be charged at the full install price.

Institutions awaiting developments, or who are planning to move to BGP for their connection to the UDN, may be able to opt to delay their PoP switch replacement but this will only be possible if the schedule allows.

The new arrangement of ports on the front panel of the switch allows the ports on an existing 1G PoP to be mapped to their equivalent port on a new 1G PoP.  If an institution is retaining a 1G PoP (option 1), it will be assumed that the port layout will remain the same (e.g. port 1 on the new PoP will have the same configuration as port 1 on the old PoP).  For other options, a new layout will need to be agreed, before deployment, as there is no direct correlation of ports.

Deployment procedure

If there is sufficient capacity within the cabinet where the PoP is housed, the new PoP will typically be installed in parallel with the existing PoP and the institution left to handle moving across at their own convenience:

  1. UIS Networks physically install the new PoP, alongside the existing one.
  2. One of the two uplinks to the UDN routers will be disconnected from the existing PoP, the new PoP linked to the old and the uplink reconnected to the new PoP, allowing both PoPs to run in parallel.  If the new PoP has 10G uplinks, this link will be upgraded at this time.
  3. The institution will move their connections from the old PoP to the new PoP during a suitable 'at risk' time of their own choosing.  Care should be taken to note the new configuration of ports on the upgraded PoPs (in particular, the spanning tree configuration).
  4. UIS Networks will return, disconnecting the uplink from the old PoP, breaking the link between the two PoPs and then reconnect it to the new PoP.  If the new PoP has 10G uplinks, this link will be upgraded at this time.
  5. The old PoP will be removed, along with the RPS unit.

 The duration between steps 2 and 4 should be minimised, to avoid the need to manage dual PoPs — typically no longer than a couple of days, maximum of a week.  In addition, institutions must take care not to create a loop between the old and new PoPs, by connecting to both at the same time: this situation will not be detected and can cause significant disruption.

Last modified: 25th February 2020