Cisco 4402 Configuration Guide - Page 10

1.5 Access points 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