v6.41 [current]

I am currently running 6.38 and don’t have any issues. I am a little concerned over the 6.41 upgrade.
Has anyone else gone from 6.38 (or earlier) to 6.41 and if so, was it smooth sailing?

Hello, after upgrade 6.40.5 → 6.41 on hAP ac IPIP6 tunel interfaces not running. Reset configuration doesn’t help.

You’re right, the actual issue appears to be that RouterOS does not appear to process or honor ICMP ‘fragmentation needed’ messages. The following capture is on a MPLS speaking 6.41 RouterOS device where MPLS switched packets are not captured and subsequently only shows incoming packets which use Penultimate Hop Popping (PHP):

The above is to validate that ICMP messages arrive correctly at 41.79.22.34. Herewith a packet capture on the MPLS ingress point, showing 41.79.22.34 continuing to send packets with a payload of 1312 bytes after it receives ICMP ‘fragmentation needed’ messages which indicate that the maximum MTU is 1348 bytes (-40 bytes = 1308 payload):




Hello, I’ve got another issue. After upgrade from v6.40.5 to v6.41 my DUDE server (running on RB1100Dx4) reporting cpu,disk and memory services down on all MK devices. Pls anybody can help me?
Thnx
Jarda

Flag,Time,Message
,Jan/01 22:15:06,syslog: Service disk on CHO51VKAP2 - 172.27.220.251 is now down (down)
,Jan/01 22:15:06,Service disk on CHO51VKAP2 - 172.27.220.251 is now down (down)
,Jan/01 22:15:07,syslog: Service memory on CHO51VKAP2 - 172.27.220.251 is now down (down)
,Jan/01 22:15:07,Service memory on CHO51VKAP2 - 172.27.220.251 is now down (down)
,Jan/01 22:15:23,syslog: Service cpu on CHO51VKAP2 - 172.27.220.251 is now down (down)
,Jan/01 22:15:23,Service cpu on CHO51VKAP2 - 172.27.220.251 is now down (down)
,Jan/01 22:16:37,syslog: Service disk on 172.27.220.253 is now up ()
,Jan/01 22:16:37,Service disk on 172.27.220.253 is now up ()
,Jan/01 22:16:37,syslog: Service disk on MK router - 172.27.220.4 is now down (down)
,Jan/01 22:16:37,Service disk on MK router - 172.27.220.4 is now down (down)
,Jan/01 22:16:40,syslog: Service disk on 172.27.220.254 is now up ()
,Jan/01 22:16:40,Service disk on 172.27.220.254 is now up ()
,Jan/01 22:16:42,syslog: Service memory on CHO51VKAP1 - 172.27.220.250 is now down (down)
,Jan/01 22:16:42,Service memory on CHO51VKAP1 - 172.27.220.250 is now down (down)
,Jan/01 22:16:50,syslog: Service memory on 172.27.220.253 is now up ()
,Jan/01 22:16:50,Service memory on 172.27.220.253 is now up ()
,Jan/01 22:19:07,syslog: Service cpu on 172.27.220.254 is now down (down)
,Jan/01 22:19:07,Service cpu on 172.27.220.254 is now down (down)
,Jan/01 22:19:10,syslog: Service disk on 172.27.220.254 is now down (down)
,Jan/01 22:19:10,Service disk on 172.27.220.254 is now down (down)
,Jan/01 22:19:50,syslog: Service memory on 172.27.220.253 is now down (down)
,Jan/01 22:19:50,Service memory on 172.27.220.253 is now down (down)

Probably known problem with discovery - do any from listed below:

Or check firewall rules - may be migrating wasn’t smooth and packets blocked by default rules…

In order to keep this 6.41 version topic as clean as possible, please before posting a question or problem report, check 6.42rc version changelog. In most cases problems are already resolved:

Note that rc version topic first post is a changelog of first rc version released. Later updates are posted further into topic:
http://forum.mikrotik.com/t/v6-42rc-release-candidate-is-released/115077/1
http://forum.mikrotik.com/t/v6-42rc-release-candidate-is-released/115077/1

That would be correct, it is not the task of the router to act upon these messages, it is the responsibility of the end system to do so. It should only process those messages when they refer to traffic originated from the router itself.
Of course the router must forward the ICMP messages to the correct end system, this is often a problem with tunneling protocols and with too many “Gibson paranoia” firewalls inbetween.

Hi,

