Console to the controller

debug mac addr <mac addr of the AP>
debug lwapp events enable
debug lwapp errors enable

Console to AP 



Todd Joyce
Network Services
Radford University - The Smart Choice
[EMAIL PROTECTED]
(540) 831-7777
 
Keep your boots and ChapStick and ice hotels.
Give me shorts and sandals and a thirty-blocker.

Temperance Brennan - Monday Mourning

-----Original Message-----
From: Lee Badman [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 20, 2006 9:41 AM
To: [email protected]
Subject: Re: [WIRELESS-LAN] Cisco LWAPP

Todd-

Good info (thanks to the others responding as well). On the scripting,
I'm sure we could do it as well, but for the cost of the LWAPP
environment, I'd like to see Cisco step up and develop what should have
been there anyways.

One question- you said you'd bring APs back to the shop to tell what's
going on with them- did you find any meaningful commands to tell what
the AP is trying to do beyond watching a stream of cryptic logs?
According to Cisco TAC, nothing of value can be seen from the AP for
debug.

Thanks-

Lee

>>> [EMAIL PROTECTED] 9/20/2006 9:02:42 AM >>>
I will take a stab at some of these...  I hope some of this will help. 
A little
background on our network.  We upgraded about 300 older APs to LWAPP. 
We
upgraded the following AP models: 1121, 1131, 1231 (a couple of
variations of this one).  We are using WiSM (Wireless Services Module)
based 4404 controllers.
This provides two controllers on a blade in our 6509 switches and each
controller can handle 150 APs.  We currently have three of these blades
and another one on order.  We have about 450 APs online now with
hundreds more planned.  Answers below...

On Tue, 19 Sep 2006, Lee Badman wrote:

> Date: Tue, 19 Sep 2006 19:53:09 -0400
> From: Lee Badman <[EMAIL PROTECTED]>
> Reply-To: 802.11 wireless issues listserv
>     <[email protected]>
> To: [email protected]
> Subject: [WIRELESS-LAN] Cisco LWAPP
>
> Now that we are into a Cisco LWAPP conversion/rollout, wondering if 
> anyone else has found these issues to be obstacles to 
> deployment/support, or if in the grand scheme you've found them to
be
> non-issues:
>
> 1. Can't schedule configuration jobs- is no scheduling provision
from
> WCS

We have reported this to Cisco as a feature request.

> 2. No master view from WCS of all controllers configurations to
compare
> for uniformity of config

We are addressing this internally.  We have written scripts to query
various configurations via snmp and insert the data into a mysql
database.  We can then generate reports of potential problems.

> 3. No wild card searches for clients or APs when searching in WCS

You can use % as a wildcard for your searches.  It is still not great,
but it helps.  We have written our own code to help with this too.

> 4. AP radios come up in transmit, before proper vlan is assigned to
> them- meaning that clients might associate to a non-functional cell 
> (meaning there might be confusion and help-desk calls)

We never noticed this one.

> 5. No view of the Ethernet port on the AP from the WCS or
controller,
> which means you can't tell if it negotiated speed or duplex
correctly

We have never needed this.  We can always look at the switch port to get
this data.

> 6. ACLs in the WCS have to be built line by line, no copy and edit
or
> text file input
> 7. MAC address searches have to be colon delimited

Correct, AND they are also case sensitive which we found thanks to a cut
and paste search for a rogue AP.

> 8. Mispellings in the WCS GUI, usually on error popups 9. Difficult 
> debugging, like from an AP you have no knowledge of
what
> controller it associated to or tried to associate to

If an AP is currently associated with a controller, the controller IP
address is shown in WCS if you search pull up a list of APs.  I suspect
you are talking about APs that don't connect successfully.  Early in our
migration, we just brought those back to the office and got on the
console and watched to see what was happening.  This was very helpful.

> 10. No view from the AP or WCS on what switch and port the AP is on 
> (CDP type view)

That would be a useful thing except for one thing.  We turned off cdp on
all our ports with lwapp APs on them.  This was the simplest way to
enable the radios on some of our APs.  Our switches are 802.3af aware,
but they don't provide POE (we use the injectors).  By default the
radios would turn off and unless you went in and configured them
individually.

> 11. Inconsistant AP association behavior, certificate issues on 
> converted APs (mostly 1200s) not registeriing with controllers and 
> having to be manually added

We upgraded our older APs with the upgrade tool provided by Cisco. 
This tool
would put the self signed certificates on one controller.  This worked
farily well.  We would then have to go into WCS and refresh the WCS
config from the controller that had the certificates.  Then, in WCS go
to controller templates
-> Security -> AP Authorization and the certificates would all be
there.  These
are templates and can then be pushed to all other controllers easily.

> 12. Converted APs drop their pre-conversion system names and go to
mac
> address for name

I don't know any way around this one.

> 13. No ability for AP groups VLAN templates for multiple controllers 
> 14. Cannot use static WEP and AirFortress clients together on an 
> SSID/VLAN as you can in the autonomous world
>
> There are more... and I'm not bashing the product, believe it or
not.
> We bought it and will squeeze great value out of it.  But I am
wondering
> if others see these issues as problems, or if I'm expecting too much
as
> I move from the autonomous world to this new LWAPP stuff. Even
better-
> are there any here that I am wrong about?
>
> Please do not take this as an invitation to call me about WLAN 
> management products!
>
> Regards-
>
> Lee
>
> Lee H. Badman
> Network Engineer
> CWNA, CWSP
> Information Technology and Services
> Syracuse University
> 315 443-3003
>
> **********
> Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
>

--
Todd M. Hall
Network Analyst
Information Technology Infrastructure
Mississippi State University
[EMAIL PROTECTED]
662-325-0728 (phone)

**********
Participation and subscription information for this EDUCAUSE Constituent
Group discussion list can be found at http://www.educause.edu/groups/.

**********
Participation and subscription information for this EDUCAUSE Constituent
Group discussion list can be found at http://www.educause.edu/groups/.

**********
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

Reply via email to