Access Points; The Access Point Connection Process - Cisco 4402 - Wireless LAN Controller Using Manual

Access points

1.5
The network cables connected to access points are often exposed in open areas and can represent a
security risk. An unauthorised person tapping into such a cable can potentially gain access to subnets
to which he or she should not have access and this may also enable man-in-the-middle attacks on
users. The network should therefore be organised in such a way that network access in practice is
unusable for anybody tapping into the cable. Here a controller-based system has a major advantage
over autonomous access points. In a controller-based system it is not necessary to configure a dot1q
trunk into the access point. By locating the access points in a separate, dedicated subnet and strictly
restricting access to this subnet, any attempt to tap into the system will be rendered futile. All an
access point needs to communicate with is DNS (to discover the controller) and subsequently
communicate with the controller's management address(es) via the UDP ports. All other ports should
be blocked.
It is recommended that DHCP be used to assign IP addresses to the access points. The assignment
of names to the access points is done within the controller system, either in the controller itself or
using WCS once the access point has been connected (See Section 1.5.1).
One may choose to limit the use of official IPv4 addresses by using RFC1918 addresses for all the
access points, but the organisation must then route this network internally so that the access points
can reach the controller and, if necessary, the DNS. Note that such a configuration will not be possible
in cases where the traffic between controller and access point is routed by UNINETT, i.e. over the
UNINETT backbone.
In the future there may be an option to use IPv6 addresses in the management of access points, but
this is not currently supported.
1.5.1

The access point connection process

Communication between an access point and a controller is by means of a special protocol. Older
controller software, i.e. v 5.1 and older, used the LWAPP protocol. Since the introduction of version
5.2, the standard-based CAPWAP protocol (RFC 5415) has been used. CAPWAP is based on Layer 3
(IP) communication between access point and controller. Layer 3 communication is also preferable for
LWAPP, although Layer 2 is optional for 4400 Series controllers. Given our recommendation to
separate access points and controllers in different subnets, we recommend Layer 3 mode in any case.
As mentioned previously, the 5500 Series controller has only one Management address, which is used
for all communication with access points. In the case of the 4400 Series controller, the situation is
more complex, since both the controller's Management address and its AP Manager address are used
by the access points. In connection with the initial association the Management address will be used.
Once the configuration has been downloaded to the access point (and any new firmware), it will begin
to use the AP Manager address instead.
The methods supported by an access point for the initial discovery of a controller vary somewhat
depending on what model of access point is in use. However, what they all have in common is that
they support three alternatives, and in this case we recommend Method 3 – DNS discovery:
1) Saved IP address. The access point uses the IP address already saved in the access point.
This means that the access point must previously have saved this information when it has
been connected to the controller or that the information must have been entered manually (via
a serial cable).
2) DHCP server discovery. By using DHCP option 43 for the subnet, the address of the controller
can be provided simultaneously with other information via DHCP. Further information
regarding how this is done on different DHCP servers can be found at:
10