LLDP

RouterOS General
1

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

2

http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol
http://en.wikipedia.org/wiki/Link_Layer_Topology_Discovery

up

3

up

4

I made a feature request.

http://wiki.mikrotik.com/wiki/MikroTik_RouterOS/Feature_Requests

5

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

6

I think they mean this http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol
It’s Layer2.

7

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.

8

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.

9

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.

10

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.

11

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.

12

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.

13

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.

14

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.

15

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.

16

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 ?

17

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

18

Perhaps for compabitility with OTHER hardware and OTHER networks.

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

19

Ok.

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

LLDP is IEEE 802.1AB. http://standards.ieee.org/getieee802/download/802.1AB-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 ??)




>show lldp info remote-device 5

 LLDP Remote Device Information Detail

  Local Port   : 5
  ChassisType  : network-address
  ChassisId    : 192.168.0.58
  PortType     : mac-address
  PortId       : 00 08 5d 85 ed 0e
  SysName      : Aastra IP Phone
  System Descr : Aastra IP Phone
  PortDescr    : port 0

  System Capabilities Supported  : bridge, telephone
  System Capabilities Enabled    : bridge, telephone

  Remote Management Address
     Type    : ipv4
     Address : 192.168.0.58

  MED Information Detail
    EndpointClass          :Class3
    Media Policy Vlan id   :10
    Media Policy Priority  :6
46
    Media Policy Tagged    :True
    Poe Device Type        :PD
    Power Requested        :150
    Power Source           :Unknown
    Power Priority         :High
20

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