We are using Cisco 2950 switches which do not provide PoE but are PoE aware as
far as cdp is concerned.  The AP checks the port it is plugged into using cdp to
see if the port is capable of providing enough power for the AP.  The response
from the switch is such that the AP will go into a low power mode (with the
radios turned off).  You can configure the AP letting it know that it is getting
its power via the injector but this gets very annoying when you are upgrading
hundreds of APs.  We found that if you just disable cdp on the switch port, the
AP then assumes that it is getting its power via an injector and turns the
radios on.

It is not the best solution, but it works.


On Thu, 21 Sep 2006, Lee Badman wrote:

> Date: Thu, 21 Sep 2006 18:51:54 -0400
> From: Lee Badman <[EMAIL PROTECTED]>
> Reply-To: 802.11 wireless issues listserv
>     <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Cisco LWAPP
>
> I don't think that's correct at all- CDP makes no difference in my
> findings as to whether APs come up or not.
>
> Lee
>
> Lee H. Badman
> Network Engineer
> CWNA, CWSP
> Information Technology and Services
> Syracuse University
> 315 443-3003
>
> >>> Charles Spurgeon <[EMAIL PROTECTED]> 9/21/2006 6:14 PM
> >>>
> Todd,
>
> Many thanks for your replies to the issue list from Lee Badman.
>
> I wanted to ask for more info on your response to point 10, in which
> you said that you had to disable cdp in order to get lwapp radios to
> come up.
>
> Am I reading that correctly? We're working on a WiSM deployment
> beginning later this year and we will be converting Cisco 1230 APs to
> lwapp. Will we have to disable cdp to get the radios to work?
>
> Thanks,
>
> -Charles
>
> Charles E. Spurgeon / UTnet
> UT Austin ITS / Networking
> [EMAIL PROTECTED] / 512.475.9265
>
>
> On Wed, Sep 20, 2006 at 08:02:42AM -0500, Todd M. Hall wrote:
> > 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
> > >     <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> > > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> > > 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/.
>

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

Reply via email to