I am hoping someone could explain (i.e., help me understand) what is going on here.
These devices are set up now in a lab environment (i.e., for testing and learning), but I hope to deploy soon.
hEX Refresh with ether1 (WAN) connected to this location's LAN so it can get Internet access.
ether2 is connected to a NetMetalax
ether3 is connected to a cAPax
VLAN32 (172.16.32.0/24) is the management vlan that all three of these devices are on and use to communicate.
From the hEX, IP NEIGHBORS shows both the NetMetalax as well as the cAPax twice, as shown below.
Any idea why I am seeing duplicate entries, albeit one of each without the IP address?
And, why the different mac addresses only for the NetMetalax (not for the cAPax)?
IP Neighbors and VLANS
You do not have the required permissions to view the files attached to this post.
Re: IP Neighbors and VLANS
Little more info:
On the cAP, ether1 and bridge have the same MAC address.
On the NetMetal, ether1 and bridge have different MAC addresses.
On both devices, both ether1 and bridge are tagged for vlan32.
I think this explains the different MAC addresses, but I'd like to understand why there are 2 instances displayed in IP NEIGHBORS on the hEX.
On the cAP, ether1 and bridge have the same MAC address.
On the NetMetal, ether1 and bridge have different MAC addresses.
On both devices, both ether1 and bridge are tagged for vlan32.
I think this explains the different MAC addresses, but I'd like to understand why there are 2 instances displayed in IP NEIGHBORS on the hEX.
Re: IP Neighbors and VLANS
Because the neigbor advertisement protocols (any combination of MNDP, LLDP, and CDP depending on the settings) are being sent from all interfaces that are members of the interface list configured in the discover-interface-list item under /ip neighbor disovery-settings, indicating their respective MAC addresses and IP addresses. Since in bothn cases, ether1 is a member port of a bridge, no IP address is attached to it directly, hence the advertisement sent from these interfaces does not contain any, whereas those sent from the bridge interfaces do.I'd like to understand why there are 2 instances displayed in IP NEIGHBORS on the hEX.
Re: IP Neighbors and VLANS
Agree. But this one is tricky. And the operation is NOT documented well (actually have on open issue that the neighbor docs should be improved).
The key is that "neighbors" can one of three types (MNDP, CDP, LLDP) & that's one way you can end up with multiple entries. Specially MNDP is Mikrotik-specific and what winbox uses, and it's based on regular UDP broadcasts to 255.255.255.255, send at the interval= set in /ip/neighbors. And since it tied to UDP broadcasts, it will be sent on any VLAN that's covered by interface list set in /ip/neighbors (i.e. if a VLAN is in the interface-list, the router will be discoverable on that VLAN). And even with MNDP, depending on where you look, you'll see same router multiple times if it came from different interfaces (i.e. Wi-Fi and ethernet, etc).
LLDP is a different animal than Mikrotik's MNDP, it is a standard and is more complex. It operates at the L2/ethernet level. It's typical main use case with VoIP or 3rd party network monitoring/management tools, since it is a standard discovery. There are scheme in LLDP for VLAN, but interaction with vlan-filtering=yes bridge add other twists. But AFAIK winbox does not use LLDP, but it will also show more entries in /ip/neighbors. Unless you have some outside need for LLDP, it likely can be disabled.
CDP is Cisco's protocol, so unless you older Cisco stuff that looking for Mikrotik, that can be disabled.
The key is that "neighbors" can one of three types (MNDP, CDP, LLDP) & that's one way you can end up with multiple entries. Specially MNDP is Mikrotik-specific and what winbox uses, and it's based on regular UDP broadcasts to 255.255.255.255, send at the interval= set in /ip/neighbors. And since it tied to UDP broadcasts, it will be sent on any VLAN that's covered by interface list set in /ip/neighbors (i.e. if a VLAN is in the interface-list, the router will be discoverable on that VLAN). And even with MNDP, depending on where you look, you'll see same router multiple times if it came from different interfaces (i.e. Wi-Fi and ethernet, etc).
LLDP is a different animal than Mikrotik's MNDP, it is a standard and is more complex. It operates at the L2/ethernet level. It's typical main use case with VoIP or 3rd party network monitoring/management tools, since it is a standard discovery. There are scheme in LLDP for VLAN, but interaction with vlan-filtering=yes bridge add other twists. But AFAIK winbox does not use LLDP, but it will also show more entries in /ip/neighbors. Unless you have some outside need for LLDP, it likely can be disabled.
CDP is Cisco's protocol, so unless you older Cisco stuff that looking for Mikrotik, that can be disabled.
Last edited by Amm0 on Sat Mar 22, 2025 5:57 pm, edited 1 time in total.
Re: IP Neighbors and VLANS
Wow!Because the neigbor advertisement protocols (any combination of MNDP, LLDP, and CDP depending on the settings) are being sent from all interfaces that are members of the interface list configured in the discover-interface-list item under /ip neighbor disovery-settings, indicating their respective MAC addresses and IP addresses. Since in bothn cases, ether1 is a member port of a bridge, no IP address is attached to it directly, hence the advertisement sent from these interfaces does not contain any, whereas those sent from the bridge interfaces do.I'd like to understand why there are 2 instances displayed in IP NEIGHBORS on the hEX.
A clear, concise, full, and accurate response -- as usual from @sindy.
Thank you very much.
Re: IP Neighbors and VLANS
This very much expands on, and more fully explains, what is going on. Here, too, thank you!Agree. But this one is tricky. And the operation is NOT documented well (actually have on open issue that the neighbor docs should be improved).
The key is that "neighbors" can one of three types (MNDP, CDP, LLDP) & that's one way you can end up with multiple entries. Specially MNDP is Mikrotik-specific and what winbox uses, and it's based on regular UDP broadcasts to 255.255.255.255, send at the interval= set in /ip/neighbors. And since it tied to UDP broadcasts, it will be sent on any VLAN that's covered by interface list set in /ip/neighbors (i.e. if a VLAN is in the interface-list, the router will be discoverable on that VLAN). And even with MNDP, depending on where you look, you'll see same router multiple times if it came from different interfaces (i.e. Wi-Fi and ethernet, etc).
LLDP is a different animal than Mikrotik's MNDP, it is a standard and is more complex. It operates at the L2/ethernet level. It's typical main use case with VoIP or 3rd party network monitoring/management tools, since it is a standard discovery. There are scheme in LLDP for VLAN, but interaction with vlan-filtering=yes bridge add other twists. But AFAIK winbox does not use LLDP, but it will also show more entries in /ip/neighbors. Unless you have some outside need for LLDP, it likely can be disabled.
CDP is Cisco's protocol, so unless you older Cisco stuff that looking for Mikrotik, that can be disabled.
Are you suggesting that I can disable the LLDP and CDP discovery protocols everywhere if I have no Cisco or other equipment that needs to be discoverable?
Taking the complexity of the conversation back down to my low level: Any idea how and/or why ether1 and bridge share the same mac address on the cAP whereas they have different MAC addresses on the NetMetal?
Re: IP Neighbors and VLANS
That has nothing to do with discovery protocols but with how the bridge is implemented. Unless you specify a MAC address for a bridge manually, it inherits the MAC address from one of its member ports, in particular, the first one to become available, and maintains it unless/until that interface is moved away from the bridge. That's why it is recommended to set admin-mac to yes and specify the MAC address of the bridge manually.how and/or why ether1 and bridge share the same mac address on the cAP whereas they have different MAC addresses on the NetMetal?
Re: IP Neighbors and VLANS
Understood that MAC address is not related to the discovery protocols.That has nothing to do with discovery protocols but with how the bridge is implemented. Unless you specify a MAC address for a bridge manually, it inherits the MAC address from one of its member ports, in particular, the first one to become available, and maintains it unless/until that interface is moved away from the bridge. That's why it is recommended to set admin-mac to yes and specify the MAC address of the bridge manually.how and/or why ether1 and bridge share the same mac address on the cAP whereas they have different MAC addresses on the NetMetal?
I have admin-mac defined on all devices, and auto-mac=no.
Re: IP Neighbors and VLANS
OK, but for some reason, it is the MAC of ether1 on the cAP whereas it is the address of some other interface, or unrelated to any interface, on the NetMetal. It is a "locally administered one" (because the least significant digit of the first byte is 2, 6, a, or e), so unless you have created it manually, it seems to be inherited from some L2 tunnel interface (EoIP, VPLS, VXLAN).I have admin-mac defined on all devices, and auto-mac=no.
Re: IP Neighbors and VLANS
Also see viewtopic.php?p=992390#p992390, the latter paragraphs explain why some neighbours are listed against an /interface vlan rather than a physical port. I usually keep management traffic untagged on the bridge-to-CPU port to avoid this.