Unified Communications Certifications

CCNA Voice

Cisco’s CCNA Voice certification is one of three technical “concentrations” released in 2008 in response to a Cisco study that found 69% of IT managers expect to have a dedicated voice specialist role in their IT organization within five years, while only 40% have them today.

CCNA Voice confirms validates your skills in VoIP technologies such as

• IP PBX and telephony
• Call control
• Voicemail solutions

Through the course of preparing for the exam, you’ll also get exposure to the Cisco Unified Communications architecture and design covering mobility, presence, and TelePresence applications. CCNA Voice proves that you are committed to your career, and prepared for these job roles:

• Voice Administrators
• Voice Engineers
• Voice Managers

Prerequisite: Valid CCNA certification or any CCIE certification.

Required Cisco Exam: 642–461 ICOMM v8.0

CCNP Voice

Cisco recently completed a significant upgrade to their CCVP program, including a new name: Cisco Certified Network Professional Voice (CCNP Voice). The topics covered on these new exams better reflect the daily job tasks of Cisco Unified Communications and VoIP professionals and have streamlined the process of getting certified by eliminating the enterprise/commercial option.

Prerequisite: Valid CCNA Voice certification, or any CCIE certification.

Required Cisco Exams:
642–437 CVOICE v8
642–447 CIPT1 v8.0
642–457 CIPT2 v8.0
642–427 TVOICE v8.0
642–467 CAPPS v8.0

CCIE Voice

Achieving CCIE Voice certification declares your expert-level knowledge of Voice over IP (VoIP) solutions in an enterprise environment and informs that you have the skills to help companies accelerate business processes, increase productivity, and speed innovation. Success on the CCIE Voice written exam and the CCIE Voice lab exam means that you are capable of building and configuring complex end-to-end telephony networks, troubleshooting and resolving VoIP-related problems, and ensuring Quality of Service using in-depth understanding of Layer 2 and 3 network infrastructure.

Prerequisite: While there are no formal prerequisites for CCIE Voice certification, you are expected to have an in-depth understanding of the topics in the exam blueprints and are strongly encouraged to have three to five years of job experience before attempting certification.

Required Cisco Exam:
Step One: CCIE Voice Written Exam
You must pass the two-hour written exam covering those technologies and applications that comprise a Cisco enterprise VoIP solution before you are eligible to schedule the lab exam.

Step Two: CCIE Voice Lab Exam
The CCIE Voice lab exam is an eight-hour, hands-on exam which requires you to configure a Cisco enterprise voice solution over an IP network. Although basic network connectivity is provided, you will be responsible for configuring the pre-installed applications to satisfy the requirements of the lab and for troubleshooting important parameters of a voice network, such as Quality of Service, VLANs, gateways, and gatekeepers.

You must pass the lab exam within three years of passing the written exam to achieve CCIE Voice certification. Your first lab attempt must be made within 18 months.

Wireless Certification

CCNA Wireless

Cisco’s CCNA Wireless certification is one of three technical “concentrations” released in 2008 in response to a Cisco study that found that by 2013 the number of companies with a dedicated wireless role is expected to increase by 30%.

The CCNA Wireless certification validates your skills in configuring, implementing, monitoring, supporting, and troubleshooting wireless LANs in small to medium-sized business (SMB) and enterprise networks.

Prerequisite: Valid CCNA certification, or any CCIE certification.

Required Cisco Exam: 640–721 IUWNE

CCNP Wireless

CCNP Wireless certification recognizes the critical importance of professionals who support and manage Cisco wireless LANs and networks. Driven by the need for professionals responsible for the design, implementation, security, and operation of wireless networks and mobility infrastructures, CCNP Wireless certification emphasizes wireless networking principles and theory.

It also recognizes the expertise of wireless professionals who can assess and translate business requirements into technical specifications for successful installations.

Value of CCNP Wireless Certification to Professionals

• Recognizes and validates your professional-level wireless design expertise
• Demonstrates your ability to configure, implement, and manage all aspects of Cisco wireless LANs
• Prepares individuals interested in pursuing a Cisco Certified Internetwork Expert (CCIE) Wireless certification

Prerequisite: Valid CCNA Wireless certification, or any CCIE certification.

Required Cisco Exams: 
642–746 IUWMS
642–731 CUWSS
642–741 IUWVN
642–736 IAUWS

CCIE Wireless

Passing the CCIE Wireless certification exams demonstrates your broad theoretical knowledge of wireless networking and your solid understanding of Cisco Wireless LAN technologies. CCIE Wireless certification validates that you have the expertise to design and manage wireless networks and to make mission-critical and business-critical wireless network decisions.

