LLDP MED not working if port PVID is not 1 ? (no, other bug found, see summary thread)

Edit : please read this summary and conclusion thread before :

https://forum.mikrotik.com/viewtopic.php?t=203774

All the stuff below are the details that led to the final conclusions. PVID = 1 or not is not the culprit for LLDP-MED not working.


Setup : RB5009, RouterOS 7.14beta7

I have some hybrid ports in a bridge for phones.

On those hybrid ports i have a tagged VLAN for telephony, and an untagged guest VLAN to allow to connect some devices on the secondary phone PC ports.

I’m using LLDP MED to switch the phone to the right Voice VLAN. This is necessary to avoid the hassle of configuring the phone. Using LLDP MED, the phone setup is fully automatic through auto-provisionning at boot time directly on the voice VLAN.


The problem is that if i want to use something else than VLAN ID = 1 for the guest VLAN, LLDP MED does not work anymore.

It seems that LLDP announcements are working only if the untagged VLAN has ID = 1


On switches it is possible to use any VLAN ID for the untagged guest VLAN and LLDP MED still works.


Could someone confirm this problem ?

Hi FIPTech,

That’s strange. Can you send your discovery settings and the interface lists members?

Also and to confirm - your bridge is configured with vlan-filtering=yes, correct?

/ip/neighbor/discovery-settings/print
/interface/list/member/print

Yes the bridge is a VLAN aware bridge.

   discover-interface-list: LAN
  lldp-med-net-policy-vlan: 4000
                  protocol: lldp,mndp
                      mode: tx-and-rx



LIST INTERFACE

0 LAN Bridge-LANs
1 LAN VLAN-INFO
2 WAN VLAN-Free
3 WAN Tunnel-FREE-IPIPv6
4 LAN VLAN-TEL
5 LAN VLAN-INVITE
6 LAN VLAN-Management

I did some tests with my equipment (7.13.2 on ARM), here is my configuration

> /ip/neighbor/discovery-settings/print 
   discover-interface-list: LAN
  lldp-med-net-policy-vlan: disabled
                  protocol: cdp,lldp,mndp
                      mode: tx-and-rx

> /interface/list/member/print
Columns: LIST, INTERFACE
# LIST  INTERFACE
0 LAN   vlan.10  
;;; Outside network
1 WAN   vlan.4000

And I do see LLDP advertisement on one of my workstations connected to an ethernet port in VLAN 10, untagged.
20240122 LLDP Wireshark.png
Between the Mikrotik and the client, I assume you have nothing else: no other switch, no AP or anything that would be at L2. Correct?

Also, I gather that the network we are talking about is “VLAN-INVITE”?

Yes the untagged guest VLAN for phones hybrid ports is VLAN-INVITE.
And i have nothing else between the phones and the router. The phones are powered by the router POE ports.

Your setup is a bit different because you are not using LLDP MED announcements.

Could you enable lldp-med-net-policy-vlan on a tagged vlan, put this vlan as tagged in the port, and see if you get the MED option announcements in the LLDP packets ?

For me it works only if the untagged VLAN is the default VLAN (with ID = 1).

MED is an option to announce the voice VLAN, so that phones can automatically switch to this VLAN without any manual configuration. This is a lot of time saving and simplifications when you need to install or change a lot of phones connected on hybrid ports.

Without MED, you need to manually set the VLAN on the phone before it will be able to access the voice VLAN. Could eventually be done automatically with a double boot, but this is a lot of hassle, MED is simplifying things a lot.

Another advantage of MED is that the phone do not stay locked on a VLAN setting. If you move the phone to another network, with a different voice VLAN or with voice on the untagged VLAN, it will follow and boot on the right VLAN without any manual setting. Again time savings.

Sure thing - one moment!

I still see LLDPDU. I will install an LLDP responder on my computer to see that I can get the Voice VLAN.


> /ip/neighbor/discovery-settings/print                          
   discover-interface-list: LAN
  lldp-med-net-policy-vlan: 11
                  protocol: cdp,lldp,mndp
                      mode: tx-and-rx

20240122 LLDP Wireshark 2.png

I think I found something - setting the list to LAN, I got LLDP announcements on my workstation but the router did not get my announcements. Nor did I get the VLAN.

> /ip/neighbor/print

I then configured a second list that has the bridge member interface

> /interface/list/member/print                                        
Columns: LIST, INTERFACE
# LIST      INTERFACE
0 LAN       vlan.10  
;;; Outside network
1 WAN       vlan.4000
2 LAN-LLDP  ether1

And set that list for the discovery:

> /ip/neighbor/discovery-settings/print 
   discover-interface-list: LAN-LLDP
  lldp-med-net-policy-vlan: 11
                  protocol: cdp,lldp,mndp
                      mode: tx-and-rx

I am now seeing the neighbor on the router. But still no trace of the MED network policy.

> /ip/neighbor/print                    
Columns: INTERFACE, ADDRESS, MAC-ADDRESS, IDENTITY
#  INTERFACE  ADDRESS        MAC-ADDRESS        IDENTITY
0  ether1     192.168.2.254  40:B0:XX:XX:XX:XX  XXXXpc01
   bridge

