After live migration the CHR router to another cluster node, I've noticed network connection to the router drops randomly. After that, if I logon to the router console directly from hypervisor host and send one ping from router to any address on problem VLAN, all becames fine again in that VLAN up to next migration.

Investigating the issue, I've noticed that CHR doesn't notify the switch upon migration completion, and switch doesn't update its MAC database. Therefore, the switch continues to send packets to the port where router was before migration.

To fix this issue I think that CHR must send gratuitous ARP to all connected VLANs after migation, this helps the switch to update its MAC database in a timely manner.

What type of network adapter's do you use on the CHR? "Normal" or Legacy?

Is the CHR connected to a Hyper-V switch? If so I thought that the switch in the machine you migrate to would see a new mac and handle all ARP parts. The CHR should not really know it's been moved.
I must add I need to read up on this if the migration end up on another switch.
O and also is this a cluster or not?

What type of network adapter's do you use on the CHR? "Normal" or Legacy?

I'm using synthetic NIC.

Is the CHR connected to a Hyper-V switch? If so I thought that the switch in the machine you migrate to would see a new mac and handle all ARP parts. The CHR should not really know it's been moved.

CHR connected to virtual switch, and virtual switch connected to real switch via dedicated NIC.

O and also is this a cluster or not?

Yes, it's a cluster. Migration was performed between cluster nodes. All nodes connected to same switch.

I remember there was similar issue in early builds of Linux integration components (about two years ago or so), and was fixed by sending gratuitous ARP after completing migration.

My guess is this is because integration tools which are with the current Linux kernel in ROS is not up to date.
I was at a session a long time ago on a Microsoft event and they talked about this issue for Linux. If my memory serves me right I think this was due to poor network drivers for the Hyper-V OS itself. Was especially true to Broadcom drivers on Hyper-V. I can’t test this myself, as I don't have a cluster, but a recommendation was to turn of Virtual Machine Queue off. You could start on the machine itself and also disable IPSec offload. If this does not help also test to disable this on the network card itself. Found a link regarding disabling both parts. Note that when you disable Virtual Machine Queue on the Hyper-V server Network card it will lose network connectivity for a while.
http://alexappleton.net/post/7711675515 ... ng-network

Before this you should however try to update the network drivers for the Hyper-V server.
You may already have tested all this and in this case all I wrote is useless

Kindis, thanks for your suggestions, but I've already tried almost of them. There are about 80 VMs in cluster, with differens OSes, including Windows and Linux, and migration issue happens to CHR only