Prerequisite: While there are no formal prerequisites for CCIE Wireless certification, you are expected to have an in-depth understanding of the topics in the exam blueprints and are strongly encouraged to have three to five years of job experience before attempting certification.

Required Cisco Exams:
Step One: CCIE Wireless Written Exam
You must pass the two-hour written exam covering planning, designing, implementing, operating, and troubleshooting Enterprise WLAN networks before you are eligible to schedule the lab exam.

Step Two: CCIE Wireless Lab Exam
The CCIE Wireless lab exam is an eight-hour, hands-on exam which focuses on implementing Enterprise WLAN solutions, including the autonomous infrastructure, unified infrastructure, unified controllers and APs, unified WCS and location, and implementing Voice over Wireless.

Knowledge of troubleshooting is an important skill, and you are expected to diagnose and solve issues as part of the CCIE Wireless lab exam. You must pass the lab exam within three years of passing the written exam to achieve CCIE Wireless certification. Your first lab exam attempt must be made within 18 months.

Related Courses
Cisco Certifications

1. 802.11ac is 5 GHz only. This “limitation” is possibly the most important development because it will bring about a shift in client device support for the cleaner band with more usable spectrum. Mobile devices should adopt quickly if they want to stay “cutting edge” on the spec sheet, and because mobile devices are consumer products, the marketing of speed-based specs carries vast importance. Pervasive client adoption of 5 GHz will improve aggregate performance across the enterprise. 2.4 GHz is a garbage band; Wi-Fi is taking the goods to 5 GHz and leaving its refuse in 2.4.
2. The IEEE has a “reach for the stars” attitude with the 802.11ac spec. Unfortunately, the marketing hype of “gigabit Wi-Fi” is way overdone. The few features that really drive the maximum data rate up are not immediately, or possibly ever, relevant to the enterprise.
• Very large channels—certainly 160 MHz, and likely 80 MHz as well—can ruin aggregate capacity, especially with high client densities and lots of 20 MHz only mobile devices. Some experts call these large channels a “gimmick.” Marketing departments love it.
• The other big data rate boost is more spatial streams (up to 8). As a reminder, today’s products incorporate only 3 (and rarely utilize them all) of the possible 4 spatial streams specified in 802.11n, so the likelihood of ever utilizing 8 is very slim. Adding more spatial streams to real-world products will take a lot of time.
• MU-MIMO promises better spectral efficiency with simultaneous transmissions to multiple users. However, this feature relies on better support (heck, let’s start with some support) of client beamforming as well as significant queuing modifications, and even then, there are still questions about achieving sufficient signal isolation between target clients. MU-MIMO doesn’t change the raw data rate, but it’s one of those marketed theoretical features that won’t be in the first, or first several, generation of products.
3. Both 802.11ac and 11ad will be hot in the consumer market, and like previous technologies, will filter into the enterprise as use cases develop. This is especially true for 11ad, which is almost exclusively focused on consumers, but may find niche uses in enterprises. 11ac will be a mainstream enterprise technology, but many of its gains are muted in the enterprise.
4. 3 out of 4 experts had reservations about the significance of “gigabit Wi-Fi.” The dissenting 1 out of 4 is optimistic. 
5. Products will not hit the market until late 2012 or early 2013, so we still have time to wait and let the many marketers beat their drums.

The short answer is standards. By using the same standards rules on both of those computers, you and your friend (and just about everyone) can talk across the Internet.

Okay, so who uses these standards?

Well, since they are set by different organizations, they cover different parts of the communication process. Let’s take a generic look at that process.

When you start sending data, your computer uses a set of rules or protocols. The first rules, we’ll call them Data Formatting, are up to the software you and your friend use in your computers. For example, you may save your file as a PDF (Portable Data Format), and, if your friend has software to read a PDF, it will appear on their screen just as you sent it. If your friend’s computer is missing the right software to read a PDF, they will see gibberish (if anything) instead.

Some of these standards get set by users accepting the software like Microsoft’s Word while other standards are set by The Internet Engineering Task Force (IETF). Each Working Group is made up of lots of different people who are interested in working on that group’s application standards.

Inside your computer, the formatted data reaches other software that comes with the computer. That software, based on the standards set by another IETF Working Group, makes sure the two computers talk with each other in a way that gets the data to its destination without errors and in the right order. We’ll call that the Session Handling part of the process. At this step, a communication header gets added to the data that holds the Session Handling information.

