Hyper-V vSwitches do not work with 2.x drivers on a I225-V

[Elu]

I have a system with an I225-V running driver version 1.1.3.28, with a Hyper-V vSwitch configured against it and multiple management OS vNICs (with both VLAN and not). This works correctly.

When any driver from the 2.x branch is installed, e.g. 2.1.3.15, this fails. The vNICs appear to stop receiving any network traffic (packets received count stops incrementing).

This also occurs with a clean setup without VLANs: even with a basic vSwitch, the default management vNIC does not appear to receive any packets.

NIC: (3) I225-V

Working driver version: 1.1.3.28, any other 1.x

Failing driver versions: 2.1.3.15, any other 2.x (e.g. 2.1.1.7)

OS: Windows 11 22H2 Build 22621.2283

Motherboard: Asus Maximus Z690 Hero

BIOS: 2703 (latest)

Intel ME: 16.1.27.2176 (latest)

[ABCa]

The only difference between the drivers in the WS2022 folder and the drivers in the NDIS68 folder suggested by BY_Intel is ... the readme file!!!

You can do a binary compare on the 4 other files: it is a perfect match.

Regards,

[Richard94]

I'd like to just add that I'm also eagrly awaiting a fix for this issue. Unfortunately it appears the most recent driver updates still haven't resolved it.

I went with Intel on this most recent computer build for stability. It's ridiculous that I've lost the ability to connect to multiple VLANs (through the loss of the PROSet in Win 11 and now a faulty driver that prevents the workaround).

[legacy1]

This still going on?

Is it a Microsoft or Intel problem to support many VLANs with the new driver? 

[Sazirah]

Hi Elu,

Good day.

Regarding your issue, please take note that you are using an ASUS motherboard with an Intel (R) Ethernet Controller I225. You have made the purchase with ASUS instead of Intel. Therefore, if you encounter any issues, ASUS will be your primary contact for support and any assistance. As a user, you should be visit the ASUS website to obtain the correct drivers. Intel has not published any retail drivers (the drivers on the public Intel website) to Windows Update. In fact, ASUS controls all the driver releases and validations. ASUS will have to follow Microsoft policy to publish the driver on Windows Update after they have been validated. Moreover, just because one feature is not working does not mean the entire driver has failed. For example, there may be an issue with the VLAN feature in the 2.x driver, or the Windows NetAdapterCx driver may not be ready. 

Microsoft has introduced a new network protocol driver in Windows 11, as reported in this article https://learn.microsoft.com/en-us/windows-hardware/drivers/netcx/. Following this, Intel has recommended using the NetAdapterCx driver 2.x for devices. However, Microsoft has only implemented the NetAdapterCx driver in Windows 11 Client OS, not Windows Server or any other Windows system. According to a Microsoft article https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/supported-windows-guest-operating-systems-for-hyper-v-on-windows , Windows 11 is one of the versions of Windows client that is currently supported as a guest operating system for Hyper-V on Windows Server. It is still unclear if the Windows 11 NetAdapterCx driver is capable of supporting Hyper-V. Therefore, Intel cannot acknowledge this as an Intel driver bug. User will have to clarify with Microsoft whether the Windows 11 NetAdapterCx driver can support Hyper-V. 

Regards,

Sazzy_Intel

[CGGX]

Hi @Sazirah,

I am not @Elu but I have the same problem, but with the i226-V on a PCI-E adapter (not the motherboard). I can address the 2nd paragraph of your post: I know for a fact that NetAdapterCx does support the Hyper-V + VLAN scenario described in this thread. Because that feature works perfectly with the ethernet adapter from my motherboard, which uses a Realtek RTL8111B chip. Here is the device:

If I follow the driver path and look into the properties of the .sys file, I can see this:

As you can see from the "File description" line, the Realtek driver IS a NetAdapterCx driver. It even has Version 1.x.x.x. When I first use this motherboard, it had a driver version 6.x.x.x, which was NDIS, and a couple of years ago the driver was updated by Windows to this newer one with version 1.0.0.x  (date is DD/MM/YYYY) because it has changed to the NetAdapterCx architecture. And it looks like Realtek has managed to make NetAdapterCx drivers two years ago that fully support the VLAN feature of Hyper-V!

[Elu]

I'm sorry, but could you please read the rest of the thread? This is not an Asus issue. At this point we've had multiple users with different motherboards and PCIe cards with the same issue. There is one user who has tested a PCIe I226-V card. I myself have now tested an I225-V PCIe card in a completely different (Dell-based) system that contains no Asus components whatsoever.

> Intel has not published any retail drivers (the drivers on the public Intel website) to Windows Update.

That is an interesting claim. So the drivers that come down from Windows Update, with the name "Intel - net", are not published by Intel? The drivers that are automatically updated on a non-Asus machine are uploaded by Asus?

