I have updated the following boards to 6.41 RB750GR3, RB960PGS, RB3011 and CRS112-8G. All of them were successfully provisioned to this new version with no issues. Specially for the CRS112 I noticed a huge improvement in the throughput speed as a simple switch (no IP.Firewall), with 6.40.5 I usually got ±400Mbps, once the update to 6.41 now the clients can reach ±850Mbps as a bridge, hw offload, IGMP Snooping and Fast Forward. Certainly for my application, this update is working brilliant.
Hi Guys,
After update to 6.41 Router OS I have a problem with EoIP tunnel. On PH2 State it shows - no phase 2 - status.
Is any ideas how to fix it?
Could anybody from Mikrotik explain more this fix ? From which version it is broken and which network-type are afected ? Thanks.
It appears that running both a L2TP and an OVPN server is impossible on a HAP ac
When enabling OVPN established L2TP sessions are getting kicked out and new sessions are failing to establish. It looks like enabling OVPN just shuts down or filters out L2TP trafic
Can someone explain why eoip interface has a l2mtu setting of 65535 in this version and not changeble.
If I do bridging it is this value that is the max l2 recieved right? and it sould after adding headers fragment if outgoing interface after routelookup has a smaller ip mtu?
I was with version 6.39.3 in a ccr 1036 working as PPPOE server, all correct, I update to version 6.41 and I have problems with access to some ftp sites, among them ftp://200.47.24.13/, I return to the version 6.39.3 again and the problem disappears.-
version 6.40.5 also have problems MTU and packets bigger than 1400 bytes lost a lot, 6.39.9 work ok
HAP AC Lite upgrade 6.41 cannot be started.
Usr lights are always bright.
How to fix it?
You can try Netinstall to reinstall RouterOS:
Then there’s the third possibility, which was a hybrid one: use switch chip VLAN functionality for ethernet ports and CPU functionality for adding other interfaces (e.g. WLAN with VLAN tags such as virtual AP) or other switch chips. And you don’t have to create multiple bridges, one is enough.
My observation is that CPU bridge is VLAN-transparent. If you want to do something specific to a particular VLAN, you have to create a VLAN virtual interface and then do whatever needs to be done using that particular VLAN virtual interface. E.g. if you want to route between two different VLANs, you create two VLAN virtual devices, one for each VLAN. They both belong to “the” bridge. Then you bind different IP addresses to each VLAN virtual device and then you can do the routing between the two interfaces.
However, if you want to switch traffic between e.g. WLAN with VLAN id 42 and ethernet with VLAN id 42, you don’t need to do anything apart from having WLAN interface and “switch CPU” port belong to same (CPU) bridge.
I don’t have any RB with more than one switch chip, but I guess this is the optimum way of spanning all of the ethernet ports: let switch chip deal with traffic between ports belonging to the same switch chip and have single bridge, spanning all “switch cpu” ports. From switch chip point of view, this CPU bridge appears to be normal ethernet port connecting it to some virtual switch (implemented in SW). One just needs to be careful about VLAN setup of these ports. Bridging without (many) rules should not bog down CPU too much, at least that’s what MikroTik wants to show with test results - I’m just not sure how the “brigding - fast path” results compare to switch chip performance on the same hardware.
It would be good to know if anything changed in 6.41 with regard to switch/bridge functionality.
The disadvantage of that method is that it allows VLAN communication of any VLAN id between those ports. You cannot easily forward one VLAN and disallow another.
When some security is desired, it is better to explicitly bridge the wanted VLAN subinterfaces.
Huh?..
/interface bridge
add name=bridge1 vlan-filtering=yes
add name=bridge2 vlan-filtering=yes
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge2 interface=ether2
/interface bridge vlan
add bridge=bridge1 tagged=ether1 vlan-ids=10
add bridge=bridge2 tagged=ether2 vlan-ids=10
@Chupaka,
my experience shows that for the last part,
/interface bridge vlan
add bridge=bridge1 tagged=ether1,bridge1 vlan-ids=10
add bridge=bridge2 tagged=ether2,bridge2 vlan-ids=10
is necessary. Without the bridge itself being listed as a tagged member of the VLAN, some things did not work for me, so I looked at the manual page and example #3 was showing this (unlike the other two). I was not the only one to bump into this, but I have no explanation why this is necessary. And if it is necessary only in particular cases, why.
I have similar (bad) experience with the new bridge and VLAN tagging. The first attempt to convert my initial multi-bridge setup to a single bridge with VLAN tags failed.
I reverted to my pre-6.41 configuration (separate bridge for each VLAN and switch configured for the VLANs and tagged/untagged ports) and have to try again some time.
@sindy, yep, if you need those VLANs locally. It was just a short example of possible way 
if you need those VLANs locally
Can you elaborate? It sounds as if the VLAN wouldn’t reach the CPU if the bridge itself is not stated among member interfaces, but in such case, if you have a dual-switch machine and you assign ports from both switches to the same bridge, wouldn’t you have to do the same even if you don’t need to access the VLAN locally, just want it to flow between ports of different switches?
The second point is what the difference in CPU load is whether you list the bridge itself among VLAN members or not. If it is none or negligible if you do list it but don’t actually access the VLAN locally, why this setting has been put to configuration at all?
I have the same experience. After the upgrade, no connection via ethernet or wifi works. Wifi is off. Winbox cannot show it. I asked another RB on the LAN which properly upgraded to show its neighbours, and the dead RB is listed with a MAC address of 00:00:00:00:00:00. The dead device is up in the air, been operating for a few years, and properly installed to protect it from rain and weather. It will not be fun to replace. It will not be fun to hit a reset button. Any ideas will be appreciated.
I just wanted to point that if you don’t need to send packets to the router itself, you may use something like this for isolating two VLANs with the same VlanID:
/interface bridge
add name=bridge1 vlan-filtering=yes
add name=bridge2 vlan-filtering=yes
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge2 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge2 interface=ether4
/interface bridge vlan
add bridge=bridge1 tagged=ether1,ether3 vlan-ids=10
add bridge=bridge2 tagged=ether2,ether4 vlan-ids=10
As for adding ports from different switches (where software switching is needed) - I think, the router itself should decide and automatically add bridge to the list (or kind of that), because user don’t have to know exact hardware implementation, so he shouldn’t guess why something is not working.
P.S. I haven’t tested anything above, just my thoughts 
Switch chip sees all VLANs employed by member ethernet ports and switch administrator has to configure VLANs per port properly. It doesn’t matter if some additional VLAN comes from another switch via bridge (=switch cpu port).
In addition to that, traditionaly you had to define which VLANs do pass through switch cpu port and you can restrict some VLANs from “escaping” out of a particular switch chip if so desired.
I’m not sure if this part is different in 6.41 or not, my VLAN-infested RBs are still on 6.40.5.
pppoe client dont open after update.
We are seeing a strange problem with 6.41 in the fact that it prevents one particular HTTPS website from being accessable. This is the case if either 6.41 is running on the PPP server/router or indeed if 6.41 is running on the client’s Mikrotik router.
The website in question is https://safeseas.ie/ssi/login.jsp and we have replicated the problem on many iterations of 6.41 across multiple sites. In each case rolling back fixes the issue.
Feedback would be welcome