Network Design & Install Best Practices Revision 1.1 June 13, 2005

Transcription

1 Network Design & Install Best Practices Revision 1.1 June 13, 2005 Aruba Networks 1322 Crossman Ave Sunnyvale, CA

2 Table of Contents Network Design...3 How to use this Guide... 3 Topology... 3 Getting Started... 4 Controller Placement... 4 AP Placement... 5 Topology Recommendations... 7 L3 Connectivity and IP Addressing Schemes... 7 Non-IP Protocols... 7 Wireless User Addressing... 7 Controller Addressing... 8 AP Addressing... 9 VLAN Design Getting Started VLAN Recommendations Building Large Networks with Multiple Controllers Master Mobility Controller Local Mobility Controller Redundancy Port channel VRRP redundancy

3 Network Design This chapter provides a number of guidelines for determining the Layer 1 through Layer 3 design of an Aruba wireless deployment. How to use this Guide This chapter provides an overview of planning and design guidelines for an Aruba wireless deployment. Discussions are divided into the following general topics: Topology L3 Connectivity and IP Addressing Schemes VLAN Design Building Large Networks with Multiple Controllers Redundancy Within each topic is a Getting Started section, a full discussion of the topic, and a set of recommendations. Read the Getting Started section if you are unfamiliar with the technology or problem to be solved and need guidance in what questions to ask. The bulk of each section is a full discussion of possible design choices, with the tradeoffs between each highlighted. Finally, read the Recommendation section for a quick cookie-cutter solution to each problem. The cookie-cutter approach is designed to get a network up and running quickly, and may prove useful for evaluations, trials, and pilots where a full design and analysis is not practical. Topology The Aruba Mobility Controller is designed with the flexibility required by enterprise networks in mind. A number of different network topologies are possible, and some consideration should go into the design and placement of components before installation. At a high level, an Aruba controller requires a way to get user data into the controller typically done through Access Points (APs) and a way to get user data out of the controller into the wired network. This process may require the interaction of both switching and routing processes, inside the controller or external, depending on the design

4 Getting Started Controller Placement In theory, controllers may be attached at any point in the network. In practice, controllers are normally placed either in the wiring closet or in the datacenter. There are advantages and disadvantages to each approach, and an appropriate design should be chosen based on the solution that provides the greatest number of advantages in a given network. A mixed deployment is also possible, with closet controllers handling only dense floors and a datacenter controller handling the rest of the network. Closet Placement When placing controllers in the wiring closet, a direct attachment between the controller and AP is normally possible. Benefits of closet placement include: Ability to direct-attach APs, providing a solution for power and serial connectivity to APs. Smaller outage area in the event of a non-redundant controller failure. Ability to better control broadcast and multicast traffic. A network heavily utilizing IP multicast, for example, may be better served by a closet deployment model from a network efficiency standpoint. The disadvantages to closet placement include: Closet placement normally means more controllers deployed in a network, since there must be at least one controller in each closet. This results in higher capital costs. Redundancy is more difficult to achieve with closet deployments, since a minimum of two controllers must be deployed for each closet to achieve redundancy. Device management requirements can be increased in a closet deployment as a result of there being more devices to manage. A closet deployment model almost always requires either a master Aruba controller or an Aruba NMS in the system. This can lead to increases in operational costs. Mobility can be slower, since a controller-to-controller tunnel must be established each time a client moves from one controller to another. Datacenter Placement As an alternative or supplement to closet placement of controllers, placement in the datacenter or network backbone is also possible. Advantages of datacenter placement include: Ability to terminate a large number of APs in a single location. When highdensity controllers such as the Aruba 5000 are deployed, this results in a capital cost savings by having to purchase fewer controllers

