It would be nice to have LLDP in routeros. Newer Procurve switches don't have CDP anymore; and LLDP is a better standard anyway...

http://en.wikipedia.org/wiki/Link_Layer ... y_Protocol
http://en.wikipedia.org/wiki/Link_Layer ... _Discovery

up

up

I made a feature request.

http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests

that is IPv4 as i see and thus will be outdated in several "hours", you really want that?

I think they mean this http://en.wikipedia.org/wiki/Link_Layer ... y_Protocol
It's Layer2.

and what will this give over existing /ip neighbors and /ipv6 neighbors coupled with, for exmaple, dude monitoring of the network? It looks more like something will be left to dust with no real use.

Sadly, it looks the same as with scsi drives - everyone needed it and still there is no response if it works at all.

It would let you map out networks easily if other devices also speak LLDP. LLDP lets you crawl networks ands query LLDP databases via SNMP to discover topologies.
Like SCSI it's so fundamental it's probably true that there isn't much feedback. Once the OS is installed there isn't much reason to pay attention to SCSI anymore. If you're not walking into an unknown network there isn't much attention paid to LLDP because you don't need it, much like the existing neighbor protocol. But when you do need it, boy, is it great to have.

Sadly, it looks the same as with scsi drives - everyone needed it and still there is no response if it works at all.

I hope this is not the general attitude from MikroTik. If you implemented, for instance, the HP scsi drivers that has been requested by myself and seconded by many, so everybody running HP servers could actually use RouterOS on their devices, perhaps then you would receive some feedback. My feedback so far would be that every single server we have in our network cannot run RouterOS, so for my new router replacement, I am forced to use a non-standard server. Something I hate to do. Right now I am neglecting a soon to be very critical upgrade because I can only boot the special server with RouterOS 5, and I don't want to run beta software in my core.

Now, regarding the topic of LLDP, from my point of view it would only be beneficial to implement it. Your support for third-party protocols have so far only been in the direction of closed, proprietary protocols. You support CDP. LLDP is the open version of this. You support netflow (or, you have a netflow implementation at least), yet sflow is the open version of this and at least on par with it.

You built your operating system on open software, yet you seem to neglect open alternatives to closed, proprietary protocols when you implement your own. Please stop reverse engineering proprietary protocols when open, well-described protocols exist that have the same features.

I know the community has a certain respect for you, because you have built your system on open source software, yet it seems you are trying to be cisco. Please don't.

Here's an example what Information LLDP can provide. Useful for us. (in this case its a Switchport)

------------------------------------------------
Chassis id: 10.200.212.182
Port id: 0004.0dec.2992
Port Description - not advertised
System Name: AVAEC2992
System Description - not advertised

Time remaining: 114 seconds
System Capabilities: B,T
Enabled Capabilities: B,T
Management Addresses:
IP: 10.200.212.182
OID:
1.3.6.1.4.1.6889.1.69.2.2.
Auto Negotiation - supported, disabled
Physical media capabilities - not advertised
Media Attachment Unit type: 16
Vlan ID: - not advertised

MED Information:

MED Codes:
(NP) Network Policy, (LI) Location Identification
(PS) Power Source Entity, (PD) Power Device
(IN) Inventory

H/W revision: 9630D01A
F/W revision: hb96xxua3_10.bin
S/W revision: ha96xxua3_10.bin
Serial number: 06N532761905
Manufacturer: Avaya
Model: 9630
Capabilities: NP, PD, IN
Device type: Endpoint Class III
Network Policy(Voice): VLAN 212, tagged, Layer-2 priority: 5, DSCP: 46
Power requirements - not advertised
Location - not advertised


and for the scsi driver thing:

You can count me in for the hp raid driver, we've a lot of hp dl38x Servers. I promise, I'll test as soon as a Release
becomes available.

Mmm... I our case we are sending vlan information to voip phones too get the correct vlan for the computer vlan (phones with builtin switchport). So we just apply the config in the switch and the phone learns.

And of course, as mentioned before, we retrieve now about twice the amount of information that we did with only cdp enabled.

I try to change (within my company) from the use of 8 ports cisco, with a canopy and voip euipment for remote locations, to replace this with mikrotik and a voip device, but its difficult arguing with stubborn cisxxx people when i even don't support the same protocols.

so, my vote for lldp still stand, it should be rather easy to implement, and if someone else think its usefull please vote.

and what will this give over existing /ip neighbors and /ipv6 neighbors coupled with, for exmaple, dude monitoring of the network? It looks more like something will be left to dust with no real use.

Sadly, it looks the same as with scsi drives - everyone needed it and still there is no response if it works at all.

I was a tad surpised to read a staff member reply like that.

From what I saw in the post most of the people want/need cciss support - something you've not implemented, and thus you could not expect a response. I checked the thread and 2 people have actually responded saying their systems are working with the raid drivers.

