I have configured neighbor discovery on a bridge interface, and am now seeing multiple neighbors per physical interface, which does not seem useful.
After an initial investigation, having the CDP and MNDP protocols enabled seems to exhibit this behavior. If I enable only LLDP, and make sure to have LLDP enabled in the other end, it seems to only discover the directly connected device, as I would expect. It is my understanding that this is the intended behavior, and I thought that at least CDP is supposed to mimic LLDP in that regard. Not sure about MNDP.
I guess I can use only LLDP if that is necessary. Would like to know what the intended behavior is.
This is on 6.48.6. I have witnessed the same behavior on at least some slightly older versions, too.
Are you sure your multiple neighbors are all discovered using LLDP? You know RouterOS can discover neighbors in multiple ways?
What is connected to those ports?
Those protocols (MNDP/CDP) were meant to reveal devices in the same L2 broadcast domain, not to show “only physical directly connected devices”,
so everything works as it’s supposed to.
If you put it on the bridged interface how do you expect anything other than crawling on all bound interfaces?
Obviously, if you want to analyze only one port, you don’t have to do the discovery on the bridge but on a group of interfaces,
and in that group you insert the interfaces (or only one) on which the discovery must be maded.
I forgot to mention that all discovered devices are MikroTiks. (including the directly connected device) There are no other vendors in the network (with LLDP enabled, at least), and I don't think I have tested with any other.
What do you mean? I do expect it to discover neighbors on all bridged ports. What I didn't expect is multiple neighbors per port.
I guess MikroTik's documentation does say that it shows all L2 neighbor devices, but I have never heard of that behavior being true for CDP. This is what it says in one of their documents, at least:
Cisco Discovery Protocol is a Layer 2, media-independent, and network-independent protocol that networking
applications use to learn about nearby, directly connected devices
Talk about device**S** not single device, and for each port you can have only one device directly connected…
Is better “interconnected on layer2” than the only word “connected”, can be misunderstanded…
Functionality to show the actual port name in contexts where some function was enabled on a bridge has been added in v7.
So in the future you will be able to see on which physical port a device is actually connected (e.g. in neighbors, arp, dhcp).
Not sure what functionality that refers to, exactly, but it already works like that for neighbor discovery, as far as I can tell.
Since RouterOS v6.44, neighbor discovery is working on individual slave interfaces. Whenever a master interface (e.g. bonding or bridge) is included in the discovery interface list, all its slave interfaces will automatically participate in neighbor discovery.
I see physical ports both for the local and the remote device.
The only thing I have noticed is that when you configure discovery on VLAN interfaces, it shows that as the interface rather than a physical one.
Right, I could have been more clear. The issue is that it is showing _in_directly connected devices in addition to directly connected ones, hence listing all discoverable devices for each physical port, rather than only the directly connected device. I understand now that this is the intended behavior of MNDP and sometimes CDP.
Thanks. I probably don’t need to use VLAN interfaces for discovery, anyway.
So basically, other vendors do not implement CDP as intended by Cisco, and thus LLDP is the only reliable way to discover directly connected devices, eh.
Well, the difference between CDP and MNDP is that CDP is using a multicast MAC and that switches “are supposed” to drop this (not forward it even when multicast flooding is in use).
In practice, low-end switches do not always adhere to that, and probably MikroTik bridges as well (did not check that).
But MNDP is using local broadcast (IP 255.255.255.255 MAC FF:FF:FF:FF:FF:FF) so it IS forwarded by switches.
When you see many devices it, however, is indicative of a (design) problem in your network. Try to limit the reach of broadcasts.
E.g. when you have a router, with a WiFi link to another router, make the port connecting to the WiFi AP (on both routers) a separate port not member of a bridge, and assign a small subnet (e.g. a /29) at IP level.
Now you see only the MNDP from the 2 APs and the remote router on this port. And you can use the link for routing, either statically or using a routing protocol like BGP or OSPF.
That is a better network design than just bridging everything together.
I would say the reverse - most switches will treat unknown multicast in the same way as broadcast and forward it to all ports, if they did not do this IPv6 would break.
On managed switches there may be options to drop unknown multicast or filter certain multicast addresses. The Mikrotik CRS1xx/2xx devices have a rich set of layer 2 FDB & filter features, other Mikrotik devices with switch chips supporting rule tables most likely can also be configured not to forward CDP, a static bridge host entry may work too.