5 Ability to provide cost-effective redundancy. If a single controller is required to support the entire network, then full redundancy can be provided by installing just one additional controller. Device management is simplified by having fewer devices to manage. If a single controller is sufficient for the entire network, that controller can serve as both the master controller and the NMS for the network. This becomes a single point of management for the entire wireless network. High-cost resources are centralized. The expensive portion of the wireless access equipment consists of the encryption hardware, network processor, and memory. If these components are reduced in number and centralized, cost efficiencies can be realized. Mobility is greatly simplified. Because all wireless access for an entire enterprise is centralized in a small number of devices, most roaming happens inside the same controller. Disadvantages to datacenter placement include: A method of powering the APs must somehow be provided. This could be an existing POE switch, a POE injector, the included AC adapter, or an Aruba closet controller performing only POE and L2 switching functions. If serial port access to the AP is also desired, an Aruba closet controller should be deployed. Note that an Aruba controller in the closet does not necessarily require enabling that controller s wireless functions it can operate as a pure L2 controller and be used simply to provide power and serial over Ethernet. Large portions of the wireless network are supported by a single device. If the device is not protected with a redundant controller, a failure could take out most, if not all, of the wireless network. Datacenter deployed controllers supporting large numbers of APs should always be protected by a redundant controller. Broadcast/multicast traffic inefficiencies. If large-scale IP multicast is used, packets will be copied onto closet subnets already, and will be sent a second time for the wireless network. If TKIP is used as an encryption protocol, additional inefficiencies result because the controller must send a separate copy of each multicast packet for each AP. This is less of an issue in highperformance switched networks, but may be more of a concern in lower bandwidth networks. AP Placement The AP is the point in the network where user data typically enters the system. An AP is either logically or physically attached to the controller; in both cases, the AP communicates with the controller using IP. Thus, an AP can function as long as an IP network exists between itself and the Aruba controller. Two options are available when deploying APs, the direct-attach model and the indirect-attach model

6 Direct-Attach AP In the direct-attach AP model, APs connect directly to an Aruba controller over Category 5 cabling. The controller provides power over Ethernet (POE) as well as access to the AP s serial port over the same Cat5 cable. One advantage to the direct-attach model is the ability to provide a slightly greater degree of security on the wired side of the network, since the AP is directly attached to an Aruba controller without passing through any intervening networks. Another, and possibly more important advantage, is the ability to shut down or reboot the AP by controlling its power from the controller. Indirect-Attach AP The indirect-attach AP model is popular because it allows the wireless network to be deployed as a complete overlay to the existing wired network. Most enterprise buildings are already outfitted with Cat5 cabling, and most already have an investment in wiring closet Ethernet controllers. As long as a solution for power exists, the existing network can be used to provide transport for the wireless network. Many enterprises have already deployed POE controllers in wiring closets in order to support voice over IP desk phones, and this POE support can also be used to power wireless access points. One feature that is lost with the indirect-attach AP model is the ability to provide centralized serial port access to the APs. However, the convenience associated with using the existing wired network typically outweighs this disadvantage, especially considering that serial port access to the APs is rarely, if ever, needed

7 Topology Recommendations The indirect-attach model (or overlay model) provides the simplest deployment and greatest redundancy. L3 Connectivity and IP Addressing Schemes To a large extent, the IP addressing scheme determines how the wireless network operates overall. The controller can be deployed in L2 mode, in L3 mode, in a combination of the two, with VLAN tagging or without, and with an external router or without. These factors all have a bearing on the IP addressing scheme and on what type of L3 network connectivity is provided. Non-IP Protocols The Aruba system requires an IP network for transport of data between APs and controllers. This network may consist of simply a number of APs directly-connected to a controller running IP between them. The Aruba system is transparent to non-ip protocols, and will operate just as any learning bridge or controller would operate. Non-IP traffic will not be processed by the Aruba stateful firewall, and will be forwarded according to VLAN boundaries and learned MAC address tables. Non-stateful ACLs may be applied to ports and user roles to permit or deny access to non-ip protocols. The Aruba system has been tested to support AppleTalk, IPX, and NetBEUI. Other protocols have not been specifically tested, but should have no problem functioning as long as they adhere to Ethernet standards. Wireless User Addressing Wireless clients typically associate to the network, are assigned an IP address from a subnet, and forward inter-subnet traffic through a default gateway. Where the user s IP subnet exists and how far it extends into the network is a design consideration. There are two common practices when addressing wireless users. One practice is to extend addressing of the wired network into the wireless domain for example, users associating with an AP on floor 3 will receive an IP address from the floor 3 subnet. This has the advantage of leveraging existing access control lists between different subnets, and works well with closet deployments. The second approach involves dedicating an IP subnet to wireless access that exists only on the wireless portion of the network. This practice greatly simplifies management, since a network manager may look at a client s IP address and immediately know whether or not the client is wireless. This practice also greatly reduces the need to extend VLANs throughout the network, and is the best practice for datacenter-located controllers. An additional consideration involves how inter-subnet traffic will exit the wireless user s subnet in other words, which device acts as the default gateway. One possibility is to use the Aruba controller itself as the default gateway. A second approach involves using an external router as the default gateway, thus putting the Aruba controller in L2 mode. Both approaches are illustrated in the figure below

