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

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