On the note of "what will it give us" - well, LLDP is able to detect devices you cannot detect via any of the methods you mentioned - its an open standard; and is gaining a lot of popular support with vendors.

I am involved with a software dev house and understand the frustrations of implementing features that then seem to fall by the wayside - maybe implementing a decent bug tracker/feature request system (trac would be but one example) would allow you guys to prioritise and manage requests.

Just my 2c worth.

I would also like to request support for LLDP.

Most network hardware from the big guys only supports CDP or LLDP (not both). So it would be nice if Mikrotik could do LLDP for those of us who have non-Cisco equipment.

For information, LLDP-MED is mandatory to boot a VoIP phone on a tagged VLAN.

Without LLDP-MED, the phone cannot know wich VLAN ID is the voice VLAN.


So LLDP and LLDP-MED are not a toys. There are very interesting as well to get informations about connected devices, not only switches ports. For example, you can get with it the IP address of the device, or POE informations like device consommation.


But i'll have to say as well, that Mikrotik devices are good routers but low end switches, the hardware chip available inside some MT routers are far from being usable for serious level2 switching.

So in the end, LLDP is certainly more usefull on switches, than on routers.

CDP is proprietary and should be droped.

LLDP is today the real standard.

Add LLDP by all means as that would be very, very useful - but I see absolutely no sense in removing CDP if it's working and is also useful.

Keeping duplicate things is not a good idea.

It gives two times more work to debug, support, and compile.

It makes the code bigger as well and slower.

Why would you need CDP ? Everyone is supporting LLDP today and manufacturers start to remove CDP.


Perhaps for compatibility with older hardware ?

Neighbor discovery protocols have tiny foot prints.
Just because LLDP is available on all manufacturers doesn't mean it's used in all networks.

Keeping duplicate things is not a good idea.

It gives two times more work to debug, support, and compile.

It makes the code bigger as well and slower.

Why would you need CDP ? Everyone is supporting LLDP today and manufacturers start to remove CDP.


Perhaps for compatibility with older hardware ?

Perhaps for compabitility with OTHER hardware and OTHER networks.

Same reason we have RIP, OSPF and BGP in there and not only one.

Ok.

Anyway LLDP-MED (ANSI/TIA-1057) should be implemented, not only LLDP.

LLDP is IEEE 802.1AB. http://standards.ieee.org/getieee802/do ... B-2005.pdf


Here is a link to an opensource LLDP project :

http://openlldp.sourceforge.net/

Media Endpoint Discovery is an enhancement of LLDP, known as LLDP-MED, that provides the following facilities:

* Auto-discovery of LAN policies (such as VLAN, Layer 2 Priority and Differentiated services (Diffserv) settings) enabling plug and play networking.
* Device location discovery to allow creation of location databases and, in the case of Voice over Internet Protocol (VoIP), Enhanced 911 services.
* Extended and automated power management of Power over Ethernet (PoE) end points.
* Inventory management, allowing network administrators to track their network devices, and determine their characteristics (manufacturer, software and hardware versions, serial or asset number).


Here is a sample of what we can get with LLDP-MED (can you do this with CDP ??)

Yes, CDP can. But who cares what CDP can do? Add LLDP-MED to the existing options, everyone is happy.

This thread is probably dead, but as a newcomer to the forum, would anyone know if Mikrotik supports LLDP?

We have an engineer here who is pushing Mikrotik strongly, but this is a feature we use daily, and I can see no way to set this up in the boxes we have.

--
Sanjeev

I would also like to add my voice for LLDP support. Our Avaya environment is dependent on LLDP support and this would be a great inclusion to the overall network edge.

I'd also vote on LLDP with LLDP-MED

LLDP for viewing neighboring switch/router info for topology maps would be great. I could care less about LLDP MED.

I read some Avaya documentation recently that recommended turning off LLDP MED because it can't provide as many options to VoIP phones. Instead use DHCP option 242 which points the phone to a call server for a downloadable script. There are infinitely more options to configure on the call server side than a data switch could ever provide.

There's some details here:
http://www.ipofficeassistance.com/HOWTO ... hones.html

I've also had colleagues run across issues with Polycom phones that learn VLAN info from LLDP MED and don't get rid of the info without factory defaulting the phone. That's a pain if you're moving a group of phones to a new office with a different voice VLAN.

I hope CDP never goes away. It's a great protocol and I wish it was the standard instead of LLDP. I've had too many times I had to custom configure all kinds of silly LLDP settings because a hardware/software manufacturer wasn't following the "standards". I've never had that problem between Cisco devices using CDP...it just works.

OMG You do not support LLDP?!!

I just rolled out several Mikrotik's into a bank for VLANs and other great networking features because I really like Mikrotik's, but guess what no LLDP. So the VOIP implementation is now going to get very very complicated with no LLDP.