8 In general, the recommended practice is to use an external router as the default gateway in all but the simplest of networks. ArubaOS today does not support routing protocols, router discovery, WAN interfaces, and a number of other features that standard enterprise-class routers support. For this reason, it is best to allow the Aruba controller to handle wireless functions, and to allow a purpose-built router to handle inter-subnet routing. Controller Addressing An Aruba controller can act as either a L2 switch or as an IP router, or both. Therefore, the controller can be configured with multiple IP addresses. Four types of IP addresses are available on the controller: Loopback Address The loopback address is bound to an internal loopback interface and is not tied to any physical port or logical VLAN. The loopback address is always in an operationally up state, theoretically making it available at all times. Configuration of a loopback address is optional. VLAN Address Each VLAN configured in an Aruba controller be optionally configured with an IP address. This IP address is operationally up whenever at least one physical port in the VLAN is also operationally up. The VLAN IP address can be used as a gateway by external devices; packets directed to the VLAN IP address that - 8 -

9 are not destined for the controller will be forwarded according to the Aruba controller s IP routing table. Controller IP Address The controller IP address is not directly configured on an Aruba controller, but is derived from one of the two previous address types. If a controller is configured with a loopback address, the loopback address is always used as the controller IP address. If a loopback address is not configured, the IP address of the lowestnumbered VLAN is used. Each Aruba controller in the network must have a unique controller IP address. The controller IP address serves many purposes, including the following: o Address used for APs to request a TFTP download of their image o Termination of GRE tunnels originated at APs (in a non-redundant configuration) o Configuration of APs through the PAPI protocol o Termination of VPN tunnels from wireless clients, including PPTP and IPSEC o Controller management through HTTP, HTTPS, and CLI. Management communication is also possible through a VLAN IP address, but communication through the controller IP address is preferred. Note: If a certificate is loaded on the controller for HTTPS, the certificate name should match the controller IP address to avoid certificate warnings from the user s browser. o In a multi-controller network, the controller IP address is used for intercontroller communication o Origination of RADIUS messages, if so configured o Communication with the Aruba NMS VRRP Address In a redundant controller configuration, one or more IP addresses are created that are protected through VRRP. If an active controller fails or becomes isolated from the network because of another device failure, the backup controller will take over service for this IP address. In a redundant configuration, the VRRP address is normally the termination endpoint for GRE tunnels originating from APs, allowing APs to resume communication with a controller after a failure. VRRP is discussed in more detail in the redundancy section of this guide. AP Addressing Because access points communicate with controllers over IP, each AP in the network must have an IP address. This IP address can be either statically configured on each AP, dynamically assigned using DHCP, provided through DHCP options, or discovered through broadcast/multicast. The most common option is to use DHCP. The addressing of an AP has no bearing on the address of wireless users connecting through that AP; user traffic is tunneled from the AP to the controller and processed only at the controller. Therefore, the most common deployment scenario has the APs connected to the existing wired infrastructure. The AP will be assigned an address out of the same DHCP pool that workstations, printers, or other devices will use

