Access point support networking

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. Please contact the Wireless Team should you require more information.

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.

• VLAN port configuration for access points
• Network types
• Management networks
• Security of uplink traffic and access point modes
• Wired port configuration
• AP power requirements
• Network and power specification table.

Critical - 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.

The presentation to access points must be untagged and should not traverse a firewall.

Central service networks

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

Presentation to access points is not required (it is 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.

The presentation to access points must be tagged.

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).

When a University Wireless access point starts up, it uses DHCP on the management network to obtain its IP addressing information. It then uses preconfigured addressing information attempting to establish a connection its allocated wireless controller cluster.  Once allocated a controller in the cluster this connection is used to handle not only management traffic but also tunnel client traffic over a VPN using IPSec or GRE. Note that this AP management VLAN must not traverse a firewall.

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.

The differences between these options are summarised below:

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 the number of access points deployed in the institution. 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. The AP management VLAN should not traverse a 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.

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. Access points are 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:

• Access points with multiple ports, such as the AP-505H can be configured as VLAN-capable switches.
• On some access points, multiple uplink ports can be aggregated to increase available bandwidth.

Some access points also include a pass-through port.

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

LLDP support

The wireless access points support LLDP to advertise their model, firmware version, connect port name and capabilities and IP address. LLDP support should be enabled to assist the access point negotiating its power requirements with the switch.

LLDP support can also 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 in use.

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 the Wireless Team with the required credentials (username and password) and which access points are to be reconfigured.

Uplink port aggregation (LACP) and HPE Smart Rate/ Cisco multigig switches

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

Some high capacity access points (especially those in busy areas) with high-bandwidth radios can theoretically exceed the maximum bandwidth of a 1Gbit/s ethernet connection for client traffic.  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. Alternatively, subject to switch support, access points are able to accommodate HPE Smart Rate or Cisco mulitgig technology on a single port (CAT 6/6a cabling required) when connected to Eth0, that will allow speeds greater than 1 Gbit/s. The switch will need to be able to supply 803.bz (class 5) PoE to allow the AP-534/5, 555, 636 and 655 to fully function on a single port. Please see the table below for more details.

For LACP connections, 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.

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 and client traffic to be lost.  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.

AP-514/515, 534/535, 635 and 655 should have 802.3at POE+ delivered on both the E0 and E1 interfaces if using LACP.

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 (the AP may power up for staging but the radios will stay off).

This varies by model.

Note that LLDP must be enabled on the switch to negotiate the correct power. In addition if using multiple uplink ports on an access point, POE should be delivered to all ports.

Network and power specification table.

*Built in switch and PSE out disabled
** Applying LACP to this access point will downgrade the speed to the lowest link speed (Eth1) i.e. 2 x 1Gbps.

Last updated: Sept 2024