I have an aggregation use case where I need as low level bridging as possible.
Here’s a picture:
<third party 802.1br port extender> — mikrotik crs504 — mikrotik crs504 — <third party 802.1br controlling bridge>
There is a 1:1 mapping of source/destination interfaces on the mikrotiks, so each frame coming in interface A would exit interface B and vice versa. So I plan to use port isolation and the forwarding-override option to configure those links explicitly. With this setup, will all frames, regardless of content, be appropriately forwarded by the switch? I’m specifically thinking about frames with:
- BPDUs
- 802.1br headers
- a multicast destination like EAPoL that’s typically handled by the switch
- a MACsec SecTag (ethertype 0x88E5)
etc. etc.
Any experiences to share?
I’m sure you’ve all been at the edge of your seats with this one!
Documenting this here for posterity:
I got the port extender / controlling bridge working with the MikroTiks in the middle, with this setup:
/interface bridge
add arp=disabled forward-reserved-addresses=yes name=bridge protocol-mode=none
/ipv6 settings
set disable-ipv6=yes
/ip neighbor discovery-settings
set discover-interface-list=lldp_interfaces
/interface ethernet switch rule
add comment="one way" new-dst-ports=qsfp28-1-1 ports=qsfp28-2-1 switch=switch1
add comment="another way" new-dst-ports=qsfp28-2-1 ports=qsfp28-1-1 switch=switch1
Even my initial try was mostly correct, what took me the longest time to debug was the need to disable LLDP on the affected interfaces (because the 802.1br gear panicked when it saw unknown LLDP packets on the wire when it thought it had a dedicated link). I disabled IPv6 too for similar reasons, to avoid the multicast traffic on the interfaces.
If you enable VLAN filtering on the bridge you get better facilities for isolating the CPU from the bridge, but I thought this setup was clearer than that (the 802.1br stuff probably skips the filtering since the e-tag is where the VLAN tag would be, but I didn’t want to rely on that). So having a facility for specifying a hardware bridge without VLAN filtering AND without any CPU participation would be great for these pseudo-L1 bridging cases.
A clear diagram showing the precedence order of VLAN filtering, switch rules, switch port isolation and neighbor discovery would have been very, very useful in setting this up too. As it is, I had to guess which processing would happen first, whether the switch rules would override VLAN filtering, etc. Also if MikroTik supported egress switch rules the setup would’ve been clearer (in terms of not needing the separate LLDP / IPv6 config).
@markonnen,
As it is, I had to guess which processing would happen first, whether the switch rules would override VLAN filtering, etc.
such a thorough observation. beautiful 
I’m just reading your posts partially, so please excuse me if i might missed something.
as far as logic concerned,
everything should start with plain vanilla processing first. which is bridging ingress process - because any dot1 was built on top of it. including vlan stp port security etc.
why?
as simple as you just don’t know what to read if there is nothing written on the paper.
Right, I think this documentation does exist for the general bridging case, but not for the hardware switch implementation which I rely on here.
Well, it does not have the sort of diagram that I asked for and it doesn’t apply to the devices I’m using (CRS504). So no.