One more reason why Mikrotik's are not become an enterprise option. I guess I could always do some small business networking. Maybe UBNT supports the IEEE standard.

-DesertAdmin

The only businesses using LLDP-MED (DHCP for the VoIP VLAN) and 802.1X are companies with big LANs and they are sold on Cisco/Juniper/HP/Dell already. MikroTik might have a shot at that environment in five years or so if they specifically target it. MikroTik knows their bread and butter crowd and they serve us well.

We are growing up, however, and while the CCR line is headed the right way, it's still positioned as an edge device and not something for the business casual enterprise of the USA. MikroTik should have a stronger US presence and try to understand the culture over here. It would help speed up this proposition.

Your very right.

I really do like Mikrotik. I just get disappointed when I come across a protocol that is a standard and it is not implemented because there is not enough requests for it. I feel that standards are standards and to be in the industry you must meet all default standards. I will probably use another vendor to do the LLDP across a ported VLAN port to the POE switches to do the autodiscovery. It is just a pain that I have to introduce another device to do something that is catching on. VOIP is every where, where is the support for its deployment?


-Sincerely,
DesertAdmin

/ip neighbor is seriously outdated, doesn't correctly detect most non-mikrotik devices, and it doesn't support LLDP, which is a spiritual successor to CDP. Many switches speak LLDP these days and having support for it would ease some administration pains. Obviously both RX and TX support. Comparing this to SCSI drivers is just... wrong.

Yes I was also very surprised to learn that LLDP is not supported....

So Mikrotik, Please implement it!
LLDP +1 !

LLDP needs to be supported!

Could this even make MT's work with standard 802.3at/af PoE devices since it broadcast its power requirements (is voltage part of the information?)?

Another upvote.

Please Mikrotik, add LLDP and add LLDP-MED if possible. This would come in very handy for the new CRS switch.

+1

+1.

up.

For now, routerboards has no one wide-spread discovery protocol. CDP is rx-only, and nobody other understands MNDP.
HP also limits CDP support, but it doesn't invent wheels, and uses standartized solution.

+1 LLDP would really be appreciated. Some newer phone systems absolutely require it to work .

+1 LLDP = awesome.

+1
This would be super useful to put phones in the correct clan at branch sites

Sent from my SM-G900F using Tapatalk

+1 and a bump on a 6 year old feature request.

LLDP makes my life a lot easier... please make it happen in RouterOS

+1
Vmware vsphere since v5 has LLDP support

+1 for LLDP

It was back in 2010 when janisk dismissed LLDP, now with a much more grown up line of their CCR routers that are going into networks next to the likes of Juniper and others with LLDP support, it seems silly to ignore your users requests for useful features especially as MikroTik are pushing into bigger markets with their CCR range.

+1 for lldp

+1 for lldp

+1 for LLDP
in switching it's very usefull

+1 for LLDP
in switching it's very usefull Please add it it would also make CRS's more usefull.

+1 for LLDP

+1 for LLDP support.

plus 2

LLDP support in RouterOS for the 6th anniversary of this topic ?



But seriously, why has it not been added ?

We use it extensively on other vendors equipment for provisioning phones in to vlan's at customer branches, and for working out port connectivity on switches and routers. It would be super useful to have LLDP on RouterOS..

NMSs also use it to build topology tables (and maps).

It would be EXTREMLY useful for this purpose to us.

Seems this thread is from 2008 and we are still waiting for implementation LLDP

We also need LLDP... Please implement.

+16384

+1 here

We really need it.

There is an ISC-licensed, open source implementation of LLDP called lldpd (obvioulsy ) that also supports CDP and other L2 discovery protocols. It is available on most Linuxes, Openwrt and others and it seams to me that MikroTik could use this to deliver LLDP in no time ... there is also ladvd that I have not used ...
And LLDP is almost obligatory these days for network devices ... same as MSTP is obligatory for bridges that support VLANs as are Mikrotik devices ...

Seems this thread is from 2008 and we are still waiting for implementation LLDP

apparently amount of consumers, that share opinion/excitement about how much "would be nice" to had LLDP supported - vastly over-exaggerated/overestimated.
in fact its more common to be among "kill on sight" by global-deploy rules in networks, than something useful.
and both - had reasons for if you think about a little

I for one don't need LLDP too much, as if I couldn't live without it. I can. It's just nice for me to look at switch and see in which port some device is plugged. I might as well find it by MAC address, I don't need to do it that often to really bother me.

But look at it this way: RouterOS has CDP and it's supported by MikroTik, Cisco and that's about it. And it's not rising. LLDP is supported by everything else, including Cisco. It seems to me that MikroTik will have to give up eventually and support it too. Why wait?

I for one don't need LLDP too much, as if I couldn't live without it. I can. It's just nice for me to look at switch and see in which port some device is plugged. I might as well find it by MAC address, I don't need to do it that often to really bother me.