Since you and your friend are probably on different networks, there needs to be some rules for getting the data from one network, through another network, to the destination network. That involves addressing, checking for errors, setting how important the data is to be treated, logical addressing, and routing. Those rules come from a separate IETF Working Group. That group adds another header that carries the information about the Routing part of the process.

Before your computer send the data out the local network cabling on the first leg of the journey toward your friend’s computer, it passes the data to the network software in your computer. That software decides which path to take and rules to use. These standards come from industry groups who work on the Local Signaling part of the process. The most commonly used choices come from the Institute of Electrical and Electronics Engineers (IEEE) who set the standards for Ethernet and wireless communications. Yes, they also add a header to carry their information.

The explosion of data, its criticality, and business’ growing dependency on digital information are leading to larger and more complex information storage environments that are increasingly challenging to manage.

IT/storage managers and storage professionals across companies of all sizes face the following mission-critical challenges:

• Managing storage growth
• Designing, deploying, and managing storage in a virtualized server environment
• Designing, deploying, and managing backup, recovery, and archive solutions
• Storage consolidation
• Making informed strategic/big-picture decisions
• Designing, deploying, and managing disaster recovery solutions
• Lack of skilled storage professionals
• Designing, deploying, and managing storage in a cloud computing environment
• Convincing higher management to adopt cloud
• Managing external cloud service providers

Impact of Cloud Computing

Migrating to a highly virtualized cloud environment is a significant transformation. It requires a considerable amount of technology and business planning. Since cloud computing requires cross skilled expertise, IT professionals are required to have necessary knowledge across technologies that will be used in cloud infrastructure and services.

Complex Storage Environments

Despite the differences in industry segments and the data center size, there is a strong consistency across companies in terms of the technology deployed, storage management practices, and challenges.

Nearly all critical data is now stored on external disk storage subsystems. The average usable capacity is approximately 1.3 PB which is typically spread across multiple sites. Growth in storage requirements, larger capacity disks and subsystems, and affordable pricing have all led to large storage configurations. Storage subsystems, SANs, and backup/recovery technologies are most commonly implemented, followed by NAS, DAS, and replication technologies. Technologies such as storage virtualization and cloud (private and public) have started to emerge strongly.

Each of these storage technology segments is unique, offering their own specific business and operational value. Each requires a different set of skills for effective design and management. Lack of knowledge and expertise in a specific segment can lead to under-deployment of one or more of these technologies.

Criticality of Storage and the Need for Formalized Storage Groups

Storage infrastructure is mission-critical. Losing storage in a catastrophic situation can severely damage a customer’s business. When a disaster does occur, information on storage subsystems can be lost permanently unless a well-designed recovery mechanism is planned and implemented.

In addition to reliable equipment, a well-structured storage group of highly skilled professionals is critical to build and maintain a high-performance, high availability storage infrastructure. Storage groups are responsible for overall planning, design, implementation, monitoring, administering, managing, and operations. While the structure of the group, titles, and roles may not be standardized, responsibilities and tasks are common across companies.

The Storage Technology Knowledge Gap

Although managers prefer to hire experienced or certified storage professionals, a severe shortage of such skills in the marketplace is causing managers to resort frequently to internal recruitment. The skills gap continues to widen as organizations adopt virtualization and cloud computing.

The shortage of experienced storage professionals and the lack of storage technology education in the marketplace and in academics have restricted the growth of information storage and management functions.

Step 1: LAN Switch Configuration

If you happen to have a Layer 3 PoE switch (e.g., 3560, 3750), then you have a lot of extra work done at the outset since the device itself can route between VLAN segments. If not, you may need to add a router by way of a trunk connection to perform that function for you. The ASA 5500 platform can do a few things but is not really intended for use as a routing device.

Assuming that the following is already completed, you will need to perform some specific tasks in order to support the attached wireless devices, as follows:

1. Inline Power
   By default, power should be configured to automatically detect the attached device, but if it has been disabled, use the following commands to correct the issue:

   power inline auto	Enables power detection and supply
   no shutdown	Enables the interface or resets it

2. Access Point Port Configuration
   1. Autonomous AP’sFirst decide what design you plan to use regarding single or multiple SSID’s on the AP. If you plan to only configure and use a single SSID mapped to a single VLAN, issue the following command on the attached port:
      

      switchport mode access	Sets the port for access mode
      switchport access vlan <VLAN-ID>	Identifies the VLAN to map to

      Make certain that the VLAN exists, and it doesn’t issue the following command from global configuration mode:

      vlan <VLAN-ID>

      If you plan to use multiple VLANs and SSID’s, configure the AP port for trunking mode, as follows:

      switchport trunk encapsulation dot1q	Sets the trunking type
      switchport mode trunk	Sets the port to trunk only mode

   2. Lightweight AP’s send traffic to specific VLANs using tunnels created between the AP and the Wireless LAN controller rather than defining VLANs on the AP itself. For that reason, set the port to access mode as follows:
      

      switchport mode access	Sets the port for access mode
      switchport access vlan <VLAN-ID>	Identifies the VLAN to map to