I noticed after upgrading to v6.41 that ether3 & ether5 were showing the exact same TX throughput all the time, I checked bridge settings and played around to see if there was a configuration issue from the upgrade, a saw that ether3’s “auto isolate” was disabled, I reenabled it and as soon as I did, I lost all access from any port on the bridge interface, only discovery was working, couldn’t even login via winbox mac. After rebooting the router, everything came back up fine??

Whats this about? Bug?

Hey soonwai! So thanks to you, I was able to config my RB750Gr3 :slight_smile:

I checked and vlan-filtering = yes
at momet everything is ok.
I do not know if it was supposed to work on both bridge to do vlan-filtering

There is a difference between the above example and the new tagging / untagging settings
https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#VLAN_Example_.231_.28Trunk_and_Access_Ports.29

Thanks!

Unfortunately this problem is not mentioned at 6.42rc topic and 6.42rc5 did not resolve my problem. Dude is still getting information about cpu,memory and disk overloading.

jardap - have you reported this to support@mikrotik.com with problem description and supout files?

Just in the process of downgrading back to 6.40.5…

On the RB2011 it doesn’t appear possible to create a working bridge (hw offload) config as efficient as the previous software revision, where we could use switch hardware offload on both the 1000M ports and 100M ports - then bridge those switches together with the SFP port.
The additional complexity is that I had a vlan trunk port on the 1000M switch (Business + Guest vlan wifi) - as well as the other untagged (business) ports. The initial 6.41 configuration I had appeared to be working, but with NO hardware offload, and things traversing the 1000M switch (e.g. ping) appeared to get 3x extra duplicate packets received.

hello,

have a problem with this release.

we have two CRS-326 connected together through 4 ether ports, both have same configuration:

4 connecting ether ports are bound into a bonding
that bonding is part of a bridge

before upgrade (6.40.5), everything worked fine.
but after upgrade to 6.41, both CRSs start throw “bridge port received packet with own address as source address” error and both freeze up (because of packet storm).

what is wrong? how can i fix it?

kor3k

https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#IGMP_Snooping

Reading Wiki and reading Questions here on the Forum. As there is no version setting for IGMP snooping I assume it’s on IGMPv2? or is it IGMPv3? It can’t be IGMPv1 still?

As you se the Confusion is obvious and there is a ton of other stuff to think about when talking multicast that is not obvious at first.

You have two routes/interfaces for packets received by this bridge.
I have noticed something similar configuring CAPSMAN with CAP’s device WiFi interface assigned staticaly to “locally-forwarded” CAP’s bridge in CAP device and virtually created in CAPSMAN and included in CAPSMAN’s bridge.

thanks for pointing this out.

actually, we are using capsman in our network.
and i think in the same setup as you describe.

each CAP’s wlan is “locally-forwarded” into CAP’s bridge, but each wlan also has 2 VirtualAPs, which are “capsman-forwarded” into CAPSMAN’s bridge.
and these two CRS-326 with bonding are in the middle of the network (backbone switches), but they are not caps managers.
the whole network is bridged.

how did you solve the issue? do you know why this is happening? seems like a bug to me.

Seeing that I am connecting to this router, it would subsequently confirm that RouterOS does not honour ICMP fragmentation needed messages.

ie: I connect via Winbox or SSH (port 2200), initial packets go back and forth until a payload exceeds the remote VPN MTU. ICMP ‘fragmentation needed’ message is received by RouterOS, which contains maximum MTU, so RouterOS should fragment at that boundary, instead of continuing with original MSS received during TCP establishment…

Could you please disable HW offloading when bridge filter rules are added?

The problem is that they’re incompatible with each other (at least it seems that way). I just bought a hEX, set it to bridge mode (which enables HW offloading for all those ports, because the hEX board supports it) and then added a filter that drops UDP packets to port 67 & 68 (DHCP).

The counters for the filter increase, but they have zero effect. All those packets are still forwarded, regardless of chain. Disabling HW offloading and leaving only rules for the forward chain has the desired effect.

I’m using all ports on my RB2011 as a switch with vlans (tagged and untagged) and am getting HW offloading and not seeing any duplicate packets. I posted my config in this thread: http://forum.mikrotik.com/t/6-41-and-vlans-what-is-the-proper-an-most-performant-way-to-do-that-now/115100/2

This is for mikrotik, you disappointed me with your product and updates, i have problems with flapping eth, your updates worse my problem, is not for my cable connection, your product sucks, i don’t buy ever again your product.
I tell you friends, don’t go in roads with mikrotik. Good luck.