cancel
Showing results for 
Search instead for 
Did you mean: 

Add LLDP support to Ruckus devices

chris_wooddell
New Contributor
This has been an enhancement request open since Jan 27, 2009 3:14pm on the old website.

Not having LLDP support is a major downside for devices positioned as players in the enterprise space. It's about five years since the standard was finalized, and this is a critical infrastructure management protocol. Please prioritize this.
22 REPLIES 22

keith_redfield
Valued Contributor II
This is one of those features that keeps getting bumped in favor of others.

It's important to hit the +1 icon on the original post above (or other features you want to see) if you haven't already.

What would be helpful in the comments is use-cases (why it would be useful) or business-case (deals/installs lost) and that will help our product managers prioritize features better.

Many times you do a predictive deployment where you specify where each AP should be placed. You document everything. Then when you go to the site to do some troubleshooting or doing a survey you need to check if they have done their job right.

Otherwise you could spend a lot of time solving the wrong problem. It's essential to start with the basics first and work your way up and checking that APs are at their right locations is usually the first step.

andrew_larsen_6
New Contributor II
As a piece of network equipment, for a network engineer/administrator, LLDP is an indispensible tool for managing and troubleshooting a network. It's almost surprising that I would have to explain how incredibly useful it is, since every other major wifi network equipment manufacturer recognizes this and supports it. Devices which support LLDP will show up on a switch stating what they are (phone, switch, router, WAP, etc), what their IP address is, what their host name is, their firmware revision, manufacturer, etc. This is extremely helpful when you are trying to track down a device that isn't reachable, has failed a firmware update, isn't showing up on an expected port, etc. An incorrect IP address on a WAP means that somehow it got hard coded with a bad IP and may need to be set to factory defaults. A WAP that no longer shows up on the ZoneDirector that shows up on a port that isn't untagged in the native VLAN just needs to have the port reconfigured or be moved to the right port. The list goes on and on. It's a tool that greatly simplifies and speeds up troubleshooting.

dave_burns_5993
New Contributor II
As i previously posted (and has been repeated by all here) the ability to perform some basic discovery via automated tools that already exist and already read LLDP/CDP/etc is instrumental in problem solving and troubleshooting misbehaving APs.

For me specifically, because of the variety of switches (and levels of switches) I have deployed, frequently APs at a site will mesh, because 1 has determined that either its switch is closer to the default gateway(or spanning tree root bridge) or the port is 100Mb instead of 1Gb. When this happens, no MAC address shows on the port, but POE is being drawn...so then how to determine which AP is connected to which port? LLDP!

matthew_ausmus
New Contributor II
Most of my installations are larger scale: school districts, corporations and the like. At least 200 APs spanning multiple locations.

Business Cases:

From a VAR side: I use automated tools to map the network after a deployment. Without LLDP the APs get discovered (because they support SNMP) but they just hang in the ether. I still have to map connect the APs to the correct switch & port. This adds time and expense to the project both for the VAR and the client.

From the Client side: Clients use network monitoring tools like Solarwinds, WhatUP Gold and the like. These provide mapping functions as well that utilize LLDP. Again, when they run a discovery, the AP is found but just hangs in the ether. The IT team then has to manually create the connections adding more work where they shouldn't have it. When an AP is moved to a new switch port or replaced they have to do it again. IT teams have enough work on their plate without having to do this and it becomes a point against deployment of Ruckus Wireless.