Inter-WLC Roaming

[a12288]

On WiSM-A, I have client associate with AP-A and WiSM-A local WLAN is 192.168.A.0, then as I roam to WiSM-B while the local WLAN is 192.168.B.0, and I can maintain my original IP but WiSM-B has no knowledge about 192.168.A.0, I don't know how WiSM-B do the routing / switch? I did capture the traffic but seems like Ethereal can not decode LWAPP very well, any comments are welcome.

[Stephen Rodriguez]

The way this works, is you would have mobility groups built between the two sides of the WiSM. This allows the client to roam to the "foreign" controller, and maintain it's address. When the client roams over, there is a mobility tunnel that is built between the two, and all the traffic that has a destination of the client is relayed through tunnel, and all traffic from the client is sent out through the side it is connected to.

http://www.cisco.com/en/US/products/ps6366/products_configuration_guide_chapter09186a00806b0755.html

this link goes into more detail about mobility groups and how they function in the WLC world.

[a12288]

the inter-WLC / VLAN roaming works in our environment, but just can not figure out how does 2nd foreign WLC route the roaming client outgoing traffic, I can understand the roaming client return traffic which would be over the L2 Tunnel, but for the outgoing traffic, since the roaming client is on VLAN-X and 2nd foreign WLC konws VLAN-Y only, how could a wirewall client in VLAN-X send traffic onver VLAN-Y? what the frame looks like and who would answer APR query for VLAN-X's default gateway, still confusing. our newly setup WiSM work in Inter-WLC scenario, but do not know where to start if it does not work somedays. thanks.

[jakew]

L3 roaming traffic follows an asymmetric route path. When a client sends a frame, WiSM 2 will bridge the frame onto the VLAN corresponding to the client's WLAN. A packet destined for the client will be delivered to WiSM1, which will encapsulate it in an EtherIP tunnel and forward it to WiSM2. WiSM 2 then delivers the packet to the client via LWAPP.

The key thing is that the packet that travels between the controllers is not LWAPP. Ethereal should understand EtherIP.

[MARK HEUZENROEDER]

The version of Ethereal I use,

0.99.0

does a jolly good job of parsing LWAPP.

We got some captures from a simply-old switch SPAN.

I can't help with the basic problem, though.

Regards, MH