skip to content

This section describes features available on University Wireless access points to support extra functionality that some institutions may require, such as additional SSIDs or wired port configuration.

Information about the management support network to connect the access points is described separately.


Local SSIDs

University Wireless access points can be configured to offer wireless networks (SSIDs) instead of, or in addition to, the central service VLANs (eduroam and UniOfCam).  Such networks can provide a mechanism to connect to a local office or guest network.

It should be noted that each additional SSID creates a burden on the performance of the wireless network (affecting all SSIDs, not just the additional ones) and their number and use should be limited.  In addition, the UIS strongly advises that services provided to users are not limited to 'internal' local SSIDs which may inconvenience users when they roam outside the physical location of the institution.

If an institution wishes such a service, the following information must be provided:

  • What the ESSID (wireless network name) should be.  This can technically be anything, but it is recommended that something identifying the institution be chosen (e.g. "Botolph's Guests" rather than just "Guest Network").
  • Whether the ESSID should be announced in beacons or "hidden" from wireless network lists in client devices.  This is not a security tool as the network can still be found by wireless snooping software or equipment, but is often used to hide a non-public network from being obviously selectable.
  • What security should be used on the wireless side of the network (none/open, WPA2-AES-PSK, etc.).
  • Which access points the network should be available on (the default is all the ones within an institution; if it is to be selectively available, some access points may need to be reconfigured and restarted).  Usually the affected access points should be grouped under a single zone in the Wireless Console.
  • What 802.1Q VLAN ID should be used for the SSID.  Here there are three choices:
    • For VLANs which are to be routed directly by the CUDN, the UIS will allocate a Global VLAN ID.  If this is an existing VLAN, that number will be used for it.  This VLAN will need to be fed from the institution's PoP switch to the required access points.
    • For VLANs which are routed inside (or otherwise private to) institutional networks, the VLAN ID can be selected by the institution but must come from the Local VLAN ID ranges.  The institution will need to create this VLAN on their local network and feed it to the required access points.  There is a potential problem that this number could conflict with some internal numbers used by the wireless system itself — these numbers are gradually being freed up and, until this is complete, if a clash causes a problem, the UIS will advise the institution to select another number.
    • In some cases, the local SSID will be routed by the UIS centrally.  In this case, traffic will be tunnelled over the management network and the VLAN ID will not need to be exposed to the institution, nor will any local configuration be required.

For the security options, various choices are available:

  • Open – no security.  If this choice is used, there will typically need to be some additional security provided internally, to limit or authenticate/authorise access further onto the network.  Even if this is done, institutions should be aware that many devices will connect to any open network and attempt to gain internet access, possibly using local IP addresses.  Also, traffic over open networks is not encrypted over the air, allowing it to be easily captured.These networks are only allowed in certain circumstances.
  • WPA2-AES-PSK ("WPA2 Personal") – single, shared key (or passphrase) known by all users.  Here a single, shared key is used for all connecting users and traffic is encrypted over the air, such that it cannot easily be captured (although someone with knowledge of the shared key can set up a fake access point to capture traffic). These networks are only allowed in certain circumstances.
  • WPA2-AES ("WPA2 Enterprise") with Lookup – individual usernames / access passwords.  This is essentially the same as eduroam (although the local network must be provided by the institution) but only a subset of users can connect to it (controlled by a Lookup group).
  • Federated WPA2-AES – The UCS servers proxy authentications to your institutional RADIUS server(s). The local network must be provided by the institution.

Various legacy options are not available for security reasons (e.g. WEP, WPA-TKIP-PSK and WPA-TKIP).

There is no hard limit on the number of locally-bridged services available to an institution (although the current equipment is limited to a maximum of 8 SSIDs per access point radio, including the UniOfCam and eduroam ESSIDs), but their usage should be kept to a reasonable number due to over subscribing the aceess point.

There are several limitations regarding locally-bridged networks:

  • If a public shared key is used, this can only be changed by contacting Network Support.  A date and time for a change can be coordinated, but it cannot be changed excessively.
  • Access lists cannot be employed on locally-bridged networks, so they are essentially open.
  • Usage of locally-bridged networks is not currently reported in the University Wireless Console, although it is logged for diagnostic and abuse purposes.
  • The underlying network to which a locally-bridged network connects the client is the responsibility of the institution: they must provide services for IP networking, DHCP, access control and logging, as appropriate.
  • The access points have no ability to detect if the client VLAN has been fed correctly to them - if this has not been set up, the client will end up in an isolated network on that access point.
  • There is no way to control the VLAN onto which individual clients are based - each ESSID has its own VLAN, on a particular access point.
  • Clients cannot be forcibly disconnected or banned from the network.

These limitations may be resolved in future with updates to the system.

Remote access points (RAPs)

Remote access points are no longer supported by the University Wireless Service

Local switch using wired ports

By default, the wired ports on an access point are configured such that the first one is the uplink to the (untagged) management VLAN and no other ports are usefully active.  On access points with multiple ports (e.g. the 303H (hospitality series) APs), each port can be configured in a manner similar to a switch: VLANs can be presented tagged or untagged on each port and traffic bridged locally between them.

To utilise this functionality, an institution will need to contact Network Support with the desired configuration of each port (which VLAN(s); tagged or untagged), stating which access points this configuration should apply to. Where necessary VLAN IDs will be allocated by Network Support.

Local VLAN bridging is also used to feed the traffic from local SSIDs into the institutional network.

Please note that, as stated above, LLDP-MED is not currently available to advertise a voice VLAN to a phone so this must be manually configured on a handset.

Pass-through ports

Some access points have a pair of ports labelled pass through (e.g. on the AP-303H there is one on the back and one on the panel at the bottom).  This is literally a direct electrical connection between the two ports, allowing a cable to be physically extended through to the other port: the access point does not interfere with the connection either to control VLANs nor supply Power over Ethernet.  As such, nothing needs to be (nor can be) configured to use this facility.

Last updated: Jan 2020

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

Your University GoogleDrive: 20GB quota limit from December 2022

19 January 2022

Google is replacing its G Suite for Education model licensing model in October 2022. As a result, there will be a new limit of 20GB on personal GoogleDrive spaces provided with G Suite@Cambridge accounts. If your GoogleDrive usage exceeds 20GB after 1 December 2022, your University account GoogleDrive will become read-only until your usage is brought below 20GB.

Moodle offline for upgrade during 06:00–12:00 on Tuesday 11 January

10 January 2022

Moodle will be unavailable from 06:00 to 12:00 on Tuesday 11 January while we upgrade it to version 3.9. During the upgrade, you won’t be able to view or upload sessions on Panopto because access is managed via your Moodle login. Assessment Moodle, ICE Moodle and Clinical School Moodle users will be unaffected. An outline...

HEAT authentication method changing to Azure on 13 January

7 January 2022

We're changing the authentication method for the IT service management system, HEAT, to Microsoft Azure on Thursday 13 January 2022. What is changing? You should continue to use the same URL for accessing HEAT: However, the 'Sign in' screen you'll be directed to will look slightly different,...