CCNA Wireless Official Exam Certification Guide part 25 potx

Roaming Client Controller1 CP_Mobile Figure 12-4 Client Roaming in the Same Mobility Group Figure 12-5 shows a client transmitting data and moving from AP2 to AP3.. 10.10.0.107/24 Guest_

Figure 12-3 Edit All Page

controller you want to add Then you paste the contents of the text file into the Edit All page In Figure 12-3, two controllers are listed on the Edit All page You can have up to 24 controllers in a mobility group

So what happens if a user moves to another mobility domain? Because a controller in a different mobility domain does not have information about the client, the client must reassociate When the client reassociates, it will most likely get a new IP address, and any sessions it currently has will need to be restarted

So now you understand the part that controllers play in roaming In truth, they play an even bigger part, depending on the type of roaming that is happening Cisco controllers can support a Layer 2 or Layer 3 roaming process, as detailed in the following sections

Types of Roaming

Before we dive into roaming as a Layer 2 or 3 process, let’s define it Roaming is the move-ment of a client from one AP to another while still transmitting Roaming can be done across different mobility groups, but must remain inside the same mobility domain Con-sider the following examples

Figure 12-4 shows a client transmitting data and moving from AP1 to AP2 These two APs are in the same mobility domain This is roaming

Roaming Client

Controller1

CP_Mobile

Figure 12-4 Client Roaming in the Same Mobility Group

Figure 12-5 shows a client transmitting data and moving from AP2 to AP3 These two APs are in different mobility groups but are in the same mobility domain This too is roaming

Now here is where roaming breaks In Figure 12-6, a user is transmitting data and decides

to go work at a local coffee shop that offers wireless network access After buying a $5 cup of coffee and settling down into a cushy sofa, he fires up his laptop and continues surfing the net This is not roaming In this case, the user has a new IP address, and any

sessions that were active before need to be restarted

The following must occur for your controllers to support roaming:

■ The controllers need to be in the same mobility domain

■ The controllers need to run the same code version

■ The controllers need to operate in the same LWAPP mode

■ Access control lists (ACL) in the network need to be the same

■ The SSID (WLAN) needs to be the same

Let’s return to Layer 2 versus Layer 3 roaming Here is the simple explanation Layer 2 roaming happens when the user roams to a different AP and keeps his existing IP address

Layer 3 roaming occurs when a client leaves an AP on one subnet and associates with an-other AP on a different subnet, but using the same SSID

The following section takes a closer look at the Layer 2 roaming process

Key Topic

Key Topic

Roaming Client

AP2

Controller1

AP3 Controller2

Mobility_Domain_1

Wired Network

Figure 12-5 Client Roaming in the Same Mobility Domain

DSL Connection

Home_AP

Not Roaming!

Coffee Shop Free Wi-Fi

Figure 12-6 Client Not Roaming

Key

Topic

10.10.0.107/24 Guest_Access

10.10.0.0/24 VLAN 5 Guest_Access

Roaming Client

Guest_Access Guest_Access

Controller1

Figure 12-7 Intracontroller Roaming

The Layer 2 Roaming Process

As previously discussed, Layer 2 roaming happens when a user moves to another AP but stays on the same VLAN and the same IP subnet As far as the user is concerned, nothing special has happened The client isn’t notified that he is roaming He also keeps his IP ad-dress, and all active transmissions stay active This process is handled within a single con-troller This process is called intracontroller roaming and takes less than 10 ms Behind

the scenes, the client, when roaming to a new AP, sends a query to request authentication

The query is sent from the AP to the controller, where the controller realizes that the client

is already authenticated, just via another AP The client is then registered as roaming in the controller, although you do not see this in the controller or in the WCS, and life goes on

Figure 12-7 depicts this scenario

Now take that same scenario and add another controller, as shown in Figure 12-8 Here, the client associated with Controller1 is on VLAN10 Upon roaming to AP3, which is managed by Controller2, the connection stays active What happened? In this situation,

