bridging with mac-learning turned off

[doneware]

there should be a way to limit the number of mac addresses learnt by a bridge instance. in case of p2p E-VCs (when one bridges an ethernet port/vlan into a eomps [vpls] circuit) there are only two ports in the bridge, so what arrives on one exits on the other, and vice versa. there’s no need for mac learning.
let’s assume a very varying L2 set of src/dst addresses show up in the communication, and the “pipe” device’s bridge host table gets polluted and resource is spent to maintain this states.

if we could limit (disable) mac learning this would be great.

[FIPTech]

Inside version 6.39 there is support for fast-forward (available in the console only).

I suppose that it is mac-learning turned off, and perhaps a couple other optimizations at the code level.

Router OS 6.39 :

• bridge - added support for special and faster case of fastpath called “fast-forward” (available only on bridges with 2 interfaces);
  
  
  [admin@MikroTik] /interface bridge> print
  Flags: X - disabled, R - running
  0 R name=“bridge-test” mtu=auto actual-mtu=1500 l2mtu=65535 arp=enabled arp-timeout=auto mac-address=00:00:00:00:00:00
  protocol-mode=none fast-forward=yes priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s
  forward-delay=15s transmit-hold-count=6 ageing-time=5m

There are new counters for fast-forward as well :

[admin@MikroTik] /interface bridge> settings print
use-ip-firewall: no
use-ip-firewall-for-vlan: no
use-ip-firewall-for-pppoe: no
allow-fast-path: yes
bridge-fast-path-active: yes
bridge-fast-path-packets: 0
bridge-fast-path-bytes: 0
bridge-fast-forward-packets: 0
bridge-fast-forward-bytes: 0

[doneware]

@FIPTech

Inside version 6.39 there is support for fast-forward (available in the console only).
I suppose that it is mac-learning turned off, and perhaps a couple other optimizations at the code level.
Router OS 6.39 :

• bridge - added support for special and faster case of fastpath called “fast-forward” (available only on bridges with 2 interfaces);

oh, i did not notice that! will test it asap. there whouldn’t be no mac addresses on that bridge’s host table.

[FIPTech]

@doneware

@FIPTech

Inside version 6.39 there is support for fast-forward (available in the console only).
I suppose that it is mac-learning turned off, and perhaps a couple other optimizations at the code level.
Router OS 6.39 :

• bridge - added support for special and faster case of fastpath called “fast-forward” (available only on bridges with 2 interfaces);

oh, i did not notice that! will test it asap. there whouldn’t be no mac addresses on that bridge’s host table.

It’s because there is no port inside. I did just create it to show you fast-forward option.

[doneware]

it does learn mac addresses though…

[admin@wapn] /interface bridge> host print 
Flags: L - local, E - external-fdb 
  BRIDGE                                                 MAC-ADDRESS       ON-INTERFACE                                                AGE                 
  fp                                                     00:D0:09:F8:B9:5D eoip1                                                       1s                  
  fp                                                     B8:C7:5D:C7:CE:CA eoip1                                                       16s                 
  fp                                                     FE:1B:3D:19:07:F0 eoip1                                                       19s                 
  fp                                                     FE:47:3B:12:88:29 eoip1                                                       2s                  
L fp                                                     FE:5C:88:24:71:05 eoip1                                                       0s         

[admin@wapn] /interface bridge> export 
# may/12/2017 14:05:20 by RouterOS 6.39
# software id = W7KY-N3IP
#
/interface bridge
add name=fp protocol-mode=none
/interface bridge port
add bridge=fp interface=wlan1
add bridge=fp interface=eoip1

[FIPTech]

In linux bridge using ageing-time=0 disable mac learning.

But the smaller value in Router OS is 10 seconds.

If it would allow 0, we would have mac learning disable capability.

[doneware]

@FIPTech

If it would allow 0, we would have mac learning disable capability.

this is certainly a possibility. i just checked the corresponding code in kernel (net/bridge/br_fdb.c) and it seems to act so.
there’s a function called br_fdb_update and its first check is on whether there’s a topology change, and if not, then what is the ageing value.
if it’s 0, it just returns, e.g. the FDB will not be updated, so all frames will be flooded.

and this is exactly what i want.

so Mikrotik needs to allow ageing to be 0 but only in case there are two interfaces in the bridge. or they could just create a new kind of special bridge, called ‘pipe’.
it could have the following attributes:

• max 2 member ports
• running no protocol
• max ageing = 0 (MAC learning disabled)
• forward delay = 0
• can not have IP address
• does not need mac address (router cannot receive frames through it, not even BC or MC)

it could enslave its members as bridge does, and this way we could separate it from the more advanced “bridge”-s.

[FIPTech]

@doneware

@FIPTech

If it would allow 0, we would have mac learning disable capability.

this is certainly a possibility. i just checked the corresponding code in kernel (net/bridge/br_fdb.c) and it seems to act so.
there’s a function called br_fdb_update and its first check is on whether there’s a topology change, and if not, then what is the ageing value.
if it’s 0, it just returns, e.g. the FDB will not be updated, so all frames will be flooded.

and this is exactly what i want.

so Mikrotik needs to allow ageing to be 0 but only in case there are two interfaces in the bridge. or they could just create a new kind of special bridge, called ‘pipe’.
it could have the following attributes:

• max 2 member ports
• running no protocol
• max ageing = 0 (MAC learning disabled)
• forward delay = 0
• can not have IP address
• does not need mac address (router cannot receive frames through it, not even BC or MC)

it could enslave its members as bridge does, and this way we could separate it from the more advanced “bridge”-s.

Creating a new interface type is certainly a lot more work. I’m not sure Mikrotik do have such free time, they are probably working hard actually on Router OS 7.

Because it is a minor modification to allow ageing-time=0, you could try to send this request to support@mikrotik.com

This would be a console command only anyway, and a console warning could be issued :

“ageing-time=0 will disable mac learning. Are you sure you want to do this ?”

[sup5]

router cannot receive frames through it, not even BC or MC

Especially this feature is important.
When connecting customer sites via VPLS/EoIP our Routers are not affected anymore by a broadcast-storm caused by the customer, if we got such a ‘pipe’ feature.

[doneware]

@FIPTech

[
This would be a console command only anyway, and a console warning could be issued :
“ageing-time=0 will disable mac learning. Are you sure you want to do this ?”

interactive commands with user confirmation suck. cannot be automated properly. of course a system wide “confirm=yes” option would kick-a$$ in other cases, like /system reset-configuration or similar.

all in all the “pipe” feature would require a major change, a totally new device i guess to avoid messing with BC and MC with the existing bridge device.
if it comes down to mac-learning=0, honestly i guess this is the only place it makes sense, when you only have 2 interfaces in a “bridge”. but in a different implementation a very optimised code can be created that doesn’t look for other “bridge member” interfaces, just blindly copies the frame received on one end to the other end. as far as i know, bridge’s “use ip firewall” setting is a global one, so it would have unnecessary load on “pipes” whether you want it or not.
for me this is another reason to have it implemented differently.

there is just one thing that i guess we could leave up to the user: whether the mndp/cdp packets shall be processed by the router (e.g. reveal the router in “pipe-mode” to the far ends) or just transmit those frames w/o special treatment.

[FIPTech]

@doneware

@FIPTech

[
This would be a console command only anyway, and a console warning could be issued :
“ageing-time=0 will disable mac learning. Are you sure you want to do this ?”

interactive commands with user confirmation suck. cannot be automated properly. of course a system wide “confirm=yes” option would kick-a$$ in other cases, like /system reset-configuration or similar.

all in all the “pipe” feature would require a major change, a totally new device i guess to avoid messing with BC and MC with the existing bridge device.
if it comes down to mac-learning=0, honestly i guess this is the only place it makes sense, when you only have 2 interfaces in a “bridge”. but in a different implementation a very optimised code can be created that doesn’t look for other “bridge member” interfaces, just blindly copies the frame received on one end to the other end. as far as i know, bridge’s “use ip firewall” setting is a global one, so it would have unnecessary load on “pipes” whether you want it or not.
for me this is another reason to have it implemented differently.

there is just one thing that i guess we could leave up to the user: whether the mndp/cdp packets shall be processed by the router (e.g. reveal the router in “pipe-mode” to the far ends) or just transmit those frames w/o special treatment.

Some frames should not be relayed through a bridge regardless it is a pipe or a normal bridge.

For example if mac destination is 01-80-C2-00-00-00 to 01-80-C2-00-00-0F. (Ethernet OAM, STP, pause frame, LLDP…)