But look at it this way: RouterOS has CDP and it's supported by MikroTik, Cisco and that's about it. And it's not rising. LLDP is supported by everything else, including Cisco. It seems to me that MikroTik will have to give up eventually and support it too. Why wait?

why should care anyone about "everything else" especailly if tats only companies like microsoft, hp and alikes ?
"CDP don't need to be "rising" or whatever else. its just Works and thats are what it are for and why. not pathetic, bloated, vulnerable/exploitable things like LLDP are extremely unsuitable for low-overhead-implementation-aimed vendors, like MikroTik are(which is cute and handy a lot).

my point os: even if "whole World" was do something Evil - thats not point to turn to Evil side by itself
*swung LLDP RFC by lightsaber*

I think we can agree that some discovery protocol is nice thing. That's why several vendors invented some. Then they realized that future would be brighter if they could discover also devices from other vendors. And so we got LLDP as common standard. Sounds good to me. Well, at least it did, until now...

Should I rather believe you that they're all riding on some evil wave? So stick to buying MikroTik & Cisco, forget about the rest and live happily ever after? Sure, that's a possibility. Just one thing, can we really trust those Cisco traitors? I mean, they support LLDP too. Shouldn't we rather choose the only true path and use MikroTik's proprietary discovery protocol (yep, there's one)?

Disclaimer: Some parts of my post are not completely serious.

oh yea, "myriads of flies - can't be wrong !"
we're heard thats thousands time from mass-media
which eventually - create some immunity in some of (same portion of)us, over time, since childhood.
and no, bloated, insecure, poorly-documented and supported things, redundant(in "best case")for majority of consumer - isn't really Necessity
i do Respect other opinions, of course, but give no fk bout them, obviously. which is only way to co-exist in harmony between, seems.

Ok, so you don't like it, while some others do. I don't have any deep technical knowledge of LLDP, I just like it as user. If you say it's "pathetic, bloated, vulnerable/exploitable, insecure, poorly-documented and supported", I'd like to know more. Do you have any info about that, links to some articles or something? So far I wasn't able to find anything myself. If that's really the case, I assume you can't be the first one to notice and it must be already covered somewhere.

*bump*

+1000000

Since I am using HP switches, lack of LLDP is a real issue for me.
However, given the "overwhelming" response from MikroTik on this thread, I have to wonder if there is any point in even asking for this feature, as they seem determined to not ever implement it, for whatever reasons. I do hope a more positive response from them is forthcoming.

see ? another good reason to use MikroTik switches instead
but seriously-talking, MikroTik obviously - aimed for different kind of consumers with different set of priorities.
if you prefer to bump particular "wrong request" to "wrong company" its not really lead something.
its like asking CISCO to support OpenFlow or Dude(or in early adoption of it - MPLS/VPLS), otherwise.

see ? another good reason to use MikroTik switches instead
but seriously-talking, MikroTik obviously - aimed for different kind of consumers with different set of priorities.
if you prefer to bump particular "wrong request" to "wrong company" its not really lead something.
its like asking CISCO to support OpenFlow or Dude(or in early adoption of it - MPLS/VPLS), otherwise.

Show me a 48 port SFP+ Mikrotik switch. Show me a Mikrotik switch with 40GigE or 100GigE. Show me a Mikrotik switch without a confusing VLAN setup. I love Mikrotik, but they aren't the answer for everything.

see ? another good reason to use MikroTik switches instead
but seriously-talking, MikroTik obviously - aimed for different kind of consumers with different set of priorities.
if you prefer to bump particular "wrong request" to "wrong company" its not really lead something.
its like asking CISCO to support OpenFlow or Dude(or in early adoption of it - MPLS/VPLS), otherwise.

Show me a 48 port SFP+ Mikrotik switch. Show me a Mikrotik switch with 40GigE or 100GigE. Show me a Mikrotik switch without a confusing VLAN setup. I love Mikrotik, but they aren't the answer for everything.

not yet, sadly.
you right :=)
but they Would in future, i hope

Show me a 48 port SFP+ Mikrotik switch. Show me a Mikrotik switch with 40GigE or 100GigE.

If only Mikrotik would ever consider making their OS available on the Whitebox switches That Cumulus support tax is just too expensive.
Think I asked the question on here before but people on here didn't seem all that interested about it I guess.

Also strongly support the notion to add support for LLDP.
It's standard and supported by most vendors nowadays.

42!
18.03.2016, still no LLDP.

42!
18.03.2016, still no LLDP.

Rather pathetic, isn't it?

I would also welcome lldp implementation in RouterOS. Most producers (excludig Cisco itself off-course) started sweep off cdp support from their new firmware production. And honestly, most of us does not maintain RouterOS - only networks

Please specify what info would you like to get from LLDP?