3. Wireless LAN Controller Port Configuration
   Wireless LAN controllers are the “brains” behind wireless networking and have the ability to create the mappings between VLANs and SSID’s. For that reason, the port to the WLC should be configured for trunking using the following commands:

   switchport trunk encapsulation dot1q	Sets the trunking type
   switchport mode trunk	Sets the port to trunk only mode

Step 2: Wireless LAN Controller Initial Configuration

To perform the very initial configuration on the WLC-2106, you will need to be connected to the console port of the device using a terminal services client. Most of the process is menu-driven, so knowing the command syntax is not a hard requirement. Keep in mind that the Command Line Interface (CLI) is IOS–like but not identical, so it can take some getting used to. The WLC will go through some boot processes, but eventually you will see the following displayed:

Booting Primary Image…
Press <ESC> now for additional boot options…

If the device has not had its configuration erased, press break or Control-R, and then press the ESC key, which will display the following menu:

1. Run primary image (active)
2. Run backup image (Version x.x.x.x)
3. Manual upgrade primary image
4. Change active boot image
5. Clear configuration
6. Please enter your choice:

Select 5 to clear the configuration and reset everything to factory defaults.

Whether you reset the device or you are powering it up with no configuration, you’ll be prompted through a series of questions designed to enable the WLC for use, as follows:

1. System Name:  Basically the hostname of the WLC-2061
2. Administrative User Name:  Username of the system administrator (default is admin)
3. Administrative User Password: Password of the system administrator (default is admin)
4. Management Interface IP Address: The first of several IP addresses required, this is one of the most important ones as you will access the web GUI by this address
5. Management Interface Netmask: Mask of the previously configured IP address
6. Management Interface Default Router: Layer 3 default gateway on the Management VLAN
7. Management Interface VLAN Identifier:  VLAN-ID of the management VLAN, leave at 0 to leave traffic untagged (simpler and easier for a lab environment)
8. Management Interface Port Number: Not a TCP/UDP port but the physical port connected to the upstream LAN switch (see numbers on the back of the WLC)
9. Management Interface DHCP Server IP Address:  DHCP server on the Management VLAN
10. AP Manager Interface IP Address: This is the IP address and subnet that will be used to communicate with the AP’s
11. Virtual Gateway IP Address: This is a fictitious address for purposes of mobility management and some other functions, most administrators tend to use 1.1.1.1
12. Mobility/RF Group Name: Optional, not needed for this lab environment
13. Network Name (SSID): Default SSID that Lightweight AP’s use to join the controller
14. Allow Static IP Addresses: Specifies whether or not clients are forced to use DHCP
15. Configure a RADIUS Server Now? Yes/No whether or not to add a RADIUS server for security purposes (leave at no unless you have added it to your lab)
16. Enter Country Code: This indicated the area where the wireless will be deployed, using a two letter code (the US is default)
17. Enable 802.11b Network: Yes/No as to whether to enable the 802.11b (2.5 GHz) RF network
18. Enable 802.11a Network: Yes/No as to whether to enable the 802.11a (5 GHz) RF network
19. Enable 802.11g Network: Yes/No as to whether to enable the 802.11g (2.5 GHz) RF network
20. Enable Auto-RF: Yes/No as to whether to enable Radio Resource Management

Step 3: Wireless Control System Initial Configuration

The Wireless Control System (WCS) can run on any one of three operating system environments, namely Windows, Linux Red Hat, or VMware ESX Server. The biggest hurdle with using Windows is that a Server OS is required, which in a production environment isn’t optional. There is a workaround to use Windows XP, which is fine for a lab environment. The trick is to go to the Windows Command Prompt and enter the following:

<WCS Filename> –DCHECK_OS=false

An actual example would be C:\WCS-STANDARD-K9-5.2.130.0.EXE –DCHECK_OS=false

I actually did this on a Toshiba Netbook running Windows XP Pro, and it worked fine. My issue only had to do with using an underpowered machine. Once WCS is installed, you can reach it using the IP address assigned to the laptop. Log into the WLC GUI, and perform the integration between the WLC and WCS, and you will be good to go.