10 Once the AP has an IP address, either through static configuration or DHCP, it must contact a controller. Specifically, it must contact the master controller in the network. If there is only one controller in the network, it will always be designated as the master controller. If there are multiple controllers in the network, one of them will be designated as master. The AP can be statically configured with the IP address of the master controller, or it can learn this address by performing a DNS query. The AP boot process is further described in the ArubaOS User s Guide. VLAN Design Typically, VLAN design follows naturally from IP addressing design. VLANs are portbased in an Aruba controller. In addition to physical ports on the controller, each wireless client association constitutes a virtual port with membership in a particular VLAN. VLANs can exist only inside the Aruba controller for separation of traffic, or can extend outside the controller using 802.1q VLAN tagging. Getting Started One of the goals of Aruba s user management process is to determine which VLAN a given client will join. There are a number of ways to achieve this. This process is further documented in the User Segmentation section of the Security Design Guide, but is summarized here: 802.1x Authentication When using 802.1x, authentication takes place before any access to the network is permitted. This means that an IP address is not assigned to the client until after authentication has taken place. When 802.1x is in use, VLAN assignment can be done based on the user s role (or group) assignment learned during the authentication process. This concept is known as Role-Based VLANs. AP Location When AP Location-based VLAN configuration is used, the AP with which the client originally associates determines the VLAN. The client will keep this VLAN as they move to other APs. This concept is known as Location-based VLANs. ESSID Rules may be configured to determine VLAN assignment based on the ESSID with which the client associated. This concept is known as SSID-based VLANs. Default If no other VLAN determination method has been configured, the client will be mapped to VLAN 1, the default VLAN

11 VLAN Recommendations The following recommendations are listed in order of the amount of labor required. 1. A single VLAN provides the simplest operation. 2. Use multiple VLANs where dictated by the external network, or if L2 segmentation of multiple user classes is required. Building Large Networks with Multiple Controllers A multi-controller deployment may be done for many reasons, including large deployments where the number of APs exceeds the capacity of a single controller, networks where closet deployment of controllers was chosen, multi-building campus networks where localization of traffic is desirable, or any other number of reasons. Master Mobility Controller All Aruba deployments require at least one master controller. In smaller networks, the master controller may be the only controller in the network. In larger networks, traffic processing may be split between a master controller and one or more local controllers. To ensure consistent application of policies and seamless roaming, multi-controller networks should all share a common master controller. The master controller in a network is responsible for a number of functions, including: Booting and configuring all APs in the network Providing APs with the address of their local mobility controller WLAN configuration for the entire network Ensuring inter-controller mobility home agent tables are updated on each controller Ensuring consistent user access policies across all controllers RF management for all APs Central consolidation of all wireless intrusion detection events In addition to master controller functions, the master controller can also process user traffic originating with APs. Larger networks may have a standalone master controller that does nothing but master and network management functions. Other smaller networks may have master and traffic processing functionality both enabled on the master controller. A master controller can be replicated for redundancy purposes. See the section on redundancy for more information. Local Mobility Controller The local mobility controller is responsible for terminating and forwarding all traffic from locally-configured access points. To provide this functionality, APs terminate GRE tunnels at the local controller

12 A local controller can be replicated for redundancy purposes. See the section on redundancy for more information. Redundancy Port channel The most basic form of redundancy available on the Aruba controllers is Port Channel or Etherchannel. Not only does configuring a port channel offer higher bandwidth than a single link, but also provides the ability for the logical link to be up and running (albeit at a lower bandwidth) if one of the member links goes down. To configure a Port channel from the CLI, perform the following steps: (config) #interface port-channel 2 (config-channel)#add fastethernet 2/1 (config-channel)#add fastethernet 2/2 This configuration will add fast Ethernet ports 2/1 and 2/2 to the port channel interface 2. The port channel interface switchport (access/trunk mode, member VLANs et al) characteristics can then be configured as one would configure the same for any interface. VRRP redundancy This section provides an overview of different VRRP configurations. For a more complete discussion of redundancy configuration with VRRP, please see the Redundancy Best Practices Design Guide published by Aruba. VRRP configuration There are two parts to the VRRP related configuration. The first part is related to the VRRP protocol on the two redundant controllers themselves. The second part is related to the other Aruba elements of the network that need to communicate with this pair of controllers. The first part of the configuration is explained in detail in the User Guide. The second part of the configuration is different for different scenarios of redundancy. When configuring VRRP to act as a redundant pair of controllers for a set of APs to terminate their GRE tunnels on, the lms-ip of the set of APs needs to be configured as the virtual IP of the VRRP pair. This is illustrated in the examples of local redundancy below as a part of the example topologies section