> Moreover, just because one feature is not working does not mean the entire driver has failed. For example, there may be an issue with the VLAN feature in the 2.x driver, or the Windows NetAdapterCx driver may not be ready.

We can argue over the definition of failure. Quite clearly, functionality that used to work and comes standard as part of Windows no longer works on the new driver. If the new driver is "not ready", why is it released and recommended by Intel? There is no mention of this loss of functionality in the release notes, which to me means this is not an intentional deprecation.

> However, Microsoft has only implemented the NetAdapterCx driver in Windows 11 Client OS, not Windows Server or any other Windows system.

My current test case has nothing to do with Server. Hyper-V is a fully supported component of Windows 10 and 11 client OS. I am not even using the hypervisor, only as a vSwitch. As others have shown, Realtek has managed to release working NetAdapterCx drivers, so it is clearly not a limitation of the driver framework itself.

To me this seems like a whole lot of deflection. You're trying your hardest to disclaim all responsibility, rather than attempting at all to help the users of your products. Even to the point of ignoring the multiple other messages and evidence of this being a more widespread problem than with the one motherboard I initially used as an example.

[Elu]

Here is an alternative question: which cards do you consider "retail" cards? A I225-T1? Can you guarantee that this card, being a fully Intel-branded retail card, will work correctly with the NetAdapterCx driver and Hyper-V VLANs? If I were to acquire an I226-T1 card, will that be properly supported or will I get more deflection?

I'm perfectly happy to work with you to find a fix. I've provided as much detail as I can. I've already acquired new hardware (the first PCIe card) to perform further testing. But if I keep going down this path, if I get a T1 card to make sure it's fully Intel-branded, will you look into it properly or will you start deflecting me towards Microsoft instead?

Can you see why I've lost trust?

Actually, we were told months ago that this was forwarded to your engineers. Were they unable to reproduce the issue? That would be a much more straightforward answer than what you've provided so far.

[Richard94]

As @Elu has noted, this isn't specific to ASUS motherboards. I'm having the same issue and am using an MSI Z790 Carbon Wifi. The issue is with the chipset/it's driver.

[Elu]

So just some news for anyone else watching this issue, Intel has sent me a survey email indicating that they have closed this issue. I doubt they will make any further reply.

Clearly they care more about arguing over the OEM-ness of the case than actually investigating it at all. Or even telling me which 'retail' product they support (if at all).

If anyone else wants to try their luck or open a new thread, I wish them luck. Maybe post a link here, I'd be interested to see if it actually goes anywhere.

Thanks to everyone else who tried to respond with additional info and evidence. As much as I tried to direct attention to those posts, Intel only seemed interested to respond to me, and my increasing frustration with the refusal to acknowledge the issue probably didn't help.

Honestly, I think the most practical course of action at this point is to avoid all Intel products in the future. Clearly they are entirely uninterested in supporting them properly. We've wasted so much more time arguing over semantics and support itself, than actually addressing or attempting to confirm the issue. If this is the support experience over a NIC, I shudder to think of what it would be like if I ran into a CPU issue, and I'll be taking steps to never find out if possible.

[L_Gk]

I agree with everything you have said.

I think from their point of view, the I225 and I226 are budget/consumer products. If you want VLAN capability, you'd get a enterprise/server NIC. I know this sucks, because it's like they are taking away features.

It's the same problem that we have on the processors. Consumer offerings don't allow for more than 256gb of RAM, neutered PCIe lanes, and lack of registered ECC memory support. Have to upgrade to the Xeon W series to get those features on the desktop.

Just for the people that come here moving forward. I was able to get VLANs working with Hyper-V by forcing the PRO2500 WS2022 driver to install. It's worked for a few months now and I've had no issues with multiple VLANs being tagged.

[Elu]

The WS2022 driver looks to be identical to the NDIS68 driver in the same pack (same descriptor and binaries, it's only the readme that differs). If they hadn't originally pushed the NetAdapterCx drivers via Windows Update, I'd probably not have even noticed this issue.

At this point I'm back on the NDIS driver, which of course currently works. But given they refuse to acknowledge this issue exists, I fully expect either another rogue WUpdate at some point to break things. Or possibly some future W11 version doesn't work with this driver and their official advice will be to use the newer/broken driver. It's why I was so interested in working towards a long-term fix, but it's looking more like the long-term fix is to go buy a Realtek card instead.

Funny thing is, two years ago I would've had the opposite opinion. In fact, I specifically went with Intel over Realtek (it significantly factored into my motherboard choice) initially because they had good VLAN support with ANC, but of course that's gone now.

[cailyera]

Thanks Elu for your efforts. 

I've been reading all the replies to this post since last year. It's a good reminder to avoid Intel at all costs.