Community discussions

MikroTik App
just joined
Topic Author
Posts: 1
Joined: Tue Nov 01, 2022 3:44 pm

CDP discovering neighbor of neighbor

Thu Nov 03, 2022 4:58 pm

I have a Mikrotik CRS354-48G-4S+2Q+ that I am using in a test environment with a Cisco WS-C3850-48XS connected to ether1 and a vmware host connected to ether24. I have added a management interface that is connected to ether48 and is in a different vlan (I turned on mst as part of this), but apart from that the configuration is all default.

The issue I am experiencing is that the vSwitch on the vmware host connected to ether24 displays its CDP neighbor as alternately ether24 of the mikrotik router or te1/0/1 of the cisco switch (presumably alternating depending on the last cdp packet it received). This is unwanted behavior as the cisco switch is not directly connected to the vmware host.

As a test I created an interface list of just ether24 and set /ip neighbor discovery-settings to use this list. With this in effect the Cisco switch no longer saw the mikrotik router on ether1, however the vmware host still saw both ether24 and te1/0/1 as connected

Looking on this forum I found an indication that cdp frames might be getting forwarded over the bridge, the recommendation was to add a bridge filter for 01:00:0C:CC:CC:CC, I added the rules as I believed was correct however doing "print stats" from /interface bridge filter shows that the rules are not being hit. This has also had no effect on what the vmware host sees as its neighbor.

Can someone please confirm that the issue is caused by CDP packets being forwarded by the bridge? If so, how can I correctly prevent this?

I have attached the config of my mikrotik router.
You do not have the required permissions to view the files attached to this post.
MikroTik Support
MikroTik Support
Posts: 128
Joined: Fri Sep 15, 2017 10:05 am
Location: Riga

Re: CDP discovering neighbor of neighbor  [SOLVED]

Fri Nov 04, 2022 2:24 pm

Correct, the CDP 01:00:0C:CC:CC:CC gets forwarded on RouterOS hardware-offloaded and software bridges just like regular multicast traffic.

If you have a software bridge, then you can filter these packets using bridge filter rules.

But if you have a hardware-offloaded bridge, these rules will not apply because packets are forwarded on the switch without passing through the bridge filter rules (on CPU). In the case of BUM traffic, sometimes you will be able to see packets on the CPU if vlan-filtering allows that and thus can filter with bridge rules, but the bridge will not forward packets back to the group of HW offloaded ports anyways, because it knows that switch has already done the forwarding job and avoids duplicate packets.

But you can use switch rules to drop these packets on ingress ports, for example, to drop received CDP on ether2 and ether3, use this rule:
/interface ethernet switch rule
add dst-mac-address=01:00:0C:CC:CC:CC/FF:FF:FF:FF:FF:FF ports=ether2,ether3 new-dst-ports="" switch=switch1
If you still want to receive CDP on the switch itself, but do not want to forward them, you can use redirect-to-cpu option:
/interface ethernet switch rule
add dst-mac-address=01:00:0C:CC:CC:CC/FF:FF:FF:FF:FF:FF ports=ether2,ether3 redirect-to-cpu=yes switch=switch1

Who is online

Users browsing this forum: Amazon [Bot], Majestic-12 [Bot] and 13 guests