13 When configuring VRRP for master redundancy, the following must be done: 1. Master redundancy configuration (peer-ip-address and VRRP-VLAN). 2. All the local controllers and APs now should be configured with the Master IP having the value of the Virtual IP of the VRRP ID used for Master redundancy. These are illustrated in the examples of Master redundancy as a part of the example topologies section. AP and Client failover process This section details the exact process by which the APs and the clients transition from the primary controller to the backup controller in the event of a failure. The timeline below shows the events occurring at various times in this process. The figure below shows the general topology for APs connected to a pair of Aruba Controllers. Controllers S1 and S2 are configured to run VRRP on VLAN x and the APs are configured for the lms-ip to be V ip that is the virtual IP configured on the two controllers. Aruba S1 VLAN x Aruba S2 Layer 2/3 network AP LMS IP = V i In the figure above controller S1 is the original Active controller where the APs are terminating their GRE tunnels. Controller S2 is in the Backup state and is receiving VRRP advertisements from S1. In the event of a failure (like the link from S1 to the rest of the network going down), S2 will stop receiving the VRRP advertisements from S1 and will assume the Active state. S2 is now ready to terminate GRE tunnels for this VLAN

14 In the meanwhile, the APs will also be missing heartbeats that they were receiving from S1. After 3 seconds, the AP will turn off their radios (at this point, clients lose their associations). After 6 seconds, the APs will re-bootstrap and will therefore contact the Master to receive their configuration once again. As a part of this configuration, the Master will also provide the LMS-IP to the AP. This LMS-IP would have been configured as the Virtual IP between the redundant pair of controllers S1 and S2. So now when the AP attempts to establish a GRE tunnel with this IP address, it will be communicating with S2 that has assumed this IP address. Once the registration with S2 is complete, the APs will be up and ready to accept clients again. The clients can then reassociate to the AP and will regain connectivity. Normal connectivity Station regains connectivity T 0 T0 + 3 T T 0 +6+x Failure event occurs. Station loses connec tivity 3 missed VRRP advts on Backup, transitions to VRRP master. And 3 missed heartbeats to AP, turns off radio, station loses association AP reboots and contacts Master for config. AP associates with LMS again and ready to accept associations Master redundancy The aim of having a redundant pair of Master controllers is to ensure that any event that causes a loss of connectivity to the Active Master controller does not cause loss of the following functionality of the Master Aruba controller in an Aruba network: 1. Provide configuration to the Local controllers. 2. Provide configuration (if required the image) to the Aruba access points. 3. Serve as a central point of collecting VLAN information to form the Home Agent Table and update it if any changes occur. Configuration This redundancy is provided by using VRRP as the base mechanism. The administrator can configure VRRP on a VLAN on both controllers and deploy the controllers such that

15 they have Layer 2 connectivity on that VLAN. In addition to this, the administrator needs to configure master redundancy for the following two parameters: 1. VRRP-Id that will be used for Master redundancy 2. Peer-IP-address. The one additional configuration item as a part of the VRRP configuration recommended for Master redundancy is the tracking configuration. By use of this configuration, the administrator can configure the controller to raise the VRRP priority on the basis of the duration that the controller has been in the Active state for that VRRP instance. This is advisable to avoid loss of data in the database when there is a transient failure of a Master controller. The other important difference in configuration when Master redundancy is used is that all local controllers and the Access Points are now configured with their Master IP being the Virtual IP of the VRRP instance that will be used for Master redundancy. All databases that are maintained on the Master controller can be synchronized by using the command database synchronize on the Active Master controller. Operation When both the active and backup Master controllers are up and running, the active Master performs all the responsibilities of the Master controller in an Aruba network. The Backup Master receives the global configuration from the Active Master in the same manner as a local controller would. The VRRP instance on the Backup Master detects a failure event when there are three consecutive missed heartbeats on the VRRP instance being used for master redundancy (standard VRRP operation). This causes the backup controller to transition from the Backup State to the Active state and take over all responsibilities of a Master controller. When the original Master controller regains connectivity, it may or may not take back the role of the Active Master depending on how long it was inactive and the configuration for tracking, as explained above