Community discussions

MikroTik App
 
User avatar
jbl42
Member Candidate
Member Candidate
Topic Author
Posts: 214
Joined: Sun Jun 21, 2020 12:58 pm

RB5009 bridge with l2hw forwards LLDP packets?

Thu Jan 27, 2022 2:36 pm

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...
Last edited by jbl42 on Sun Feb 06, 2022 2:50 pm, edited 4 times in total.
 
User avatar
npeca75
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Thu Aug 03, 2017 3:12 pm

Re: RB5009 bridge with l2hw forwards LLDP packets?

Sat Feb 05, 2022 1:56 pm

[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.
You are a King !!!

working, but only in CLI
tnx
 
User avatar
jbl42
Member Candidate
Member Candidate
Topic Author
Posts: 214
Joined: Sun Jun 21, 2020 12:58 pm

Re: RB5009 bridge with l2hw forwards LLDP packets?

Sun Feb 06, 2022 2:24 pm

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.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: RB5009 bridge with l2hw forwards LLDP packets?

Sun Feb 06, 2022 3:49 pm

[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.
You are a King !!!
Notice this before. Never would have thought to use the switch interface to fix this. Great idea!
 
maxwilloweb
just joined
Posts: 2
Joined: Fri Mar 11, 2022 8:42 pm

Re: RB5009 bridge with l2hw forwards LLDP packets?

Tue Jul 04, 2023 1:00 am

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.
 
User avatar
jbl42
Member Candidate
Member Candidate
Topic Author
Posts: 214
Joined: Sun Jun 21, 2020 12:58 pm

Re: RB5009 bridge with l2hw forwards LLDP packets?

Tue Jul 04, 2023 1:45 am

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
 
RavenWing71
newbie
Posts: 34
Joined: Thu May 12, 2011 3:52 am

Re: RB5009 bridge with l2hw forwards LLDP packets?

Thu Oct 05, 2023 8:52 pm

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.
 
EdPa
MikroTik Support
MikroTik Support
Posts: 274
Joined: Fri Sep 15, 2017 10:05 am
Location: Riga
Contact:

Re: RB5009 bridge with l2hw forwards LLDP packets?

Fri Oct 06, 2023 10:55 am

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

Who is online

Users browsing this forum: No registered users and 19 guests