On your side, can you try to create a separate interface list and add a couple of physical interfaces to it, to which you know phones are connected, and change the discovery-interface in the discover settings?

You are probably right, LLDP needs low level access to the port, not the VLAN interface on it. I’m going to try that.

Knock on wood!

I suspect that the device tried to tag the LLDP traffic … which cannot be encapsulated, so while the physical interfaces received and sent the LLDPDU, the LLDP process itself did not receive them.

Hopefully, this will solve it. Let me know how it goes.

Still do not work with the Ethernet physical port in the discovery interface list…

I suspect that only the Default VLAN with ID = 1 can send LLDP MED.

Are you in a VLAN aware bridge too ?

I do. I will test later today with VLAN1 and VLAN10 to see if there is a difference.

Meanwhile, if you issue “/ip/neighbor/print” to check that you see neighbors?

I got curious and tried with my workstation on VLAN1 and VLAN10 - same result, I do not get an advertisement for LLDP-MED, but my workstation doesn’t advertise itself as Voice or Phone. I think I may have an app somewhere for that.

I configured LLDPD on my computer with a network policy, which got advertised immediately. The fact that my Mikrotik is not advertising the MED extension kind of tells me there could be a bug.

As a last try, I will reboot my device and see if that changes something.

I found a post from mid-2023 that reported the same issue post 7.7: http://forum.mikrotik.com/t/discovery-lldp-med-net-policy-vlan-not-working-on-ccr2116/166873/1

Nope, not working. Ticket open: SUP-141451.

I see the phones when their hybrid port are configured with VLAN 1 as untagged. As soon as i put a different VLAN ID LLDP does not work anymore.

I can see the phones issuing “/ip/neighbor/print”, only when the untagged VLAN ID of their port is set to 1.

The problem stay the same if i set the phone ports as access ports (without any tagged VLAN inside).

OK. So you see the same when you change the VLAN of the port as I do when I set the discovery on the VLAN interface. I have the feeling that there is something I am missing but I can’t quite point it.

Can we do the following?

  • With the discovery as it is, port with PVID1 and additional VLAN (4000) tagged, packet capture to see the LLDPDU
  • With the discovery adapted, port with the other PVID and additional VLAN (4000) tagged, packet capture to see the LLDPDU
  • With the discovery list set to the physical port, port with the other PVID and additional VLAN (4000) tagged, packet capture to see the LLDPDU

You can drop the packet captures or, if you prefer, screenshots of the LLDPDU.

Without changing the neighbor discovery interfaces, if i change the PVID of the port, LLDP appear for PVID = 1 and disappear with PVID not equal 1.

Regardless the settings i tried for the neighbor discovery interfaces, i can never get LLDP working if PVID not equal 1.

I’m going to packet capture from another router to check, but i’m almost sure that there is no more LLDP packets when i put the PVID to something else than 1. It is probably not an LLDP MED problem, but simply an LLDP diffusion problem when PVID is not 1.

I connected another auxiliary router for packet capture, and i did first discover something abnormal : LLDP announcement from every devices connected to the ports of the other router bridge are visible. This indicates that LLDP is switched and broadcasted between ports.

I suspect that it’s a bug. Normally, LLDP packets should stay within the link. I can observe LLDP on VLAN interfaces too.

LLDP should only be seen untagged. And should never go inside VLANs, or be read from VLANs if i’m right.

To my knowledge this is a point to point link layer protocol, not switchable and untagged only. We could call that a Level 1.5 protocol.

I think that there is a mess with LLDP. Going to Wireshark now.

Edit : after studying the capture, isolating LLDP packets, i can see that my phones are probably not getting the LLDP MED voice VLAN ID from the Mikrotik router, but from the HP Procurve switch connected to the RB5009 router on the same Bridge ! I can see it clearly according to the LLDP announcements, during phone boot, immediately after the HP Procurve announce with the VLAN Voice information, i can see that the Phone change its LLDP packet, announcing then that he got the voice VLAN ID.

I can see LLDP on tagged vlans too in the capture…

However the above are assumptions as i do not have a tap device to check directly on the link between the router and a phone. The packets i can see are those that are broadcasted on the bridge ports. All LLDP traffic appears to be broadcasted in the bridge, suggesting i might be seeing the complete story.

If my assumptions are correct, then LLDP seems to be problematic inside RouterOS 7.14 beta7, at least on the RB5009.

To be sure, i will try to capture the traffic between a phone and the router using a 100 mb/s RJ45 HUB. Should works if i put the router and phone ports in half duplex mode.

Good catch and correct - LLDP is link-local and should never be bridged. Some unmanaged switches will do it though but these are simple device. Why you would see that with a managed device is strange.

I was not able to reproduce the same issue here so far on 7.13.2.


Correct again, and that is why I asked for the test with the physical interfaces directly in the discover-interface-list.


I think we have identified two issues here.

  • MT’s LLDP doesn’t generate the MED TLV in the LLDPDU (ticket open)
  • MT (7.14b7 on RB) bridges the LLDPDU