Step 4: Access Point Configuration

The Lightweight AP’s should be ready to go if they are already imaged to lightweight mode and set to get their addresses through DHCP. If you DO have to reimage the access points (for instance, from autonomous mode) then the procedure is available on Cisco.com. To make your autonomous AP, log in through the console port and assign an IP address to the Bridged Virtual Interface (BVI). Following that, you should be able to get access through that IP using the web GUI.

That should get you prepared to perform Wireless LAN lab exercises and give you a great start on learning this exciting technology!

First, there are at least two devices that talk on the network. The devices may be desktop or laptop computers, tablets, mainframe computers, printers, servers, smart-phones, terminals, fax machines, relay systems, and any system a person may use for communications. To do that, each device must have a separate identifier or address, so they can recognize the other device(s) as different.

Second, the network media connects these devices to each other. It may be copper carrying electrical signals, fiber (plastic or glass) sending and receiving signals of light, or wireless radio signals. Some older networks even used infrared light. Many of today’s networks combine copper, fiber, and wireless to offer the networking experience both users and managers want.

Third, the functions a device must find outside itself. These can also be used as some of the reasons for networking. A definition may refer to them as external services. There are two main groups of these services: Information Sharing aka Collaboration and Resource Sharing.

Collaboration raises the knowledge level for all who share information. This works for researchers, student study groups, medical staff, and many other groups. Researchers learn more and get to experiments and results faster. Students learn more and faster. Patients reap the benefits of the collaboration of all medical professionals’ sharing wherever they may be located. All of this also saves travel time and costs.

Sharing resources such as printing, messaging, file sharing, server browsing, video conferencing, and management functions has multiple benefits. The per-device costs drop when compared to separate resources for each device. This lets a network manager get better and faster resources knowing they will spend much less time sitting idle. The larger the network, the more likely those shared resources will also include networking staff and equipment to keep the network secure and running at its best.

2–3 — Cisco Aironet 1200 AP’s
1 — 3524-XL-EN (Power over Ethernet)
1 — ASA-5505 (Base License)
Cisco 2106 Wireless LAN Controller
7 Cat-5 Ethernet Cables
1–2 XP Pro Laptop/Desktop

Correctly assembling these components into an easily accessible lab is fairly simple, and I have built enough of them over the years to help simplify the process. One item not listed above that can be helpful is a terminal server, which establishes console-based access to all of the devices in the lab. In the simplest setup, you can simply swap the console cable between each device, but when you have eight or more devices (as I typically do) a terminal server is a big help.

Step 1: Rack, Stack & Power

This particular lab environment is rather small and probably will not create significant issues if you have to host it in a home environment. You can probably find a very small network cabinet (6-9RU) that would be able to host the rack-mountable pieces. When possible, fasten mountable devices and cable strap the various power cables together to a power strip to provide electricity to the components. If you use Power over Ethernet (PoE), then you need very little else regarding power cabling and such. Additionally, most wireless device configurations are done through the web graphical user interface (GUI), so console access may be somewhat irrelevant.

Step 2: LAN Cabling

The second step in assembling this wireless lab is extremely simple. Run LAN cables from the PoE switch taking care to connect all the following devices in the lab:

• Cisco Wireless Access Points (2–3 depending on your quantities)
• Cisco WLC-2106 (only cable one connection, the others will not be needed)
• Run the AP cables directly to the WLC as two ports supply PoE (Optional)
• Workstation/Laptop Hosting WCS
• Client Workstation (Optional)

You can use CAT 5/6 cables of any length, but the shorter the better (the exception is adequate length to comfortably reach between devices). One option is to cable the client workstation so that you can easily use Remote Desktop Protocol to reach it and perform any wireless configuration on the client adapter without locking yourself out of the device.

• Design (Cisco Certified Design Associate, or CCDA): Principles for optimal design of WAN, LAN, and other network methodologies
• Unified Communications (CCNA Voice): Introduction to the Cisco Voice suite of products, including Cisco Unified Communications Manager Express (CUCME), Cisco Unified Communications Manager (CUCM), Voice Messaging (Unity Connection), and related items
• 802.11 Wireless (CCNA Wireless):  Introduction to 802.11 wireless technologies and the Cisco Unified Wireless suite of products
• Network Security (CCNA Security): Introduction to security threats and mitigation techniques for Cisco networks

