So it looks like someone has gotten wise to Mikrotik's having bandwidth-test enabled by default and pretty much every public IP-facing Mikrotik we have has logs looking like this now: https://i.imgur.com/mpH1dXu.png Upside: Getting more targeted attacks against Mikrotiks means they're becoming just ...

Still can't turn off flooding options on dynamic bridge members
Should be an option to blanket deny or blanket accept for a given bridge, then allow static port settings to override.

With the Unknown Unicast/Multicast Flood disable button being added in to the bridgeports, is there a way we can get that added to PPP profiles similar to bridge/bridge priority/cost/horizon? OR have a bridge-wide default option for it to be either on or off? I'd rather it DIDN'T default to "on...

What's new in 6.42rc39 (2018-Mar-07 07:01): *) bridge - added per-port forwarding options for broadcasts, unknown-multicasts and unknown-unicasts; *) bridge - added per-port learning options; *) bridge - added support for static hosts; *) bridge - fixed reliability on software bridges when used on ...

Is IGMP snooping fixed in rc24 or in 6.41.2?

Got yelled at last time so I've left it off for now

Response to my ticket to support@ is that they plan on addressing it in 6.42 eventually, but it doesn't look like it's been touched yet

NetflashTechnical - Please generate supout file on your router while you see such behavior and send this file to support@mikrotik.com

Done! In fact, several supouts attached to it even

Ticket#2018020522004918

Issue of flooding all bridge ports with IGMP Snooping on stream change (ie channel surfing, flood lasts about 1-2 sec) or interface removal (ie dynamic interface leaves bridge, flood lasts 60+ sec) still exists on this version. How to easily replicate: Method a) Put multiple interfaces on the IGMP-S...

In normal operation IGMP snooping blocks traffics if equipment didn't get IGMP join or report through the interface. In my opinion Mikrotik only blocks if it's in the MDB table.

100% Spot On what I'm thinking as well!

Issue persists in 6.41 final. Also tried with a CRS226-24G-2S+RM, same problem when using hardware offloading. Basically makes Mikrotiks useless for IGMP snooping, if someone flips channels too rapidly I can saturate every 1G interface on the switch in a matter of seconds. :| EDIT: I think I've got ...

Ohhh, good to know! It might be related to which CPU/chipset is doing the snoopin' because the 2011's use mipsbe... or at least the specific implementation of it for that chipset. Were you doing hardware offloading for the bridge on your CRS? I see the same problem on a CRS-125-1S-2HnD using 6.41 rc...

Update: Issue persists on 6.41rc56

Nadda?

Better question then: Is immediate leave implemented? I think that might solve this issue... maybe?

I've run into an interesting issue with IGMP Snooping while testing on a 6.41rc52 bridge. It looks like when someone is channel surfing or when a port suddenly drops from the bridge, it then floods that stream to all channels for anywhere between 2 and 20 seconds. this can get excessive really quick...

Ok, LNS Support! Does that include LAC support? It'd be nice to aggregate all our line edge routers to central powerhouse routers for PPPoE, and ideally if we can do separate domains it would let us set up a reseller network through our infrastructure!

I want our Mikrotik line edge routers to connect customer PPPoE requests back to our primary Cisco LNS (which is a massive powerhouse of a router) for PPPoE termination, ie LAC mode. I'm going to give it a test next week, but in the meantime does anyone else have LAC connectivity outbound working?