intercontroller roaming happened This occurs when a user roams from one controller to

another but remains on the same VLAN and does not have to perform a DHCP process again, which would force the session to break The two controllers are configured with the same mobility group The two controllers then exchange mobility messages Using mobil-ity messages, the client database entry on Controller1 is moved to Controller2 This hap-pens in less than 20 ms Again, the process is transparent to the user He roams, data keeps flowing, sessions stay active, and life is good

Key Topic

Both intracontroller roaming and intercontroller roaming allow the user to roam and re-main on the same IP subnet This is Layer 2 roaming Now let’s explore Layer 3 roaming

The Layer 3 Roaming Process

As with Layer 2 roaming, the goal of Layer 3 roaming is for a client to roam transparently The difference is that you are working with multiple controllers on different subnets The catch is that although the controllers are on different subnets, the user does not change IP addresses Instead, the controllers tunnel the traffic back to the original controller So it’s a smoke-and-mirrors configuration You are literally making the network believe that the user hasn’t roamed The two tunneling methods are as follows:

■ Asymmetric tunneling:In asymmetric tunneling, traffic from the client is routed to the destination, regardless of its source address, and the return traffic is sent to its original controller, called an anchor, and is tunneled to the new controller.

■ Symmetric tunneling:In symmetric tunneling, all traffic is tunneled from the client

to the anchor controller, sent to the destination, returned to the anchor controller, and then tunneled back to the client via the foreign controller

The following sections discuss these two types of tunneling in more detail

Asymmetric Tunneling When a client roams in an intercontroller roam, the database entry moves to the new con-troller That’s not the case with Layer 3 roaming In the case of Layer 3 roaming, the client’s entry in the original controller is marked as an anchor entry Then the database en-try is not moved; instead, it is copied to the foreign controller On the foreign controller, the entry is marked “Foreign.” The client is then reauthenticated, the entry is updated in the new AP, and the client is good to go The client’s IP address doesn’t change All this is transparent to the user Figure 12-9 depicts this process

“Internal”

Roaming Client

“Internal”

VLAN_10

“Internal”

“Internal”

AP3 AP2

Figure 12-8 Intercontroller Roaming

Key

Topic

Local Controller

Foreign Controller

Client 1 Roaming

10.10.0.227/24

10.10.0.0/24 10.20.0.0/24 Client DB

(Anchor) Client 1

Client DB Client 1 (Foreign)

Figure 12-9 Layer 3 Roaming

Normally when a client sends traffic, it is sent to a default gateway, assuming that it is leav-ing the subnet, and then on to the destination The traffic makes its way back to the client, taking the reverse path that it traveled to get there This means that if Controller1 sends traffic to Router1 and then to Server1, Server1 returns the traffic via Router1 and then Controller1, as shown in Figure 12-10

After the client roams to a new controller and a new AP, the return traffic is not delivered

to the correct controller So the anchor controller sees that the return traffic is for a client with an entry marked anchor and knows that it needs to tunnel it to the foreign controller

The foreign controller, upon receiving the packet, forwards it to the client, and all is well

This is how asymmetric tunneling works

However, this configuration has some problems Today’s networks are taking more and more security precautions; one of these precautions is Reverse Path Filtering (RPF), a function used by routers The router examines all packets received as input on that inter-face to make sure that the source address and source interinter-face appear in the routing table and match the interface on which the packet was received Also, following RFC 3837 and some other antispoofing ACL recommendations, the source address would not match what is expected to be seen, and it would be dropped So what do you do when this hap-pens? The answer is symmetric tunneling

Symmetric Tunneling

In general, when a client sends a packet for Server1, much like what is shown in Figure

12-10, the following occurs:

The foreign controller tunnels the packet to the anchor controller rather than forwarding

it Then the anchor controller forwards the packet to Server1 Server1 replies, sending the traffic back to the anchor controller The anchor controller tunnels it back to the foreign

Controller1 Controller2