Please specify what info would you like to get from LLDP?

At a minimum, everything we get via CDP, just now in a format that's readable to\from more devices.

Please do not forget to implement LLDP MIB in SNMP, I think having LLDP information available over SNMP is a crucial feature for everyone.

Maris,

We would like to send/receive local port and remote port

We would also like to be able to specify the voice vlan via LLDP so phones will jump in to it.

It might be best to allow specifying LLDP options manually like is done with DHCP currently on RouterOS. This way it should keep everyone happy.

Also +1 on LLDP info from SNMP using the standard LLDP MIB

Please specify what info would you like to get from LLDP?

You can start from here :
http://vincentbernat.github.io/lldpd/features.html

The license for lldpd is permissive enough that you can even reuse the source ... and it is smart enough to support various protocols not only LLDP ...

Also strongly support the notion to add support for LLDP.
It's standard and supported by most vendors nowadays.

thats not true "most" vendors - don't give a .. about LLDP.
and for very obvuiys reasons.

Voice VLAN LLDP support is absolutely critical esp on the CRS.
We have totally migrated away from a DHCP based reconfiguration based system to full LLDP.

Lots of newer network devices only support LLDP and not ISDP/CDP anymore making /ip neighbor discovery not all that valuable any more.

thats not true "most" vendors - don't give a .. about LLDP.

