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.
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.
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.
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.
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.
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 interface 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
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.