Each technology area has its own unique rewards, challenges, and concepts to master in order to gain the necessary professional skill sets. Having constructed a CCNA Wireless level lab environment myself, I want to cover that topic in this series of posts. Using the previous process outline, there are two primary phases to creating a lab for study purposes. The first is design and the second is the physical assembly of the components.

Phase I: Design

Since our focus this time around is the CCNA Wireless, as always the exam blueprint will be the most helpful in constructing the most optimal technical environment. If you ever need to reference any of the exam blueprints, start at http://www.cisco.com/go/certifications. For our purposes, we’ll examine the contents of the CCNA Wireless (640–721), blueprint as follows:

• Cisco Wireless LANs
  • Autonomous Access Point (AP)
  • Lightweight Access Point (AP)
  • Wireless Clients
  • Operating the Wireless Control System (WCS)
  • Wireless LAN Maintenance/Troubleshooting

Several essential items should be in any CCNA Wireless lab, including one autonomous (standalone) access point, one or more lightweight access points, a wireless LAN controller, and a workstation to install WCS on. If need be, there are very inexpensive older AP’s that can fill the role; newer ones are ideal but not required. This also brings up power requirements. Some older PoE switches may be ideal, but worst case you can get away with external power supplies. Having at least one test workstation is a good idea, as well as one client laptop or desktop device.  Translating this into more specific requirements, the equipment list (much of which can be found on eBay) could look something like this:

• 1 2106 Wireless LAN Controller (prices around $600–800)
• 1 Autonomous/IOS Based Access Point
  • Cisco 1141/1142N (prices around $200–400)
  • Cisco 1200 Series (prices around $30–40)
• 1–2 Lightweight Access Points
  • Cisco 1141/1142N (prices  around $200–400)
  • Cisco 1200 Series (prices around $30–40)
• 1 ASA-5505 (optional, for access)
• WCS is available on Cisco.com for a 30 day trial license.  You can actually install it on a Windows XP workstation with a special trick (will explain under the next section).
• Cisco 3524-XL-EN PoE Switch (prices around $50–60)

In the next post we’ll build our CCNA wireless lab.

Hotspot 2.0 and the Next Generation Hotspot initiatives are possibly the most exciting areas of wireless progress occurring in 2012. For starters, these developments have a worldwide scope of influence. The technologies that come to market as a result of these programs will directly affect a large portion of the world’s population. If brought to market with extensibility, they could revolutionize the hotspot ease-of-use and security landscapes. These programs deserve the spotlight.

The Initiatives

Hotspot 2.0 and Next Generation Hotspot (NGH) are highly complementary initiatives, but they are different in scope. Hotspot 2.0 is the Wi-Fi Alliance’s certification program that will include a technical specification defining the Hotspot 2.0 technology. Following the Wi-Fi Alliance’s core purpose, Hotspot 2.0 will also be a device certification, based on product interoperability testing, that allows vendors to implement the protocols in a common way.

Hotspot 2.0 is designed for Wi-Fi clients and infrastructure devices to support seamless connectivity to Wi-Fi networks. The specification is still a document in progress, but as a non-Wi-Fi Alliance member, I have a little bit of insight about what we can expect. The first thing to understand about the specification is that the Wi-Fi Alliance is not attempting to define all new technologies. The Hotspot 2.0 effort is a bit more like putting together the pieces of a fragmented puzzle.

For example, the spec will draw largely (and selectively) from 802.11u, which enhances network discovery and selection by Wi-Fi clients. 802.11u provides all the protocol-level “hooks” for infrastructure vendors (the WLAN controller and APs) to interwork with backend services (like hub AAA proxy servers and operator AAA servers and user databases). Perhaps more important than the backend integration and querying, 802.11u also provides the protocols and frame components that allow the clients to learn about the backend services on the network. The client can learn what service providers or roaming partner agreements are available through the BSS, what the hotspot service model is like, and the client can even query the backend services for other information. This level of backend transparency facilitates the seamless client selection and connectivity process.

In addition to 802.11u, Hotspot 2.0 will draw on the familiar 802.1X/EAP architecture we use in Wi-Fi today. Four EAP types are in the existing spec: EAP-SIM, –AKA, –TLS, and –TTLS. Obviously, the cellular convergence focus comes in with EAP-SIM and AKA. 802.1X is also incorporated for user authentication, but the backend components will vary from one network to another. In most cases, the WLAN infrastructure (APs and/or WLC) will integrate with a “hub” AAA proxy server that interfaces directly with each operator’s AAA server. Or the WLAN may interface directly with AAA servers belonging to the network operator as well as a AAA proxy for other operators in a roaming agreement. This is where the business complexity gets interesting and also where the Wireless Broadband Alliance’s (WBA) work with Next Generation Hotspot (NGH) picks up.

