RB5009 bridge with l2hw forwards LLDP packets?

Hardware MikroTik hardware general
1

I’m working on a network with 2 Switchzilla SG250 floor switches connected to a RB5009 acting as router and core switch.


switch-sz(gi8) <--> (ether4)RB5009-bridge1-l2hw(ether3) <--> (gi1)switch-wz

Very happy with that so far, RB5009 bridge1 bridging, VLAN filtering, STP, IGMP and DHCP snooping is all working with l2hw offload at wirespeed. A big advantage over RB4011.
But we noticed the SG250 switches both issue warnings about detecting ingress LLDP packets from more than one source on gi8 resp. gi1.

switch-sz# show lldp neighbors
  Port        Device ID          Port ID         System Name    Capabilities  TTL  
--------- ----------------- ----------------- ----------------- ------------ ----- 
gi8       dc:2c:6e:45:d2:e3  bridge1/ether4        RB5009           B, R      75   
gi8       b8:11:4b:1a:6f:4c        gi1            switch-wz          B        96   

switch-wz# show lldp neighbors 
  Port        Device ID          Port ID         System Name    Capabilities  TTL  
--------- ----------------- ----------------- ----------------- ------------ ----- 
gi1       dc:2c:6e:45:d2:e3  bridge1/ether3        RB5009           B, R      117  
gi1       b8:11:4b:1a:6a:40        gi8            switch-sz          B        108  

[admin@RB5009] > ip/neighbor/print 
0  ether3     B8:11:4B:1A:6F:4D  switch-wz
   bridge1                                
1  ether4     B8:11:4B:1A:6A:48  switch-sz
   bridge1

Obviously the RB5009 forwards incoming LLDP packets ether3<->ether4. This makes the switches believe they are interconnected with a direct physical link. While in reality the RB5009 switch chip is inbetween. In result the switches try to adjust advanced power managment, MAC/PHY etc parameters using IEEE802.3 TLVs assuming a direct physical connection.

This problems can worked around by adapting the SG250 LLDP port configs.
But in genereal LLDP packets carry parameters specific to the physical egress port and hence should not be forwarded between switch/bridge ports. Especially if LLDP-MED comes into play, forwarding incoming LLDP between physical ports will cause confusion.

==============================
Edit:
Just figured out the easist work around is to use RB5009 switch rules:

[admin@RB5009] /interface/ethernet/switch/rule> add switch=switch1 ports=ether3,ether4 mac-protocol=lldp copy-to-cpu=no redirect-to-cpu=yes mirror=no

This makes sure the CPU gets incoming LLDP for /ip/neighbor book keeping, but restricts any forwarding.

Edit2:
It is further recommended to completly drop ingress LLDP on client access ports to avoid malicious device can mess with LLDP by sending LLDP reports.

[admin@RB5009] /interface/ethernet/switch/rule> add switch=switch1 ports=ether2,ether5,ether6,ether7 mac-protocol=lldp copy-to-cpu=no redirect-to-cpu=no mirror=no new-dst-ports=""

If the rules are added using Winbox, 88cc must be used for mac protocol (ethertype). The protocol name lldp only exists on the CLI.

Without those rules any client directly (or via dumb switch) connetced to l2hw enabled bridge port can send LLDP messages which will be forwarded to all bridge ports on the same VLAN…

2

You are a King !!!

working, but only in CLI
tnx

3

working, but only in CLI

If 88cc is used for mac-protocol, the switch rule can also be set up using Winbox.
The protocoll name lldp (ethertype 0x88cc) is only known on the CLI, not in Winbox.

4

Notice this before. Never would have thought to use the switch interface to fix this. Great idea!

5

Hi, I tried this same rule on a few CRS326-24G-2S+ daisy chained on the SFP ports and it didn’t work, they all keep showing up in the neighbors table.

The diagram is like this:
crs#1 ↔ crs#2 ↔ crs#3 ↔ crs#4

i.e. on crs#4 I see in the neighbors table 1, 2 and 3 even if I apply the rule to all four switches. Same on the other switches I keep seeing lldp info of non-directly connected switches being forwarded.

Here’s the rule:

interface ethernet switch rule add switch=switch1 ports=sfp-sfpplus1,sfp-sfpplus2 mac-protocol=lldp copy-to-cpu=no redirect-to-cpu=yes mirror=no

I’m not sure what’s going on, or if a different type of rule needs to be used on the CRS, very frustrated about this implementation of the discovery protocol. I saw this only on Mikrotiks.

6

I’m not really familiar with the CRS326-24G-2S+, but as far as I understand switch rules should work the same way as on RB5009

ROS supports CDP, LLDP and MNDP for discovery protocols. The switch rule only applies for LLDP, as CDP does not use e special EtherType but a reserved multicast dest MAC (01:00:0c:cc:cc:cc).
If CDP is not required, disabling it in /ip/neighbor/discovery-settings might help. Or as an alternative, try adding a switch rule blocking forwarding for packets with the CDP dest MAC:

interface ethernet switch rule add switch=switch1 ports=sfp-sfpplus1,sfp-sfpplus2 dst-mac-address=01:00:0c:cc:cc:cc copy-to-cpu=no redirect-to-cpu=yes mirror=no
7

I found this flaw in Mikrotik devices too. It seems to be true of all of their switching chips and I think I also saw it in their software bridging. I came up with a different solution.

/interface ethernet switch rule add dst-mac-address=01:80:C2:00:00:0E/FF:FF:FF:FF:FF:FF \
redirect-to-cpu=yes switch=<name of switch chip> ports=<list of all ports on switch chip> \
comment="IEEE 802: Individual LAN Scope group address. NEVER Forward! (LLDP, PTP)"

The above should be repeated on all switch chips in the device. Like the OPs solution, this sends all the restricted traffic to the CPU. Believing the software bridge also has this flaw, I also include the following:

/interface bridge filter add action=drop chain=forward dst-mac-address=01:80:C2:00:00:0E/FF:FF:FF:FF:FF:FF \
comment="IEEE 802: Individual LAN Scope group address. NEVER Forward! (LLDP, PTP)"

This will not restrict the CPU from receiving the LLDP packets but will ensure that the bridge code does not forward them to the other ports.

When I add the “Discovered By” column to the IP/Neighbor List in winbox on a CRS326-24G-2S+RM, I do see devices discovered by LLDP, but I no longer see LLDP listed for devices on the other side of similarly configured routerboxes.

8

Thanks for the feedback!

Software bridge and the majority of HW offloaded bridges do not forward reserved multicast MAC range 01:80:C2:00:00:0X by default (which includes LLDP). This can only happen when you chose to disable RSTP (protocol-mode=none). See the setting description.


The non-forwarding of reserved MAC range is an STP compliance thing. Once you disable the R/M/STP, there is no reason not to forward these packets, they become just a regular multicast traffic. And this kind of ability is important for transparent bridging setups (e.g. extending long links, media converters, network analyzing).

If you still do not want to use RSTP, but also not forward reserved MACs, I can suggest an alternative option. Enable the RSTP, but use “edge=yes” on all bridged ports, which will stop sending and ignore received BPDUs:

/interface bridge port set [find] edge=yes