Here is a new thread to summarize this one where i found some LLDP problems :
http://forum.mikrotik.com/t/lldp-med-not-working-if-port-pvid-is-not-1-no-other-bug-found-see-summary-thread/172966/1
I was able to detect 3 main problems during LLDP and LLDP-MED testing (RouterOS 7.14beta7 - RB5009). Some of them have been discussed before, but probably not enough, or not deeply enough, to trig some corrections.
Here are my conclusions :
1) RouterOS does not include a 802.3 MAC/PHY TLV in its LLDP MED announcements packets.
The 802.3 MAC/PHY Configuration/Status TLV is an option for LLDP, but it is mandatory for all LLDP-MED to both send and receive devices.
This is clearly stated in the ANSI/TIA-1057- 2006 document.
This TLV is defined inside the IEEE 802.1AB-2005 [1] Annex G.2 document.
When the MAC/PHY TLV is not included inside the LLDP-MED announcements, phones are rejecting the LLDP-MED announcement packets, because they consider them as malformed. The direct consequence is that phones never select the tagged voice VLAN announced by LLDP-MED. This has been tested and confirmed with Mitel phones.
2) RouterOS is broadcasting the reserved LLDP multicast MAC address (01:80:c2:00:00:0e) between ports if (R/M)STP protocol is disabled on the bridge.
This address is a link local MAC address that must never be forwarded outside of the link. Not following this rule can translate to some network problems.
The IEEE reserved addresses table clearly states that the LLDP multicast destination address should never be forwarded :
b It is intended that no IEEE 802.1 relay device will be defined that will forward frames that carry this destination address.
https://standards.ieee.org/products-programs/regauth/grpmac/public/
As a side note, it is important to check that the filtering is active even during the devices boot. I’ve seen on Linux based devices some filtering problems during boot.
Another note : in a similar way, it seems that some STP and GVRP packets that should never be forwarded between ports are forwarded when (R/M)STP is disabled on the bridge. I did not investigate more here, as i was concentrating on LLDP testing. But the consequences of such unfiltered traffic can be terrible on a network (from loss of connectivity to switches crashes).
3) RouterOS does not seems to implement the LLDP-MED fast start mechanism. It is part of the LLDP-MED protocol (ANSI/TIA-1057).
The fast start mechanism do allow a faster initialization of LLDP-MED devices. When the LLDP receive state machine receive an LLDPDU not already associated, then it should enable a faster timer to send a few LLDP-MED announcements packets at a faster rate (1 second). This is designed to speed-up for example phones boot, and to give a better chance for new devices appearing on the network to catch LLDP announcements.
Important note : if the fast start LLDP-MED mechanism is not implemented, router LLDP-MED packets are only sent every 30 seconds or more. Then there is a high probability that phones will not catch an LLDP-MED packet before the end of their LLDP-MED waiting slot (a few seconds during initial boot for Mitel phones). The direct consequence is that the phones will consider that there is no LLDP-MED announcements, and will continue their boot on the untagged VLAN. By chance, if the phone LLDP waiting slot coincide with an LLDP router announcement, then it could boot correctly on the voice VLAN.
If fast start is implemented, then as soon as the router sees a device LLDP-MED packet, it enables the fast start timer immediately, changing delay between LLDP-MED packets announcements to 1 second. Then the phone are always able to catch it during initial boot phase, and get the voice VLAN, as well as other optional LLDP-MED setups (Elin, COS, DSCP…).
Less important considerations :
-
COS and DSCP values for voice traffic are not included in the LLDP-MED Network Policy TLV. This is important on networks with a high level of traffic so that phones automatically add those tags to the sent traffic.
-
For large telephony setups, it is interesting to use LLDP-MED Elin (Emergency Location Identification Number).
This TLV is used to change the caller ID to a number given by the switch, only for urgency calls. This allow to have the same setup for all phones, and distribute a local caller ID number inside local switches to be sure that emergency calls are done with the right caller ID.
Elin is actually not supported on Mikrotik RouterOS.
