Add LLDP support to Ruckus devices

  • 36
  • Idea
  • Updated 4 years ago
  • Implemented
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.
Photo of Chris Wooddell

Chris Wooddell

  • 1 Post
  • 0 Reply Likes
  • disappointed

Posted 4 years ago

  • 36
Photo of Dave Burns

Dave Burns

  • 5 Posts
  • 1 Reply Like
I too have asked my sales rep for this feature. I have over 500 APs deployed, with another ~300 on the way, having lldp would be just about the best thing i could ask for.
Photo of Peter Dohm

Peter Dohm

  • 13 Posts
  • 1 Reply Like
considering linux is the basis of the device, this seems appropriate:

http://open-lldp.org/
Photo of Andrew Larsen

Andrew Larsen

  • 2 Posts
  • 0 Reply Likes
I would also love to see this feature and urge it to be a top priority.
Photo of Point of Presence

Point of Presence

  • 3 Posts
  • 0 Reply Likes
Us too!
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
Me too.
Photo of joco_ph

joco_ph

  • 4 Posts
  • 0 Reply Likes
+1
Photo of Com1 NL - Bas Sanders

Com1 NL - Bas Sanders

  • 32 Posts
  • 9 Reply Likes
+1..!
Photo of Dave Burns

Dave Burns

  • 5 Posts
  • 1 Reply Like
any updates to this? even my request is now 5 months old, let alone the original request being from ~2009. some kind of network discovery protocol is now almost REQUIRED for these to work in my environment. I need to be able to query my switches and find every Ruckus AP, not have to run macros against an OUI list and hope for the best.
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 48 Reply Likes
It's actually quite funny. They have an OPT LED on all APs that seems to be there just to make up the numbers.
Photo of Matt

Matt

  • 7 Posts
  • 1 Reply Like
I just posted a question related to this. I'm doing a rollout for a school district and want to use a tool to automate diagraming so I want to find out what the APs support. I guess I can rule this one out for discovery purposes.

Add me to the list requesting LLDP support be added.
Photo of Heath Barnhart

Heath Barnhart

  • 5 Posts
  • 1 Reply Like
I would like LLDP support as well.
Photo of Rich Kusak

Rich Kusak

  • 1 Post
  • 0 Reply Likes
LLDP - Yes please!
Photo of Jeff Roback

Jeff Roback

  • 28 Posts
  • 8 Reply Likes
Me too!
Photo of Scott Sawin

Scott Sawin

  • 1 Post
  • 0 Reply Likes
I guess I was a tad surprised this was not already included. Please add
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 51 Reply Likes
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.
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 48 Reply Likes
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.
Photo of Andrew Larsen

Andrew Larsen

  • 2 Posts
  • 0 Reply Likes
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.
Photo of Dave Burns

Dave Burns

  • 5 Posts
  • 1 Reply Like
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!
Photo of Matt

Matt

  • 7 Posts
  • 1 Reply Like
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.
Photo of Mitchell Axtell

Mitchell Axtell

  • 60 Posts
  • 17 Reply Likes
We have somewhere near 5000 Ruckus APs in service, and I would dearly love to be able to more easily create port mappings with the neighbors table. Also, troubleshooting is way easier, due to the IP information provided and the ability to see the AP somewhere.

Would also lower the power allocation for APs such as the 7055 or the 7982, where they don't use nearly what the 802.3af or 802.3at classification affords them, leading to exhaustion of power budgets even though there is 40% utilization.

I really like Ruckus for the GUI ease of use, but right now Cisco has the edge for AP-level troubleshooting...
Photo of Dave Burns

Dave Burns

  • 5 Posts
  • 1 Reply Like
oh my goodness! i don't know how many of you have attempted a 9.8 upgrade on your ZDs, but if/when you do....ssh to an AP that has been upgraded, and "set lldp enable". AMAZING!

unfortunately it doesnt show in the GUI, nor is it configurable there, but lldp is now baked into the firmware on the APs! i turned it on on my test AP, and my switch now sees it just like all my other lldp devices.

THANK YOU THANK YOU THANK YOU Ruckus!
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 51 Reply Likes
While 9.8 is still LCS, even when it's released to GA this won't be a "supported" feature. What this means is that although the code is there, it has not been tested thoroughly, so it would be a use-at-your-own-risk situation. Any problems found would be deferred to a release that does officially support it.

We are still working on getting the resources committed to having a fully-supported and robust implementation in an upcoming release.

But as you can tell, we are at least listening and working on it.