!! Warning !! Guest anchor mobility fails in 5.0.48, Single Foreign

struttob · ‎03-19-2008

Finally some 5.0 chat showing up so I'll add this nugget. All controllers migrated from 4.2 to 5.0.48. All site (foreign) controllers = MOBGRP-CORP, anchor controller in central dmz = MOBGRP-DMZ..

Found that my first site where I implemented Guest via anchor mobility worked ok. Tried to bring up 2 new sites with their own foreign controller against same (working) anchor. NO GO. All debugs & shows indicate mobgroup, mobgroup anchor, etc all good. Debugs reveal mobility anchoring messages never being initated by foreign to anchor.

Reviewed with TAC for 3 hours last night. Finally found a bugID that related against 5.0.48.

Bottom line is that our site that was working had 2 foreign controllers. Site that wouldn't come up only had 1 foreign. Weird bug that if site has only 1 mobility member (beside anchor definition) then mob anchor plumbing messages won't exchange from foreign to anchor. Instead, debugs show foreign as anchor. Workaround = move anchor controller into same mobility group as the internal (foreign) controllers. All good now.

Hope this helps someone avoid 3 hrs w/ TAC. (And I felt I had a GOOD tac guy).

Now if I could just figure out how to have multiple profile/wlan definitions on anchor controller but have the same ssid on them all so that our guest ssid @ sites can be uniform. Currently won't let me define multiple wlans on anchor with same ssid, even if profile name is unique. Guess despite it not running APs it's still checking wlans for uniqueness. Not very 'enterprise' as we want to have each site a) Have standard guest ssid and b) Have their own IP address space for firewall log purposes, etc. A & B seemingly mutually exclusive in current situation, assuming central anchor controllers of course.

struttob · ‎03-20-2008

Well I guess now I need to follow up on my own post. After moving dmz anchor controller into "internal' mobility group, we ran into some weird issues.

1) New APs at the site we were bringing on were somehow getting joined up to another site's controller. Only thing in common between sites was mobgrp name and the fact that they both anchored guest to the same central anchor controller.

2) At the new site, guest seemed to work OK now but we were experiencing problems with hosts on one of the controllers internal wlans. They were not getting IPs. Debugs revealed that foreign (site) controller was bringing up guest tunnel to itself for this local, non-anchored wlan.

Opened another tac case. This tac engineer advises that while bug CSCsm71840 exists, the other engineer should not have told us the workaround was to put dmz anchor controller into internal mobility group. Rather, he advised, we should go into any controller (on dmz anchor end or internal foreign end) where there was only 1 controller in the mobility group and add a 'dummy' entry into the mobility group.

We changed the dmz anchor back to his own mobility group and then made the dummy entries and the mobility anchor worked correctly & so far appears that previously problematic internal wlan also works correctly.

This whole thing should make for some 'interesting' conversation with the BU shortly.

dennischolmes · ‎03-20-2008

Sorry you guys had to be among the first christians fed to the lions my friend. Keep us posted as to your efforts. I have sworn my customers off of 5x code until it is bug free.

pmccubbin · ‎07-07-2008

Dennis,

Thank you. I was getting ready to walk a customer into the lion's den with 5.x code until I read your very educated opinion. I tend to trust the "Nerd Herd" (as Rob Huffman's wife would say) more than the marketing from our pals at Cisco. You rate a "5" from your avid reader in New York City.

I'm sure Cisco will get it right because they always do, but I can wait. Please let the forum know when you believe the code is relatively bug free.

Cheers!

Paul

brian.kachel · ‎07-07-2008

Ahh - someone else with the need to creating multiple profiles, with the same SSID on the anchor guest controller.

At least, I've learned - you can have unique profile names at your local site controllers - the profile names don't have to match.

And - also confirmed that even having one big subnet for the guest lan, the broadcasts are stopped at each local sited WLC so no worries on the sizing of the guest net across an enterprise.

But as you say - would be nice to have indidual profiles on the anchor.

armonk_netdesk · ‎07-07-2008

This sounds eerily similar to the AUTO-ANCHOR bug I came across in 5.148. Even though auto-anchor is disabled in the GUI - when you do a "show wlan" in the CLI it will say auto-anchor is enabled. This had me going berzerk for weeks until I found the issue. The symptom sounds similar to yours - traffic gets to foreign AP and then vanishes into EOIP tunnel - never to be seen again! FUN!!!

dennischolmes · ‎07-07-2008

LOL track that down with your lil packet sniffer. HEHEHEHEHEHE