Client 1

10.10.0.227 = IP 10.10.0.1 = Gateway

Router1 10.10.0.0/24

Server1

Return Traffic Original

Traffic

Figure 12-10 Original Traffic Flow

controller The foreign controller delivers the packet back to the client If the client roams

to another foreign controller, the database is moved to the new foreign controller, but the anchor controller does not change

Configuring Tunneling

To begin the tunneling configuration, first you must decide which type of tunneling you will do The default mode is asymmetric, and the controllers must match in their

configu-ration Select CONTROLLER > Mobility Management > Mobility Anchor Config.

Figure 12-11 shows the resulting configuration page

This configuration page enables you to configure a Keep Alive Count and Keep Alive In-terval There also is a checkbox for symmetric mobility tunneling mode, which is not en-abled by default The Keep Alive Count is the number of times a ping request is sent to an anchor controller before the anchor is considered unreachable The default value is 3 The Keep Alive Interval is the amount of time (in seconds—the default is 10) between each ping request sent to an anchor controller

Mobility Anchors With mobility anchors, also called guest tunneling or auto anchor mobility, all the client traffic that belongs to a WLAN (especially the Guest WLAN) is tunneled to a predefined WLC or set of controllers that are configured as an anchor for that specific WLAN This feature helps restrict clients to a specific subnet and have more control over the user

Figure 12-11 Mobility Anchor Configuration

traffic Normally what happens is that a client anchors to the first controller it associates through But what if you want clients anchored to a controller on a DMZ interface of a firewall? Using a mobility anchor forces clients to be anchored to a controller other than the one they first associate with This forces their traffic to be tunneled to the DMZ Then

it must pass through the firewall and its associated policies before getting anywhere This

is done on a per-WLAN basis

Note: The protocol used for tunneling is known as EoIP It’s beyond the scope of the CCNA Wireless exam, but you can find more information in RFC 3439

You should configure the same mobility anchors for a WLAN If a client associates with a WLAN in which the local controller is the mobility anchor, the client is anchored locally

The whole mobility anchor concept might seem strange at first, but think of it as roaming ahead of time That’s basically what it is As soon as the client associates to a WLAN, it is known to be anchored somewhere else, and a tunnel is set up This means that the foreign controller sets up the tunnel before the client has an IP address So the foreign controller doesn’t have any knowledge of the client’s IP address This tunnel is the same type of tun-nel that is created when Layer 3 roaming occurs between controllers

To configure a controller to act as mobility anchor, follow these steps:

Figure 12-12 Selecting a Mobility Anchor

Step 1 Click WLANs to open the WLANs page.

Step 2. Click the blue down arrow for the desired WLAN or wired guest LAN, and

choose Mobility Anchors, as shown in Figure 12-12.

Note: On a WiSM running controller code 4.1.185.0, you do not click the blue down ar-row; you just hover the mouse pointer over it

Step 3. Select the IP address of the controller to be designated a mobility anchor in

the Switch IP Address (Anchor) drop-down box

Step 4 Click Mobility Anchor Create The selected controller becomes an anchor for

this WLAN or wired guest LAN

Step 5 Click Save Configuration to save your changes.

Step 6. Repeat this process for any other mobility anchors you want to designate for

this WLAN

Step 7. Repeat this process on every controller where this WLAN exists.

Table 12-2 Key Topics for Chapter 12

Figure 12-4 A client roaming in the same mobility group 213

Figure 12-5 A client roaming in the same mobility domain 214

List from the section

“Types of Roaming”

Requirements for controllers to support roam-ing

213

Exam Preparation Tasks Review All the Key Topics

Review the most important topics from this chapter, denoted with the Key Topic icon

Table 12-2 lists these key topics and the page number where each one can be found

Definition of Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

mobility group, mobility domain, roaming, intracontroller roaming, intercontroller roam-ing, asymmetric tunnelroam-ing, symmetric tunnelroam-ing, anchor, mobility anchor