So who else is on that proud list, together with MikroTik? Who supports some discovery protocol (preferably CDP, because it's what RouterOS has) in their current devices/software, but not LLDP? Number of devices I worked with is limited, but I can help you by ruling out at least Cisco, HP, Zyxel and D-Link.

and for very obvuiys reasons.

Those reasons being? I remember you writing how LLDP is, in short, really bad. But so far I wasn't able to find any confirmation about the fact from other sources.

Also strongly support the notion to add support for LLDP.
It's standard and supported by most vendors nowadays.

thats not true "most" vendors - don't give a .. about LLDP.
and for very obvuiys reasons.

I think you are a rather confused fellow.

thats not true "most" vendors - don't give a .. about LLDP.
and for very obvuiys reasons.

Huh what ?

Mikrotik is the only equipment we use that doesn't support LLDP !

We use it all the time on HP, Extreme and Juniper switches.

thats not true "most" vendors - don't give a .. about LLDP.
and for very obvuiys reasons.

Huh what ?

Mikrotik is the only equipment we use that doesn't support LLDP !

We use it all the time on HP, Extreme and Juniper switches.

which is my point actually - most of other vendors do not care much about it in most line of products.
try used it with say Ericsson routers or Alcaltel ? other brands (SMB or SOHO or magistral routers or BRAS, whatever)openwrt didn't had mature lldp support, ddwrt had incomplete support of it aswell(bit better than former), same about VyOS and "routed flawors" of FreeBSD/NetBSD/dfBSD/oBSD and most mainstream L-UX distros aswell.
frankly LLDP is much more like UPnP today - fancy, bloated, insecure(partialy by concept, partialy by implementation, partialy by insane/insecure "defaults" in), proprietary stuff /nearlty/nobody care about or use even in NA.
its not "standard" thing in major part of World or important at all.

thats not true "most" vendors - don't give a .. about LLDP.
and for very obvuiys reasons.

Huh what ?

Mikrotik is the only equipment we use that doesn't support LLDP !

We use it all the time on HP, Extreme and Juniper switches.

which is my point actually - most of other vendors do not care much about it in most line of products.
try used it with say Ericsson routers or Alcaltel ? other brands (SMB or SOHO or magistral routers or BRAS, whatever)openwrt didn't had mature lldp support, ddwrt had incomplete support of it aswell(bit better than former), same about VyOS and "routed flawors" of FreeBSD/NetBSD/dfBSD/oBSD and most mainstream L-UX distros aswell.
frankly LLDP is much more like UPnP today - fancy, bloated, insecure(partialy by concept, partialy by implementation, partialy by insane/insecure "defaults" in), proprietary stuff /nearlty/nobody care about or use even in NA.
its not "standard" thing in major part of World or important at all.

I don't spend much time on this forum. Is Zorro a serious poster or just a troll?

Everybody stay calm
We are working on LLDP implementation, it will magically appear in future ROS versions, maybe even ROS v6.

I don't spend much time on this forum. Is Zorro a serious poster or just a troll?

i frankly don't think that "seriousness" or "trolling" are mutually-exclusive things. some trolls can be quite serious(and as pointless,despite that. and some posts above is clear example of that) and some not so serious posters was better/more helpful than trolling "myster seriousness" crowds.
my point is: you had no point here.
aside discussion of personalities, which is clearly balancing on ToS edge here(let alone say etiquette)
*swtiched to "calm" state, beeping aloud*

Everybody stay calm
We are working on LLDP implementation, it will magically appear in future ROS versions, maybe even ROS v6.

well i guess anyone that do really need that thing - willl be happy.
and even others. if its not implemented within core, "System" package i guess.

Everybody stay calm
We are working on LLDP implementation, it will magically appear in future ROS versions, maybe even ROS v6.

Awesome news Maris

Why this is awesome ?

LLDP will allow you to:

- Identify where a cable goes to (remote device name and port)
- Provision VoIP phones into the correct vlan
- Monitor status of remote devices at Layer2 (provided Mikrotik use LLDP-MIB)

- Identify where a cable goes to (remote device name and port)

- you can do this already with the current MDP. '/ip nei print details'

- Identify where a cable goes to (remote device name and port)

- you can do this already with the current MDP. '/ip nei print details'

only if device has some CDP function..

- Identify where a cable goes to (remote device name and port)

- you can do this already with the current MDP. '/ip nei print details'

only if device has some CDP function..

Which is largely limited to Cisco, Ubiquiti and Mikrotik devices. No Mimosa, no Cambium, no Juniper, no Polycom, no....

- Identify where a cable goes to (remote device name and port)

- you can do this already with the current MDP. '/ip nei print details'

Mikrotik devices always report the switch master port or bridge name for interface. Is there any way to get the real port?

Which is largely limited to Cisco, Ubiquiti and Mikrotik devices. No Mimosa, no Cambium, no Juniper, no Polycom, no....

No HP, no Extreme, no Netgear, no Allied Telesis

I could go on but I'm sure you get the idea.

Which is largely limited to Cisco, Ubiquiti and Mikrotik devices. No Mimosa, no Cambium, no Juniper, no Polycom, no....

No HP,  no Extreme, no Netgear,  no Allied Telesis

No TP Link, No D-Link, No Yealink, No SuperMicro...
Other Known LLDP Supporters: Brocade, Avaya, Zyxel, Huawei, even those crappy IPECS phone systems support it.
Solarwinds Auto Collects that data to make network maps.... 
Don't be left out Mikrotik... Just add extra fields to neighbours and put them all in there.

Everybody stay calm  :D
We are working on LLDP implementation, it will magically appear in future ROS versions, maybe even ROS v6.

Very good news for all my customers

- you can do this already with the current MDP. '/ip nei print details'

only if device has some CDP function..

Which is largely limited to Cisco, Ubiquiti and Mikrotik devices. No Mimosa, no Cambium, no Juniper, no Polycom, no....

And not even compatible with *all* Ciscos.  As someone else mentioned too, the port MT reports, are also frequently incorrect.  CDP should only be on physical interfaces, MT has a open day as far as CDP goes  

its not that "simple" basically
and tiresome amount of work, perhaps.
generally both UPnP(not usre bout PCP implementations), IGMP snooping and LLDP code, available for use in ~ "complete" state - vulnerable/broken as hell and (would)expose routers almost as forrest fire in each case, implemented "from shelves" w/o applying hands to code and some devices-specific policies perhaps.

its not that "simple" basically
and tiresome amount of work, perhaps.
generally both UPnP(not usre bout PCP implementations), IGMP snooping and LLDP code, available for use in ~ "complete" state - vulnerable/broken as hell and (would)expose routers almost as forrest fire in each case, implemented "from shelves" w/o applying hands to code and some devices-specific policies perhaps.

What???

+1 for LLDP

Plenty of equipement doesn't have CDP and being able to identify what's connected to what it pretty useful ...

as Normis already noted - they working on LLDP implementation already and perhaps there was no need to try push/poke them about anymore. they arent 5000ppl huge corporation and thus cannot "isntantly implement whatever anyone want from thru time/space continnum". just keep you finger crossed and patiently wait. eg "stay calm and wait for ROS7".
CDP and LLDP aren't mutually-exclusive things, they both parts of IEEE 802.1AB development/evolution. there was even more weird/unusual beast in field, especially among new gear so generally LLDP will have dinosaurs fate pretty soon(CDP wouldn't i guess).
and despite CDP being labeled as "deprecated" cause LLDP avantages(real or existing in advertisers minds) in few areas including "security" in real life - its not so flawless thing, generally cause Implementation(usually no LLDP itself, but things its relying on. protocols+ daemons/services for) its may be even more "broken by design" just like some 3rd parties "purposely ruined" NDP implementation/design and IPSec and IPv6 arch, for example.
so depite usefullness within "CDP-free" installations/networks its ain't "silver bullet" and generally always better to pick "bit less antagonistic/selfish" hardware vendor thats not drop things you may need.
similarly to 802.1AB - other parts of 802.3 - advance pretty Quick. if you study even 2012 version of 802.3 you will notice for example thats all 802.1x-2010 portions - become not "optional", but part of Standard and same was with other parts of it http://network.wzu.edu.cn/bjpkc/downloa ... ction2.pdf
and 2015 version of 802.3 - push forward even harder.

