Edit : please read this summary and conclusion thread before :
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 ?
LLDP MED not working if port PVID is not 1 ? (no, other bug found, see summary thread)
Last edited by FIPTech on Fri Jan 26, 2024 4:46 pm, edited 7 times in total.
Re: LLDP MED not working if port PVID is not 1
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?
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?
Code: Select all
/ip/neighbor/discovery-settings/print
/interface/list/member/print
Re: LLDP MED not working if port PVID is not 1
Yes the bridge is a VLAN aware bridge.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?
Code: Select all/ip/neighbor/discovery-settings/print /interface/list/member/print
Code: Select all
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
Re: LLDP MED not working if port PVID is not 1
I did some tests with my equipment (7.13.2 on ARM), here is my configuration
And I do see LLDP advertisement on one of my workstations connected to an ethernet port in VLAN 10, untagged.
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"?
Code: Select all
> /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
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"?
You do not have the required permissions to view the files attached to this post.
Re: LLDP MED not working if port PVID is not 1
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.
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.
Last edited by FIPTech on Mon Jan 22, 2024 10:42 am, edited 2 times in total.
Re: LLDP MED not working if port PVID is not 1
Sure thing - one moment!
Re: LLDP MED not working if port PVID is not 1
I still see LLDPDU. I will install an LLDP responder on my computer to see that I can get the Voice VLAN.
Code: Select all
> /ip/neighbor/discovery-settings/print
discover-interface-list: LAN
lldp-med-net-policy-vlan: 11
protocol: cdp,lldp,mndp
mode: tx-and-rx
You do not have the required permissions to view the files attached to this post.
Re: LLDP MED not working if port PVID is not 1
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.
I then configured a second list that has the bridge member interface
And set that list for the discovery:
I am now seeing the neighbor on the router. But still no trace of the MED network policy.
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?
Code: Select all
> /ip/neighbor/print
Code: Select all
> /interface/list/member/print
Columns: LIST, INTERFACE
# LIST INTERFACE
0 LAN vlan.10
;;; Outside network
1 WAN vlan.4000
2 LAN-LLDP ether1
Code: Select all
> /ip/neighbor/discovery-settings/print
discover-interface-list: LAN-LLDP
lldp-med-net-policy-vlan: 11
protocol: cdp,lldp,mndp
mode: tx-and-rx
Code: Select all
> /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
Re: LLDP MED not working if port PVID is not 1
You are probably right, LLDP needs low level access to the port, not the VLAN interface on it. I'm going to try that.
Re: LLDP MED not working if port PVID is not 1
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.
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.
Re: LLDP MED not working if port PVID is not 1
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 suspect that only the Default VLAN with ID = 1 can send LLDP MED.
Are you in a VLAN aware bridge too ?
Re: LLDP MED not working if port PVID is not 1
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?
Meanwhile, if you issue "/ip/neighbor/print" to check that you see neighbors?
Re: LLDP MED not working if port PVID is not 1
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.
Re: LLDP MED not working if port PVID is not 1
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: viewtopic.php?t=196403
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: viewtopic.php?t=196403
Re: LLDP MED not working if port PVID is not 1
Nope, not working. Ticket open: SUP-141451.
Re: LLDP MED not working if port PVID is not 1
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 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 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).
Re: LLDP MED not working if port PVID is not 1
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?
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
Re: LLDP MED not working if port PVID is not 1
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.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?
You can drop the packet captures or, if you prefer, screenshots of the LLDPDU.
- 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
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.
Re: LLDP MED not working if port 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.
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.
Re: LLDP MED not working if port PVID is not 1
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 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.
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.LLDP should only be seen untagged. And should never go inside VLANs, or be read from VLANs if i'm right.
I think we have identified two issues here.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...
- MT's LLDP doesn't generate the MED TLV in the LLDPDU (ticket open)
- MT (7.14b7 on RB) bridges the LLDPDU
Re: LLDP MED not working if port PVID is not 1
I do not have a true tap device, but is is not really needed here to confirm those problems. A true TAP would be useful to watch for L1 problems but we are not in this case.
...
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
I was able to setup a passive HUB device to capture between a phone and a router port. I wanted this setup because using a switch port for capture could add some undesired packets in the capture or could filter LLPD traffic. This is specially important when observing LLDP, STP or GVRP problems, that are sitting between layer 1 and layer 2.
I did set all ports to 100 mb/s half duplex for compatibility with the hub. I did connect an Ethernet port of another router (RB3011) on the Hub. I did fully disable CDP, LLDP and MNDP on this auxiliary router, and i did use the packet sniffer tool in stream mode to send the capture packets of this router port (with RX only filter) to Wireshark. Then i did use this capture filter on Wireshark : "udp port 37008", so that i isolate TZSP capture packets.
The results are interesting :
1) I can confirm that inside the RB5009 brigge, LLDP packets, GVRP, and STP are broadcasted between ports... This is terrible, because it can put down a full network.
The first time i did connect the RB5009 on my network, i got such a network failure and i did not understood why it did occur. For the first time in my life, i've seen a Procurve switch crashing and rebooting. This has probably been trigged by the bridging of packets that should not have been forwarded between ports. I suspect that GVRP packets (VLAN distribution) from the Procurve switch connected to the RB5009 router have been looped, causing the switch crash.
If this problem is confirmed by other people, it needs to be corrected asap.
2)
I was able to get Mikrotik LLDP to send the Voice Vlan through LLDP on a untagged VLAN different from VLAN ID = 1.
Instead of using the bridge as the discovery interface, i did use the physical Ethernet Interfaces. Then i was able to get LLDP on untagged VLANs with an ID different from 1.
In fact, if i'm correct, if using the bridge as the discovery interface, LLDP is connected to the VLAN ID that correspond to the PVID of the Bridge. In my case it is PVID=1.
Using physical Ethernet interfaces as discovery interfaces instead of the bridge, i was able to get LLDP on the untagged VLAN of those interface, in my case ID=300 (my guest network).
Now i need to switch off LLDP inside the connected Procurve switch, to see if LLDP MED voice VLAN announcements are really working on the RB5009. Wireshark seems to show correct packets. I'm quite confident here.
Edit : after switching off the Procurve switch, the phone was not able to take the Voice Vlan from the Mikrotik LLDP announcements. I need to check why. Something is probably missing in the Mikrotik LLDP packets. It is not the Voice VLAN ID, it is here.
Observation :
It is possible to send LLDP inside VLANs, that should not be possible. LLDP (STP, GVRP) should be restricted to physical ports.
Last edited by FIPTech on Tue Jan 23, 2024 4:55 pm, edited 1 time in total.
Re: LLDP MED not working if port PVID is not 1
Some observations might be explained with disabled (R/M)STP on the bridge. It is expected to forward reserved multicast MACs 01:80:C2:00:00:0X (LLDP, BPDU, etc.) when using "protocol-mode=none" setting.
Re: LLDP MED not working if port PVID is not 1
STP is disabled on the bridge. I will try to enable it and see if it stops to forward reserved multicast MACs.Some observations might be explained with disabled (R/M)STP on the bridge. It is expected to forward reserved multicast MACs 01:80:C2:00:00:0X (LLDP, BPDU, etc.) when using "protocol-mode=none" setting.
Re: LLDP MED not working if port PVID is not 1
Wow, yup! I tested and that's indeed the case. As FIPTech said that its bridge had STP disabled, I suspect that is why he saw the LLDPDU on each port. Really something I wouldn't have thought of.Some observations might be explained with disabled (R/M)STP on the bridge. It is expected to forward reserved multicast MACs 01:80:C2:00:00:0X (LLDP, BPDU, etc.) when using "protocol-mode=none" setting.
Remains the question about the LLDP-MED network policy TLV which I do not see advertised in my tests. I hope FIPTech will have a different outcome.
Re: LLDP MED not working if port PVID is not 1
I can confirm, enabling RSTP or MSTP stop link layer MAC addresses to be forwarded.Wow, yup! I tested and that's indeed the case. As FIPTech said that its bridge had STP disabled, I suspect that is why he saw the LLDPDU on each port. Really something I wouldn't have thought of.
Remains the question about the LLDP-MED network policy TLV which I do not see advertised in my tests. I hope FIPTech will have a different outcome.
It means that multicast link layer reserved addresses are forwarded when neither STP, RSTP or STP is enabled on bridge. That should not be the case. If link layer protocols that are using those addresses are forwarded, a serious mess can follow in the network.
Reserved link layer multicast addresses should never be forwarded.
As a side note, i loose connectivity with my switches if i enable STP (this is strange, i have no loops), but i was able to test using RSTP and MSTP.
Here is an LLDP frame from the RB5009. We can see the voice VLAN ID = 4000 in it.
In my tests i can see that the RB5009 is sending a pair of two LLDP packets, spaced by 300 us (microsecond). The first one is normal LLDP, the second one is LLDP with the MED and network policy TLVs. That is not normal.
I think that the phone is catching only the first one, without network policy. Then the phone stay on the untagged traffic, instead of switching to the voice VLAN.
Here we can observe the double LLDP announcement, the first packet do not have the voice VLAN 4000 :
You do not have the required permissions to view the files attached to this post.
Re: LLDP MED not working if port PVID is not 1
One issue down, 99 to go!I can confirm, enabling RSTP or MSTP stop link layer MAC addresses to be forwarded.
I guess the first thing to look would be whether you have something like rootguard or bpduguard on the HP switch. Or set a very low priority on the Mikrotik to make sure it can't be root. We can troubleshoot that in another thread if you want.As a side note, i loose connectivity with my switches if i enable STP (this is strange, i have no loops), but i was able to test using RSTP and MSTP.
Can you send again the discovery config and the interface list associated with it?Here is an LLDP frame from the RB5009. We can see the voice VLAN ID = 4000 in it.
On 7.13.2, despite what I can try, no LLDP-MED TLV.
You do not have the required permissions to view the files attached to this post.
Re: LLDP MED not working if port PVID is not 1
A)
The LLDP forwarding problem was detected two years ago :
viewtopic.php?t=182667
I think that the default should be filtering of the reserved LLDP multicast MAC address (01:80:c2:00:00:0e), even if (R/M)STP is disabled. And eventually give an option to disable the filtering but obviously i can't imagine a case where this would be necessary. All manageable switches and even probably all switches are filtering this address.
The IEEE reserved addresses table indicate that the LLDP multicast destination address should never be forwarded :
B)
My discovery config is actually very simple, the discovery interface list has only the LANs bridge in it. No other interfaces.
I reverted to that because it is the default RouterOS 7 configuration : that should works.
To test the voice VLAN ID diffusion and catching by the phone, i did put the phone port PVID = 1.
In this setup, i do not get the double LLDP announcements anymore, i can get the voice vlan (id = 4000) announced in the LLDP network policy, but Mitel phones still do not want to accept it.
I'm still trying to understand why.
The same phone that will receive LLDP from a Procurve switch will switch to the voice VLAN. For some reason, it doesn't work if the phone is connected to a RB5009 router port.
It could be because Emergency Location Identification Number (ELIN) is not supported in Mikrotik LLDP. But i'm not sure about that.
This function is used to change the caller ID to a number given by the switch for urgency calls.
Edit : no; i tried to add this capability and inject the modified LLDP packet, without success.
This is supported on HP switches.
Another small difference is the Ethernet II trailer of LLDP packets, it is 0xae0000 for Procurve LLDP Frames, and 0x000000 for Mikrotik LLDP. Not sure if that could have an influence.
Edit : no, this seems to be a Wireshark dissecting problem.
I did notice that Mikrotik LLDP is using the port MAC address instead of the bridge mac address. But that seems to be the same for Procurve switches. The 802.1AB LLDP standard does not seem to forbid that :
Edit, after a few tries changing the LLDP packet source address, this had no effect.
Edit : i tried to modify and inject a Mikrotik LLDP packet, using COS = 6 and DSCP = 46, this had no influence.
Edit, ----- An interesting finding :
I found something interesting watching the captures, it seems that RouterOS does not have an LLDP fast timer.
On the Procurve switches, i can see the change in LLDP TX timings, and i can observe an LLDP packet that is immediately sent after the switch receives a phone LLDP packet.
This is probably the reason why the phones are not catching the router LLDP announcements.
Here is an LLDP capture where we can see the Procurve switch LLDP fast timer coming into action :
In this capture we can see a 1 second timing in the LLDP packets, and a fast answer of the HP switch, as soon as it receives an LLDP packet from the Mitel phone. This is not the case with Mikrotik RouterOS. Seems like RouterOS does not have an LLDP state machine that controls timing changes.
Edit : i did try to manually inject Mikrotik LLDP packets during phone boot to mimic the LLDP fast timer. No effect...
This does not really mean that the fast timer and state machine is not mandatory. But there is still something else preventing the phone to take the received LLDP MED voice vlan.
Then i did try to manually inject clones of the Procurve LLDP MED packets during phone boot. It did work.
In fact there is no need for an immediate send after receiving a phone LLDP packet. This mean that the LLDP state machine is here to speedup things, and at least with Mitel phones, the faster LLDP timer and state machine is not mandatory.
This mean that the problem does come from the formatting of the Mikrotik LLDP packet. Perhaps because the 802.3 MAC/phy TLV is missing. I need to check that, if i can add this TLV to a Mikrotik LLDP packet, and inject that in the phone link. Not so simple...
The LLDP forwarding problem was detected two years ago :
viewtopic.php?t=182667
I think that the default should be filtering of the reserved LLDP multicast MAC address (01:80:c2:00:00:0e), even if (R/M)STP is disabled. And eventually give an option to disable the filtering but obviously i can't imagine a case where this would be necessary. All manageable switches and even probably all switches are filtering this address.
The IEEE reserved addresses table indicate that the LLDP multicast destination address should never be forwarded :
https://standards.ieee.org/products-pro ... ac/public/b It is intended that no IEEE 802.1 relay device will be defined that will forward frames that carry this destination address.
B)
My discovery config is actually very simple, the discovery interface list has only the LANs bridge in it. No other interfaces.
I reverted to that because it is the default RouterOS 7 configuration : that should works.
To test the voice VLAN ID diffusion and catching by the phone, i did put the phone port PVID = 1.
In this setup, i do not get the double LLDP announcements anymore, i can get the voice vlan (id = 4000) announced in the LLDP network policy, but Mitel phones still do not want to accept it.
I'm still trying to understand why.
The same phone that will receive LLDP from a Procurve switch will switch to the voice VLAN. For some reason, it doesn't work if the phone is connected to a RB5009 router port.
It could be because Emergency Location Identification Number (ELIN) is not supported in Mikrotik LLDP. But i'm not sure about that.
This function is used to change the caller ID to a number given by the switch for urgency calls.
Edit : no; i tried to add this capability and inject the modified LLDP packet, without success.
This is supported on HP switches.
Another small difference is the Ethernet II trailer of LLDP packets, it is 0xae0000 for Procurve LLDP Frames, and 0x000000 for Mikrotik LLDP. Not sure if that could have an influence.
Edit : no, this seems to be a Wireshark dissecting problem.
I did notice that Mikrotik LLDP is using the port MAC address instead of the bridge mac address. But that seems to be the same for Procurve switches. The 802.1AB LLDP standard does not seem to forbid that :
Edit, after a few tries changing the LLDP packet source address, this had no effect.
Then i did see another small difference, Procurve switches announce the COS and DSCP priorities in the MED Network policy, this is not the case for Mikrotik.8.2 Source address
The source address shall be the MAC address of the sending station or port."
Edit : i tried to modify and inject a Mikrotik LLDP packet, using COS = 6 and DSCP = 46, this had no influence.
Edit, ----- An interesting finding :
I found something interesting watching the captures, it seems that RouterOS does not have an LLDP fast timer.
A device that is enabled with Link Layer Discovery Protocol (LLDP) transmits LLDP packets to neighboring nodes at a specified time interval. Fast transmission periods are initiated when a new neighbor is detected, and cause LLDP packets to be transmitted at a shorter time interval than during normal operation of the protocol. The fast transmission period ensures that more than one LLDP packet is transmitted when a new neighbor is detected. The first transmission is immediate, and the subsequent transmissions occur at the specified fast transmission (TX) interval.
This fast timer is generally 1 second. I do not see those packets in the capture, neither the router LLDP packet that should immediately follow an LLDP phone announcement.When LLDP receives an
advertisement indicating a newly connected LLDP-MED-capable device on a port, it
transmits one LLDP-MED advertisement per second via this port, a configurable number
of times (the fast start count). Thereafter, it sends regular advertisements at the LLDP
transmit interval. When the last advertisement for an LLDP-MED-capable device
connected to the port times out, it stops sending LLDP-MED advertisements via the port.
On the Procurve switches, i can see the change in LLDP TX timings, and i can observe an LLDP packet that is immediately sent after the switch receives a phone LLDP packet.
This is probably the reason why the phones are not catching the router LLDP announcements.
Here is an LLDP capture where we can see the Procurve switch LLDP fast timer coming into action :
In this capture we can see a 1 second timing in the LLDP packets, and a fast answer of the HP switch, as soon as it receives an LLDP packet from the Mitel phone. This is not the case with Mikrotik RouterOS. Seems like RouterOS does not have an LLDP state machine that controls timing changes.
Edit : i did try to manually inject Mikrotik LLDP packets during phone boot to mimic the LLDP fast timer. No effect...
This does not really mean that the fast timer and state machine is not mandatory. But there is still something else preventing the phone to take the received LLDP MED voice vlan.
Then i did try to manually inject clones of the Procurve LLDP MED packets during phone boot. It did work.
In fact there is no need for an immediate send after receiving a phone LLDP packet. This mean that the LLDP state machine is here to speedup things, and at least with Mitel phones, the faster LLDP timer and state machine is not mandatory.
This mean that the problem does come from the formatting of the Mikrotik LLDP packet. Perhaps because the 802.3 MAC/phy TLV is missing. I need to check that, if i can add this TLV to a Mikrotik LLDP packet, and inject that in the phone link. Not so simple...
You do not have the required permissions to view the files attached to this post.
Re: LLDP MED not working if port PVID is not 1
.
I did find the problem.
RouterOS does not include a 802.3 MAC/PHY TLV in its LLDP MED packets.
The 802.3 MAC/PHY Configuration/Status TLV is mandatory for all LLDP-MED devices to both send and receive.
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.
Here is a capture where we can see a Mitel Phone catching a modified RouterOS LLDP MED Packet, where i did add a MAC/PHY TLV.
- The first packet is the phone LLDP packet before voice VLAN auto configuration. VLAN ID = 0 (not configured).
- The second one is the modified RouterOS LLDP MED announcement with the MAC/PHY TLV
- The third one is the phone LLDP packet where we can see that the phone got the voice VLAN ID = 4000
. .
And here the modified RouterOS LLDP MED packet with an added MAC/PHY TLV.
The original packet has been captured with the packet sniffer, edited, then injected with the packet generator during the phone boot :
.
I did find the problem.
RouterOS does not include a 802.3 MAC/PHY TLV in its LLDP MED packets.
The 802.3 MAC/PHY Configuration/Status TLV is mandatory for all LLDP-MED devices to both send and receive.
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.
Here is a capture where we can see a Mitel Phone catching a modified RouterOS LLDP MED Packet, where i did add a MAC/PHY TLV.
- The first packet is the phone LLDP packet before voice VLAN auto configuration. VLAN ID = 0 (not configured).
- The second one is the modified RouterOS LLDP MED announcement with the MAC/PHY TLV
- The third one is the phone LLDP packet where we can see that the phone got the voice VLAN ID = 4000
. .
And here the modified RouterOS LLDP MED packet with an added MAC/PHY TLV.
The original packet has been captured with the packet sniffer, edited, then injected with the packet generator during the phone boot :
.
You do not have the required permissions to view the files attached to this post.
Re: LLDP MED not working if port PVID is not 1
To conclude, the real problem is the missing MAC/PHY TLV.
LLDP is working if port PVID is not 1.
I thought that it was not working because when i did setup a different ID, this did cut the forwarding of the Procurve switch LLDP connected to the RB5009 on the same bridge. Then the phone was not able to receive anymore a correct LLDP MED packet from the switch and was not booting. This side effect did was disturbing to find the real culprit.
This would be a bit long to explain, but in the end the packet analysis was necessary to diagnose those mixed problems and find the real culprit.
LLDP is working if port PVID is not 1.
I thought that it was not working because when i did setup a different ID, this did cut the forwarding of the Procurve switch LLDP connected to the RB5009 on the same bridge. Then the phone was not able to receive anymore a correct LLDP MED packet from the switch and was not booting. This side effect did was disturbing to find the real culprit.
This would be a bit long to explain, but in the end the packet analysis was necessary to diagnose those mixed problems and find the real culprit.
Last edited by FIPTech on Thu Jan 25, 2024 3:21 pm, edited 2 times in total.
Re: LLDP MED not working if port PVID is not 1
:thumb up:
I saw the other post, if you haven't already, I will create a bug report.
I saw the other post, if you haven't already, I will create a bug report.
Re: LLDP MED not working if port PVID is not 1
Yes please create a bug report based on the thread below. Thanks a lot for the help you did provide as well other participants.
For reference, the summary thread :
viewtopic.php?t=203774
For reference, the summary thread :
viewtopic.php?t=203774
Re: LLDP MED not working if port PVID is not 1
LLDP MED and Port PVID: Unraveling the Connection
The statement "LLDP MED not working if port PVID is not 1" is partially true, but with nuances:
Understanding the Terms:
LLDP MED: Link Layer Discovery Protocol - Media Endpoint Discovery. It allows network devices to advertise their capabilities and network settings to connected devices, including voice-over-IP (VoIP) phones.
Port PVID: Port Protocol VLAN ID. This defines the untagged VLAN traffic carried on a switch port. Setting it to 1 means all untagged traffic on that port belongs to VLAN 1.
The Nuances:
LLDP MED can work regardless of the port PVID. It primarily advertises capabilities, not VLAN information. However, some specific aspects of MED, like configuring voice VLAN on connected devices, may be affected by the PVID:
Auto Voice VLAN: If the switch uses LLDP MED to automatically assign a voice VLAN to a device, and the device expects the voice VLAN to be untagged, setting the PVID to 1 ensures the voice traffic arrives untagged, facilitating automatic configuration.
OUI-based VLAN participation: When identifying devices based on their Organizationally Unique Identifier (OUI) using LLDP MED, the switch might expect the device's traffic to be untagged if the PVID is 1.
Therefore:
LLDP MED core functionality is not dependent on port PVID being 1.
Specific applications of LLDP MED, especially for VoIP devices and automatic configuration, might require the PVID to be 1 for optimal operation.
Recommendations:
Consult your network switch documentation and the specific devices you're using to understand their LLDP MED behavior and recommended PVID settings.
If you encounter issues with automatic voice VLAN or OUI-based configuration using LLDP MED, setting the PVID to 1 on relevant ports might be a troubleshooting step.
Remember, troubleshooting network issues like this often requires examining various factors beyond just the PVID setting.
The statement "LLDP MED not working if port PVID is not 1" is partially true, but with nuances:
Understanding the Terms:
LLDP MED: Link Layer Discovery Protocol - Media Endpoint Discovery. It allows network devices to advertise their capabilities and network settings to connected devices, including voice-over-IP (VoIP) phones.
Port PVID: Port Protocol VLAN ID. This defines the untagged VLAN traffic carried on a switch port. Setting it to 1 means all untagged traffic on that port belongs to VLAN 1.
The Nuances:
LLDP MED can work regardless of the port PVID. It primarily advertises capabilities, not VLAN information. However, some specific aspects of MED, like configuring voice VLAN on connected devices, may be affected by the PVID:
Auto Voice VLAN: If the switch uses LLDP MED to automatically assign a voice VLAN to a device, and the device expects the voice VLAN to be untagged, setting the PVID to 1 ensures the voice traffic arrives untagged, facilitating automatic configuration.
OUI-based VLAN participation: When identifying devices based on their Organizationally Unique Identifier (OUI) using LLDP MED, the switch might expect the device's traffic to be untagged if the PVID is 1.
Therefore:
LLDP MED core functionality is not dependent on port PVID being 1.
Specific applications of LLDP MED, especially for VoIP devices and automatic configuration, might require the PVID to be 1 for optimal operation.
Recommendations:
Consult your network switch documentation and the specific devices you're using to understand their LLDP MED behavior and recommended PVID settings.
If you encounter issues with automatic voice VLAN or OUI-based configuration using LLDP MED, setting the PVID to 1 on relevant ports might be a troubleshooting step.
Remember, troubleshooting network issues like this often requires examining various factors beyond just the PVID setting.
Re: LLDP MED not working if port PVID is not 1
Thanks for the explanation.
I think that i need to make things clearer.
LLDP MED is practically non-operational on Router OS, but the real problem is not bridge port PVID = 1 or bridge port PVID = something else.
The real problems are described in this summary thread which should be read before :
viewtopic.php?t=203774
The real problems are :
1) Missing MAC/PHY TLV inside LLDP-MED RouterOS announcements (causing phones to reject the packets). MAC/PHY TLV is mandatory for LLDP-MED.
2) Missing LLDP-MED enhanced state machine with fast start mechanism (if LLDP-MED is only sent every 30 seconds or more, there are large chances that the phones do not catch an LLDP-MED packet before the end of their LLDP-MED waiting slot.
3) 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 can lead to LLDP induced confusion because phones (or other devices) can receive LLDP packets coming from other switches or routers.
Now i need to explain why at first i thought that LLDP-MED was not working or not sent when bridge port PVID ID is not 1 :
This is a side effect of problem 3 : my bridge had (R/M)STP protocol disabled. Then because of bug 3) i did received on phones LLDP-MED packets from another Procurve switch. At first, i was thinking that RouterOS LLDP-MED was working because my phones did boot on the correct voice vlan.
PVID of the phones ports was then set to 1. In fact, the phones did boot correctly on the right voice VLAN only because they did receive correct LLDP-MED traffic from the Procurve switch.
After i decided to change the untagged VLAN of phones, because i wanted to use guest VLAN for the phones secondary PC ports. I did change PVID ID to ID = 300 for all phones connected to the RB5009.
Then the phones where not able to boot correctly, not catching anymore the voice VLAN ID. I tought that RouterOS was stopping to send LLDP traffic when PVID was different from 1. I was wrong.
The truth was different. A packet analysis was needed to see that when i did switch to PVID = 300, the phones did not receive anymore the LLDM-MED announcements from the Procurve switch connected to another bridge port, with PVID = 1.
In fact they did still receive the (not working) LLDP-MED announcements from RouterOS, but did reject them because those packets are missing the MAC/PHY TLV. That's why i thought primarily that switching the phone ports to a PVID different from 1 was the problem.
Here is the full story. PVID = 1 or not is not the problem. Let me know if something is not clear.
This study was very interesting, it shows that when there are two problems at the same time, confusion can lead to difficult troubleshooting.
In the end, the only important things to keep into consideration are summarized in this thread :
viewtopic.php?t=203774
I think that i need to make things clearer.
LLDP MED is practically non-operational on Router OS, but the real problem is not bridge port PVID = 1 or bridge port PVID = something else.
The real problems are described in this summary thread which should be read before :
viewtopic.php?t=203774
The real problems are :
1) Missing MAC/PHY TLV inside LLDP-MED RouterOS announcements (causing phones to reject the packets). MAC/PHY TLV is mandatory for LLDP-MED.
2) Missing LLDP-MED enhanced state machine with fast start mechanism (if LLDP-MED is only sent every 30 seconds or more, there are large chances that the phones do not catch an LLDP-MED packet before the end of their LLDP-MED waiting slot.
3) 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 can lead to LLDP induced confusion because phones (or other devices) can receive LLDP packets coming from other switches or routers.
Now i need to explain why at first i thought that LLDP-MED was not working or not sent when bridge port PVID ID is not 1 :
This is a side effect of problem 3 : my bridge had (R/M)STP protocol disabled. Then because of bug 3) i did received on phones LLDP-MED packets from another Procurve switch. At first, i was thinking that RouterOS LLDP-MED was working because my phones did boot on the correct voice vlan.
PVID of the phones ports was then set to 1. In fact, the phones did boot correctly on the right voice VLAN only because they did receive correct LLDP-MED traffic from the Procurve switch.
After i decided to change the untagged VLAN of phones, because i wanted to use guest VLAN for the phones secondary PC ports. I did change PVID ID to ID = 300 for all phones connected to the RB5009.
Then the phones where not able to boot correctly, not catching anymore the voice VLAN ID. I tought that RouterOS was stopping to send LLDP traffic when PVID was different from 1. I was wrong.
The truth was different. A packet analysis was needed to see that when i did switch to PVID = 300, the phones did not receive anymore the LLDM-MED announcements from the Procurve switch connected to another bridge port, with PVID = 1.
In fact they did still receive the (not working) LLDP-MED announcements from RouterOS, but did reject them because those packets are missing the MAC/PHY TLV. That's why i thought primarily that switching the phone ports to a PVID different from 1 was the problem.
Here is the full story. PVID = 1 or not is not the problem. Let me know if something is not clear.
This study was very interesting, it shows that when there are two problems at the same time, confusion can lead to difficult troubleshooting.
In the end, the only important things to keep into consideration are summarized in this thread :
viewtopic.php?t=203774