skip to content
 

Page Review

Please note that this page is under review due to changes in the way access points connect to the wider network. In particular, the supported arrangements for untagged and tagged VLANs are changing. In the interim please contact the Wireless Team for more information.

Who is this information for

This page is intended to be read by network managers in institutions on the University Data Network (UDN) who host University Wireless access points on their institutional network. It gives details about how the network needs to be configured to allow the access points to work.

What information is covered

For most institutions, a single access point management VLAN (as described below) will be delivered to their UDN PoP switch.  The institution will be advised of the ID and asked how they would like it presented on the PoP, to carry into their network. The access points need to be connected to ports on which this VLAN is presented untagged.

Read the access point feature webpage with information about features available on access points, such as local SSIDs.

 

Important - VLAN port configuration for access points

The ports connecting access points in the network types below must be configured with only the access point management VLAN and bridged VLANs using the pre-arranged 802.1Q tags with the University Wireless Service.  Ports must not be configured with VLANs which are not required by the access point or using tags which have not be approved. Doing so can cause severe operational issues for the entire Wireless Service.

Network types

There are 3 main types of network used by University Wireless access points:

Management network

Purpose

Used to allow the access points to communicate with the central controller infrastructure in University Information Services (UIS) for management, authorisation and logging.

Presentation to access points