I understand they don't have unlimited resources, which is why they must focus on the features that will benefit the most their customers and IMHO a gentle "+1" on a thread isn't a bad way to show interest in a feature ...

Also first post is from 2008, so I wouldn't call that "instantly".
And finally "Wait for ROS7" ... is starting to get a bit old, I've seen severals years old post talking about ROS7 features, but I haven't seen anything even resembling a roadmap for release for it.

There are several other features (like IKEv2) that have been said to be supported in ROS7 but without knowing if it's going to be there in 6 months or 6 years, I have no other choice than to assume the worst case scenario.

+1 here. As we can see the IPv4 is still alive and the feature is still in demand.

I understand they don't have unlimited resources, which is why they must focus on the features that will benefit the most their customers and IMHO a gentle "+1" on a thread isn't a bad way to show interest in a feature ...

Also first post is from 2008, so I wouldn't call that "instantly".
And finally "Wait for ROS7" ... is starting to get a bit old, I've seen severals years old post talking about ROS7 features, but I haven't seen anything even resembling a roadmap for release for it.

There are several other features (like IKEv2) that have been said to be supported in ROS7 but without knowing if it's going to be there in 6 months or 6 years, I have no other choice than to assume the worst case scenario.

they can't have "appx schedule" to share with customers to help them do some planning/management, yep.
demand-wise - more frequently hear whine about igmp snooping or gaps in dns implmentation(in both ipv4 and ipv6 portions)than complaints bout LLDP.
as already noted "ROSv7" become somewhat "magical unicorn" that solve all(or majority of) problems of customers, heal their kids, improve their fitnes and boost global security. hell, properly-marketed - it may even stops aliens invasion !!

... it may even stops aliens invasion !!

It will be "fight of the millenium" ... ROS v7 vs. Plan 9 from Outer Space ...

... it may even stops aliens invasion !!

It will be "fight of the millenium" ... ROS v7 vs. Plan 9 from Outer Space ...

yeah, would be Epic battle
and then dragonflybd versus haiku versus MorphOS versus AmigaOS versus AROS versus would be cool too. my best bets would be on dfbsd forks(especially Gentoo) and Haiku, but Morphos not look bleak too and in past AtheOS not look bleak(perhaps both DfBSD and Haiku - need bit more investments and contributors)

+1
Please implement LLDP! We have a few different brand of switches in production and everyone of them are talking LLDP, except MT

+1 for lldp

+1
Please implement LLDP!

http://forum.mikrotik.com/viewtopic.php?f=21&t=112844

What's new in 6.38rc7 (2016-Sep-30 07:33):
*) discovery - added LLDP support;

Better late than never
Thx MikroTik

Now they just need to ad LLDP-MIB and LLDP-MED support and it will be complete

Now they just need to ad LLDP-MIB and LLDP-MED support and it will be complete

Just wait 8 more years (first post on this thread was in 2008) and I'm sure it will be implemented most magnanimously.

(or get scripting and write your own OIDs, ya lazy bum!)

Just wait 8 more years (first post on this thread was in 2008) and I'm sure it will be implemented most magnanimously.

(or get scripting and write your own OIDs, ya lazy bum!)

It's was just a gentle poke at Mikrotik to "finish the job"

It would surely be more efficient for them to work on a particular feature until it is complete, rather than having to go back to years old code and relearn it to add in the functionality originally missed out.

I was just bein' silly.

Now they just need to ad LLDP-MIB and LLDP-MED support and it will be complete

Thoses MED informations do allow voice vlan auto selection on a phone :

MED Information Detail
EndpointClass :Class3
Media Policy Vlan id :70
Media Policy Priority :6
Media Policy Dscp :46

But LLDP-Med do allow as well fine grained power allocation and reporting for POE :


ProCurve Switch 3500yl-48G(config)# show power-over-ethernet 23

Status and Counters - Port Power Status for port 23
Power Enable : Yes
LLDP Detect : enabled
Priority : high Configured Type :
AllocateBy : value Value : 5
Detection Status : Delivering Power Class : 2
Over Current Cnt : 0 MPS Absent Cnt : 0
Power Denied Cnt : 0 Short Cnt : 0
Voltage : 516 dV Current : 55 mA
Power : 5000 mW


LLDP alone gives only this :

LLDP Remote Device Information Detail
Local Port : 10
ChassisType : network-address
ChassisId : 0.0.0.0
PortType : mac-...
PortId : 08 00 0f 15 fb f9
SysName : MITEL 5220 DM
System Descr : MITEL 5220 DM,h/w rev 0,ASIC rev 0,f/w Boot 02.02.01.03
PortDescr : LAN port
System Capabilities Supported : bridge, telephone
System Capabilities Enabled : bridge, telephone
Remote Management Address
Type : all802
Address : 08 00 0f 15 fb f9

