Community discussions

MUM Europe 2020
 
User avatar
Hotz1
Member
Member
Topic Author
Posts: 391
Joined: Tue Oct 09, 2007 6:55 am

vlan-filtering=no is NOT the same as pre-6.41

Sat Mar 17, 2018 2:50 am

Part of our standard router configuration in a MUD involves bridging some Ethernet ports, then defining several VLANs on that bridge. Through 6.40.x, it works fine with all our equipment: other RouterBoards, as well as Ubiquiti EdgeSwitches and Dell 5324 switches.

As soon as we upgrade a router to 6.41 or beyond, any Dell 5324s connected to it stop responding or passing traffic, until we downgrade the router to 6.40.x.

How (and why?!) has the behavior of VLANs on bridges in 6.41.x (with vlan-filtering=no) changed from their behavior pre-6.41, that would cause problems with this particular type of device but no others? Does this mean we have no choice but to replace all our Dell 5324s, or to re-implement our configuration at every site to use the new VLAN filtering functionality?

I had kind of hoped that leaving the new feature disabled wouldn't break anything.
Principal, Engineering
Cape Ann Communications, Inc.
Gloucester, MA, USA
 
skuykend
Member Candidate
Member Candidate
Posts: 270
Joined: Tue Oct 06, 2015 7:28 am

Re: vlan-filtering=no is NOT the same as pre-6.41

Sat Mar 17, 2018 4:26 am

Sounds like it may be an issue with changes in STP in the new bridge implementation, what settings are you using on the MikroTik and Dell's for STP?
 
User avatar
Hotz1
Member
Member
Topic Author
Posts: 391
Joined: Tue Oct 09, 2007 6:55 am

Re: vlan-filtering=no is NOT the same as pre-6.41

Sat Mar 17, 2018 5:40 am

Sounds like it may be an issue with changes in STP in the new bridge implementation, what settings are you using on the MikroTik and Dell's for STP?
We're using RSTP on all of the above, basically default settings, worked for years. It looks like we need to switch to MSTP on the Mikrotiks. TBD how MSTP will get along with the Dell 5324s' 2011-vintage RSTP implementation.

We decided to upgrade from 6.40 to 6.41 now rather than later in response to the buffer overflow vulnerability that was recently announced. I'm not especially thrilled that I first have to work out a number of configuration changes that risk taking remote equipment offline or flood their networks with packets. Maybe they'll back-port the fix to the 6.40.x stream, so I can fix the security issue now, and work out our new bridge/VLAN settings when things aren't so urgent? :-/
Principal, Engineering
Cape Ann Communications, Inc.
Gloucester, MA, USA
 
mkx
Forum Guru
Forum Guru
Posts: 3353
Joined: Thu Mar 03, 2016 10:23 pm

Re: vlan-filtering=no is NOT the same as pre-6.41

Sat Mar 17, 2018 9:53 am

We decided to upgrade from 6.40 to 6.41 now rather than later in response to the buffer overflow vulnerability that was recently announced.
Do you actually have SMB service enabled on your routers? As far as I understand RB vulnerability only exists if this is enabled. If it's not, then "vulnerable" ROS versions are safe.
BR,
Metod
 
User avatar
Hotz1
Member
Member
Topic Author
Posts: 391
Joined: Tue Oct 09, 2007 6:55 am

Re: vlan-filtering=no is NOT the same as pre-6.41

Sat Mar 17, 2018 5:47 pm

We decided to upgrade from 6.40 to 6.41 now rather than later in response to the buffer overflow vulnerability that was recently announced.
Do you actually have SMB service enabled on your routers? As far as I understand RB vulnerability only exists if this is enabled. If it's not, then "vulnerable" ROS versions are safe.
We don't. From the scattered information that I have found, it is said the vulnerability "uses SMB", but it was unclear whether that means the exploit only works if SMB is enabled, or if it works even when the service is disabled. If this vulnerability depends on SMB being enabled, then it's a non-issue for us--but it would have been good to know that yesterday, when the articles and warnings started appearing.

This is why I agree with the calls for MT to create a forum specifically for security. Mikrotik users should be able to go to one place to get clear, authoritative information from MT and experienced users, rather than spend hours scouring the web for articles written by people who may have never touched a MT product, and trying to piece together which information is accurate and which is misleading.

So, my concern about the new bridge implementation not working with some third-party products and not others still stands, but at least I don't have to fix that today.
Principal, Engineering
Cape Ann Communications, Inc.
Gloucester, MA, USA

Who is online

Users browsing this forum: No registered users and 18 guests