The Wi-Fi Alliance’s Hotspot 2.0 is primarily focused on Wi-Fi device interoperability and testing (i.e. clients and APs), but the WBA’s mission is targeted at the whole scope of functionality and interoperability, including interoperability between network operators and service providers on the backend. In 2011, the WBA conducted NGH trials, which are real-world functionality tests using equipment from the participating vendors. Wi-Fi client and infrastructure participants were required to first pass the Wi-Fi Alliance’s Hotspot 2.0 test events. In the NGH trials, the approved Hotspot 2.0 devices were tested with the various backend systems and architectures. NGH trials included testing for different authentication setups, including direct authentication with the owner operator (e.g. AT&T SIM on an AT&T network), authentication through third-party hubs (e.g. using Syniverse or others as a AAA proxy to an operator’s servers), and through visited network operators (e.g. AT&T SIM on an Orange network).

Based on the results of the NGH trials, the WBA is creating recommendations to bring these operator and service provider technologies to market in a consistent and interoperable way.

In a typical client connection to a wired Ethernet port, the client will be a member of a VLAN based on the switch port configuration. When the client connects, it does the usual DHCP exchange by sending a broadcast DHCP discovery frame to find a DHCP server. If there’s a DHCP server on the local Layer 2 domain, it will reply and everyone will be happy. However, if the DHCP server is not on the local subnet, a router must be configured to forward the DHCP discovery. Typically, this is accomplished by configuring an IP Helper Address on the router, which is just a way of telling the router to relay certain broadcast UDP frames (like DHCP) to a specific IP destination. In the case of DHCP, the router will forward the DHCP discovery and request as unicast frames to one or more pre-configured DHCP servers.

However, the router does something interesting. Remember that the original client doesn’t yet have an IP address, so there is no source IP address in the DHCP discovery. When a router forwards the frame across the IP network, the router must include a relay IP address so that the DHCP server can send the DHCP offer back to the proper relay device. For this, the router uses the interface (or subinterface) IP address that matches the client’s VLAN.

For wireless clients, when you understand the above process, DHCP is not terribly complex. There are a few more potential gotchas on the wireless segment, though. A few reasons why Wi-Fi DHCP is a little different follow:

1. An AP’s radio interface performs different functions than an access (non-trunked) port on a switch
   1. A single radio interface is expected to allow multiple clients at the same time
   2. The radio interface may support multiple service sets with different parameters and functions
   3. Clients associated to an interface may be in different VLANs
2. The AP may be connected to its uplink switch via a trunk (with multiple VLANs) or an access port (with only a single VLAN) and may forward data directly to its source or tunnel the data to a WLAN controller for forwarding
3. Clients move

So the first goal for the infrastructure is to determine which VLAN a wireless client belongs in. The most common method is to statically map an SSID with a VLAN. Once the client associates to the SSID, it is automatically placed in that SSID’s VLAN. The other method—more flexible, but less common— is to implement 802.1X user-based policies in which the client is assigned to a VLAN dynamically based on RADIUS attributes sent during 802.1X authentication. Regardless of the method, after the authentication is complete, the infrastructure (WLAN controller and/or AP) can map the client with a VLAN and IP subnet. Of course, the client doesn’t know which subnet it belongs in.

When the client initiates a DHCP exchange, the WLAN infrastructure can handle it in a few ways.

DHCP Bridging

DHCP bridging is somewhat self-explanatory in that the WLAN infrastructure simply “bridges” the DHCP frames to the wired network without modifying them. Neither the WLAN controller nor AP changes the DHCP frames in any way. In this configuration, the upstream wired network remains responsible for handling DHCP exchanges, as described previously for wired clients. This is the expected behavior for a WLAN infrastructure that does not support the proxy or relay DHCP features described later

Below is an overly simplified network diagram in which the DHCP server is in a different IP subnet than the client.

With DHCP bridging, the client’s DHCP discovery and request frames would be passed to the upstream network, in this case, the first router (connected via a red link for illustration). The router would then act as a DHCP relay agent, forwarding/routing the DHCP discovery and request to the DHCP server. A frame decode of this is shown below, captured from the red link prior to the router’s modification.

DHCP Relay

At the beginning of this article, we described the DHCP exchange for a wired client. When a DHCP discovery or request hits an IP subnet boundary, a router must be configured with an IP Helper address pointing to a DHCP server. Wi-Fi segments can accomplish the same basic task by turning the AP or WLAN controller into the relay agent.

