Tagged (VLAN ID 0 or 1) multicast traffic (IEC61850 GOOSE) is dropped on Hyper-V Internal swich or Network Adapter

Question

I am creating industrial demo (some sort of substation imitation) in Hyper-V on Azure server.
Host OS - Windows Server 2016.
Several guest VMs (mostly Windows7) are connected by internal only virtual switch - flat network, most MACs and all IPs configured manually.

One of VMs generate IEC 61850-8-1 GOOSE (generic object oriented substation event) traffic on one of its NICs and should receive it on another (different MAC\IP connected to same V-switch). In addition, I need this traffic to be received by other VMs.
GOOSE is multicast and this previosly never caused problems - all demo works well on other virtualization platforms. (But now I need it in Hyper-V on Azure.)
Also according to IEC 61850 standard all GOOSE packets are always tagged (by default with tag 0, but can be any other tag values) - this is used for prioritization in real switches.

The problem is that GOOSE does not reach the destination. Other unicast and multicast traffic from same NICs is OK, but not GOOSE.
With Wireshark I see GOOSE outgoing traffic on VM NICs, but no one VM in my network recieve this packets.
I assume that Hyper-V virtual switch for some reason drops tagged and at the same time multicast traffic.
I already some options and most of its combinations - nothing help:

1. enabling MAC address spoofing
2. changing NIC from standart Network Adapters to Legacy Network Adapters
3. configuring VLANs on the V-switch
4. switching VM NICs into trunk mode with Power Shell
5. changing the GOOSE tag from default 0 to 1

Can someone explain how to solve this in Hyper-V and what could be the reason of GOOSE packets loss?

Answer 1

Hello

Thank you for your question and reaching out.

I would start by checking if you have Broadcom or QLogic network cards and if you do, check if the VM Queue is enabled. if it is disable it and check the latency again.

Also please try to update drivers of your NIC cards.

Disable TCP Offloading for the Virtual Machine Network Cards.

Please ensure current MTU or Jumbo Frames on the host NIC card setting should be same.

IF you have NIC teaming try to remove it and use Physical NIC card.

---

--If the reply is helpful, please Upvote and Accept as answer--

Answer 2

Hello, @Limitless Technology

Thanks for the advice.
I have two types of NICs available in Guest VM (shown on screenshot), in Hyper-V settings they are "Network adapter" and "Legacy Network Adapter", drivers are installed automatically. I could not find if they are Broadcom or QLogic - looks like both are some sort of Emulation from Microsoft.
As I mentioned above, my Hyper-V host is an Azure VM itself, so on host I also have only Hyper-V Virtual Ethernet Adapters.

I'll try to Disable TCP Offloading and inform you about the result. But I doubt - GOOSE is layer below then TCP.
Also I'll try to find out if there is any possibility to update my Guest VM NIC drivers.

Answer 3

Finally I've found time to publish the rezult from Microsoft support.
After several rounds of investigation it was found that:

"The problem is VLAN information in injected packet, either from WinPCAP NDIS 5.X or NPCAP NDIS 6.X, are not stored in the OOB (Out of band) storage called NET_BUFFER_LIST_INFO for NDIS 6.X and called _NDIS_PER_PACKET_INFO prior.
WinPCAP (NPF) and NPCAP, are not compatible with VMSwitch.sys, and furthermore violating NDIS contract regarding VLAN"

Shortly that means that Hyper V virtual switch does not support any tagged traffic generated with WinPCAP or NPCAP, and drops such packets. The only possible way to overcome the problem is to generate packets with Win API.