+1000 for LLDP-MED support

Its funny how we can have open standards for XX devices and since 2010 mikrotik is just not doing anything for LLDP.

Please clarify "not doing anything"? LLDP initial support was added in 2016-Sep-30

mrz ... should we be still shocked with this fenomenal initial start for next few years?

Please clarify "not doing anything"? LLDP initial support was added in 2016-Sep-30

RouterOS is still missing LLDP-MED which allows the router/switch to signal to VoIP phones which vlan they need to use. This is one of the main reasons for using LLDP, and is a standard feature on switches.

Also no LLDP data is present in SNMP.

Another main use-case for LLDP is to have topology data available over SNMP, so monitoring and mapping software can use it to map the network.

I completely agree that some features are still missing, but that doesn't fit a statement that MT is not doing anything since since 2010

I think everyone in this thread appreciates VERY MUCH that LLDP is implemented at all.
And I personally thank the MKT team a lot for this.

But I think all of us here wish the work on LLDP would continue, since there is still a lot that can be improved.

Also separation of LLDP from MNDP would probably be beneficial.
It is way too easy to inject LLDP frames into VLANs or Bonds with current implementation - which is incorrect behavior.
But we do want MNDP on those interfaces - so the current way LLDP is configured is forcing you to either:
1) do no run MNDP where you want it
2) inject LLDP frames where they are not supposed to be

I have been coming to the MKT tables at MUMs for over 2 years now with these notes (along with SNMP), and there has been no movement at all for the last 2 years on the LLDP front.

I think everyone in this thread appreciates VERY MUCH that LLDP is implemented at all.
And I personally thank the MKT team a lot for this.

But I think all of us here wish the work on LLDP would continue, since there is still a lot that can be improved.

Also separation of LLDP from MNDP would probably be beneficial.
It is way too easy to inject LLDP frames into VLANs or Bonds with current implementation - which is incorrect behavior.
But we do want MNDP on those interfaces - so the current way LLDP is configured is forcing you to either:
1) do no run MNDP where you want it
2) inject LLDP frames where they are not supposed to be

I have been coming to the MKT tables at MUMs for over 2 years now with these notes (along with SNMP), and there has been no movement at all for the last 2 years on the LLDP front.

I agree with everything Tomas has said. I really appreciate that Mikrotik have put in an effort with LLDP, it just needs a little bit more polish to make it workable.

LLDP-MED, yes please else the use of the PoE switches is limited.

Agree 100%. It is a fundamental requirement in any enterprise switch.

Why lldp neighbour interface description is shown as neighbour interface name? There is no interface name in LLDP. For identification purpuse it is better to use interface id.
Please, fix it. Also lldp interface id and id subtype should be accessible via corresponding fields and of course SNMP.

Agree 100%. It is a fundamental requirement in any enterprise switch.

+1 for LLDP-MED which really simplify things.

+100000
I would love to deploy MT switches all day long if they supported LLDP-MED. But without it, they're useless in offices with VoIP phones (all offices we support and upgrade).
That's about 300 switches not sold in the last two years just with the deployments I managed.

Can we get a bug-free LLDP-MED feature added please?

+1. Cannot deploy MT switches unless LLDP-MED is available. Just too much work without it.

+1. Asked this a few years ago for SIP phones VLAN automatic selection.

+1 for LLDP-MED support to be added to RouterOS, even if its an optional module - would be very handy.

+1, this is not an optional thing, it is required in most enterprise environements. Need LLDP-MED, even if it's just an installable package.

I felt LLDP features (without WebFig support) were introduced with 6.48.1 or so.
I don't know if it covered LLDP-MED (nor I didn't test it yet).

I have worked with Mikrotik and sent Logs to them regarding LLDP-MED. Their responses make me believe that they have never seen an ip phone. So it looks like the fix is not going to happen until they realize that neighbor needs to send LLDP-MED packets to the phone not just discover the phone. VERY FRUSTRATING!!!

+1 here as well for LLDP-MED. I unfortunately have not been able to replace even UniFi switches in several offices because they even support working LLDP-MED. Please Mikrotik, listen to this one! It's important to your real world users.

+1 bump!!!!!

They support LLDP-MED. Check out /ip/neighbor. I can't recall if in V6, but it's in V7 for sure.

https://help.mikrotik.com/docs/display/ ... overy-LLDP

They support LLDP-MED. Check out /ip/neighbor. I can't recall if in V6, but it's in V7 for sure.

https://help.mikrotik.com/docs/display/ ... overy-LLDP

RouterOS v6 is EOL, who cares?

And yes it's supported on v7, but never seen anyone using LLDP-MED in production.

And yes it's supported on v7, but never seen anyone using LLDP-MED in production.

Here I am. And not, is not working!

see: viewtopic.php?t=196403