Warning before installing CHR 6.42.1 on Hyper-V

Setup:

Windows Hyper-V Server 2016
LACP Network Team through 4 NICs
4 Network adapters (1 untagged, 3 tagged)

After upgrading to 6.42.1 system locks up after couple of hours, WAN (VLAN 2) stays on, LAN (VLAN 1) refuses to communicate, after another hour system loses connectivity completely, IPsec drops completely, routing doesn ´t work anymore.

I suspect this is due to Hyper-V integration services being added.

Had to revert back to 6.41.4

Successfully reproduced on 4 systems, this build is broken, stay away from it.

yes,6.42 there is a serious bug in hyperv. After a period of time, the network is disconnected and resumed after resumption. I have restored snapshot to 6.41.4..

I also encountered the same problem, after win2012r2 hyperv, ros run some time, wan disconnected, lan normal, and finally all disconnected, reboot ros returned to normal. I am having the same problem on multiple servers and I think that 6.42 is not perfect on hyperv (integration service related). I have recovered the snapshot to 6.41.4. Everything works fine.

So it is widespread, thank you guys, filed a support request with supout file

I came here to find if there is some bug, we have had 3 devices already cut off from network. Devices seem to be “pingable” from local network, but reboot solves issue. Also do not know if it is related, but we had 2 devices loose interface data - interface name reverted to default perhaps. (IP addresses detached from interfaces when they lost interface name)

We have interfaces dying on us on Hyper-V since the 6.42.1 update,

Avoid 6.42 on Hyper-V right now.

Any update planned for this issue?

For you that have this issue what guest servies have you activated? Are all activated including Dynamic Memory?
I wonder if this issue goes away if you disable all services including dynamic memory.

No, no dynamic memory.

I had all guest services disabled and still experienced the issue. Leaving all production Hyper-V CHR on 6.40.8 for now which is stable.

Thank you very much for your reports.
Please provide us with support output files, when you are experiencing issues with interfaces on your CHR.
Currently we got some files, but they do not contain enough information for us, so we can work on fix faster.

Hello,

I can confirm 6.40.8 is stable on all but one device I plan to replace today. I will remove it from production and upgrade it to 6.42.1 to try to get more spout files.

I have watchdog enabled and it reboots device whenever it looses connection but for some reason it never sends spout via mail (although it might be due to connection loss-but I have simulated loss of ping with firewall rule and it still rebooted without sending spout in mail)

Completely similar problems :frowning:
CHR on Hyper-V (on VMM SCCM Networks)
Both on firmware 6.42.1 and on firmware 6.42.2.
Only the change of the update channel from current to bugfix has helped.
Firmware 6.40.8 works stably.

When can we expect a correction of the situation?

Any new info from mikrotik? they didnt even replied to me when i sent them the supout

I emailed Mikrotik support a supout file for the issue today, with a lengthy description of our setup. Will see how we go.

Hello - I am writing to confirm that I too seem to be experiencing this issue. I have submitted a support.rif to Mikrotik. Running 6.42.3 CHR

I find if I take any of the following actions: /system restart, Hyper-V shutdown the guest OS, Hyper-V pause then resume the guest OS - network connectivity is then restored. I am running Windows 2012 R2 Datacentre edition on Lenovo RD550 servers with the 4 port Intel I350 Interface adapter on the mezzanine finger interface on the rear of the unit. The interface is going thru a hyper-v virtual swtich, connected with a physical ethernet port on the server.

I have tried enabling MAC spoofing on the guest OS, added VLANs, removed VLANs, etc - trouble persists. I have NOT tried manually deselecting integration services offerings to the guest OS (CHR) at this time. (Customer already super upset!) I have not found a pattern as to what triggers this.

I have this problem on a few servers right now.

Update: Three business days (5 Days) without a human response.

I’m getting the impression that Mikrotik either:
A) Don’t care.
B) Don’t have any idea what the problem is.

RouterOS version 6.43rc23 just have been released. It involves CHR related fixes that might resolve problems mentioned within this topic.

We applied 6.43rc23 to a couple of hAPs and a handful of Hyper-V CHRs in response to advice issued by Mikrotik Support. In all instances, the CHRs ended up even more broken then they were before, failing to detect anything other than a single interface despite several interfaces being present. We tried to debug why this was occurring, but couldn’t figure it out.

I think I preferred the “periodic breaking of interfaces” feature that headlined v6.42, at least I could write a script to resolve that automatically… Could we return?

Oh god, im so glad i didnt upgrade. I have no room to experiment with production devices, yet mikrotik puts head in the sand instead of proper testing and fixing the 6.42 branch.

Staying on 6.41, we’ll see in the following months if we’ll replace these with ciscos, better to have an expensive working product thank cheap nonworking one