Vendors usually call this DHCP Relay. Either the AP or the WLAN controller (depending on the data forwarding plane) receives the DHCP discovery/request and forwards the frame to the DHCP server(s), adding its own IP address as the relay.

The key configuration requirement for DHCP Relay is that the WLAN controller or AP must have an interface with a corresponding IP address in each of its clients VLANs—and potential clients’ VLANs. The WLAN infrastructure uses the corresponding interface and IP address as the relay agent IP address for the DHCP discovery and request frames. By using the client’s VLAN/subnet as the relay agent IP, the DHCP server knows to provide an IP address in the correct client subnet.

A frame decode of DHCP Relay is shown below. This frame was also captured from the red link between the wireless infrastructure and the router. The WLC/AP has changed the destination from broadcast to unicast (the DHCP server’s IP address) and has placed its own client-side IP address as the relay agent IP address.

DHCP Proxy

DHCP Proxy is similar to DHCP Relay in its basic function, but it goes a step further. Instead of merely forwarding the frames back and forth, the DHCP Proxy takes a more active role by inserting itself as a DHCP server to the client device. When the client sends the DHCP discovery and request frames, the WLAN infrastructure alters (or rebuilds) the frames and unicasts them to the DHCP server. After receiving the offer from the DHCP server, the WLAN infrastructure sends a DHCP offer to the client, presenting itself as the DHCP server. The WLAN infrastructure maintains a table of client MAC to IP mappings, drawing on this information to add security and performance functionality to the WLAN (I’ll explain in a minute).

If we were to look at a frame trace of DHCP proxy on the wired side as we did in the previous DHCP bridging and DHCP relay traces, DHCP proxy would look the same as DHCP relay. Below is a frame trace of DHCP proxy on the Wi-Fi interface. This frame is the DHCP offer sent to the Wi-Fi client. The WLAN infrastructure offers the IP address to the client, using its own IP address as the DHCP server. For this, the WLAN infrastructure is configured with a virtual IP address (it was common practice to use 1.1.1.1 in Cisco WLANs, but now recommended that an unused private address be used instead), which is the “DHCP server” IP address shown to the client. You’ll see here that the client is offered 10.10.50.4/24 from 1.1.1.1.

There are three primary benefits to DHCP Proxy:

1. By converting a broadcast frame to unicast at the frame’s entry point on the wired network (other than in a tunnel to the WLAN controller, which is also unicast), the DHCP relay and proxy features both eliminate wireless broadcast DHCP traffic on the LAN.
2. We mentioned earlier that the WLAN infrastructure maintains a client MAC/IP table, and this table enables the infrastructure to apply security policies between the wired and wireless segments. Specifically, participation in the DHCP process prevents unauthorized DHCP traffic between wireless and wired segments, it allows the WLAN to prevent IP and ARP spoofing as well as rogue DHCP servers, and it protects against other DoS attacks.
3. DHCP proxy also improves roaming performance. When a client roams between Layer 3 boundaries, it recognizes the need to request a new IP address. By sharing the virtual IP address (e.g. 1.1.1.1) across a mobility domain (i.e. in Cisco speak), the WLAN infrastructure can easily and efficiently renew the client’s IP address without the back-and-forth with the real DHCP server. The added efficiency and IP renewal may prevent a disruption to applications that require a continuous session.

Impact of the Data Plane

When it comes to WLAN architectures with DHCP features, the device that relays or proxies the DHCP frames will either be the AP or the WLAN controller. Regardless of the forwarding model, the device(s) that is responsible for DHCP relay or proxy features must be configured with interfaces on each client VLAN/subnet. If data is forwarded through the WLAN controller (i.e. centralized), it makes sense that the WLAN controller would be handling DHCP features. In distributed forwarding models, network design plans should account for more IP address consumption because each AP will need an IP address for each supported client subnet. When large numbers of APs serve each client VLAN, IP address consumption becomes excessive and the DHCP Bridging model is a better design choice than DHCP proxy/relay. To date, only one vendor supports DHCP relay in a distributed fashion.

Final Comments and Suggestions (FCS)

DHCP is not always  first on the list of hot topics for wireless design priorities. No less, poor DHCP planning for your network could have a significant impact on WLAN service availability. For that reason, and for troubleshooting problems that will inevitably arise, any WLAN engineer should know the three primary ways to manage DHCP in a WLAN: bridging, relay, and proxy. We spend a lot of time and energy improving our RF environments; it would be a real shame to let DHCP ruin client connectivity.

Reposted with permission from CWNP.com