The input to the hash should just be the client MAC address. But this should not come into play on a roam. Here is a snippet from a VLAN select article that can be found at http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080b78900.shtml .
*Same Subnet Mobility*—In the current solution, when a client roams from one Controller to another, the foreign sends the VLAN information as part of the mobility Announce message. Based on the VLAN information received, the Anchor decides whether the tunnel should be created between the Anchor and Foreign. If the same VLAN is available on the Foreign, then the client context is completely deleted from the Anchor and the Foreign becomes the new Anchor Controller for the client. As part of the VLAN Pooling feature, the Mobility Announce message carries an additional vendor payload that contains the list of VLAN Interfaces mapped to a WLAN. This helps the Anchor to decide on Local > Local type of handoff. It is ensured that the inter-release mobility does not get affected because of the introduction of this feature. In a guest tunneling scenario, clients joining on “export foreign” receive the IP from the interface group mapped to the WLAN on “export anchor”, or as per the foreign mappings configured on “export anchor”. If the clients who have joined over “export foreign” move to the “export anchor” controller, they might lose their IP address which means mobility is not supported between those two. However, if the clients move between two “export foreign” controllers, they retain their IP address which means roaming is supported in that scenario. So as long as the controllers are configured properly for smooth roaming (mobility group membership and virtual interfaces), it should be a clean layer 2 roam with the clients retaining their VLAN assignment. The WLAN index does not need to be the same across controllers for smooth roaming. Regards, Jeff Rensink : Sr Instructor : iPexpert <http://www.ipexpert.com/> CCIE # 24834 :: Wireless / R&S :: World-Class Cisco Certification Training Direct: +1.810.326.1444 :: Free Videos <http://www.youtube.com/ipexpertinc> :: Free Training / Product Offerings <http://www.facebook.com/ipexpert> :: CCIE Blog <http://blog.ipexpert.com/> :: Twitter <http://www.twitter.com/ipexpert> On Wed, Jan 8, 2014 at 9:39 AM, Andre Aubet <[email protected]> wrote: > Hi Team, > > I have to work to troubleshoot for one of ourcustomer, and this is an > architecture combining : > > - interface group (vlan select) > - L2/L3 inter-controller roaming > > As this topic is really interesting, I thought i could share it with you :) > > In this case, the customer is complaining about random disconnection > issues for a large number of clients. A client can be disconnected up to > one or twice an hour. > > There is mainly one WLAN having this issue, with the following > configuration > > - WLAN configured on two different controllers (WLC1 and WLC2) > - interface-group containing 3 interfaces (3 x /23) > - L2 Security = WPA2/802.1x (PEAP) > > For each interface in the interface group, a scope is configured in > different subnets. The customer also told me that a same client could have > an active lease in each scope on the dhcp server. > This doesn't make sense, because controllers are running code 7.4.110.0. > In this version, vlan select was developed for the clients to be always > mapped on the same interface (unless interface is dirty). This mapping is > based on the client mac address, using a MD5 hash algorithm. > > Regarding this algorithm, does anybody know if the client MAC address is > the only value used as an input in the hash? As the clients are dispatched > between two controllers, maybe the output is different if the algorithm > uses the WLC SN for example. > > The Access Point have been installed in a Salt and Pepper configuration. > So mobility roaming between controllers will often occur. > > I'll start a troubleshoot session tomorrow, and try to fix the problem. > I've already planned to avoid the client disconnections by modifying the > session timeout + client user idle timeout for this wlan. > > I received the WLCs run-config, and I can already identify differences > between the WLAN configured on each controller. Differences are as follow: > > - WLAN Index > - WLC1 : ID = 2 > - WLC2 : ID = 5 > - DHCP Required > - WLC1 = true > - WLC2 = false > - Scan Defer > - WLC1 = 4,5,6 > - WLC2 = 5,6 > > With mobility handoff, for L2 roaming inter-controller to occur, I know > the WLAN configuration across controllers must be identical. I'll fix the > DHCP Req and Scan Defer differences tomorrow, but I don't know if the WLAN > index must match too. > > If this is the case, I'll have to remove/recreate the entire wlan > configuration on the controller. > > I'll let you know the results of my test tomorrow. > > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc >
_______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