Untagged (although this can be changed, read about wired port configuration's below).

Central service networks

What the clients are connected to, when they successfully join a wireless network managed by UIS. The eduroam and UniOfCam SSIDs are examples of these.

Presentation to access points

None (tunnelled back to controller over management network).

Locally-bridged networks

Only present if an institution asks for an SSID to be added to an access point for local use. Clients connecting to these SSIDs will be placed on a locally-bridged network, fed directly out of the access point into the institutional network.

Presentation to access points

Tagged (although can be untagged, in a special configuration. Read about wired port configuration's below).

When a University Wireless access point starts up, it uses DHCP on the management network to obtain its IP addressing information. It then uses DNS to find the IP address of the central controller, before attempting to establish a connection with it.  This connection with the controller is used to handle not only management traffic but also tunnel client traffic over a VPN using IPSec or GRE.

In most cases, institutions need only provide a management network connection to access points.

Management networks

The management network is used to allow access points to communicate back to the central controller infrastructure hosted by UIS.  It does not offer any services directly to clients. Their traffic is either tunnelled over this network or bridged out locally at the access point (read about network types above).

An institution has various options for providing a management network to their access points.  Which is selected is a matter of local preference.

Managed VLAN 

In this situation, a new VLAN will be supplied to the institution's PoP switch from the upstream UDN routers.  The institution will be advised of the VLAN ID and will need to state how they want it presented on their PoP: port and untagged/tagged.  They must then feed it through their network and present it untagged on the edge switch ports where the access points are attached.  The institution can also opt to connect the access points directly to the PoP (if this is physically possible) and avoid the need to reconfigure their network.  UIS will manage the IP addresses, DHCP and access control on this VLAN, much as with the voice client VLANs used by the VoIP system, as well as resizing the subnet, if it becomes too small.  This choice is the most common and easiest to implement in most institutions.

Managed routed subnet

If an institution does not wish to carry a VLAN from the PoP for network engineering reasons (for example, they have their own routers and want to route the VLAN there), they can have a UIS-managed subnet routed to them.  UIS will provide the address space and DHCP servers, but the institutional will need to set up and maintain their router and associated access lists.

Local subnet 

If an institution prefers to manage the address space and allocation itself (perhaps to put individual APs on specific addresses), it can run the management network itself.  Typically this would be done by the institution handling the routing and addressing themselves, on their own routers. It is also possible for UIS to provide the subnet as an additional (special) VLAN from the PoP.  The institution will need to provide the subnet for this itself (additional address space can be requested from IP Register, if required) and operate a DHCP server providing IP details, as described in the configuration required for a Local Subnet section below.

The differences between these options are summarised below:

Institution must ... Managed VLAN Managed subnet Local subnet
Carry VLAN from PoP to APs Yes No Optional
Provide routers and maintain ACLs No Yes Optional
Provide DHCP server(s) No No Yes
Provide address space No No Yes
Reconfigure if subnet moved/resized No Yes Yes

An institution can freely transition between the different types (or even mix them), without reconfiguration of the access points. However, UIS should be notified so that the provision of a VLAN from the PoP is either set up or removed. When a new institution comes onto the University Wireless system, the institution should state whether it wants to make use of a VLAN from the PoP, or provide its own.

Regardless of type, it is recommended that DHCP Snooping, ARP Protection/Inspection and IP Source Guard are enabled, on the management network, where available.

The subnets used on a VLAN fed from the PoP will typically be created with capacity for around 25 access points, unless a larger number are ordered from the outset.  If a subnet begins to fill up, UIS will handle resizing it.  If an institution has a clear plan for the growth of its University Wireless installation, it should make that clear so an appropriately-sized subnet can be allocated at the outset and avoid renumbering (although this is fairly straightforward and can be done with only a short interruption to service).

The management VLAN offers no useful service to end user devices and they should not be allowed to connect to them. If they do, they are unlikely to get an IP address and, if they did get an IP address, the access restrictions on the network do not allow communication other than to the central infrastructure required to make an access point work.

Configuration required for a Managed Subnet

If an institution wants to route the managed subnet itself, it is responsible for configuring its own routers:

  • The UIS will advise the institution of the subnet range.
  • The institution will need to state how the range is to be routed to them, via a static route or as part of a BGP peering.
  • The institutional routers must be configured using the top usable address (the one below the broadcast address) to provide the gateway.  The next 2 addresses below this are available for physical router addresses (in other words, the real addresses of the routers, if the gateway is provided using a first hop redundancy protocol).  This is referred to as the "top" scheme.
  • DHCP relaying must be set up to the UIS wireless DHCP servers at 172.28.208.86 and 172.28.208.87.
  • Access via TCP and UDP to the University central recursive DNS servers on 131.111.8.42 and 131.111.12.20 must be permitted.
  • The network must allow unfiltered communication between the access points and the central controller infrastructure in 131.111.10.0/23 without any form of NAT.  This communication will make use of GRE and/or IPSec, which may have difficulty passing through a NAT or firewall.

Configuration required for a Local Subnet

If an institution wishes to operate its own local management network on the UDN, there are several requirements:

  • The network must use UDN-wide addressing, either public or UDN-wide private (not institution private).  It is strongly recommended UDN-wide private addresses are used as the access points do not need to communicate directly with the internet, only with other hosts on the UDN.  Institutions may request additional address space from IP Register, if required.
  • A DHCP server must be operated to provide the access points with the appropriate host, netmask, gateway and DNS server addresses.  It is not necessary for individual access points to have fixed, known addresses - upon booting, an access point registers itself with the controller and listens for commands from the controller across this.  However, an institution may wish to do this so it can use the addresses to determine which access points are up and down.
  • Access to a DNS server to resolve the addresses of names in cam.ac.uk (including the private.cam.ac.uk subdomain) and reverse-lookups of UDN addresses (both public and private).
  • As well as connectivity to the DHCP and DNS servers, the network must allow unfiltered communication between the access points and the central controller infrastructure in 131.111.10.0/23 without any form of NAT.  This communication will make use of either GRE or IPSec, or both, which may have difficulty passing through a NAT or firewall.

It is strongly recommended that access control or other security is employed to prevent general network access (other than the required access described above) to and from the subnet if an unwanted device is connected to it.  As access points (and their network connections) are often situated in public locations, this can be especially important.

It is possible, but not recommended, to connect access points to the same VLAN as used by regular hosts within the institution (for example, ehe one used for desktop computers).  If this is done, the institution must still provide the remainder of the services above. In particular, DHCP with an address from the institution's own range.

Security of uplink traffic and access point modes

Management traffic between the central controller infrastructure and access points is always encrypted and mutually authenticated so can be regarded as secure.

Most access points are situated on institutional networks, directly connected the UDN, where the security of user traffic between the access point and the central controller is not so important, as it passes over a network with reasonable security. It is certainly no worse than any regular UDN connection over a wired cable. Such access points are typically configured as a Campus Access Point (CAP) where client traffic is not encrypted but just encapsulated using GRE.

Whilst CAPs could be deployed at a remote site across a separate VPN service back to the UDN, this is not recommended due to double encapsulation, which can present issues with fragmentation. 

Wired port configuration

In most cases, only a single wired port on the access point will be connected: the first one (usually labelled E0 or ENET0) will have the management VLAN presented untagged by the upstream switch and carry all the management and client traffic back to the central controllers.

However, this can be changed in various ways:

Some access points also include a pass-through port.

For more information about the configuration of wired ports on access points, please contact Network Support.

LLDP support

The wireless access points support LLDP to advertise their model, firmware version, connect port name and capabilities and IP address.  This can be helpful when verifying connectivity, for example:

sw-uis-rnb-n1#show lldp neighbors g4/0/13 detail

Chassis id: 24de.c6c6.51a8
Port id: 24de.c6c6.51a8
Port Description: eth0
System Name: 24:de:c6:c6:51:a8

System Description:
ArubaOS (MODEL: 134), Version 6.3.1.8 (44205)

Time remaining: 99 seconds
System Capabilities: B,W
Enabled Capabilities: W
Management Addresses:
    IP: 172.30.140.25
 

LLDP-MED to advertise voice VLANs and other policies is currently not supported.

Management VLAN tagging

The management VLAN used to uplink the access point to the network is normally presented untagged.  However, if required, this presentation can be changed to tagged.

This option can be usefully combined with the local VLAN bridging functionality to configure a room wall port with the management VLAN tagged and a data VLAN untagged. The access point can use a tagged management VLAN and also bridge traffic on the untagged data VLAN through to the downstream ports.  If the access point is removed, the data VLAN will still work directly on the wall port.

The option to use a tagged uplink VLAN is stored in the internal memory of the access point and not dynamically downloaded from the central controllers. This is because it's required during boot-up, before the connection to the controller has been established. Once a tagged uplink VLAN is configured, the access point will require that presentation to work. If the access point is moved back to an untagged management VLAN port (or one with a different management VLAN tag), it will no longer start up.  This usually means that some coordination is required between the institution and UIS Networks to enable this feature and avoid an extended outage.

802.1X supplicant

Institutional networks may use 802.1X on their wired ports to authenticate attached devices, perhaps using this information to assign an appropriate VLANs per device or user. The Aruba access points can themselves be configured as 802.1X supplicants.  There are some points to note about this configuration:

  • The EAP method used will be PEAP with MS-CHAP-V2 username and password.
  • The access point does not validate the identity presented by the server. Neither that certificate is signed by a trusted authority, nor that the DN is anything specific.
  • If the access point is unable to authenticate using 802.1X (either because it is not enabled on the switch port it is connected to, or because the credentials are invalid), it will attempt to come online anyway, in case a default (fallback) connection is available.  In this situation, the access point will appear to be running normally but will report this error situation to the controllers. Access points, or the switch, should not be left in this situation and the error rectified.

Institutions wishing to use this feature should contact Network Support with the required credentials (username and password) and which access points are to be reconfigured.

Uplink port aggregation (LACP)

This section is only applicable to some access point models (currently the AP-555, AP-534/5, AP-515/4, AP-324/5 AP-224/5).  All other access points should not be connected using aggregated ports.

Some access points with high-bandwidth radios (typically the 3x3 MIMO, 802.11ac access points such as the AP-555, AP-3/5/224, AP-3/5/225 and AP-514/15) can theoretically exceed the maximum bandwidth of a 1Gbit/s ethernet connection for client traffic (1.3Gbit/s for the 5GHz radio and 450Mbit/s for the 2.4GHz radio).  To cope with this, these access points support the use of LACP (the Link Aggregation and Control Protocol). This is a standard method of grouping ports together to increase available bandwidth.

Most network equipment uses a hashing algorithm to distribute traffic across multiple ports in an aggregated group, rather than evenly distributing it across available links, perhaps in a round-robin fashion.  This hashing algorithm is often configurable but is usually based on one or more of the MAC (Ethernet) address, IP address and TCP/UDP port number of the sender or port number of the receiver.  As such, the traffic between the controller and the access point needs to be distinguishable in one of the above ways, to ensure traffic is distributed.

Distribution across to the two links is achieved by the access point using a second IP address for the same controller for all traffic to and from the 2.4GHz (802.11g) radio.  All management and client traffic from the 5GHz (802.11a) radio will use the first (normal) IP address.  This second address is configured to be the same as the first but with the last octet +1.  As such, the upstream switches should be configured to include at least the source IP address (that of the controller) in its hashing algorithm, when forwarding traffic down to the access point.

Access points which support this feature will automatically attempt to aggregate the first two wired ethernet ports (E0 and E1), negotiating this via LACP. It does not need to be explicitly enabled. If this is successful, traffic will automatically be distributed across them, as described above.

If LACP is not configured on the ports, the connection will fall back to using an unaggregated single link for all traffic to and from the controller.  It is important that, if LACP is not configured on the switch, only a single uplink is connected to the access point and the other uplink port is left unconnected. If both links are connected, the access point will fall back to aggregating the ports in a static (unmanaged or forced) channel group, causing disruption with the upstream switch.  However, this behaviour must not be relied upon and only LACP should be used for aggregated connections.

Traffic on locally-bridged VLANs will be forwarded according to the same criteria except, as the traffic is not tunnelled from the controller but directly from the source itself, the switch will distribute it according to the pattern of the traffic itself. For example, if the hashing is based solely on source IP address which link is used will depend on source, regardless of which radio the client is ultimately connected.

Due to an issue with the way PoE is negotiated on AP-224 and AP-225 (an access point with two network interfaces), 802.3at/PoE+ must only be enabled on the switch port connected to port E0 on the access point. If PoE+ is enabled to E1, the access point will run in power-saving mode with some functionality disabled, resulting in lower performance.

AP-334/335, AP-514/515 and AP-534/535 should have 802.3at POE+ delivered on both the E0 and E1 interfaces.

Alternatively, subject to switch support, AP-514, 515, AP-534,535 and AP-555 are able to accommodate HPE Smart rate or Cisco Mulitgig technology on a single port (CAT 6/6a cabling required), Eth0, which will allow speeds greater than 1 Gbit/s. However, your switch will need to be able to supply 803.bz (class 5) PoE to allow the AP-534/5 and AP-555 to function on a single port. Please see the table below.

 

AP Power Requirements

Some access points need a minimum of 802.11at (class 4) or 802.11bt (class 5) POE power to operate at full functionality. If the correct power is not delivered:

  • some features may not work
  • coverage may be reduced
  • the AP may not function at all

This varies by model.

Note that LLDP must be enabled on the switch to negotiate the correct power.
 

AP-2/3/505

  • 802.3af (class 3) POE
  • 802.3at (class 4) POE

AP-2/3/504

  • 802.3af (class 3) POE
  • 802.3at (class 4) POE

AP-2/3/514

  • 802.3at (class 4) POE

AP-2/3/515

  • 802.3at (class 4) POE

AP-2/334

  • 802.3at (class 4) POE

AP-2/335

  • 802.3at (class 4) POE

AP-534

  • 802.3at (class 4) POE (requires PoE delivery on both interfaces)
  • 802.3bt (class 5) POE

AP-535

  • 802.3at (class 4) POE (requires PoE delivery on both interfaces)
  • 802.3bt (class 5) POE

AP-555

  • 802.3at (class 4) POE (requires PoE delivery on both interfaces)
  • 802.3bt (class 5) POE H4: AP-2/3/575 • 802.3at (class 4) POE

AP-2/3/576

  • 802.3at (class 4) POE

AP-365

  • 802.3af (class 3) POE
  • 802.3at (class 4) POE

AP-367

  • 802.3af (class 3) POE
  • 802.3at (class 4) POE

AP-2/3/505H

  • 802.3af (class 3) POE (Built in switch and PSE out disabled)
  • 802.3at (class 4) POE
AP 802.3af (class 3) POE 802.3at (class 4) POE 802.3bt (class 5) POE
AP-2/3/505 X X  
AP-2/3/504 X X  
AP-2/3/514   X  
AP-2/3/515   X  
AP-2/334   X  
AP-2/335   X  
AP-534   X (requires PoE delivery on both interfaces) X
AP-535   X (requires PoE delivery on both interfaces) X
AP-555   X (requires PoE delivery on both interfaces) X
AP-2/3/575   X  
AP-2/3/576   X  
AP-365 X X  
AP-367 X X  
AP-2/3/505H X* X  

*Built in switch and PSE out disabled

Last updated: April 2023